netdev - Re: Race between "Generic PHY" and "bcm53xx" drivers after -EPROBE

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: <9a9b648c-2867-bdf8-8f6b-086d459419a8@gmail.com>
Date:   Tue, 21 Sep 2021 11:45:42 +0200
From:   Rafał Miłecki <zajec5@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <rmk+kernel@...linux.org.uk>
Subject: Re: Race between "Generic PHY" and "bcm53xx" drivers after
 -EPROBE_DEFER

On 20.09.2021 20:25, Florian Fainelli wrote:
> On 9/20/21 11:17 AM, Vladimir Oltean wrote:
> [snip]
>>> All I am saying is that there is not really any need to come up with a
>>> Device Tree-based solution since you can inspect the mdio_device and
>>> find out whether it is an Ethernet PHY or a MDIO device proper, and that
>>> ought to cover all cases that I can think of.
>>
>> Okay, but where's the problem? I guess we're on the same page, and
>> you're saying that we should not be calling bcma_mdio_mii_register, and
>> assigning the result to bgmac->mii_bus, because that makes us call
>> bcma_phy_connect instead of bgmac_phy_connect_direct. But based on what
>> condition? Simply if bgmac->phyaddr == BGMAC_PHY_NOREGS?
> 
> Yes simply that condition, I really believe it ought to be enough for
> the space these devices are in use.

I'm afraid I got lost somewhere in this discussion.

If we don't call bcma_mdio_mii_register() (as suggested in quoted
e-mail) then MDIO device 0x1e won't get created and "bcm53xx"
(b53_mdio.c) won't ever load.

We need b53 to load to support the switch.


On 20.09.2021 19:03, Vladimir Oltean wrote:
 > On Mon, Sep 20, 2021 at 09:36:23AM -0700, Florian Fainelli wrote:
 >> Given that the MDIO node does have a compatible string which is not in
 >> the form of an Ethernet PHY's compatible string, I wonder if we can
 >> somewhat break the circular dependency using that information.
 >
 > I think you're talking about:
 >
 > of_mdiobus_register
 > -> of_mdiobus_child_is_phy
 >
 > but as mentioned, that code path should not be creating PHY devices.

With the following patch [1] applied:
[PATCH net-next] net: bgmac: support MDIO described in DT
https://lore.kernel.org/linux-devicetree/20210920123441.9088-1-zajec5@gmail.com/

of_mdiobus_register() finds MDIO bus child at 0x1e from:
[PATCH 1/2] ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch
https://lore.kernel.org/linux-devicetree/20210920141024.1409-1-zajec5@gmail.com/

and it calls of_mdiobus_register_device().

For that MDIO device kernel first tries to load "bcm53xx" (b53_mdio.c)
which returns -EPROBE_DEFER and then kernel loads "Generic PHY".