> As this discussion continues, the more I think that PCI drivers need a
> SIMPLE probe interface, more like my original patch, which just scans
> for a list of PCI ids, and calls a callback for each successful id
> match.
This isn't a useful interface for CardBus/hot-swap-PCI, which means that
there will be two interfaces. Nor does it have support for the common
single-irq/single-base-addr case, which is a source of #ifdef trees.
> Most PCI drivers I've seen don't need to worry about subsystem
> ids, for example, and only driver I've seen needed to worry about
> chipset revision _at probe time_.
The subsystem IDs check is needed. There are a slew of ISA designs that
have been updated using a family of PCI bus interface chips. The primary
IDs are all the same, and the subsystem ID identifies the board. On some
Ethernet adapters the subsystem ID identifies the transceiver type in use.
Matching the subsystem ID also reduces the motivation for Taiwanese board
vendors to butcher the driver. (Yes, I have multiple stories..)
The revision ID and drv_flags field allows drivers to concentrate naming and
capability information into a single table. The 21142, 21143, 21143-TC and
21143-TD all have the same primary ID, but have different names and feature
sets. The first yellowfin chip revision had an Rx filter bug that was fixed
in all other versions.
Of course all of these subsytem and revision checks can be done later, but
then why have a common scan in the first place? Combining the naming and
capability information makes it much easier to update the driver with a new
chip type or name.
> The PCI code already takes care of
> the latency problem that Alan mentioned, in response to my original
> patch.
Not on older kernel versions.
> Maybe I will whip up a pci_simple helper function interface, while the
...
> This simple interface would also be useful for the somewhat-common case
> of a driver which must do a standard PCI probe (duplicating code), and
> then something hairy and device-specific to the PCI registers. The VIA
> IDE timings driver I am hacking on is an example of this.
If you have hairy and irregular things to do with your PCI configuration
space, you are better off not trying to use a table-driven approach.
Making an interface that can handle every theorized weird case will result
in a something more complex than the original problem.
Our goal should be to distill the common cases to their essential differences.
> How does a driver define an arbitrary probe order under your scheme?
> Forcing a driver to depend on the order of the values returned from a
> pci_find_class() iteration is not always desireable.
There is a fundamental conflict in specifying device order and supporting
dynamically inserted devices.
> > > > Does allow backwards- and forward-compatible drivers?
> > > Nothing prevents the interface from being backported to older kernels
> > > verbatim.
> > Sure, you can "backport" the interface just by applying all the kernel
> > patches to bring the kernel up to the latest version. That's not what I
> > mean.
> Keyword: verbatim. A driver using my PCI helper patch should be able
> to recompile under 2.2.x or 2.0.x without changes. Only the helper
> implementation would change. Although, my structure definitely needs a
> 'name' member, as older pci_dev structs did not have such a member.
You patch means the driver still needs an #ifdef tree for many aspects of
the PCI scan interaction.
-
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/