>> Now some OF I2C code goes looking for IIC devices in the >> device tree. It finds this thing, and from a table or >> something it derives that it has to tell the kernel I2C >> layer this is an "rtc-rs5c372". > > (I2C ML cc'ed.) > > This is where I WOULD disagree. These tables would rather live > inside the > i2c layer,
Physical location doesn't matter, logical location is a separate layer. > be filled by respective drivers themselves. That would be nicer yes, but a bigger change. > Noone except the > rs5c372 driver can know which devices it can handle. I don't really agree but that's more a philosophical than a technical argument. > Using the very same > your argument - what if in a future version this driver disappears and > another one will be used for these devices? Then that driver will > have to > register support for this device. And it's all in the same kernel source tree so it would be a trivial fixup -- quite different from keeping OF device trees and Linux kernels in synch (which is pretty much impossible). > For this to work i2c would need something similar to what pci, usb > do - > register supported device ids. The only difference is that instead of > numerical IDs we have to use plain text names for i2c devices... Yeah, that would be nice. Are you suggesting the Linux I2C layer should use "OF-style" names as its "native" naming scheme? I'd rather keep the namespaces separate, coupling them always seems like a great idea and always turns out a disaster. >> [It would be nicer if it >> could just instantiate the correct driver directly, but >> if that's how the Linux I2C layer works, so be it]. >> >> No change in the I2C "core" needed, just an OF "compatible" >> matching thing like is needed *everywhere else* too. > > Yes, this is why I put "would". Looks like this is the common powerpc > practice ATM - to make such a glue to map arbitrary "OF names" to what > respective drivers react to. Like in the case of the serial driver. Yes. This is the most flexible scheme possible and allows for all kinds of fixups/workarounds in case of broken device trees (or broken kernel code, for that matter). > But - > i2c is much more diverse and dynamic than serial, so, maybe it is > worth > thinking about "fixing" i2c? Be my guest :-) I care more about the OF side of things, but let me ask anyway -- what do you see as "broken" in the Linux IIC "core" that needs fixing here? Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
