[RFC v3 9/9] MIPS: CI20 defconfig: DEMO HACK: make DM9000 a module

[H. Nikolaus Schaller]

It appears that reading the ethernet mac address from NVMEM,
i.e. through the jz4780-efuse driver, requires the jz4780-efuse
driver to be up and running before the dm9000 driver is probed.

This is because there is a registration mechanism for nvmem
devices and consumers scan the global table. If the provider
has not yet been registered, the required matching entry
is not found and the consumer assumes there is no nvram.

In the case of the dm9000 it will not wait but assign a
random MAC address.

It appears that if the dm9000 is configured into the kernel
binary, it will be probed first and the correct sequence is
broken.

If it is a module (or even both), the way deferred probing
works seems to serialize properly.

So this hack is for demo purposes only and makes the dm9000
probing being delayed.

A proper solution is to make sure the jz4780-efuse driver
is probed earlier than the dm9000 driver (or mac address
lookup).

Signed-off-by: H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>
---
 arch/mips/configs/ci20_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 614dc18211bc..1d3d1d9b62bc 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -59,7 +59,7 @@ CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
-CONFIG_DM9000=y
+CONFIG_DM9000=m
 CONFIG_DM9000_FORCE_SIMPLE_PHY_POLL=y
 # CONFIG_NET_VENDOR_INTEL is not set
 # CONFIG_NET_VENDOR_MARVELL is not set
-- 
2.23.0