lkml.org 
[lkml]   [2008]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] e1000=y && e1000e=m regression fix
    Kok, Auke wrote:
    > Again - If there is a way to auto-enable e1000e in the right way so that more
    > systems migrate better then I'm all for it (even if forcing E1000E=y). But it
    > seems that the various patches proposed don't cut it and frankly Kconfig is
    > completely inadequate as a hardware enabling script since it knows absolutely
    > nothing about the hardware in the first place. And it wasn't meant for that
    > either. `make oldconfig` is not the answer ;).

    One problem is that the meaning of E1000 has been changed. It covers less
    hardware than it used to.

    You could add a new option to control the e1000 driver, and make E1000 set
    both this new option and E1000E. Thus it will always cover at least all
    the IDs that the original e1000 driver handled.

    config E1000
    tristate "Both Intel(R) PRO/1000 Gigabit Ethernet support"
    depends on PCI

    config E1000_ONLY
    tristate "Intel(R) PRO/1000 Gigabit Ethernet support" if E1000=n
    default E1000
    depends on PCI

    config E1000E
    tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support" if E1000=n
    default E1000
    depends on PCI

    The E1000E prompt restriction is required to upgrade existing E1000=y,
    E1000E=m configs to E1000E=y.

    But it will also upgrade E1000=y/m,E1000E=n to E1000E=y/m, which may not
    always be right.

    This still doesn't solve any problems with loading modules for E1000=m.
    Loading the e1000 module will still load support for less than it used to.
    (Because make oldconfig is not the answer ;-)


    \
     
     \ /
      Last update: 2008-04-11 02:49    [W:3.928 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site