Jeff Garzik wrote:
>
> Remember first that eepro100 is generally MMIO, so you the following is
> in effect:
> #define inw writew
readw, I hope :)
One thing I've noticed about the new PCI scanning code is that
it unconditionally maps both IO and MEM space. So even if you
don't _want_ IO (or mem) mapping, you get both. Whereas the
old code allowed you to select whether or not each address
space should be enabled. Is this kosher?
BTW, in eepro100 this:
#ifdef USE_IO
#define SPEEDO_IOTYPE PCI_USES_MASTER|PCI_USES_IO|PCI_ADDR1
#define SPEEDO_SIZE 32
#else
#define SPEEDO_IOTYPE PCI_USES_MASTER|PCI_USES_MEM|PCI_ADDR0
#define SPEEDO_SIZE 0x1000
#endif
appears to be a holdover from the previous generation
of PCI code and is now unreferenced.
Thirdly, Don's PCI scanning code allows you to specify bitmasks
to be used when comparing device and vendor IDs. This is kind
of neat, because it allows you to say that this driver supports
a (power-of-two) _range_ of device IDs, so if in a year's time
the manufacturer comes out with a new card and increments the
device ID, the driver still has a good chance of working. A
bit of future-safety.
Could we add this capability to the current PCI scan code? If
we invert the mask and put it right at the end of struct
pci_device_id it will be upward compatible with the existing
source.
Here's what I mean:
--- linux-2.3.99-pre9-1/include/linux/pci.h Wed Apr 26 22:53:05 2000
+++ linux-akpm/include/linux/pci.h Sat May 20 10:49:41 2000
@@ -524,6 +524,7 @@
unsigned int subvendor, subdevice; /* Subsystem ID's or PCI_ANY_ID */
unsigned int class, class_mask; /* (class,subclass,prog-if) triplet */
unsigned long driver_data; /* Data private to the driver */
+ unsigned int device_mask; /* Mask for matching device ID's */
};
struct pci_driver {
--- linux-2.3.99-pre9-1/drivers/pci/pci.c Mon May 15 21:24:14 2000
+++ linux-akpm/drivers/pci/pci.c Sat May 20 10:42:18 2000
@@ -283,7 +283,7 @@
{
while (ids->vendor || ids->subvendor || ids->class_mask) {
if ((ids->vendor == PCI_ANY_ID || ids->vendor == dev->vendor) &&
- (ids->device == PCI_ANY_ID || ids->device == dev->device) &&
+ (ids->device == PCI_ANY_ID || ids->device == (dev->device & ~ids->device_mask)) &&
(ids->subvendor == PCI_ANY_ID || ids->subvendor == dev->subsystem_vendor) &&
(ids->subdevice == PCI_ANY_ID || ids->subdevice == dev->subsystem_device) &&
!((ids->class ^ dev->class) & ids->class_mask))
And here's how I tested it. Note that with this change, the
0x10b7/0x9050 device now matches both 0x10b7/0x9055 and
0x10b7/0x9058 via the 0x000f bitmask.
Index: drivers/net/3c59x.c
===================================================================
RCS file: /opt/cvs/lk/drivers/net/3c59x.c,v
retrieving revision 1.84
diff -u -r1.84 3c59x.c
--- drivers/net/3c59x.c 2000/05/20 00:48:01 1.84
+++ drivers/net/3c59x.c 2000/05/20 01:01:00
@@ -296,7 +296,6 @@
CH_3C905_1,
CH_3C905_2,
- CH_3C905B_1,
CH_3C905B_2,
CH_3C905B_FX,
CH_3C905C,
@@ -358,8 +357,6 @@
{"3c905 Boomerang 100baseT4",
PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII, 64, },
- {"3c905B Cyclone 100baseTx",
- PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY, 128, },
{"3c905B Cyclone 10/100/BNC",
PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY, 128, },
{"3c905B-FX Cyclone 100baseFx",
@@ -409,8 +406,7 @@
{ 0x10B7, 0x9050, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905_1 },
{ 0x10B7, 0x9051, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905_2 },
- { 0x10B7, 0x9055, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_1 },
- { 0x10B7, 0x9058, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_2 },
+ { 0x10B7, 0x9050, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_2, 0x000f },
{ 0x10B7, 0x905A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905B_FX },
{ 0x10B7, 0x9200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C905C },
{ 0x10B7, 0x9800, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CH_3C980 },
-- -akpm-- 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/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:18 EST