Andrew Morton wrote:
>
> 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?
It is not mapping both I/O and MMIO space, it is merely reserving the
resource regions for both MMIO and PIO. I think this is a good idea
because it eliminates any chance of those resources being allocated to
anyone else.
It's basically a harmless sanity check I put in...
> 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.
SPEEDO_SIZE should probably be used in the ioremap() call.
> 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.
I wouldn't feel so secure, making predictions about the future...
> 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.
Just use PCI_ANY_ID and implement the more fine-grained scanning inside
the driver.
Jeff
-- Jeff Garzik | Liberty is always dangerous, but Building 1024 | it is the safest thing we have. MandrakeSoft, Inc. | -- Harry Emerson Fosdick- 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