[PATCH] powerpc: Add of_register_i2c_devices()

[Segher Boessenkool]

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