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

Greg KH greg at kroah.com
Sat Nov 18 10:31:04 CET 2006

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:
where XXXX matches the i2c_device_id->id field.

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


greg k-h

More information about the i2c mailing list