Hello again On second thought, removing is too general. But it's still very much broken. Is there any reason why this was not merged? https://lore.kernel.org/all/c5e8ab50-aacb-4651-8893-a6dd9edcd155@xxxxxxxxxxxxxxxx/T/ Any thoughts on how this should be handled? Best regards Einar Jón On Tue, 18 Feb 2025 at 13:45, Einar Jón <tolvupostur@xxxxxxxxx> wrote: > > Hello again > > On second thought, removing is too general. > But it's still very much broken. Is there any reason why this was not merged? > https://lore.kernel.org/all/c5e8ab50-aacb-4651-8893-a6dd9edcd155@xxxxxxxxxxxxxxxx/T/ > > Any thoughts on how this should be handled? > > Best regards > Einar Jón > > On Tue, 18 Feb 2025 at 12:12, Einar Jon Gunnarsson <tolvupostur@xxxxxxxxx> wrote: >> >> The check for BITS_PER_LONG == 32 makes no sense after calling >> tv64.tv_sec = rtc_tm_to_time64(&tm); >> >> With this check, any 32-bit system will silently return an -ERANGE error >> instead of setting the correct time if the hardware clock is storing a >> date after Y2K38 (2038-01-19). >> Without this check they should all work as intended, since the rest of >> the function is perfectly 64-bit safe. >> >> Fixes: f9b2a4d6a5f1 ("rtc: class: support hctosys from modular RTC drivers") >> >> Signed-off-by: Einar Jon Gunnarsson <tolvupostur@xxxxxxxxx> >> --- >> drivers/rtc/class.c | 7 ------- >> 1 file changed, 7 deletions(-) >> >> diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c >> index e31fa0ad127e..df58edf99ed3 100644 >> --- a/drivers/rtc/class.c >> +++ b/drivers/rtc/class.c >> @@ -72,13 +72,6 @@ static void rtc_hctosys(struct rtc_device *rtc) >> >> tv64.tv_sec = rtc_tm_to_time64(&tm); >> >> -#if BITS_PER_LONG == 32 >> - if (tv64.tv_sec > INT_MAX) { >> - err = -ERANGE; >> - goto err_read; >> - } >> -#endif >> - >> err = do_settimeofday64(&tv64); >> >> dev_info(rtc->dev.parent, "setting system clock to %ptR UTC (%lld)\n", >> -- >> 2.34.1 >> > > > -- > Regards > Einar Jón -- Regards Einar Jón
