Cc: Ingo Molnar <mingo@...>, Jeff Garzik <jeff@...>, Matthew Wilcox <matthew@...>, Linux Kernel Mailing List <linux-kernel@...>, NetDev <netdev@...>, e1000-list <e1000-devel@...>, linux-pci maillist <linux-pci@...>, Andrew Morton <akpm@...>, David S. Miller <davem@...>, Linus Torvalds <torvalds@...>, Jesse Brandeburg <jesse.brandeburg@...>, Ronciak, John <john.ronciak@...>, Allan, Bruce W <bruce.w.allan@...>, Greg KH <greg@...>, Arjan van de Ven <arjan@...>, Rafael J. Wysocki <rjw@...>
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 ;-)
--
