On Wednesday 04 June 2008, Jon Smirl wrote: > > 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. > > I don't believe this is has to be true although usually it is. A
For driver model conformant subsystems, it's always true. > driver is passed in information from the bus core on the probe > function. That is, a bus-specific struct wrapping a "struct device" instance. > It then looks at that information and decides if it wants to > bind. Drivers return true/false if they want to bind. Wrong. The probe returns zero if it bound, else negative errno. Those functions don't return booleans. > If they return > false the device structure is destroyed (or reused for the next probe > call). No. The struct device is not destroyed at that time for ANY driver model code I've seen in Linux. Destroying it would prevent driver modules from binding to that device when they get loaded later. > There is nothing in the model that requires an actual device to be > present for a probe call to happen. Well, a "struct device" must be present, but there might not be hardware backing it. Each particular bus infrastructure instantiates those structs in bus-specific ways. > A perfectly valid reason for > refusing to bind would be not having hardware present at the address. True. > This is how older ISA drivers are loaded that predate PNP. Depends somewhat on what flavor of PNP you mean too. > They search > for the hardware in the probe function. That's probably why it is > called "probe" but that predates my involvement in Linux. And that legacy model is something that's getting removed everywhere practical. Such "legacy drivers" don't support hotplugging or most of the other mechanisms defined by the driver model, since they have the driver creating the device structs (instead of bus infrastructure). You're right that this is why the name probe() remains. I prefer the bind()/unbind() names too. - Dave _______________________________________________ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
