[i2c] [patch/rfc 2.6.19-rc6 0/3] more I2C driver model updates, the Good Stuff

David Brownell david-b at pacbell.net
Thu Nov 16 20:22:32 CET 2006

Following this are three patches that add a new driver binding model to
the I2C stack ... one that matches the driver model.  In order, the patches:

 - add probe() and remove() methods to i2c_driver; modalias support, for
   hotplug/coldplug; and update docs to reflect "legacy" and "new style"
   binding models ... no net behavioral change though

 - add "struct i2c_board_info" and infrastructure using it, so that
   board-specific init code can declare the I2C devices that are really
   present ... "new style" drivers are fully enabled

 - convert one board (OMAP5912 OSK) and one driver (tps65010) over to
   use the new style driver.

These patches have only been sanity tested, by booting an OSK and noting
that (a) the tps65010 driver bound correctly, (b) the aic23 node exists,
but without a driver bound to it.  They applied on top of the driver model
patch from yesterday, but they shouldn't rely on any changes in it.

Of interest, the tps65010 driver shrank by about 10% ... or more if debugfs
isn't configured.  Most of the savings is from eliminating the huge data
tables of I2C_CLIENT_INSMOD.

As a reminder, this kind of update is important for a couple reasons.  One
is that the I2C stack is blatantly violating the driver model ... and this
"new style" is fixing that, while it adds missing capabilities like letting
I2C drivers have IRQs, and leveraging platform_data.  The other is closely
coupled:  an "I2C" stack that doesn't work without SMBUS_QUICK support is
kind of problematic for use on I2C systems (like OMAP) without SMBUS_QUICK.

That is, the I2C stack really needs changes like these.  In fact, it's more
than a bit overdue for them.

So ... comments?

- Dave

More information about the i2c mailing list