[tulip] FA511 not passing much data

[Donald Becker]

On 10 Jan 2003, Jarl Friis wrote:
> Donald Becker <becker@scyld.com> writes:
> > On 9 Jan 2003, Jarl Friis wrote:
> > 
> > A board reseller isn't required to have an ID, only the people making
> > the PCI chips.  A PCI device must have an ID, and may optionally have a
> > subsystem ID.
...
> Thank you *very* much for clearing these things up. I always wondered
> how those numbers were intended to be used. Do you have any URL on
> documents describing these usage information?

Hmmm, URL... no.  The standards documents are very precise, in a not a
not immediately descriptive way.  The book I typically grab for PCI
questions is "PCI System Architecture".  (That series of book is somehow
useful, concise and accurate while still feeling badly written and
repetitive.)

> So in short one can think of the main PCIID as the hardware/chip
> identifier ment for technicians (driver developers), whereas the
> subsystem ID is for branding, marketing and value added resellers. Is
> that correct?

Yes.  To put a MS-Windows-centric spin on it: a vendor wants MS to do
all of the work validating and updating a driver that works with the
chip (based on the PCI ID), yet still show the vendor's name when the
card is detected as if the vendor wrote the driver (based on the
Subsystem ID).

> I don't know anything about 2+22+24 bit IEEE station address, but it
> seems good that the same 16+16 bit system is used for USB devices.

The first three bytes of the "Ethernet station address" identify the NIC
vendor, with the vendor assigning the remaining three bytes in a "dense"
manner (presumably sequentially).  Each address block costs a few
kilo-$.  Some vendors, such as 3Com and Intel, have shipped so many
devices that they have multiple three byte prefixs.

> > No. The list that Linux uses was apparently user-submitted guesses.
> > And once there is an entry, it is never validated.
> 
> I will mail the pci.ids maintainer about this issues and talk to him
> about things. Thank you very much. The list is never validated, but it
> is not too difficult to update with more correct information.

One problem is when the name is put into the kernel.  Now the kernel is
wrong for all time.

Now for the _important_ question: How does the affect Donald Becker?  I
get a bunch of email where people insist that my driver and diagnostic
code is broken based on the name mismatch.

> So what you are saying is that the entry for the main PCI ID 1317:1985
> should actually be "Comet/Centaur chip" opposed to "Fast
> Ethernet 10/100" as it is now, do I get this correct?

Yes.

 1317 == ADMtek
 1317:1985 == ADMtek Centaur-C 10/100 Ethernet

> And in subsystem entry 1317:1985-1385:511a There should be "NETGEAR
> FA511" and not "ADMtek AL985 Centaur-C [NETGEAR FA511]" as I have
> submitted for now, correct?

Correct.

> Further the entry 100B:0020 should be "DP83815" opposed to "DP83815
> (MacPhyter) Ethernet Controller"

Perhaps correct.
I've only seen the name 'MacPhyter' from the table.  I'm not certain
that it's correct.  But if it is correct, the only problem I have with
the current entry is that the "Ethernet Controller" phrase is
inconsistent with other entries.

 and 100B:0020-1385:f311 should be
> "NETGEAR FA311" which is missing now.

Correct.

> Do you have any comments on the fact that the list currently contains
> "FA311" for the main PCI ID entry 1385:f311 ? or is this yet another
> users that have incorrectly entered a subsystem ID into a main ID's entry?

Perhaps should say "Netgear FA311";  there should be some consistency
with repeating the vendor name.

There should never be a conflict between primary and subsystem IDs --
there only needs to be a single database.

-- 
Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993