From: Paolo Abeni <pabeni@redhat.com>
To: shaojijie@huawei.com
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch, horms@kernel.org,
shenjian15@huawei.com, liuyonglong@huawei.com,
chenhao418@huawei.com, yangshuaisong@h-partners.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 net] net: hns3: fix speed configuration residue after driver reload
Date: Tue, 21 Jul 2026 13:05:29 +0200 [thread overview]
Message-ID: <20260721110529.201977-1-pabeni@redhat.com> (raw)
In-Reply-To: <20260708140532.1691493-1-shaojijie@huawei.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://netdev-ai.bots.linux.dev/sashiko/
---
net: hns3: fix speed configuration residue after driver reload
This change drops the req_speed overwrite in hclge_init_ae_dev() so
req_speed keeps the firmware default set during hclge_configure()
after a driver reload, and only req_autoneg continues to be
synchronized from mac.autoneg on non-copper media.
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> index fc8587c80813..164c3ecf195c 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> @@ -9498,12 +9498,8 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
> if (ret)
> goto err_ptp_uninit;
>
> - if (hdev->hw.mac.media_type != HNAE3_MEDIA_TYPE_COPPER) {
> + if (hdev->hw.mac.media_type != HNAE3_MEDIA_TYPE_COPPER)
> hdev->hw.mac.req_autoneg = hdev->hw.mac.autoneg;
> - if (hdev->hw.mac.autoneg == AUTONEG_DISABLE &&
> - hdev->hw.mac.speed != SPEED_UNKNOWN)
> - hdev->hw.mac.req_speed = hdev->hw.mac.speed;
> - }
[High]
Could removing this block reintroduce the scenario that d9d349c4e8a0
("net: hns3: differentiate autoneg default values between copper and
fiber") was written to handle?
The Fixes-tagged commit added this req_speed overwrite specifically for
optical ports where firmware presets autoneg=DISABLE at a specific
forced speed (a case its commit message describes as common in data
centers where the remote switch runs in forced mode).
There appear to be two distinct notions of "firmware default" involved:
- cfg.default_speed read from flash static parameters via
hclge_get_cfg() and stored into req_speed by hclge_configure()
- the live firmware/SFP state read via hclge_get_sfp_info() into
mac.autoneg and mac.speed
On a fiber port where the flash default_speed is 100G but firmware has
preset the port to forced 25G to match a fixed-speed remote, after this
change:
hdev->hw.mac.req_autoneg = hdev->hw.mac.autoneg; /* = DISABLE */
/* req_speed still holds flash default 100G */
hclge_set_autoneg_speed_dup() would then see !req_autoneg and call:
hclge_cfg_mac_speed_dup_hw(hdev, hdev->hw.mac.req_speed=100G, ...);
forcing 100G against a 25G-only peer.
Is that scenario still handled, or is it expected not to occur in
practice?
[Medium]
The commit message reasons about mac.speed carrying over user ethtool
changes across a driver reload:
"In hclge_init_ae_dev(), hclge_update_port_info() reads mac.speed
from hardware, which reflects the last user configuration (e.g.
ethtool changes), not the firmware default."
Does the same reasoning apply to mac.autoneg?
hclge_get_sfp_info() sets mac->autoneg from the live firmware state, so
a prior "ethtool -s ethX autoneg off speed 40000" on a 100G optical
port would leave firmware reporting autoneg=DISABLE after reload.
After this change, req_speed correctly reverts to the flash default
100G, but this line still runs:
hdev->hw.mac.req_autoneg = hdev->hw.mac.autoneg;
so req_autoneg stays at AUTONEG_DISABLE rather than reverting to the
AUTONEG_ENABLE default that hclge_configure() would set for fiber.
Why is speed residue fixed while autoneg residue is preserved?
>
> ret = hclge_set_autoneg_speed_dup(hdev);
> if (ret) {
--
This is an AI-generated review.
next prev parent reply other threads:[~2026-07-21 11:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 14:05 [PATCH V2 net] net: hns3: fix speed configuration residue after driver reload Jijie Shao
2026-07-21 11:05 ` Paolo Abeni [this message]
2026-07-24 7:00 ` Jijie Shao
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=20260721110529.201977-1-pabeni@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=chenhao418@huawei.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuyonglong@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=shaojijie@huawei.com \
--cc=shenjian15@huawei.com \
--cc=yangshuaisong@h-partners.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