[i2c] [patch/rfc 2.6.19-rc6 1/3] I2C "new style" driver model type binding

David Brownell david-b at pacbell.net
Sat Nov 18 19:30:20 CET 2006

On Saturday 18 November 2006 1:31 am, Greg KH wrote:
> On Fri, Nov 17, 2006 at 01:31:43PM -0800, David Brownell wrote:
> > On Friday 17 November 2006 7:37 am, Jean Delvare wrote:
> > > 	So we need to either list all supported 
> > > types in the driver and lookup that list in i2c_device_match(), or
> > > instanciate the i2c chips by {driver name, type number} pair rather
> > > than chip name. The former sounds more flexible. And isn't exactly what
> > > device_id tables are meant for?
> > 
> > The device id tables are for use with _managed_ device identifiers.
> > 
> > Like the PCI SIG assigns vendor codes, then vendors assign product
> > codes; the USB-IF does the same for USB; Microsoft does for PNP;
> > and so forth.  Those identifiers get associated with Linux drivers
> > through those device id tables.
> > 
> > I2C doesn't have such a managaged ID namespace.  Which is why the
> > simple solution seemed to be to reuse the approach Linux uses in
> > similar cases.  It's not necessarily the _best_ approach, but it's
> > one that works well and has precedents in Linux.  Plus it needs
> > no design effort, and no special education/training.
> > 
> > (Also, adding new device id table types gets really messy, fast,
> > since it requires modutils updates.  That complicates deployment
> > by quite a lot.)
> Note, if you look closely, I added a modalias for i2c a while ago to the
> tools, it takes a single value as the id and will allow for modalias
> strings that look like:
> 	i2c:XXXX
> where XXXX matches the i2c_device_id->id field.

But it's still an _unmanaged_ identifier, with nothing to prevent
collisions ... so the driver name sure seems like a more workable
(robust, manageable, etc) approach to me.

> But, no code uses it yet, so it's gone unnoticed :)
> But you can use the device addresses for the id if you wish, I
> originally thought that this would allow us to walk the bus in
> userspace, and merely do a 'modprobe' of any address that found a device
> on it, which would cause all of the proper modules to be loaded.
> Unfortunatly, not all systems can handle such a bus probe, otherwise I
> would have finished up that work...

And again, those addresses are unmanaged.  Plus with newer SMBUS systems,
addresses can even be dynamically assigned ...

And it's easy to make an off-the-shelf microcontroller use _any_ address
you want ... at least, any of the standard 127 addresses, since 10 bit
addressing is rare.  So depending on addresses to serve as unique chip
type identifier codes would not be robust.

- Dave

More information about the i2c mailing list