> 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/