All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: "Rafał Miłecki" <zajec5@gmail.com>,
	"Network Development" <netdev@vger.kernel.org>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Russell King" <rmk+kernel@armlinux.org.uk>,
	"Saravana Kannan" <saravanak@google.com>
Subject: Re: Race between "Generic PHY" and "bcm53xx" drivers after -EPROBE_DEFER
Date: Mon, 20 Sep 2021 09:36:23 -0700	[thread overview]
Message-ID: <4648f65c-4d38-dbe9-a902-783e6dfb9cbd@gmail.com> (raw)
In-Reply-To: <3639116e-9292-03ca-b9d9-d741118a4541@gmail.com>

+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

  reply	other threads:[~2021-09-20 16:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 12:52 Race between "Generic PHY" and "bcm53xx" drivers after -EPROBE_DEFER Rafał Miłecki
2021-09-20 16:36 ` Florian Fainelli [this message]
2021-09-20 17:03   ` Vladimir Oltean
2021-09-20 17:14     ` Florian Fainelli
2021-09-20 17:40       ` Vladimir Oltean
2021-09-20 17:46         ` Florian Fainelli
2021-09-20 18:02           ` Vladimir Oltean
2021-09-20 18:10             ` Florian Fainelli
2021-09-20 18:17               ` Vladimir Oltean
2021-09-20 18:25                 ` Florian Fainelli
2021-09-20 18:36                   ` Vladimir Oltean
2021-09-21  9:45                   ` Rafał Miłecki
2021-09-21 10:52                     ` Rafał Miłecki
2021-09-20 18:58               ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4648f65c-4d38-dbe9-a902-783e6dfb9cbd@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=saravanak@google.com \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.