[i2c] Identifying I2C busses

[David Brownell]

On Friday 09 March 2007 1:42 am, Jean Delvare wrote:
> > On embedded systems there's essentially always a one-to-one mapping between
> > driver model devices and I2C busses.  But that's not true on many common
> > PCI based systems ... like the one above, and various video adapters.
> > 
> > Unless that mapping is one-to-one, there's no way to use physical device
> > nodes as the persistent identifiers for I2C busses.  So, when I refresh
> > that patch it's going to still use bus numbers as handles.
> 
> OK, fine with me. This raises another question though:
> 
> In the course of a previous discussion where I pointed out that dev_info
> wouldn't work properly on i2c_adapter devices any longer because we got
> rid of the useless i2c_adapter driver, you said it wasn't a problem
> because we should be using the physical (parent) for the messages
> anyway. I didn't object back then, and I even started converting some
> drivers to do that, but... This will obviously be confusing for devices
> with multiple i2c adapters as the one you quote above. We need a way to
> let the user know which I2C channel the message is related to. This is
> impossible if we use the parent device for messages.

Darn!  Thing is, on most non-PC systems using the parent is fine;
and less confusing (to me and many other folk) than the alternatives.


> On top of that, 2.6.21-rc1 introduced the possibility to make class
> devices (such as i2c_adapter) virtual, i.e. have no parent nor bus.
> See /sys/devices/virtual.

Empty on all my systems...


> This is convenient for purely virtual devices 
> such as network loopback, and it would also be the right thing to do
> for i2c-stub IMHO. So class devices without a parent become legal,
> meaning we don't want to make it mandatory for i2c_adapters to have a
> parent device. Again a change in our plans...

So it seems.


> I'll post on the i2c list later today (I hope) about this topic. I
> really want Greg to clarify this point. Right now dev_info is broken
> for class devices almost by definition, this needs to be addressed
> before I push all my i2c patches to Linus, as I might have to drop
> i2c-03-use-i2c_adapter.dev.parent-for-messages.patch. Maybe we want
> dev_info to detect class devices and do something different for them,
> or we want to introduce new macros for class devices, I dunno yet.

Your patch to do different stuff for class devices seemed reasonable.

- Dave