Messages in this thread | | | Date | Sun, 12 Sep 1999 17:20:25 -0400 | From | Jeff Garzik <> | Subject | Re: [patch] pci probing |
| |
Donald Becker wrote: > My approach specifically does *not* do request_region(). That occurs only > when the device is recognized and named. For network drivers that's the > "eth0" name, which isn't known at probe1() time. In some cases a probe1() > routine will reject the device, and the region shouldn't be registered.
If resource code is to work in the kernel, presumeably you should __request_region() [note leading '__'] before ioremap, or talking to that hardware mem or I/O region at all. Including ISA-style probing to various ports, and other init-only tasks like that.
> > I outlined in my previous mail why your implementation is inadequate for > > some cases, which IMHO are becoming more common at new devices are > > released. For example, multiple PCI base addresses are becoming more > > and more common. Why not handle all the base addresses in a loop, > > instead of just simply handling the first one? Why not also add > > __request_region code also? That's a source of ifdefs. etc. > > There are nightmare devices that use all five base address registers. But > they usually full of other nightmare design decisions that prevents any > regular scheme from working. Most non-bridge devices have matching memory > and I/O space mappings, and sometime use the boot ROM register. I see fewer > exceptions to this than when PCI was new.
Multiple base addresses is common for video cards and on the Meteor-II framegrabber at least. The audio codec built into my motherboard has two I/O ports. And my IDE controller has a single I/O base at PCI region #4!
What is your suggestion for a solution to the issues I outlined, two e-mails previous? Have two sets of pci scan code, one that works well with video drivers, and one that works well with net drivers? I do not think that is optimal.
IMHO It would be nice to either expand your pci-scan code, which is fine with me, or make my suggested code handle some of the features it currently lacks, like CardBus support via the cb hooks and drv_register/unregister scheme. If I have time tonight, I'll see if I can post a patch which does this.
Regards,
Jeff
-- Custom driver development | Never worry about theory as long Open source programming | as the machinery does what it's | supposed to do. -- R. A. Heinlein
- 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/
| |