Linux-RTC Archive on lore.kernel.org
 help / color / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Steve Muckle <smuckle@google.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-rtc@vger.kernel.org,
	"Cc: Android Kernel" <kernel-team@android.com>
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 <
> alexandre.belloni@bootlin.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.

      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 \
    --to=alexandre.belloni@bootlin.com \
    --cc=a.zummo@towertech.it \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=smuckle@google.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 \
		linux-rtc@vger.kernel.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