Messages in this thread | | | Date | Fri, 10 Sep 1999 22:39:35 -0400 (EDT) | From | Donald Becker <> | Subject | Re: [patch] pci probing |
| |
On Fri, 10 Sep 1999, Jeff Garzik wrote:
> Subject: Re: [patch] pci probing > > > Can you elaborate on what my patch lacks? My patch seems much more > > > flexible than Don's method used in tulip.c and 3c59x.c at least. In > > > fact if you rip out all the net-driver-specific stuff from struct > > > pci_id_info, his method looks a lot like mine (without a couple > > > features). > > Have a look on cesdis.gsfc.nasa.gov:/pub/linux/drivers/v2.3/
Here is a URL for mail readers that make that more useful: http://cesdis.gsfc.nasa.gov/linux/drivers/kern-2.3/index.html ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3/
> > The pci scan code in that does pci scans but also handles stuff like checking > > latency and correcting it when needed .. > Besides the obvious net-centric code, his code was only more flexible
There is very little that is network-specific about the code. It's certainly not "network centric".
> such that there was a per-entry callback. My flexibility came from > being able to specify probe order, per-entry and per-probe data pointers > (dev_data, drvr_data), and matching a limited number of devices.
Questions: Does your approach handle hot-swap PCI and CardBus with a single driver? What about ACPI and Wake-on-*? Does allow backwards- and forward-compatible drivers? With the existing user-level PCMCIA implementation as well. Do you have a driver to demonstrate CardBus suspend, eject and resume? Merely asserting that it will handle it isn't good enough -- it took me dozens over versions to get it right, and I've been writing Linux PCMCIA drivers since '93, PCI drivers since '94 and several years
I have converted (and tested) a dozen network and character drivers to my scan code. Four of those support both CardBus and PCI devices, and presumably hot-swap PCI (I don't yet have test hardware).
Remember that any change in interface code triggers a massive amount of work. A change that takes only a few minutes to make may take me hours or days for me to update and retest my drivers, and is a contining testing workload over the next few years. So you must the interface close to right the first place, and that means private development and testing.
> What do you think of this merge of Donald's code, attached? Most of the > PCI_COMMAND stuff is net-driver-specific and absent in my patch, as it > is not applicable to general use.
??? The PCI_COMMAND stuff isn't a whim. It, like the latency correction and ACPI wake-up, is required for some systems.
- 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/
| |