netdev - Re: Lockup in phy_probe() for MDIO device (Broadcom's switch)

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: <YVW8WM5yxP7sW7Ph@lunn.ch>
Date:   Thu, 30 Sep 2021 15:32:08 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Rafał Miłecki <zajec5@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
        Vivek Unune <npcomplete13@...il.com>
Subject: Re: Lockup in phy_probe() for MDIO device (Broadcom's switch)

> I should also point out that as this b53 driver that is causing the
> problem only exists in OpenWRT, this is really a matter for OpenWRT
> developers rather than mainline which does not suffer this problem.
> I suspect that OpenWRT developers will not be happy with either of
> the two patches I've posted above - I suspect they are trying to
> support both DSA and swconfig approaches with a single DT. That can
> be made to work, but not with a PHYLIB driver being a wrapper around
> the swconfig stuff (precisely because there's no phy_device in this
> scenario.)
> 
> The only reason to patch mainline kernels would be to make them more
> robust, and maybe to also make an explicit statement about what isn't
> supported (having a phy_driver with its of_match_table member set.)

I agree with you here. This is an OpenWRT problem. We would hopefully
catch such a driver at review time and reject it. We could make it
more robust in mainline, but as you said, OpenWRT developers might not
actually like it more robust.

	 Andrew