[lkml]   [2005]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] add driver matching priorities
    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 {
    > > };
    > >
    > > 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).


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:10    [W:0.022 / U:8.576 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site