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

[Jon Smirl]

On 6/4/08, David Brownell <david-b at pacbell.net> 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.

I made a mistake comparing this to PCI IDs. I should not have used PCI
IDs as an example and gotten us off on the tangent of not having a
global i2c device namespace.

Adding the address range to search is an unrelated problem to the name
space issue.


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


-- 
Jon Smirl
jonsmirl at gmail.com