Hi Jacob, On Tue, 12 Oct 2010 11:01:40 -0700, Jacob Pan wrote: > What if you have mixed devices under one adapter with some prefer to > have detect funtion some not. Devices don't have detect functions. Drivers do. > Then all detect functions will be ignored > if i2c adpater class code is 0. The granularity of information provided by > our FW is per i2c device. > > Seems we have three cases: > 1. adaptor class = 0, no detect > 2. adaptor class !=0, FW provide address via board info, no detect > 3. adaptor class !=0, no FW board info, do detect by default, but should > allow platform code override > > I would think we need a global flag for case #3. You complain that the granularity of the current implementation is insufficient, but you propose to solve that problem using a _global_ flag? This doesn't make sense, sorry. There are actually two main cases, not three: 1. Adapter class == 0, no detection, platform data provides all device information. 2. Adapter class != 0, detection of all devices, no platform data. Mixed cases aren't supported, because it is expected that all devices are declared as platform data, or none is. This seems to work OK so far for everybody. If it doesn't work for you, please explain why, in details. Note though that there is some level of granularity because the adapter class is a bitfield. So it is possible to declare all I2C devices as platform data except the hardware monitoring devices, for example, and set adapter class = I2C_CLASS_HWMON. There aren't many bits really used, BTW, mostly I2C_CLASS_HWMON and I2C_CLASS_SPD, and the trend is to remove the unused class flags rather than to add new ones. However, if you need a new I2C_CLASS flag, this can certainly be done. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
