Re: [Etherboot-developers] changes checked into CVS

[<ke...@us...>]

>In any event these are the macro the linux kernel uses to deal with
>these numbers internal.  The isa-pnp spec has more information.
>
>#define ISAPNP_VENDOR(a,b,c)	(((((a)-'A'+1)&0x1f)<<2)|\
>				((((b)-'A'+1)&0x18)>>3)|((((b)-'A'+1)&7)<<13)|
>\
>				((((c)-'A'+1)&0x1f)<<8))
>#define ISAPNP_DEVICE(x)	((((x)&0xf000)>>8)|\
>				 (((x)&0x0f00)>>8)|\
>				 (((x)&0x00f0)<<8)|\
>				 (((x)&0x000f)<<8))
>
>The endian issues with the EISA part number drive me crazy.  I think
>the data is normally stored big endian.  But I am confused.  For
>purposes of synching with modules.isapnpmap from the linux kernel=20
>these values produced by the macros are the values we need.=20=20
>
>Using these in etherboot we should be able to have readable ISA part
>numbers as well as fitting everything snuggly into 32 bits.
>
>The linux kernel 3c509.c driver is a good one to work against as it
>actually implements the discovery via the isapnp id's.
>
>If we are going to fix the interface to the id's in 5.0.7 we need to
>be certain we get this correct.

Ok, an interesting issue, the Linux 3c509 driver actually declares
several vendor IDs, depending on the model, including the generic PNP
for compatibles. Conceivably we could distinguish between the models in
Etherboot as we know the configuration registers, though that's not very
useful information to the sysadmin as one Linux driver will handle them
all. A similar situation applies to the ne.c driver. So shall we just go
for the generic ISAPNP_VENDOR('P','N','P'), with the exception of the
3c515 which uses TCM? In which case the vendor_id field is effectively a
constant except for the 515. A pity but there is no ambiguity with the
device id anyway.

Also only a few Linux drivers actually declare this information but the
table you supplied in a previous mail has most of the ones we care
about.