"Soren S. Jorvang" <soren@t.dk> writes:
> > (1) what is the namespace for subsystem vendor IDs?  (I've heard "same
> > as vendor IDs," but haven't had C&V quoted at me, so i'm
> > skeptical. 8-)
> 
> 'Subsystem Vendor IDs can be obtained from the PCI SIG [...]'
> 
> Whatever that means.

Right.  So, i'll reiterate: some people (who are not really
'authoritative') have told me "same as Vendor IDs," but i've not heard
any authoritative source say that.

And then there's the question of whether or not hardware designers
will actually pay attention to that.  8-)


> I have two devices with non-zero sub-ID fields.
> 
> 			vendor	product	subsys	subvendor
> Matrox Millenium G200	0x102b	0x0521	0xff03	0x102b
> Ensoniq AudioPCI	0x1274	0x5000	0x4c4c	0x4942

I've seen several (see 'puc', and have heard of several more).


> Anyway, what is important in relation to NetBSD is whether
> drivers need the sub IDs for matching/attachment, and I
> believe that is not the case.
>
> It seems to me that one driver should be sufficient for
> any number of devices with different sub-IDs but the
> same one (or more) product ID.

In general, vendor and device ID are sufficient, but in some cases
they are not.  An example is 'puc,' and I can think of some others
that i probably shouldn't discuss.  8-)


> I think all this is necessary here is adding somewhat like
> this little diff and letting the drivers sort it out.

*sigh*  I'm not keen on that diff, because it makes an existing
problem worse.  8-)

Right now, the PCI register defines (except for the common header
bits) are 'right' for pretty much only type-0 headers.  They need to
be gutted, and redone in a way that makes it possible to add
definitions for the other header types.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.