From: netdev-bot+sashiko@kernel.org
To: ansuelsmth@gmail.com
Cc: andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk,
davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2 1/4] net: phy: as21xxx: handle corner case with link and autoneg complete
Date: Mon, 26 Oct 2026 23:07:04 +0000 [thread overview]
Message-ID: <179305602406.3134.12536030010913078225@kernel.org> (raw)
In-Reply-To: <20261022222955.698722-1-ansuelsmth@gmail.com>
Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.
Low priority / nit picks for your consideration:
- [Low] The commit message for "net: phy: as21xxx: handle corner case
with link and autoneg complete" describes the wrong condition.
--
net: phy: as21xxx: handle corner case with link and autoneg complete
This commit makes as21xxx_read_link() store the autoneg complete bit
from MDIO_STAT1 in phydev->autoneg_complete. When autoneg is enabled
but has not completed, it reports the link as down. This is the same
approach genphy_update_link() takes.
> Add missing case in custom read_link, when autoneg is started, autoneg
> complete bit is reset but link is still not up.
[Severity: Low]
Is this the condition the new code actually handles?
If the link is not up, MDIO_STAT1_LSTATUS is already clear. That means
phydev->link is already 0 before the new check runs:
phydev->link = !!(status & MDIO_STAT1_LSTATUS);
phydev->autoneg_complete = !!(status & MDIO_AN_STAT1_COMPLETE);
...
if (phydev->autoneg == AUTONEG_ENABLE && !phydev->autoneg_complete)
phydev->link = 0;
The check only changes anything when MDIO_STAT1_LSTATUS is still set
and MDIO_AN_STAT1_COMPLETE has already been cleared. The in-code
comment, copied from genphy_update_link(), describes it that way:
/* Consider the case that autoneg was started and "aneg complete"
* bit has been reset, but "link up" bit not yet.
*/
Could the commit message be reworded to match? The case being handled
is that the link up bit has not been reset yet, not that the link is
not up.
It could also help stable backporters to state the user-visible effect.
Without this check, as21xxx_read_status() can move from link down to
link up while genphy_c45_read_lpa() is taking its
!MDIO_AN_STAT1_COMPLETE branch:
if (!(val & MDIO_AN_STAT1_COMPLETE)) {
linkmode_clear_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
phydev->lp_advertising);
mii_10gbt_stat_mod_linkmode_lpa_t(phydev->lp_advertising, 0);
mii_adv_mod_linkmode_adv_t(phydev->lp_advertising, 0);
...
return 0;
}
In that case phy_resolve_aneg_linkmode() resolves speed and duplex
after the base page and 10G link partner bits have been cleared. The
link can then be reported up with an unknown or stale speed.
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261022222955.698722-1-ansuelsmth%40gmail.com
prev parent reply other threads:[~2026-10-26 23:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 22:29 [PATCH net v2 1/4] net: phy: as21xxx: handle corner case with link and autoneg complete Christian Marangi
2026-10-22 22:29 ` [PATCH net v2 2/4] net: phy: as21xxx: fix read_status speed handling Christian Marangi
2026-10-26 23:07 ` netdev-bot+sashiko
2026-10-22 22:29 ` [PATCH net v2 3/4] net: phy: as21xxx: force C45 OPs for AUTONEG Christian Marangi
2026-10-26 23:07 ` netdev-bot+sashiko
2026-10-22 22:29 ` [PATCH net v2 4/4] net: phy: as21xxx: handle odd firmware on loading Christian Marangi
2026-10-26 23:07 ` netdev-bot+sashiko
2026-10-26 23:07 ` netdev-bot+sashiko [this message]
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=179305602406.3134.12536030010913078225@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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