Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver

[Jean Delvare <khali@linux-fr.org>]

Hi Mike,

On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote:
> On 3/21/07, Jean Delvare <khali@linux-fr.org> 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