[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-i2c
Subject:    [i2c] [patch/rfc 2.6.19-rc6 1/3] I2C "new style" driver model
From:       greg () kroah ! com (Greg KH)
Date:       2006-11-21 23:01:05
Message-ID: 20061121230105.GB9080 () kroah ! com
[Download RAW message or body]

On Sat, Nov 18, 2006 at 10:30:20AM -0800, David Brownell wrote:
> 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.

Of course it is unmanaged, and yes, Jean, I know it's not unique at all.
It's merely a "hint" to userspace to try to load a subset of all of the
different i2c drivers to see which one really works for the device.

If you now have a way to ensure a 1-to-1 matching, that's great, I
couldn't figure out how to do that for the more "generic" i2c drivers,
which is why I stuck with the i2c device id.

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

Ok, I didn't realize they could be dynamically assigned.  Oh well,
nevermind, I'll go back to my corner and shut up about this stuff :)

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

"hint", not "robust", I was just trying to make it better than what we
have today, "nothing" :)

thanks,

greg k-h


[prev in list] [next in list] [prev in thread] [next in thread]