Linux-kernel mailing list archive 1999-37,: RE: PCI probing

# RE: PCI probing

Bret Indrelee (breti@bit3.com)
Wed, 15 Sep 1999 13:40:21 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jeff Garzik: "Re: MTRR setting and framebuffer driver"
- Previous message: david parsons: "Re: Accountability"

Jeff Garzik [mailto:jgarzik@pobox.com] wrote:
> Bret Indrelee wrote:
[ snip ]
> > Since it is table driven, you may want to add an entry for
> matching by class
> > as well.
>
> For the case of pci_simple_probe() I would like to keep it as small as
> possible, hopefully only covering the most common cases. Are
> there many
> cases where knowing the class _and_ the device ids is more
> valuable than
> knowing only the device ids?

My experience in this area is pretty narrow, so I don't know. I pretty much
only do device drivers for hardware designed here.

I believe the dominate search by far is by vendor and a set of device IDs.
In that case, you might as well just directly call pci_find_device() with
device ID set to any.

If the set of device IDs you handle is close to the number of possible
device IDs, you just set the device ID to PCI_ANY_ID and handle it in the
callback. There is little difference between using your interface and the
normal pci_find_device() call.

If the set of possible devices is much larger than the set you handle, then
it might be nice to eliminate those for a different class of device. It
would be a tradeoff between splitting it out by device ID (not using
PCI_ANY_ID) in the table or having the callback function executed a lot.

I know there are vendors out there that make more than one class of device.
It is in those cases that it might help to search by class as well.

In the end, I doubt it really matters that much. It isn't like searching the
list of PCI devices is performance critical. The only performance issue is
avoiding reading configuration space, since some machines have to disable
interrupts, install an exception handler to handle PCI Abort, or use a mutex
around PCI configuration accesses.

It would be nice if the callback was given the PCI vendor and device ID that
it matched. In the case where they used PCI_ANY_ID, this could save them
from reading the configuration space.

-Bret

-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity

Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Jeff Garzik: "Re: MTRR setting and framebuffer driver"
- Previous message: david parsons: "Re: Accountability"