On Thu, 2005-02-10 at 00:41 -0800, Greg KH wrote: > On Fri, Jan 28, 2005 at 05:30:04PM -0500, Adam Belay wrote: > > Hi, > > > > This patch adds initial support for driver matching priorities to the > > driver model. It is needed for my work on converting the pci bridge > > driver to use "struct device_driver". It may also be helpful for driver > > with more complex (or long id lists as I've seen in many cases) matching > > criteria. > > > > "match" has been added to "struct device_driver". There are now two > > steps in the matching process. The first step is a bus specific filter > > that determines possible driver candidates. The second step is a driver > > specific match function that verifies if the driver will work with the > > hardware, and returns a priority code (how well it is able to handle the > > device). The bus layer could override the driver's match function if > > necessary (similar to how it passes *probe through it's layer and then > > on to the actual driver). > > > > The current priorities are as follows: > > > > enum { > > MATCH_PRIORITY_FAILURE = 0, > > MATCH_PRIORITY_GENERIC, > > MATCH_PRIORITY_NORMAL, > > MATCH_PRIORITY_VENDOR, > > }; > > > > let me know if any of this would need to be changed. For example, the > > "struct bus_type" match function could return a priority code. > > > > Of course this patch is not going to be effective alone. We also need > > to change the init order. If a driver is registered early but isn't the > > best available, it will be bound to the device prematurely. This would > > be a problem for carbus (yenta) bridges. > > > > I think we may have to load all in kernel drivers first, and then begin > > matching them to hardware. Do you agree? If so, I'd be happy to make a > > patch for that too. > > I think the issue that Al raises about drivers grabbing devices, and > then trying to unbind them might be a real problem.
I agree. Do you think registering every in-kernel driver before probing hardware would solve this problem? > > Also, why can't this just be done in the bus specific code, in the match > function? I don't see how putting this into the driver core helps out > any. The match priority is a chararistic of the driver and how it's implemented rather than the bus's matching mechanism. The type of match doesn't necessarily reflect the driver's ability to control the hardware (ex. a driver could match on a specific PCI id but only provide generic support for the device). Also, I think this is a feature that would be useful for all of the buses. Therefore, it would seem implementing it in the driver core might result in the least code duplication. The second "*match" function in "struct device_driver" gives the driver a chance to evaluate it's ability of controlling the device and solves a few problems with the current implementation. (ex. it's not possible to detect ISA Modems with only a list of PnP IDs, and some PCI devices support a pool of IDs that is too large to put in an ID table). Thanks, Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/