On Fri, 2004-10-01 at 07:52, Greg KH wrote: > On Fri, Sep 24, 2004 at 10:21:08PM +0200, Michael Hunold wrote: > > If we have a PCI card where we exactly know what we are doing, we can > > use the NO_PROBE flag to effectively block any probing and can use the > > proposed interface to manually connect the clients. > > But why? The .class feature can accomplish this too. Just create a new > class for this type of adapter and device. Then only that device will > be able to be connected to that adapter, just like you want to have > happen, right? Either the i2c devices need to be able to support a list of permitted adapters, or the i2c adapters need a list of permitted clients. A single class isn't adequate. Consider the following scenario: The FooTV123 has multiplexor MX3R0K3 and frontend XYZZY, the TVMatic3000 has frontend XYZZY and multiplexor MX31337, and the FooTV124 has multiplexor MX31337 and frontend FR012. All three cards are installed in the same machine. In the worst case the probe code for MX31337 puts MX3R0K3 into a state that requires a hard reset. Manual connection of clients makes it easier to develop a driver outside the kernel tree, then merge it when ready, without having to allocate a number from a central authority. Creating the adapter with a list of permitted clients is also an adequate solution for a bus like I2C which doesn't properly support probing. The OCP bus on PowerPC has no explicit probing, and uses a similar approach of creating the bus with a list of the devices possible for that PowerPC model. - Adrian Cox Humboldt Solutions Ltd.
