Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC
Hoi Miroslav, and thanks for the input! A systemd ExecStartPre in chronyd.service that does this via e.g. core-utils:hwclock is a/the workaround... The proposed opt-in feature (as it is off by default) could IMO still be a good fit for chrony, when it is used on (embedded) systems as the sole keeper of the RTC. Thoughts? gruß Johannes From: Miroslav Lichvar Sent: Monday, July 1, 2024 10:07 To: SCHNEIDER Johannes Cc: [email protected] Subject: Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. On Mon, Jul 01, 2024 at 07:50:09AM +, SCHNEIDER Johannes wrote: > no there wasn't a kernel side discussion; > On a system where chrony is running it holds the rtc device/file-handle, e.g. > has exclusive access and manages the RTC -> there are no other applications > reading/handling the RTC. > So this patch adds the missing "userspace handling" for this uninitialized > RTC corner case. There are other applications supporting RTCs, which other users might be using, and they would eventually need to handle this corner case too, right? To me it seems it's better to handle this in the place that already has HW-specific code, the driver. If the RTC maintainers reject that for some reason, then maybe a simple script running on boot using hwclock. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC
On Mon, Jul 01, 2024 at 07:50:09AM +, SCHNEIDER Johannes wrote: > no there wasn't a kernel side discussion; > On a system where chrony is running it holds the rtc device/file-handle, e.g. > has exclusive access and manages the RTC -> there are no other applications > reading/handling the RTC. > So this patch adds the missing "userspace handling" for this uninitialized > RTC corner case. There are other applications supporting RTCs, which other users might be using, and they would eventually need to handle this corner case too, right? To me it seems it's better to handle this in the place that already has HW-specific code, the driver. If the RTC maintainers reject that for some reason, then maybe a simple script running on boot using hwclock. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC
Hoi, no there wasn't a kernel side discussion; On a system where chrony is running it holds the rtc device/file-handle, e.g. has exclusive access and manages the RTC -> there are no other applications reading/handling the RTC. So this patch adds the missing "userspace handling" for this uninitialized RTC corner case. gruß Johannes From: Miroslav Lichvar Sent: Monday, July 1, 2024 09:44 To: [email protected] Subject: Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. On Sun, Jun 30, 2024 at 05:04:00PM +0200, Johannes Schneider wrote: > Add a configuration option for an "initialization year/timestamp" > chornyd can use to start an uninitialized RTC, so that the RTC driver > can continue its start up, and chrony could later trim the RTC to an > accurate date. > > Without this 'kick-off', on systems where the RTC would return -EINVAL > when being queried either for features, or just being read, chronyd > would be unable to start the RTC driver ("513 RTC driver not running") > and hence could/would not set it. > > An example RTC where this is the case is RX8130 (of the ds1307 > family), which would return -EINVAL *until* the internal oscillator is > started by writing a valid date to it. Wouldn't all applications reading RTC need this patch? I think this should be addressed in the kernel driver instead. Was there a discussion about that? -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected]. -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [PATCH v1] rtc: handle uninitialized RTC
On Sun, Jun 30, 2024 at 05:04:00PM +0200, Johannes Schneider wrote:
> Add a configuration option for an "initialization year/timestamp"
> chornyd can use to start an uninitialized RTC, so that the RTC driver
> can continue its start up, and chrony could later trim the RTC to an
> accurate date.
>
> Without this 'kick-off', on systems where the RTC would return -EINVAL
> when being queried either for features, or just being read, chronyd
> would be unable to start the RTC driver ("513 RTC driver not running")
> and hence could/would not set it.
>
> An example RTC where this is the case is RX8130 (of the ds1307
> family), which would return -EINVAL *until* the internal oscillator is
> started by writing a valid date to it.
Wouldn't all applications reading RTC need this patch? I think this
should be addressed in the kernel driver instead. Was there a
discussion about that?
--
Miroslav Lichvar
--
To unsubscribe email [email protected] with "unsubscribe"
in the subject.
For help email [email protected] with "help" in the
subject.
Trouble? Email [email protected].
