[ofa-general] vendor_id in struct ib_device_attr

Jason Gunthorpe jgunthorpe at obsidianresearch.com
Mon Jun 23 13:41:03 PDT 2008


On Mon, Jun 23, 2008 at 01:10:09PM -0700, Roland Dreier wrote:
>  > Well, the way PCI ID usually works is that the sillicon vendor bakes
>  > their ID into the chip and then allows downstream vendors to alter
>  > the subsytem id, ie:
> 
>  > 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)
> 
> That's one model of how things work, but this is actually a good
> example: look in the tg3.c driver for this chip -- not all the vendor
> IDs are Broadcom.

Right, but we don't know what caused this. At least two of the
non-broadcom IDs have later special casing in the driver, which
suggests they may actually be different sillicon - produced under
contract, perhaps... Considering the wide use of tg3's by 3rd parties
it seems that having such a small number of non-broadcom ids does
suggest the model works and is accepted by the vendors.

If IBA vendor_id is thought to be the same as PCI vendor ID - where it
is the silicon manufactures OUI, then that is great, the iwarp folks
should follow the same model, and derive their vendor OUI/device_id
from the PCI ID. But if it is closer to the PCI subsystem ID then it
is pretty useless...

I don't have a wide enough collection of cards to tell what people
have been doing to date..

Personally, I feel the intention of the spec was to follow the PCI
model, it does introduce subsystem ID's for the IO controller
stuff, for instance. But that is moot if people have already produced
alot of equipment that does differently :)

Jason



More information about the general mailing list