On 6/4/08, David Brownell <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
