From: john stultz <johnstul@us.ibm.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>,
rtc-linux@googlegroups.com, LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Alessandro Zummo <a.zummo@towertech.it>
Subject: Re: [rtc-linux] [PATCH 04/10] RTC: Cleanup rtc_class_ops->read_alarm()
Date: Tue, 22 Feb 2011 11:58:16 -0800 [thread overview]
Message-ID: <1298404696.9215.47.camel@work-vm> (raw)
In-Reply-To: <20110222195143.GC31611@opensource.wolfsonmicro.com>
On Tue, 2011-02-22 at 19:51 +0000, Mark Brown wrote:
> On Tue, Feb 22, 2011 at 11:35:10AM -0800, john stultz wrote:
>
> > Yea. The way I thought about it originally was that you can set an alarm
> > and that alarm will fire if the machine is on, suspended or even in some
> > cases off. Then, when the machine is booted (system reset), the state
> > of the RTC's alarm should not be trusted.
>
> > Your description of the AIE/UIE having random values aligns with that
> > intuition.
>
> This seems rather worrying - it sounds like it might mean that the
> device might come up firing spuriously which doesn't seem terribly
> clever.
Well, in those known cases the driver should initalize the irq modes to
be off.
> > However, if the expectation is that once set, the alarm should persist
> > across any number of reboots, this makes it a bit more complicated.
>
> For an embedded device I'd expect that either nothing about the RTC
> would persist (including the time) or everything would.
But that isn't the reality of the hardware. On reboot the kernel can't
trust hardware to be in a valid state.
Even so, we can try to preserve what we can, but I think the expectation
from an application's point of view shouldn't be that rtc device's alarm
state will be valid upon reset.
thanks
-john
next prev parent reply other threads:[~2011-02-22 19:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-21 23:55 [PATCH 00/10] [RFC] RTC: Cleanups for 2.6.39 John Stultz
2011-02-21 23:55 ` [PATCH 01/10] RTC: Cleanup rtc_class_ops->irq_set_state John Stultz
2011-02-21 23:55 ` [PATCH 02/10] RTC: Cleanup rtc_class_ops->irq_set_freq() John Stultz
2011-02-21 23:55 ` [PATCH 03/10] RTC: Cleanup rtc_class_ops->update_irq_enable() John Stultz
2011-02-21 23:55 ` [PATCH 04/10] RTC: Cleanup rtc_class_ops->read_alarm() John Stultz
2011-02-22 2:34 ` [rtc-linux] " Mark Brown
2011-02-22 2:55 ` John Stultz
2011-02-22 8:09 ` john stultz
2011-02-22 12:51 ` Marcelo Roberto Jimenez
2011-02-22 19:35 ` john stultz
2011-02-22 19:51 ` Mark Brown
2011-02-22 19:58 ` john stultz [this message]
2011-02-22 21:26 ` Marcelo Roberto Jimenez
2011-02-22 18:16 ` Mark Brown
2011-02-22 19:51 ` john stultz
2011-02-22 20:00 ` Mark Brown
2011-02-22 20:22 ` john stultz
2011-02-22 21:05 ` Mark Brown
2011-02-22 21:21 ` john stultz
2011-02-22 21:27 ` Thomas Gleixner
2011-02-22 21:40 ` Mark Brown
2011-02-22 21:33 ` Mark Brown
2011-02-22 22:10 ` john stultz
2011-02-22 23:07 ` Mark Brown
2011-02-22 19:53 ` john stultz
2011-02-22 20:31 ` Mark Brown
2011-02-21 23:55 ` [PATCH 05/10] RTC: Clean out UIE icotl implementations John Stultz
2011-02-21 23:55 ` [PATCH 06/10] RTC: Include information about UIE and PIE in RTC driver proc John Stultz
2011-02-21 23:55 ` [PATCH 07/10] RTC: Remove UIE and PIE information from the sa1100 " John Stultz
2011-02-21 23:55 ` [PATCH 08/10] RTC: Fix the cross interrupt issue on rtc-test John Stultz
2011-02-21 23:55 ` [PATCH 09/10] RTC: sa1100: Update the sa1100 RTC driver John Stultz
2011-02-21 23:55 ` [PATCH 10/10] RTC: Fix up rtc.txt documentation to reflect changes to generic rtc layer John Stultz
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=1298404696.9215.47.camel@work-vm \
--to=johnstul@us.ibm.com \
--cc=a.zummo@towertech.it \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mroberto@cpti.cetuc.puc-rio.br \
--cc=rtc-linux@googlegroups.com \
--cc=tglx@linutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox