From: Alexandre Belloni <email@example.com> To: Steve Muckle <firstname.lastname@example.org> Cc: Alessandro Zummo <email@example.com>, LKML <firstname.lastname@example.org>, email@example.com, "Cc: Android Kernel" <firstname.lastname@example.org> Subject: Re: [PATCH] rtc: class: support hctosys from modular RTC drivers Date: Mon, 23 Mar 2020 21:06:13 +0100 Message-ID: <20200323200508.GA16405@piout.net> (raw) In-Reply-To: <CAL21Ktd3JmRbkwPCCb77knXg4AWi0vWdU147sVaDaoWeEMauDQ@mail.gmail.com> On 27/12/2019 12:23:23-0800, Steve Muckle wrote: > On Fri, Nov 15, 2019 at 5:36 AM Alexandre Belloni < > email@example.com> wrote: > > > On 06/11/2019 15:37:49-0800, Steve Muckle wrote: > > > On 11/6/19 3:19 PM, Alexandre Belloni wrote: > > > > On 06/11/2019 11:46:25-0800, Steve Muckle wrote: > > > > > Due to distribution constraints it may not be possible to statically > > > > > compile the required RTC driver into the kernel. > > > > > > > > > > Expand RTC_HCTOSYS support to cover all RTC devices (statically > > compiled > > > > > or not) by checking at the end of RTC device registration whether the > > > > > time should be synced. > > > > > > > > > > > > > This does not really help distributions because most of them will still > > > > have "rtc0" hardcoded and rtc0 is often the rtc that shouldn't be used. > > > > > > Just for my own edification, why is that? Is rtc0 normally useless on PC > > for > > > some reason? > > > > > > > On PC, rtc0 is probably fine which is not the case for other > > architectures where rtc0 is the SoC RTC and is often not battery backed. > > > > > On the platforms I'm working with I believe it can be assured that rtc0 > > will > > > be the correct rtc. That doesn't help typical distributions though. > > > > > > What about a kernel parameter to optionally override the rtc hctosys > > device > > > at runtime? > > > > > > > What about keeping that in userspace instead which is way easier than > > messing with kernel parameters? > > > > This should ideally happen before file systems are mounted so I don't see > many alternatives for communicating which RTC should be used. Android uses > the kernel command line for userspace parameters as well and that's an > option but that defeats part of the value of doing it in userspace IMO. > There's also device tree but I'm not sure this belongs there. > > Hctosys is also saving and restoring the system time on suspend/resume. It > seems more efficient to me to do this (which happens very frequently on an > Android device) in the kernel as opposed to in userspace. > > If I set the initial system time from the rtc in userspace but continue to > rely on the hctosys suspend/resume code, as it stands there will be a > window after the rtc driver is loaded but before the system time is set > where if suspend is entered, the correct time in the rtc will be lost. > > > > Can't you move away from HCTOSYS and do the correct thing in userspace > > > > instead of the crap hctosys is doing? > > > > > > Yes, I just figured it's a small change, and if hctosys can be made to > > work > > > might as well use that. > > > > The fact is that hctosys is more related to time keeping than it is to > > the RTC subsytem. It also does a very poor job setting the system time > > because adding 0.5s is not the smartest thing to do. The rtc granularity > > is indeed 1 second but is can be very precisely set. > > > > No argument with that, but millions of devices successfully rely on it > today. AFAICT this simple patch doesn't make anything worse. Together with > a change to support a kernel parameter for runtime rtc selection, it should > allow RTC drivers to be modularized on many systems. Can it be adopted as a > stopgap measure? I've applied this patch for 5.7 after removing the unnecessary reformatting of the kconfig help.
prev parent reply index Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-06 19:46 Steve Muckle 2019-11-06 23:19 ` Alexandre Belloni 2019-11-06 23:37 ` Steve Muckle 2019-11-15 13:36 ` Alexandre Belloni 2019-12-27 20:26 ` Steve Muckle 2020-01-31 18:35 ` Steve Muckle [not found] ` <CAL21Ktd3JmRbkwPCCb77knXg4AWi0vWdU147sVaDaoWeEMauDQ@mail.gmail.com> 2020-03-23 20:06 ` Alexandre Belloni [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200323200508.GA16405@piout.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-RTC Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-rtc/0 linux-rtc/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-rtc linux-rtc/ https://lore.kernel.org/linux-rtc \ firstname.lastname@example.org public-inbox-index linux-rtc Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-rtc AGPL code for this site: git clone https://public-inbox.org/public-inbox.git