All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Alessandro Zummo <a.zummo@towertech.it>, Marc Dietrich <marvin24@gmx.de>
Cc: John Stultz <john.stultz@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	John Whitmore <arigead@gmail.com>
Subject: Re: [PATCH 0/2][RFC] Try to handle hctosys w/ rtc modules
Date: Tue, 01 Jul 2014 20:42:32 +0200	[thread overview]
Message-ID: <53B30118.8060507@ahsoftware.de> (raw)
In-Reply-To: <20140630213716.36dd4227@linux.lan.towertech.it>

Am 30.06.2014 21:37, schrieb Alessandro Zummo:
> On Sat, 28 Jun 2014 20:54:33 +0200
> Marc Dietrich <marvin24@gmx.de> wrote:
>
>>> Besides that the current hctosys-mechanism doesn't really work with
>>> hot-plugable devices at all. Guess what N will be when you unplug and
>>> plug in such a RTC again.
>>
>> We have a patch in the kernel which binds the rtc number to the
>> hw device, so this even works for hotpluggable devices (at least on
>> systems supporting device-tree). Not sure what your needs are.
>
>   I'm still not sure about how to solve this, maybe it would be better to
>   identify the hctosys device that should be used at boot with
>   a different identifier than rtcX (and move the option to the kernel command line)

Just in case some missunderstood me. I didn't talk about the userland 
but the in-kernel stuff. Currently, it uses the N which was defined by 
in the config (or zero) on resume to update the time. If you look at my 
3. patch, you will see I have changed this there to use the driver (by 
name) which was used at boot to set the time.

Fixing userspace would be easy too by just changing /dev/rtcN to 
/dev/rtc_drivername. But I didn't that in my 3 patches in order to not 
confuse maintainers (and userland people) with too much changes or new 
stuff at once (unsucessfully, but ...).

There still would be a problem about how to handle two RTCs which do use 
the same driver, but I think this is fictitious scenario (and broken if 
that should be for backup purposes) and therefor if someone would really 
design such a system, he should solve this problem himself.

Alexander Holler

      reply	other threads:[~2014-07-01 18:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27 17:27 [PATCH 0/2][RFC] Try to handle hctosys w/ rtc modules John Stultz
2014-06-27 17:27 ` [PATCH 1/2][RFC] time: Introduce do_first_settimeofday() John Stultz
2014-06-27 17:27 ` [PATCH 2/2][RFC] rtc: Rework hctosys so that it is called on RTC registration John Stultz
2014-06-28  7:18 ` [PATCH 0/2][RFC] Try to handle hctosys w/ rtc modules Alexander Holler
2014-06-28  7:32   ` Alexander Holler
2014-06-28 18:54     ` Marc Dietrich
2014-06-28 20:50       ` Alexander Holler
2014-06-30 19:37       ` Alessandro Zummo
2014-07-01 18:42         ` Alexander Holler [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=53B30118.8060507@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=a.zummo@towertech.it \
    --cc=arigead@gmail.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marvin24@gmx.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.