netdev - Re: [PATCH net-next] net: stmmac: dwc-qos: calibrate tegra with mdio bus idle

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]

Message-ID: <afcvvloverjh5nadfbdkdel2dklw3yo24uh2hkmc6mufgiub6a@6esbora2xwgi>
Date: Wed, 23 Apr 2025 11:13:34 +0200
From: Thierry Reding <treding@...dia.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>, 
	Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, 
	Alexandre Torgue <alexandre.torgue@...s.st.com>, Andrew Lunn <andrew+netdev@...n.ch>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Jon Hunter <jonathanh@...dia.com>, 
	linux-arm-kernel@...ts.infradead.org, linux-stm32@...md-mailman.stormreply.com, 
	Maxime Coquelin <mcoquelin.stm32@...il.com>, netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next] net: stmmac: dwc-qos: calibrate tegra with mdio
 bus idle

On Tue, Apr 22, 2025 at 04:42:30PM +0200, Maxime Chevallier wrote:
> Hello Russell,
> 
> On Tue, 22 Apr 2025 15:24:55 +0100
> "Russell King (Oracle)" <rmk+kernel@...linux.org.uk> wrote:
> 
> > Thierry states that there are prerequists for Tegra's calibration
> > that should be met before starting calibration - both the RGMII and
> > MDIO interfaces should be idle.
> > 
> > This commit adds the necessary MII bus locking to ensure that the MDIO
> > interface is idle during calibration.
> > 
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> 
> [...]
> 	
> > -static void tegra_eqos_fix_speed(void *priv, int speed, unsigned int mode)
> > +static void tegra_eqos_fix_speed(void *bsp_priv, int speed, unsigned int mode)
> >  {
> > -	struct tegra_eqos *eqos = priv;
> > +	struct tegra_eqos *eqos = bsp_priv;
> >  	bool needs_calibration = false;
> > +	struct stmmac_priv *priv;
> >  	u32 value;
> >  	int err;
> >  
> > @@ -158,6 +159,11 @@ static void tegra_eqos_fix_speed(void *priv, int speed, unsigned int mode)
> >  	}
> >  
> >  	if (needs_calibration) {
> > +		priv = netdev_priv(dev_get_drvdata(eqos->dev));
> > +
> > +		/* Calibration should be done with the MDIO bus idle */
> > +		mutex_lock(&priv->mii->mdio_lock);
> 
> Can't priv->mii be NULL, if the PHY for that MAC is connected to
> another MDIO bus for instance ?

Looking at the code, priv->mii will either be valid when mdio_bus_data
is non-NULL, or the driver probe will fail. mdio_bus_data depends on the
presence of the "mdio" child node in DT (via plat->mdio_node).

As far as I can tell this is always the case on Tegra devices, so I
don't think we need to worry about this case. If it ever wasn't valid,
I'd probably consider that a bug.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)