Messages in this thread | | | Date | Wed, 22 Sep 1999 18:48:39 +0300 | From | Matti Aarnio <> | Subject | Re: 2.3.18ac8 doesn't detect tulip (again!) |
| |
Continuing the topic..
On Wed, Sep 22, 1999 at 05:51:47PM +0300, Matti Aarnio wrote: > > Having it one way around for pci_id and the other for > > the subsystem is lunacy. > > > > I think the subsystem idea in the tulip driver should > > be flipped instead ?
Only if you recode all matcher lists...
> How the chip->id.pci_mask and chip->id.subsystem_mask are made ? > And what are the values that are then compared. > > This relates to the question of how those two variables must be > constructed.
The 'struct pci_id_info' is so far used only by network driver cards which Donald Becker has written ( in drivers/net/*.c ), and they have hand-coded matcher literals:
struct pci_id_info { const char *name; struct match_info { int pci, pci_mask, subsystem, subsystem_mask; int revision, revision_mask; /* Only 8 bits. */ } id; enum pci_id_flags_bits pci_flags; int io_size; /* Needed for I/O region check or ioremap(). */ int drv_flags; /* Driver use, intended as capability flags. */ };
static struct pci_id_info pci_id_tbl[] = { {"Yellowfin G-NIC Gigabit Ethernet", { 0x07021000, 0xffffffff}, PCI_IOTYPE, YELLOWFIN_SIZE, FullTxStatus | IsGigabit | HasMulticastBug | HasMACAddrBug}, {"Symbios SYM83C885", { 0x07011000, 0xffffffff}, PCI_IOTYPE, YELLOWFIN_SIZE, HasMII }, {0,}, }; ... static struct pci_id_info pci_tbl[] = { { "Digital DC21040 Tulip", { 0x00021011, 0xffffffff }, TULIP_IOTYPE, TULIP_SIZE, DC21040 }, { "Digital DC21041 Tulip", { 0x00141011, 0xffffffff }, TULIP_IOTYPE, TULIP_SIZE, DC21041 }, { "Digital DS21140 Tulip", { 0x00091011, 0xffffffff }, TULIP_IOTYPE, TULIP_SIZE, DC21140 }, { "Digital DS21143 Tulip", { 0x00191011, 0xffffffff }, TULIP_IOTYPE, TULIP_SIZE, DC21142 }, ...
Right, so these magic literal tokens have low 16 bits of vendor ID (0x1011 = DEC), while upper 16 bits of those 32- bits are device id. (0x0019 = DEC 21143 - per 21143 docs) There is *one* driver where subsystem_mask == 0, but revision_mask is non-zero. That isn't Tulip.
Thus while the original change of pci_id formation is very sensible (to match how Becker's drivers are written), the subsystem does not have any *usage* where to match it.. (Especially not Tulip..)
With this in mind, perhaps subsys-vendor should stay as the low part, like Alan says.
> > Alan /Matti Aarnio <matti.aarnio@sonera.fi>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |