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]

quoted

quoted

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/ (local)

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/ (local)

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