[i2c] [patch 2.6.19-rc5] some i2c driver model updates

[David Brownell]

> I think I found the problem. You replaced the "drivers" list maintained
> by i2c-core by the list of drivers maintained by the driver core,
> assuming they were equal. However, the i2c-core only listed i2c chip
> drivers (struct i2c_driver), while it looks to me like the driver core
> lists the i2c chip drivers (struct i2c_driver) _and_ the "i2c_adapter"
> driver (i2c_adapter_driver), which you can see in /sys/bus/i2c/drivers.

Whoops, that's nonsensical.  If it's not an i2c device, it should
not be grouped with i2c devices.


> When you call to_i2c_driver() on this one in i2c_do_add_adapter(),
> well... you can't. I guess sometimes you're lucky and
> driver->attach_adapter is NULL, so it's silently skipped, and I wasn't
> lucky and it crashed on me.
>
> So we need to catch this exception in i2c_do_add_adapter(), and then
> things should work.

Thing is, i2c_adapter is what I'd normally think of as a class,
not a device.  Or maybe a way to group everyting in a given bus 
segment under one tree.  It's clearly _not_ an I2C device; it
should maybe be a different type (like "i2c_bus").

We might not be able to  do it as _just_ a class, because of common
cases like PCI SMBUS adapters with two different independent bus
segments.  But if we can, that'd be more sensible.


>	And I suspect i2c-dev will need a similar exception.

Yeah, that's a whole nother kind of confusion... but, not one
that "should" be affected by this patch series.


> OTOH I admit I wonder why i2c_adapter_driver is listed with all
> i2c_driver structs at the driver core level, while they are of
> different nature. But then again I'm not familiar with the driver
> model. Greg?

Yeah ... Greg?  :)

- Dave