Hi Trent, On Wed, 4 Jun 2008 17:40:05 -0700 (PDT), Trent Piepho wrote: > 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?
There are two key properties of the i2c listeners: 1* They live besides the driver model and complement it, rather than replacing it. They have to, because the driver model cares about device enumeration and device/driver binding, NOT device detection and identification in the hardware sense of the terms. 2* Listeners allow the i2c-core to delegate the device detection / identification to the drivers themselves (avoiding a fat, slow and unmaintainable centralized detection routine) but the drivers are still not creating the devices themselves (so the device driver model's spirit is respected.) > 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. That's correct, but the fact is that for example all I2C-based hardware monitoring drivers are already doing their best to identify the chips they support, with good success. The question is not whether we'll do that or not - we _have_ to do it in many cases. The question is how we implement it. Currently we have a separate binding model for this case, I'm proposing something that would instead fit in the standard binding model, only adding the part that the binding model doesn't cover. This is certainly an improvement, I don't think anyone can deny this. Not to say that my proposal cannot be improved further - it certainly can. -- Jean Delvare _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
