[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ec0c324-b07a-4001-b495-f34bfdd8ffe0@lunn.ch>
Date: Tue, 26 Dec 2023 17:49:56 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Jagan Teki <jagan@...rulasolutions.com>,
Heiner Kallweit <hkallweit1@...il.com>,
"Andrew F. Davis" <afd@...com>,
Florian Fainelli <f.fainelli@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org,
Michael Nazzareno Trimarchi <michael@...rulasolutions.com>,
Ioana Ciornei <ioana.ciornei@....com>,
Shawn Guo <shawnguo@...nel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Fabio Estevam <festevam@...il.com>
Subject: Re: PHY issue with SJA1105Q/DP84849I Design
> Ok. The WARN_ON() is saying that the DSA user port's phy_start() found
> the attached PHY already in the RUNNING state. As if there was already
> someone else driving it.
>
> That "someone else" seems to be the FEC driver from the log above, which
> for some reason has connected to the DP83849I by itself, and phylink/phylib
> hasn't denied the second attempt to connect to the same PHY for some
> reason.
>
> If you look at fec_enet_mii_probe(), I see it has 2 code paths, one for
> when fep->phy_node (defined as the "phy-handle" reference) is non-NULL,
> and one for when it is NULL. What you're missing is a fixed-link
> specifier in the device tree for FEC, otherwise it tries to call
> phy_connect() to some random MDIO address on the bus and that breaks
> things in some way which I don't understand.
At has an open coded phy_find_first(), or something similar. The FEC
is a bit of a mess in this respect, but it is hard to fix because of
backwards compatibility.
> The code which should have prevented this from happening is in
> phy_attach_direct():
>
> if (phydev->attached_dev) {
> dev_err(&dev->dev, "PHY already attached\n");
> err = -EBUSY;
> goto error;
> }
Yes, that is odd.
Andrew
Powered by blists - more mailing lists