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: <4648f65c-4d38-dbe9-a902-783e6dfb9cbd@gmail.com>
Date:   Mon, 20 Sep 2021 09:36:23 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Rafał Miłecki <zajec5@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vladimir Oltean <olteanv@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Saravana Kannan <saravanak@...gle.com>
Subject: Re: Race between "Generic PHY" and "bcm53xx" drivers after
 -EPROBE_DEFER

+Andrew, Vladimir, Heiner, Russell, Saravana,

On 9/20/21 5:52 AM, Rafał Miłecki wrote:
> I have problem using a switch b53 MDIO driver with an Ethernet bgmac
> driver.
> 
> bgmac registers MDIO bus before registering Ethernet controller. That
> results in kernel probing switch (available as MDIO device) early which
> results in dsa_port_parse_of() returning -EPROBE_DEFER.

Yes, putting the big picture together and assuming you have applied
these 3 patches which is how you observed that:

https://lore.kernel.org/linux-devicetree/20210920123441.9088-1-zajec5@gmail.com/
https://lore.kernel.org/linux-devicetree/20210920141024.1409-1-zajec5@gmail.com/
https://lore.kernel.org/linux-devicetree/20210920141024.1409-2-zajec5@gmail.com/

This is somewhat expected unfortunately and I don't know how we can
break the circular dependencies here.

> 
> It's OK so far but then in goes like this:
> 
> [    1.306884] bus: 'bcma': driver_probe_device: matched device bcma0:5
> with driver bgmac_bcma
> [    1.315427] bus: 'bcma': really_probe: probing driver bgmac_bcma with
> device bcma0:5
> [    1.323468] bgmac_bcma bcma0:5: Found PHY addr: 30 (NOREGS)
> [    1.329722] libphy: bcma_mdio mii bus: probed
> [    1.334468] bus: 'mdio_bus': driver_probe_device: matched device
> bcma_mdio-0-0:1e with driver bcm53xx
> [    1.343877] bus: 'mdio_bus': really_probe: probing driver bcm53xx
> with device bcma_mdio-0-0:1e
> [    1.353174] bcm53xx bcma_mdio-0-0:1e: found switch: BCM53125, rev 4
> [    1.359595] bcm53xx bcma_mdio-0-0:1e: failed to register switch: -517
> [    1.366212] mdio_bus bcma_mdio-0-0:1e: Driver bcm53xx requests probe
> deferral
> [    1.373499] mdio_bus bcma_mdio-0-0:1e: Added to deferred list
> [    1.379362] bgmac_bcma bcma0:5: Support for Roboswitch not implemented
> [    1.387067] bgmac_bcma bcma0:5: Timeout waiting for reg 0x1E0
> [    1.393600] driver: 'Generic PHY': driver_bound: bound to device
> 'bcma_mdio-0-0:1e'
> [    1.401390] Generic PHY bcma_mdio-0-0:1e: Removed from deferred list
> 
> I can't drop "Generic PHY" driver as it's required for non-CPU switch
> ports. I just need kernel to prefer b53 MDIO driver over the "Generic
> PHY" one.
> 
> Can someone help me fix that, please?

I don't think that you have a race condition, but you have the Ethernet
switch's pseudo PHY which is accessible via MDIO and the Generic PHY
driver happily goes on trying to read the MII_PHYSID1/PHYS_ID2 which do
not map to anything on that switch, but still you will get a
non-zero/non-all Fs value from there, hence the Generic PHY is happy to
take over.

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.
-- 
Florian