Re: [PATCH][2.6]

[Jean Delvare]

> With the new I2C_CLASS_ALL flag it will be possible that an adapter
> can request that really all drivers are probed on the adapter. On the
> other hand, drivers can make sure that they get the chance to probe on
> every i2c adapter out there (this is not encouraged, though)

Depends. For example the eeprom driver will do that, and this is
correct. That said, I agree that this is a collaborative approach and
everybody will have to play the game.

> - rename I2C_ADAP_CLASS_xxx to I2C_CLASS_xxx (to be used both for 
> drivers and adapters)
> - add new I2C_CLASS_ALL and I2C_CLASS_SOUND classes

Mmm, I once proposed that I2C_ADAP_CLASS_SMBUS would be better renamed
I2C_ADAP_CLASS_SENSORS (so I2C_CLASS_SENSORS now). What about that? I
think it would be great to embed that change into your patch, so that
the name changes only once.

Now that we come to speak about that, I wonder if we would _also_ need a
SMBUS class. SMBus is mostly a subset of I2C, essentially (but not
completely) compatible. It may be useful at some point to know if a chip
is compliant with SMBus or not. I don't think that i2c-core can make use
of this at the moment, nor can I think of concrete examples where this
would be needed. It's just a thought at the moment and I mention it here
in case anyone has comments ;)

For now we can stick to the classes we have (with the SMBUS->SENSORS
change and the new SOUND class). The true SMBUS class can always be
added later if needed, I guess.

BTW, if HWMON is prefered to SENSORS, this is fine with me too, I have
no strong preference.

Thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/