[i2c] Identifying I2C busses

[Jean Delvare]

Hi David,

On Thu, 8 Mar 2007 20:00:14 -0800, David Brownell wrote:
> On Wednesday 07 March 2007 12:42 pm, David Brownell wrote:
> 
> >		 But again, I may decide I like your
> > notion of device struct as handle, at which point this issue vanishes too.
> 
> OK, unfortunately that idea can't work.  I should have remembered:
> 
>     /sys/devices/pci0000:00/0000:00:01.1> ls
>     broken_parity_status  device  i2c-1       msi_bus    resource5         uevent
>     bus                   driver  irq         power      subsystem         vendor
>     class                 enable  local_cpus  resource   subsystem_device
>     config                i2c-0   modalias    resource4  subsystem_vendor
>     /sys/devices/pci0000:00/0000:00:01.1> 
> 
> Note: both i2c-0 and i2c-1 are parented by the same PCI device.

I see.

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

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

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.

-- 
Jean Delvare