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/