From: Vladimir Oltean <olteanv@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
"Network Development" <netdev@vger.kernel.org>,
"Andrew Lunn" <andrew@lunn.ch>,
"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 20:40:22 +0300 [thread overview]
Message-ID: <20210920174022.uc42krhj2on3afud@skbuf> (raw)
In-Reply-To: <11994990-11f2-8701-f0a4-25cb35393595@gmail.com>
On Mon, Sep 20, 2021 at 10:14:48AM -0700, Florian Fainelli wrote:
> The SPROM is a piece of NVRAM that is intended to describe in a set of
> key/value pairs various platform configuration details. There can be up
> to 3 GMACs on the SoC which you can connect in a variety of ways towards
> internal/external PHYs or internal/external Ethernet switches. The SPROM
> is used to describe whether you connect to a regular PHY (not at PHY
> address 30 decimal, so not the Broadcom pseudo-PHY) or an Ethernet
> switch pseudo-PHY via MDIO.
>
> What appears to be missing here is that we should not be executing this
> block of code for phyaddr == BGMAC_PHY_NOREGS because we will not have a
> PHY device proper to begin with and this collides with registering the
> b53_mdio driver.
Who provisions the SPROM exactly? It still seems pretty broken to me
that one of the GMACs has a bgmac->phyaddr pointing to a switch.
Special-casing the Broadcom switch seems not enough, the same thing
could happen with a Marvell switch or others. How about looking up the
device tree whether the bgmac->mii_bus' OF node has any child with a
"reg" of bgmac->phyaddr, and if it does, whether of_mdiobus_child_is_phy
actually returns true for it?
next prev parent reply other threads:[~2021-09-20 22:59 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
2021-09-20 17:03 ` Vladimir Oltean
2021-09-20 17:14 ` Florian Fainelli
2021-09-20 17:40 ` Vladimir Oltean [this message]
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=20210920174022.uc42krhj2on3afud@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
--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.