On Wed, 4 Jun 2008, Jean Delvare wrote: > On Wed, 4 Jun 2008 15:28:54 -0400, Jon Smirl wrote: > > On 6/4/08, Jon Smirl <[EMAIL PROTECTED]> wrote: > > > On 6/4/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > > > > > This patch set demonstrates a new concept which I would like to add to > > > > the i2c subsystem. It is named "i2c listeners" and is based on the > > > > following structure: > > > > Could the existing API be used something like this? > >
> > scans the registered driver structures looking for class matches. When > > a match is encountered it repeatedly calls the driver's probe function > > with the addresses from the range. Driver returns true/false on each > > probe which triggers creation of the device. > > The driver's probe function is, by definition of the device driver > model, called on an existing device. So the probe function cannot > decide whether the device should be created or not - it's too late at > this point. 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 and a device is created if anything responds. The generic bus code tries to match each device to a driver or drivers 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? When a new bus is created, the i2c core scans it and creates a device for each chip that responds. Each driver's probe function is called in turn on the device and it gets to device if it wants to drive it or not, probably based on i2c address range since there is usually little else to go on. _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
