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

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

Hi Trent,

On Wed, 4 Jun 2008 17:40:05 -0700 (PDT), Trent Piepho wrote:
> So scanning an I2C bus doesn't work as well as with PCI, we all know that.
> How does creating a new "i2c listeners" system solve any of these problems?

There are two key properties of the i2c listeners:

1* They live besides the driver model and complement it, rather than
   replacing it. They have to, because the driver model cares about
   device enumeration and device/driver binding, NOT device detection
   and identification in the hardware sense of the terms.

2* Listeners allow the i2c-core to delegate the device detection /
   identification to the drivers themselves (avoiding a fat, slow and
   unmaintainable centralized detection routine) but the drivers are
   still not creating the devices themselves (so the device driver
   model's spirit is respected.)

> You still want to probe for a chip and there's no foolproof way to do that,
> and there's still no way to know for sure what chip you have found.

That's correct, but the fact is that for example all I2C-based hardware
monitoring drivers are already doing their best to identify the chips
they support, with good success. The question is not whether we'll do
that or not - we _have_ to do it in many cases. The question is how we
implement it.

Currently we have a separate binding model for this case, I'm proposing
something that would instead fit in the standard binding model, only
adding the part that the binding model doesn't cover. This is certainly
an improvement, I don't think anyone can deny this. Not to say that my
proposal cannot be improved further - it certainly can.

-- 
Jean Delvare

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