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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <71ea739c7be432da356b4d3f7dca8b7658f3d2fb.1581880851.git.hns@goldelico.com>
Date:   Sun, 16 Feb 2020 20:20:51 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Mathieu Malaterre <malat@...ian.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paulburton@...nel.org>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        "H. Nikolaus Schaller" <hns@...delico.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Cc:     linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-mips@...r.kernel.org, letux-kernel@...nphoenux.org,
        kernel@...a-handheld.com
Subject: [RFC v3 9/9] MIPS: CI20 defconfig: DEMO HACK: make DM9000 a module

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@...delico.com>
---
 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