[RFC][2.6] Additional i2c adapter flags for i2c client isolation
khali at linux-fr.org
Wed Mar 17 10:17:29 CET 2004
According to Greg KH <greg at kroah.com>:
> > I guess that chip drivers would be allowed to define only one
> > class while adapters could possibly define more than one?
> Not necessarily. Just make the class a bit field, showing what kind
> of devices each expects to handle.
Of course, this is how I meant it. The way things are done for now, the
class value is already a bitfield and I'm fine with that. This makes
full sense for adapters. What I was wondering is whether it would be
allowed to set more than one class bit for a chip driver. Not that is
necessarily matters much, I'm just curious. Have we ever heard of
chips that would belong to more than one class as we defined them?
> > We also would want to introduce an I2C_ADAP_CLASS_ANY define,
> > which would be what the eeprom driver would use, for example
> > (since it can be hosted on any kind of bus). Generic bus drivers
> > such as i2c-parport would also use I2C_ADAP_CLASS_ANY, since the
> > nature of the hosted chips is unknown.
> #define I2C_ADAP_CLASS_ANY 0xffffffff
> works for me :)
Exactly what I had in mind ;)
> > Having clients define a class sounds also interesting from a
> > user-space's point of view. If we would export this information
> > through sysfs for example, programs such as "sensors" could
> > limit their work to chips of the correct class
> > (I2C_ADAP_CLASS_SMBUS at the moment, but a renaming is planned).
> That also is a good idea.
How would we export the value though? Numerical, with user-space headers
to be included by user-space applications? Or converted to some
explicit text strings so that no headers are needed?
More information about the lm-sensors