[i2c] How to find an i2c_adapter in the system

[Jean Delvare]

Hi Hendrik,

On Wed, 14 Nov 2007 00:29:15 +0100, Hendrik Sattler wrote:
> Am Dienstag 13 November 2007 schrieb Jean Delvare:
> > On Mon, 12 Nov 2007 23:23:34 +0100, Hendrik Sattler wrote:
> > > BTW: interesting busses are determined by the adapter id
> > > (I2C_HW_SMBUS_I801). And there can only be one i2c_i801 device in a
> > > system, AFAIK.
> >
> > Right now, yes. However, there's nothing preventing Intel from adding a
> > second SMBus channel in the next iteration of their ICH south bridge,
> > and then you lose.
> 
> Anyway because the data table in the BIOS does not really specify the bus, it 
> only says that it is an I2C bus. And since that was always on systems with 
> i801 SMBUS...
> Matching against .id is sufficient in this case, better than nothing.

It works, sure, but as I said it's not robust. I hope that we can come
up with something better in the future.

> > Nvidia south bridges already support two SMBus 
> > channels, for example, so it's really possible that Intel does the same
> > someday. Attempting to identify I2C channels by their adapter's .id is
> > broken by design. BTW, this .id field will most certainly be dropped as
> > some point in the future, exactly for this reason.
> 
> Then I have to match the driver name. That doesn't really matter.

Matching the driver ID or the driver name is almost the same. We won't
remove the driver ID before we have something better to replace it, so
you shouldn't have to match the driver name, ever.

> But not 
> being able to identify a specific bus when not using a fixed id is also 
> broken (because the .nr field is not usuable, either).

When using platform-based device declarations, the .nr field becomes
usable. That's the idea.

> And a pointer to a struct is not really a good identification.

A pointer to a struct is the best identification I can think of. Why
do you believe it isn't OK? Of course, the difficult part is to get
your hands on the pointer. For I2C buses on daughter boards (think TV
adapter) it's rather natural, but for an I2C device on the mainboard's
SMBus, that's a different story.

> > But as I explained before, that's certainly not the way to go. If
> > you're writing a new-style driver, you want to instantiate the device
> > from platform code, and let i2c-core attach the driver to this device
> > automatically.
> 
> Your suggestion may be suitable to embedded devices where each has its own 
> kernel configuration and can also control the i2c bus ids.
> However, that table is only present on certain laptops manufactured by 
> Fujitsu-Siemens, probably running generic distribution kernels. Having it as 
> module is the only possible way to get it accepted, I assume.

New-style i2c devices can be modular, there's really no problem with this.

It might make sense to arbitrarily reserve I2C bus number 0 and 1 for
the mainboard SMBus on x86. That would only require minor changes to
i2c-boardinfo (basically, initialize __i2c_first_dynamic_bus_num to 2
instead of 0, and change i2c-i801 and friends to use
i2c_add_numbered_adapter instead of i2c_add_adapter.) Not necessarily
very clean, but that should work. David, what do you think?

> And, there is 
> no way to assure that this module get's loaded before i2c-core and i2c_i801.

And no need for that either. New-style I2C devices can be declared
after the underlying bus driver is loaded, it works just fine.

-- 
Jean Delvare