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