Re: [PATCH 0/4] i2c: Introduce i2c listeners

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

On Wed, 4 Jun 2008 15:28:54 -0400, Jon Smirl wrote:
> On 6/4/08, Jon Smirl <jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 6/4/08, Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org> wrote:
> >  > Hi all,
> >  >
> >  >  This patch set demonstrates a new concept which I would like to add to
> >  >  the i2c subsystem. It is named "i2c listeners" and is based on the
> >  >  following structure:
> 
> Could the existing API be used something like this?
> 
> Drivers register with i2c core using standard driver registration.
> Class and address ranges are exposed in a structure like PCI IDs. I2C
> can make up it's own ID structure equivalent to the PCI IDs one.

No, no, no. I've been repeating it many times already: I2C device
addresses are NOT IDs. If you're even thinking of going in this
direction, you're plain wrong, sorry. Many devices share the same
address, and many devices can use different addresses. The address is
really only one attribute of an I2C device, amongst many others. It's
not an identifier.

Please also realize that we _do_ have "IDs" for I2C devices by now. As
there are no standard numbers as PCI has, we use arbitrary strings
(typically the device name). That's what new-style drivers use for
device binding since kernel 2.6.26. And you can't have more than one ID
format for a given subsystem, and we don't want to break new-style
drivers, so thinking about a radically different form of IDs for the
i2c subsystem is a waste of time: it's simply not going to happen.

> When a new adapter/bus is created i2c core gets the event. Core then

Side question: why would i2c-core want events when adapters are
created, given that it does create them itself?

> scans the registered driver structures looking for class matches. When
> a match is encountered it repeatedly calls the driver's probe function
> with the addresses from the range. Driver returns true/false on each
> probe which triggers creation of the device.

The driver's probe function is, by definition of the device driver
model, called on an existing device. So the probe function cannot
decide whether the device should be created or not - it's too late at
this point.

One thing that we could consider though is merging i2c_listener into
i2c_driver. For some reason I had not considered it - but I somehow
expect funny locking issues if we do that.

> Why do drivers need the bus creation (attach/detach adapter) events?

Originally, to probe the adapters in search of devices to support. I
seem to remember that some V4L/DVB drivers do more than that in their
attach_adapter callback, but I need to take a closer look. And i2c-dev
deserves particular attention, as it needs to do bookkeeping of all
the adapters that are present. In fact we might have to implement
attach/detach adapter just for i2c-dev. More on that after I have read
the code again.

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c