[F][PATCH 0/1] rtc: class: support hctosys from modular RTC drivers

[Dimitri John Ledkov]

But doesn't this break assumptions that systemd makes? I.e. it would
sync it's time from the timesync state file, and then loading rtc
module would trump this.

This change in v5.7 kernel has caused breakage. Does introducing this
in v5.4 kernel going to break UC20 machines which sync a better/secure
time in the initrd; and then will get broken time from the rtc module
because it happens to not be battery backed. Leading to inability to
snap refresh?

Can you please explain what is prompting to backport this change into
v5.4 kernels?

-- 
Regards,

Dimitri.

On Wed, Nov 24, 2021 at 11:01 AM Wen-chien Jesse Sung
<jesse.sung at canonical.com> wrote:
>
> BugLink: https://launchpad.net/bugs/1952077
>
> == Impact ==
> Although we have CONFIG_RTC_HCTOSYS enabled and set CONFIG_RTC_HCTOSYS_DEVICE
> to "rtc0", system time would only be set if the RTC driver is built-in. This
> may not be an issue on most amd64 systems because CONFIG_RTC_DRV_CMOS is y
> for amd64, however it is an issue for other architectures since there may not
> be a proper RTC driver enabled as built-in. Also making every RTC driver that
> may be used as built-in is not a good option.
>
> == Fix ==
> The commit is in mainline since v5.7:
>
> == Risk of Regression ==
> It's a clean cherry-pick for v5.4 and looks straight forward so risk should be low.
>
>
> Steve Muckle (1):
>   rtc: class: support hctosys from modular RTC drivers
>
>  drivers/rtc/Kconfig   |  3 --
>  drivers/rtc/Makefile  |  1 -
>  drivers/rtc/class.c   | 61 ++++++++++++++++++++++++++++++++++++++
>  drivers/rtc/hctosys.c | 69 -------------------------------------------
>  4 files changed, 61 insertions(+), 73 deletions(-)
>  delete mode 100644 drivers/rtc/hctosys.c
>
> --
> 2.25.1
>
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team