Clemens Koller wrote: > Scott Wood schrieb: > >> I would prefer to not tell the driver for 'foo' that it should attach to > >> 0-0068 > >> because it should attach to the first i2c bus (0) it finds per default. > > > > Absolutely wrong. > > Hmm... Why?
It's error prone. > > What if foo is on bus 1? > > Then I would need to tell the driver 'foo' that it should attach > to 1-0068. So we're back to the situation where drivers that aren't explicitly told where to look are making assumptions that are possibly incorrect. You should be able to enable drivers without harm, even if the hardware isn't there. > Propably you should see the bigger picture here: Pot, meet kettle. :-) > We just need to tell what we have, if it's not some default... > statically (kconfig) or dynamically (of/dt) to get it right > because we cannot probe for sure what we have (in contrast to PCI). > > I just don't want to be pushed into configuring things twice or on > two different places because that's error prone. The new system is far less error prone than the old system. You seem to be suggesting a third system, with a radically different kconfig format and no multiplatform support (again, this was one of your complaints in your original e-mail -- why do you ignore it now?). Please show us the code, or at least some description of how you would change kconfig to get it up to the task, and how you would handle multiplatform kernels. > >> Then I would need to tell 'bar' to attach to 1-0068. Where is the > problem? > > > > OK, now say there's another foo on bus 2, and a pair of bars on buses > 3 and > > 4? > > Okay, let's play that game: > foo -> connect an instance to 0-0068 and 2-0068 > bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068 That doesn't resemble kconfig in the least -- and even if you transform it into some sort of runtime-parsable textual list, what do those bus numbers mean, anyway? How do you associate those with various i2c buses, potentially coming from different i2c drivers? How do you specify IRQs? How do you specify device variants among those the driver supports? By the time you fix all of that, you'll basically have the device tree. The device tree provides a hierarchy that is well suited to handling this sort of problem, and it also logically separates what the kernel supports from what the hardware has (which is *necessary* for multiplatform support). > >> The 0068 is already redundant in the case of these RTCs because they > are > >> fixed. > > > > How do you know I'm even talking about RTCs? > > Well, the subject is about RTCs. Not really, it's about a change in the i2c subsystem (I noticed you didn't include the i2c list or linuxppc-dev... you'd get a larger audience of the people that actually made the change that way). That it happens to be an RTC chip you're using on the i2c bus is an inconsequential detail. > >> linux-2.6/Documentation/powerpc$ grep "rtc" * > >> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, > >> btw.). > >> which could give a clue what's going on here. > >> linux-2.6/Documentation/powerpc$ grep "fsl_soc" * > >> - nothing - > > > > Uh, did you try grepping for "i2c"? > > No, I've just read the whole file from time to time. OK, it seems the description of i2c devices didn't make it into that file. I'm not sure why. > That was discussed already in detail in several threads and there > were already decisions made that the DT went into the kernel - no problem > with that. > I just don't see that it 'really does help' in it's current state if > things are broken in a way they are hard to fix for non DT-familiar > developers, almost impossible to fix for users which just need to > compile their own kernel to achieve their project goal. I agree there's been excessive roughness in the transition -- but in this case, it's largely due to the i2c subsystem change, whereby a driver can't be new-style and old-style at the same time. Thus, once the driver is converted, all platforms have to register the device. On powerpc, we happen to do it using the device tree (though you could do it with board-specific platform code the way other arches do if you really wanted). > Well... let's take it easy. I'll dig into the pcf8563 code now. BTW, there were patches posted recently by Jon Smirl to convert that driver to new-style, and to change the i2c subsystem to have the OF matches in the driver itself. -Scott _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
