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: <7f328778-fab7-79de-6adf-57d650bc3e2f@gmail.com>
Date:   Thu, 30 Sep 2021 15:47:25 +0200
From:   Rafał Miłecki <zajec5@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     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)

On 30.09.2021 15:32, Andrew Lunn wrote:
>> 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.
I was thinking about patching mdio_bus_match() / phy_driver_register()
to prevent other developers from doing the same mistake as OpenWrt &
b53. Also saving your time from reports similar to mine.

I understand it's an issue that OpenWrt has to handle downstream.

Thank you a lot for helping me investigate this problem.