Hi Mike, On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote: > On 3/21/07, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > + p_adap->class = I2C_CLASS_ALL; > > > > This pretty much voids the point of these probing classes. You should > > only select the classes matching devices which may actually be probed > > for on this bus. If different boards have different needs, get the > > right classes from the platform data. > > i asked about the class issue previously specifically for this bus > driver and was told that they werent really fully defined ... the > on-chip I2C interface on the Blackfin chip can handle any I2C device > which is why i added this line
Grep for I2C_CLASS_ and you'll see that the classes are defined and used consistently in the kernel tree. Maybe just not by the embedded folks. Also note that what matters is not the type of devices that can be connected on the bus, but the type of devices that can be probed for. This was essentially the same so far (general probing was the only way to instantiate an i2c device), but the new i2c-core code that will go into 2.6.22 will make it different. These classes will probably be less used in the future. > any examples of how to go about doing it via boards ? i dont see any > other I2C bus driver doing it that way ... I don't think many drivers from the embedded world do it properly. But they don't appear to define any class at all, which means that in practice they keep most regular i2c drivers out of their bus. Pretty much the contrary of what you're doing with I2C_CLASS_ALL. It's really up to you, but if you set the class to I2C_CLASS_ALL, don't later come and complain that other drivers keep probing your I2C bus and possibly attach to your I2C devices. You asked for it. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
