RE: Putting PCI-class/vendor/deviceinfo into source of PCI-driver

Bret Indrelee (bindrelee@sbs-cp.com)
Sat, 4 Dec 1999 16:01:36 -0600

Martin Mares [mailto:mj@suse.cz] wrote:
> Jochen Dolze wrote:
> > To avoid this and to be able to create automatic kernel configs, one
> > solution could be to add more module info into the source
> of pci-capable
> > drivers (e.g. 3c59x.c from Donald Becker):
> >
> > MODULE_PCICLASS("0200");
> > MODULE_PCIVENDOR("10b7");
> > MODULE_PCIDEVICE("5900,5950,5951,5952,5900,9000,9001,9005,9055");
> >
> > Then scripts could look for a driver class "0200" (Ethernet
> controller)
> > from vendor "10b7" (3Com) which supports the cards shown in
> PCIDEVICE
> >
> > If there are two or three (or more) Vendors with same chips (like
> > in the Tulip-driver) the vendor string can look like this:
> >
> > MODULE_PCIVENDOR("1011,11ad,10d9");
> >
> > Any comments to that?
>
> I'm preparing a very similar mechanism for my PCI hotplug
> code. It should
> work this way:
>
> o Each driver contains a list of supported vendor+device
> pairs (likely
> a more general ID's, so that they can be used for
> ISAPnP, PCMCIA and
> CardBus as well).

I would suggest instead that they include a bus type (PCI, USB, 1394, SBus,
etc) so that they can (where available) use the native ID listings.

PCI, SBus, NuBus, MicroChannel, 1394, EISA, and as I recall USB all have
different methods for identifying a device on the bus. It comes out to
matching integer properties where what properties and what values are bus
dependent.

Make the code that matches devices to drivers accept various parameters
dependent on bus allows you to avoid writing this all over again when the
next auto-config bus comes out.

> o Depmod extracts these data and stores them in modules.dep.
> o If a new device gets inserted, the kernel looks up its
> ID in all currently
> loaded drivers and asks them if they want to handle the device.
> o If no driver is found and kmod is enabled, modprobe gets
> called to find
> a driver corresponding to the device ID according to
> modules.dep and load
> the appropriate module.

Wouldn't it be cleaner to do a separate driver program that does all this?
Use the existing kmod interface to do the linking and loading, but include
the moddep stuff (that you are talking about having to change anyways) and
make it part of the same program.

You would create a deamon to do device loading. It gets notified by the
kernel each time a new device is added to the bus, and searches (in app
space) for a matching module. Once it finds one, it loads it. Since everyone
keeps on wanting a way for a driver to load a file (for microcode and such),
you could provide the hooks for that at the same time.

In another message you mentioned wondering how to pass parameters. Might I
suggest that the module doing the loading search for a <device>.conf file
whereever it finds the device object file?

Example:
Module is btp.o, named btp.

The new interface would be equivilent to:
/sbin/insmod btp `cat /etc/modules/btp.conf`

Where the btp.conf file is automatically checked for by the insmod or it's
replacement and parsed the same way that parameters would be. Parameters
entered on the command line should override the settings in the file.

-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/