linux-kernel - Re: [PATCH] reset: microchip-sparx5: allow building as 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: <20220712125836.2676525-1-michael@walle.cc>
Date:   Tue, 12 Jul 2022 14:58:36 +0200
From:   Michael Walle <michael@...le.cc>
To:     p.zabel@...gutronix.de
Cc:     Steen.Hegelund@...rochip.com, UNGLinuxDriver@...rochip.com,
        allan.nielsen@...rochip.com, clement.leger@...tlin.com,
        horatiu.vultur@...rochip.com, lars.povlsen@...rochip.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        thomas.petazzoni@...tlin.com, Michael Walle <michael@...le.cc>
Subject: Re: [PATCH] reset: microchip-sparx5: allow building as a module

Hi,

> On Fr, 2022-06-17 at 12:37 +0200, Clément Léger wrote:
> > Set RESET_MCHP_SPARX5 as a tristate and add MODULE_DEVICE_TABLE() to
> > allow building this driver as a module.
> > 
> > Signed-off-by: Clément Léger <clement.leger@...tlin.com>
> 
> Thank you, applied to reset/next.

Unfortunately, this is breaking ethernet on my board
(lan966x-kontron-kswitch-d10-mmt-6g-2gs, see dts in arch/arm/).

I suspect this is because the postcore_initcall() was called earlier
in the kernel startup. Now, somehow the MDIO controller isn't working
anymore.

For a bit of a background, on the LAN9668 (I guess this is also true
on most other microchip switch platforms), there is a global switch
reset which is shared among most subsystems, i.e GPIO, SGPIO and
switch core. The switch driver will use this reset as there is no other
reset available (e.g. one which only reset the switching core). But when
it asserts the reset it will also reset other devices on the SoC. This
was for example the case for the GPIO, see commit 453200af8a85 ("pinctrl:
ocelot: add optional shared reset"). It seems like the MIIM is also
affected by this global reset, thus it needs the same fix.

I tried the obvious by adding the reset to the MIIM, but that didn't
help for all broken interfaces. I have to dig deeper into that.

In the meantime I'd appreciate it if this commit can be reverted until
the other fixes (at least the missing MIIM reset) will be merged.

-michael