Messages in this thread | | | From | Bret Indrelee <> | Subject | RE: PCI probing | Date | Wed, 15 Sep 1999 13:40:21 -0500 |
| |
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/
| |