On Wed, 22 Aug 2007 22:35:58 +0200
Brian Murphy <email@example.com> wrote:
> Yoichi Yuasa wrote:
> <much snipping>
> >> +
> >> +config DS1603
> >> + bool "DS1603 RTC driver"
> >> + depends on LASAT
> > If you add new RTC driver, it should go to drivers/rtc.
> It's hardly new, is it? It was removed by you with the rest
> of the LASAT stuff two months ago after it had been in the kernel
> for 5 years. Why are RTC drivers more important than any others?
> And why is it important that a platform specific driver goes in a
> common area when only one platform uses it?
DS1603 can be likely to be used with others.
> The driver is quite platform specific:
> 1) It needs to adjust for a slow transistor on the I/O line to allow
> for three-stating.
> 2) A special lasat_ndelay which guesses the clock speed based
> on platform to allowi the bit-banging interface to control the device
> before the CP0 timer is calibrated (by the RTC).
> 3) Platform specific I/O which is not programmable (part of an FPGA/CPLD).
> 1 Is basically solved now in an ugly manner with a long delay parameter.
> 2 I cant really see a sensible solution to.
> 3 I could use the new fancy gpio interface but as the I/O is neither
> general or programmable I'm not sure of the point. If someone else
> needed the driver then I would have no problem in doing this but as
> it is it seems like a waste of time.
> The interface the rtc uses is still used by many drivers implemented
> in the platform directories and is much simpler and straightforward
> than the general interface used by the drivers in drivers/rtc and will
> give more code.
> I have no problems with your other points but I would really like the
> RTC code to stay where it is.
it's OK with me.