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

[Feng Tang <feng.tang@intel.com>]

On Mon, Dec 17, 2012 at 11:22:02AM -0700, Jason Gunthorpe wrote:
> 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.

No, it's not about my concern (actually I don't have concerns :), my 3
patches are just some optimization).

My point is the "driver/rtc" or "drivers/rtc/class.c" can't be ganrateeded
to be built for all kernels, myself saw several cases, under which
the read_persistent_clock is still needed.

If you want drivers/rtc code to take the priority, first thing you have
to do is to make those codes always "obj-y=xxx.o"

Thanks,
Feng