| Message ID | 71ea739c7be432da356b4d3f7dca8b7658f3d2fb.1581880851.git.hns@goldelico.com |
|---|---|
| State | New |
| Headers | show |
| Series | MIPS: CI20: Add efuse driver for Ingenic JZ4780 and attach to DM9000 for stable MAC addresses | expand |
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
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@goldelico.com> --- arch/mips/configs/ci20_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)