Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag

[Jason Gunthorpe]

On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:

> > Sure, but my view on this is that it has nothing to do with
> > read_persistent_clock. If the RTC driver can run with IRQs off is a
> > property of the RTC driver and RTC hardware - it has nothing to do
> > with the platform. ARM platforms will vary on a machine by machine
> > basis. The rtc-mv driver used on my ARM system is perfectly
> > re-entrant, lots of rtc on SOC drivers will be the same.
> > 
> > If this is the only thing keeping you on read_persistent_clock, for
> > real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
> > rtc_device.flags?
> > 
> > Reserve read_persistent_clock for things like that very specialized
> > non-RTC ARM counter.
> 
> Yes, these non-RTC device is one reason for keeping read_persistent_clock,
> one other reason I can think of is the CONFIG_RTC_LIB is not always on by
> default for all Archs, and some platforms may chose to disable it on purpose. 
> When CONFIG_RTC_LIB is not set, we need the read_persistent_clock for
> time init/suspend/resume.

I thought your concern was the case where the RTC was turned on and
read_persistent_clock was also turned on. Having a flag in the RTC and
disabling read_persistent_clock for that situation would help you
avoid the double code path to the same hardware.

What is motivating having a RTC but not using RTC lib? Embedded
doesn't seem to the be the case, nearly all the interesting rtcs are
under class rtc....

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/