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

Scott Wood scottwood at freescale.com
Tue Dec 4 05:07:27 EST 2007

Clemens Koller wrote:
> Scott Wood schrieb:
>  > The problem is the "probed successfully" bit -- i2c can't be
>  > automatically detected like PCI can, and the probing that was being done
>  > before was very error-prone.
> I think I understood the original purpose of device trees, or it's
> intended advantage but don't see much of this yet.
> Before (2.6.22) everything was working fine just by enabling the proper
> kernel config.

Just because it worked fine *for you* doesn't mean it worked fine in 

1. This means that you can't use the same kernel with different 
hardware, which is precisely what you were complaining that you couldn't do.
2. What if you have two i2c devices at the same address on different 
buses?  Or if you have two devices, these devices can reside on a 
variety of ports, and the driver for one tries to probe the port of the 
other?  .config doesn't help you now.
3. What if you need to pass in extra information to the driver, such as 
the exact chip type when more than one is handled by the same driver, or 
the IRQ line if the chip uses one, etc?

> Well, I don't want to start a flamewar on this since we have had
> already enough pro & contra Device Tree discussions. I just want
> to point out that the current situation doesn't really follow
> the KISS principle at all in my eyes.

It should be as simple as it can be and still work, but no simpler. 
Before, it was too simple to work.

> 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.


More information about the Linuxppc-embedded mailing list