On PCI ids being embedded in drivers...

[Alex Deucher]

On 9/28/05, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote:
> I've been a bit frustrated by the time it takes a PCI ID to get
> reported back to the source maintainers, eventually committed into
> source, picked up by the various Linux packagers, and pushed out
> via distribution (yum or whatever).
>
> Does it even make sense to (1) fragment this information which
> is pretty much common amongst various drivers (except maybe
> some driver-specific flags such as LVDS support, etc. which
> could be defined in a driver-defined field), (2) compile this
> information into the drivers?
>
> Why not have a "PCI" module that handles scanning for ID's
> and picking up the associated information from the tabular file?
>
> Since it only needs to be done at startup, parsing overhead isn't
> a very convincing argument...  worst case, we could do it as a
> data-only .so that gets linked in, but that users could update and
> rebuild themselves (of course, that means that the compiler/linker
> would have to be present to do so).  Only possible hitch I can
> think of is that a voluminous table of data is extra space and
> start-up overhead for embedded systems...  But for most, having
> plug-n-play is a good thing.
>
> What do you all think?  Could this make it onto the 7.1 roadmap?
>
> -Philip
>

You can alreay support chips with missing pci ids using the chipid
option.  Just specify a compatible id, eg:

chipid 0xXXXX

where XXXX is the chip id of another compatible supported chip

If that doesn't work, then your chip needs more work than just adding
pci ids, in which case it make sense to grab the latest from cvs.

Alex