On Wed, 13 Oct 2010 08:54:18 -0700, Jacob Pan wrote: > Jean Delvare Wed, 13 Oct 2010 09:26:54 +0200 > >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. > > it works for us in practice, at least for today. perhaps I am just playing > devil's advocate, but also for the completeness of the logic for future > use. OK, thanks for clarifying. I do not expect this case to ever happen. But if it ever does, then feel free to come back to me with all the details and we'll discuss it again. I don't think it makes sense to add support for a case which doesn't exist, because it's impossible to figure out the best way to fix it until we actually see it. > >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. > > Can we make an explicit bit I2C_CLASS_NO_DETECT so that is is more > explicit? It also allows co-existance with other flags so that we can > handle mixed cases? And what exactly would this bit do? Confused. -- 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
