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.
_______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
