linux-kernel - Re: PHY issue with SJA1105Q/DP84849I Design

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]

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