[i2c] [PATCH] i2c: Deprecate legacy RTC drivers

[David Brownell]

> Regarding the ds1337 driver, it exports a public function,
> ds1337_do_command(), which is currently used by functions in
> arch/ppc/platforms/radstone_ppc7d.c. This code is used to provide
> implementations used by the ppc arch get_rtc_time() and set_rtc_time()
> platform hooks.

The RTC framework has CONFIG_RTC_HCTOSYS and CONFIG_RTC_HCTOSYS_DEVICE
which ought to suffice for everything except NTP integration.

By the way:  I notice that ppc7d_{get,set}_rtc_time() call that
hook while holding a spinlock ... not allowed, I'm surprised
such a bug has persisted for about two years now!  Maybe part
of the issue is lockdep not working yet on Powerpc/PPC?


> If the rtc subsystem now provides a better way to hook 
> up these functions, the radstone_ppc7d code could be changed to use it
> instead of ds1337_do_command(), thereby allowing the old ds1337 driver
> to be removed.

I think there was some noise afoot to switch all of PPC over
to the new RTC framework once the resume hooks were merged;
and that's achieved by 2.6.22-rc1 ... I figure that conversion
will need to happen one driver at a time.


> Perhaps the radstone_ppc7d platform code should use rtc_read_time() and
> rtc_set_time() instead? Is it possible for platform code to obtain the
> rtc's struct class_device which are needed by those calls?

More like:  the PPC7D stuff should stop using the ppc_md RTC hooks,
and just update its default config to use the RTC framework with
CONFIG_RTC_HCTOSYS.

In fact, since I've got patches to switch rtc-ds1307 over to a
new-style I2C driver, I'll send you a patch to test that on that
platform as soon as I re-verify those on the 2.6.22-rc1 kernel.

- Dave