Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Scott Wood <scottwood@freescale.com>]

On Mon, Dec 03, 2007 at 08:35:29PM +0100, Clemens Koller wrote:
> Hello, Scott!
>
> Scott Wood schrieb:
> >> Here, the next idea which comes to my mind:
> >> Maybe we should think about a kernel-config -> dts compiler for
> >> the future where the enabled drivers generate their default dts
> >> entries automagically?
> >
> > Sorry, there's just not enough information in .config for that.
>
> If there is really the need to put more information (which I don't
> see in the case of the RTCs)

It's not uncommon for RTCs to have an alarm IRQ.  It's not uncommon for
multiple not-quite-compatible RTC chips to be driven by the same driver,
which needs to know what it's dealing with.

> to .config, it might be an idea to extend the current structure for this
> use instead of duplicating and maintaining a second repository.

.config is not nearly as flexible in describing hardware as the device tree
is.  Sorry, but even apart from the multiplatform issue, it's the wrong tool
for the job.

> And regarding the DS1337 (or the PCF8563 and similar RTCs):
> It's address (0x68) is immutable fixed by the manufacturer
> of that device. So, why do we include it in the DT, when we
> already told the kernel what driver we want to use?

You did not tell the kernel what driver you wanted to use; you told the
driver which address the chip will be on.  There are other chips that also
use address 0x68, such as DS1374, which is completely incompatible with
DS1337 and uses a different driver.

> Even if I have an eeprom which can have varying addresses,
> I can simply tell the driver/the kernel .config what address
> it should use...

That's precisely what we do, via the device tree.  It is not practical to do
it with kconfig.  Again putting aside multiplatform kernels for the moment,
what would you do in kconfig to describe the addresses of multiple chips
without having a fixed-size list of possibilities?  How would you tell the
kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c bus
0, and a "bar" chip at address 0x68 on i2c bus 1?

-Scott