mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: f.fainelli@gmail.com
Cc: netdev@vger.kernel.org, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
	pabeni@redhat.com, hkallweit1@gmail.com, linux@armlinux.org.uk,
	shaojijie@huawei.com, horms@kernel.org, runyu.xiao@seu.edu.cn,
	mmyangfl@gmail.com, hvr@gnu.org, jeff@garzik.org,
	danny.kukawka@bisect.de, mugunthanvnm@ti.com,
	sebastian.hesselbarth@gmail.com, linux-kernel@vger.kernel.org,
	manuel.lauss@gmail.com
Subject: Re: [PATCH net 03/11] net: au1000: disconnect the PHY before freeing the MDIO bus
Date: Thu, 29 Oct 2026 16:15:10 +0000	[thread overview]
Message-ID: <179329051062.3134.8683202411485629333@kernel.org> (raw)
In-Reply-To: <20261027223140.3774570-4-f.fainelli@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0 (1)

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] In drivers/net/ethernet/amd/au1000_eth.c, au1000_remove() now
  calls phy_disconnect() after unregister_netdev().

Pre-existing issues:
- [Low] The two new phy_disconnect() calls (au1000_remove() after
  unregister_netdev(), and the au1000_probe() err_out path) run without…

--

net: au1000: disconnect the PHY before freeing the MDIO bus

This patch adds phy_disconnect() calls to the au1000_probe() error path
and to au1000_remove(). This balances the phy_connect() done in
au1000_mii_probe(). In both paths the disconnect runs before the MDIO bus
is unregistered.

> diff --git a/drivers/net/ethernet/amd/au1000_eth.c b/drivers/net/ethernet/amd/au1000_eth.c
> index 58bc8e1b539d5..70319b432182f 100644
> --- a/drivers/net/ethernet/amd/au1000_eth.c
> +++ b/drivers/net/ethernet/amd/au1000_eth.c
> @@ -1287,6 +1287,8 @@ static int au1000_probe(struct platform_device *pdev)
>  	return 0;
>  
>  err_out:
> +	if (dev->phydev)
> +		phy_disconnect(dev->phydev);
>  	if (aup->mii_bus)
>  		mdiobus_unregister(aup->mii_bus);
>  

[ ... ]

> @@ -1334,6 +1336,8 @@ static void au1000_remove(struct platform_device *pdev)
>  	struct resource *base, *macen;
>  
>  	unregister_netdev(dev);
> +	if (dev->phydev)
> +		phy_disconnect(dev->phydev);

[Severity: Medium]
Can this leave the MAC clocked and out of reset after the driver unbinds?

By the time au1000_remove() reaches this point, the MAC is already in
reset with its clock gated, and aup->mac_enabled is 0. If the interface
was never opened, au1000_probe() did this by calling au1000_reset_mac()
just before register_netdev(). If the interface was opened,
au1000_close() did it.

If the interface was never opened, phydev->suspended is still false,
because phy_attach_direct() resumed the PHY. In that case phy_disconnect()
does MDIO accesses:

phy_disconnect()
  phy_detach()
    phy_detach_internal()
      phy_suspend()
        genphy_suspend()
          phy_set_bits(phydev, MII_BMCR, BMCR_PDOWN)

Each of these accesses goes through au1000_mdiobus_read() or
au1000_mdiobus_write(). Both call au1000_enable_mac(dev, 0) first:

	if (force_reset || (!aup->mac_enabled)) {
		writel(MAC_EN_CLOCK_ENABLE, aup->enable);
		...
		writel((MAC_EN_RESET0 | MAC_EN_RESET1 | MAC_EN_RESET2
				| MAC_EN_CLOCK_ENABLE), aup->enable);
		...
		aup->mac_enabled = 1;
	}

Nothing later in au1000_remove() calls au1000_reset_mac() again before
the registers are unmapped and the netdev is freed. Before this patch,
remove left the MAC in reset with its clock gated.

The err_out path in au1000_probe() does call au1000_reset_mac(dev) after
phy_disconnect() and mdiobus_unregister(). Should au1000_remove() also
call au1000_reset_mac(dev) after phy_disconnect(), to match it?

[Severity: Low]
This is a pre-existing issue, not one introduced by this patch, but both
new phy_disconnect() calls run without RTNL held. In au1000_remove(),
unregister_netdev() has already dropped RTNL. au1000_probe() never takes
it.

phy_disconnect()->phy_detach()->phy_detach_internal() does:

		hwprov = rtnl_dereference(dev->hwprov);

With CONFIG_PROVE_RCU enabled, could this emit a one-time "suspicious
rcu_dereference_protected() usage" warning? The read itself looks
harmless, since au1000 never installs a hwtstamp provider.

Other drivers already call phy_disconnect() after unregister_netdev()
without RTNL, for example r6040_remove_one(), et131x_pci_remove(),
bgmac_enet_remove(), mlxbf_gige_remove(), hisi_femac_drv_remove() and
ixp4xx_eth_remove(). So this looks like a problem with the phylib
annotation, not with this driver.

>  	mdiobus_unregister(aup->mii_bus);
>  	mdiobus_free(aup->mii_bus);
>

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261027223140.3774570-1-f.fainelli%40gmail.com

  reply	other threads:[~2026-10-29 16:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 22:31 [PATCH net 00/11] net: au1000: Bug fixes Florian Fainelli
2026-10-27 22:31 ` [PATCH net 01/11] net: au1000: recycle RX descriptors on allocation failure Florian Fainelli
2026-10-27 22:31 ` [PATCH net 02/11] net: au1000: clear all-multicast mode when restoring hash filtering Florian Fainelli
2026-10-27 22:31 ` [PATCH net 03/11] net: au1000: disconnect the PHY before freeing the MDIO bus Florian Fainelli
2026-10-29 16:15   ` netdev-bot+sashiko [this message]
2026-10-29 17:23     ` Florian Fainelli
2026-10-27 22:31 ` [PATCH net 04/11] net: au1000: report MDIO transaction timeouts Florian Fainelli
2026-10-29 16:15   ` netdev-bot+sashiko
2026-10-29 17:25     ` Florian Fainelli
2026-10-27 22:31 ` [PATCH net 05/11] net: au1000: serialize TX completion with packet submission Florian Fainelli
2026-10-29 16:15   ` netdev-bot+sashiko
2026-10-29 17:32     ` Florian Fainelli
2026-10-27 22:31 ` [PATCH net 06/11] net: au1000: assign a valid MAC address without platform data Florian Fainelli
2026-10-29 16:15   ` netdev-bot+sashiko
2026-10-29 17:33     ` Florian Fainelli
2026-10-27 22:31 ` [PATCH net 07/11] net: au1000: fix buffer descriptor free list insertion Florian Fainelli
2026-10-29 16:15   ` netdev-bot+sashiko
2026-10-29 17:35     ` Florian Fainelli
2026-10-27 22:31 ` [PATCH net 08/11] net: au1000: restore receive filtering after MAC initialization Florian Fainelli
2026-10-29 16:15   ` netdev-bot+sashiko
2026-10-29 17:37     ` Florian Fainelli
2026-10-27 22:31 ` [PATCH net 09/11] net: au1000: restore RX buffer addresses when restarting the MAC Florian Fainelli
2026-10-27 22:31 ` [PATCH net 10/11] net: au1000: keep the MAC stopped until the PHY link is ready Florian Fainelli
2026-10-29 16:15   ` netdev-bot+sashiko
2026-10-29 17:39     ` Florian Fainelli
2026-10-27 22:31 ` [PATCH net 11/11] net: phy: smsc: wait for LAN83C183 power-down recovery Florian Fainelli
2026-10-27 23:21 ` [PATCH net 00/11] net: au1000: Bug fixes Jakub Kicinski
2026-10-28  0:12   ` Florian Fainelli

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=179329051062.3134.8683202411485629333@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=danny.kukawka@bisect.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=hvr@gnu.org \
    --cc=jeff@garzik.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=manuel.lauss@gmail.com \
    --cc=mmyangfl@gmail.com \
    --cc=mugunthanvnm@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=runyu.xiao@seu.edu.cn \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=shaojijie@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®