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