Hi Chris, Le dimanche 03 mai 2020 à 20:42 +0200, Chris Hofstaedtler a écrit : > the supplied patch does not apply anymore; actually I can't find the > code that it tries to patch.
It's still there in sys-utils/hwclock*.c. > Maybe this is just obsolete after 10 > years in the Debian BTS; if this is still a problem please try > upstream, as they can be more helpful. Thanks for the follow-up! Actually, it made me dig if it's still accurate; I saw that the other RTC in the kernel I mentionned (pcf8563) that specifically ignored returning an error when failing to read the RTC has been fixed in 2015 to return EINVAL because “at least the current version [of hwclock] do set the time as expected”: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=538330ccb93849530f5617d1fa870237496caa60 Still, looking at the latest hwclock code, the parts I fixed did not change much: it still propagated an error on synchronization. Going up to sys-utils/hwclock.c:manipulate_clock() cleared the mistery: there is now a mention of “enabl[ing] setting a corrupted RTC without reading it first”. The full explanation is in ee723d23524d8e170aae030bb7579b4fae5599df from J William Piggott in 2017, two years later, explaining very thoroughly that the problem was partially fixed throughout the years in hwclock, hence the fix from 2015 for some platforms, and its final fix solving the problem once and for all. I do not own the hardware anymore so I cannot really test it, but I think that today my patch is indeed not needed anymore and has been fixed in another way. Thanks for bringing me some memories and your clean-up work of the BTS! Regards, -- benjamin
