lkml.org 
[lkml]   [1999]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] pci probing
    Donald Becker wrote:
    > There is very little that is network-specific about the code.
    > It's certainly not "network centric".

    That was shorthand for
    only-applicable-to-your-net-drivers-without-changes. Sorry. :) Or in
    other words, using that code unchanged will cause problems in my
    drivers. :)


    > Questions:
    > Does your approach handle hot-swap PCI and CardBus with a single driver?

    Maybe.


    > What about ACPI and Wake-on-*?

    Check out the patch at the end of the message to which you replied.


    > Does allow backwards- and forward-compatible drivers?

    Nothing prevents the interface from being backported to older kernels
    verbatim.


    > Do you have a driver to demonstrate CardBus suspend, eject and resume?

    I seem to have misplaced it... :)


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

    I don't disagree with this, and the high quality of your network drivers
    attests to the attention and thought you've put into the interface.

    The central problem is that the pci-netif.c code is not a drop-in
    replacement for existing PCI probe code. However, if changing your code
    to be more generic means lots of private development and testing, it
    will be ages before anyone but you can stop duplicating code in their
    drivers.


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

    It's bad news for video cards at least in its current form, though.
    Turning on I/O decoding blindly is just asking for a lockup, with
    multiple VGA cards. But don't worry, as I stated in another e-mail in
    this thread, PCI_COMMAND will definitely be used. I just need it more
    flexible than the current pci-netif.c code.

    I'm very interested in comments on the patch sent to you. I probably
    need a drv_unregister in order to support CardBus. And I like your
    handling of pciaddr/ioaddr, but that needs to be extended to support
    multiple regions, and different schemes of using ioremap().


    And a comment from pci-netif.c:
    > /* The PCI code in 2.2 is harder to use, and the extra complexity serves
    > no real purpose. The resource code in 2.3 is far worse. It is a complex
    > abstaction layer with negative benefit. */

    It is incredibly useful for video cards, and I'm thinking for my
    framegrabber driver too. Easy sub-allocation of PCI resources is made
    possible by the new scheme.

    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    [W:4.562 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site