Re: [patch] e1000=y && e1000e=m regression fix

[Philip Craig <philipc@snapgear.com>]

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 ;-)