lkml.org 
[lkml]   [1999]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:53    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean