mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: netdev-bot+sashiko@kernel.org
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 10:23:52 -0700	[thread overview]
Message-ID: <b15c85ea-85b4-4900-b422-07fd629c0b6e@gmail.com> (raw)
In-Reply-To: <179329051062.3134.8683202411485629333@kernel.org>

On 10/29/26 09:15, netdev-bot+sashiko@kernel.org wrote:
> 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);
>>
> 

Agreed. PHY teardown can re-enable the MAC through MDIO accesses. I’ll 
update patch #3 to call au1000_reset_mac() after MDIO bus teardown, 
matching the probe error path.

The RTNL annotation concern appears to be a separate phylib issue shared 
by other drivers.

pw-bot: cr
-- 
Florian

  reply	other threads:[~2026-10-29 17:23 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
2026-10-29 17:23     ` Florian Fainelli [this message]
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=b15c85ea-85b4-4900-b422-07fd629c0b6e@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=danny.kukawka@bisect.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --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-bot+sashiko@kernel.org \
    --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®