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

[Trent Piepho]

On Wed, 4 Jun 2008, David Brownell wrote:
> On Wednesday 04 June 2008, Trent Piepho wrote:
> > Couldn't you say the probe function is called on a potential device?  The
> > probe function can return -ENODEV, in which can other driver's probes get
> > called, and it's perfectly ok if no driver binds to it.
> >
> > The way PCI works, is that when a new pci bus is created, each address is
> > probed
>
> ... by config space accessors which all PCI devices support.

PCI is not immune to broken hardware.  It's much better than I2C of course,
which doesn't even have a scanning method devices are supposed to follow.

> > and a device is created if anything responds.  The generic bus code
> > tries to match each device to a driver or drivers
>
> ... using a formally managed set of product identifiers.

There are plenty of PCI devices with broken ids.

> >	 and calls those drivers'
> > probe functions.  The drivers don't have to claim the device in the probe
> > function.  The bus code handles all the cases of a driver or bus getting
> > added or removed in various orders.
> >
> > So why can't I2C do this too?
>
> No such product identifiers, and in general no way to tell
> what's sitting at a given address.  And in fact, there's no
> sure way to tell if a device is present there, since when
> an I2C device is busy, it's not required to ack its address.

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?
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.