linux-kernel - Re: [PATCH net-next 1/2] net: stmmac: Add PCS_LYNX as a dependency for the whole driver

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, 6 Jun 2023 11:26:12 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>, davem@...emloft.net,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        alexis.lothore@...tlin.com, thomas.petazzoni@...tlin.com,
        Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Simon Horman <simon.horman@...igine.com>
Subject: Re: [PATCH net-next 1/2] net: stmmac: Add PCS_LYNX as a dependency
 for the whole driver

On Tue, Jun 06, 2023 at 12:13:11PM +0200, Maxime Chevallier wrote:
> Hello Geert, Russell,
> 
> On Tue, 6 Jun 2023 10:30:32 +0100
> "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
> 
> > On Tue, Jun 06, 2023 at 10:29:20AM +0200, Geert Uytterhoeven wrote:
> > > 	Hi Maxime,
> > > 
> > > On Tue, 6 Jun 2023, Maxime Chevallier wrote:  
> > > > Although pcs_lynx is only used on dwmac_socfpga for now, the cleanup
> > > > path is in the generic driver, and triggers build issues for other
> > > > stmmac variants. Make sure we build pcs_lynx in all cases too, as for
> > > > XPCS.  
> > > 
> > > That seems suboptimal to me, as it needlesly increases kernel size for
> > > people who do not use dwmac_socfpga.  Hence I made an alternative patch:
> > > https://lore.kernel/org/7b36ac43778b41831debd5c30b5b37d268512195.1686039915.git.geert+renesas@glider.be  
> > 
> > A better solution would be to re-architect the removal code so that
> > whatever creates the PCS is also responsible for removing it.
> > 
> > Also, dwmac_socfpga nees to be reorganised anyway, because it calls
> > stmmac_dvr_probe() which then goes on to call register_netdev(),
> > publishing the network device, and then after stmmac_dvr_probe(),
> > further device setup is done. As the basic driver probe flow should
> > be setup and then publish, the existing code structure violates that.
> > 
> 
> I agree that this solution is definitely suboptimal, I wanted mostly to get it
> fixed quickly as this breaks other stmmac variants.
> 
> Do we still go on with the current patch (as Geert's has issues) and then
> consider reworking dwmac_socfpga ?

As Geert himself mentioned, passed on from Arnd:
  As pointed out by Arnd, this doesn't work when PCS_LYNX is a loadable
  module and STMMAC is built-in:
  https://lore.kernel.org/r/11bd37e9-c62e-46ba-9456-8e3b353df28f@app.fastmail.com

So Geert's solution will just get rid of the build error, but leave the
Lynx PCS undestroyed. I take Geert's comment as a self-nack on his
proposed patch.

The changes are only in net-next at the moment, and we're at -rc5.
There's probably about 2.5 weeks to get this sorted before the merge
window opens.

So, we currently have your suggestion. Here's mine as an immediate
fix. This doesn't address all the points I've raised, but should
resolve the immediate issue.

Untested since I don't have the hardware... (the test build is
running):

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index e399fccbafe5..239c7e9ed41d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -494,6 +494,17 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
 	return ret;
 }
 
+static void socfpga_dwmac_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	struct phylink_pcs *pcs = priv->hw->lynx_pcs;
+
+	stmmac_pltfr_remove(pdev);
+
+	lynx_pcs_destroy(pcs);
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int socfpga_dwmac_resume(struct device *dev)
 {
@@ -565,7 +576,7 @@ MODULE_DEVICE_TABLE(of, socfpga_dwmac_match);
 
 static struct platform_driver socfpga_dwmac_driver = {
 	.probe  = socfpga_dwmac_probe,
-	.remove_new = stmmac_pltfr_remove,
+	.remove_new = socfpga_dwmac_remove,
 	.driver = {
 		.name           = "socfpga-dwmac",
 		.pm		= &socfpga_dwmac_pm_ops,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fa07b0d50b46..1801f8cc8413 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -940,9 +940,6 @@ static struct phylink_pcs *stmmac_mac_select_pcs(struct phylink_config *config,
 	if (priv->hw->xpcs)
 		return &priv->hw->xpcs->pcs;
 
-	if (priv->hw->lynx_pcs)
-		return priv->hw->lynx_pcs;
-
 	return NULL;
 }
 
-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!