Netdev List
 help / color / mirror / Atom feed
* [PATCH net] net: rnpgbe: Accept link-down events without speed magic
@ 2026-10-26  7:54 Dong Yibo
  2026-10-26  8:00 ` netdev-bot+sinfo
  2026-10-29 11:30 ` patchwork-bot+netdevbpf
  0 siblings, 2 replies; 5+ messages in thread
From: Dong Yibo @ 2026-10-26  7:54 UTC (permalink / raw)
  To: andrew+netdev, davem, edumazet, kuba, pabeni, vadim.fedorenko
  Cc: netdev, linux-kernel, dong100, yaojun

The interface can continue reporting carrier up after the link goes
down because the driver ignores the firmware's link-down notification.

Firmware reports link-down events with a zero port_magic and no
valid speed or duplex information. The driver requires ST_VALID_MAGIC
for every link event and returns before updating the cached link state
when this check fails. It also writes an invalid driver snapshot to
firmware instead of acknowledging the link-down state.

Validate the speed magic only for link-up events. This allows link-down
events to update the cached state, propagate carrier loss, and update
the snapshot exported to firmware. Keep the checks for invalid link-up
magic and unsupported speeds.

Fixes: 92a671d510a8 ("net: rnpgbe: Add link status handling support")
Signed-off-by: Dong Yibo <dong100@mucse.com>
---
 drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c b/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c
index 683e0ea74113..c6ce9dbee3d0 100644
--- a/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c
+++ b/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c
@@ -392,8 +392,11 @@ static void mucse_mbx_fw_req_handler(struct mucse_hw *hw,
 		u16 speed = le16_to_cpu(req->link_stat.st.speed);
 
 		spin_lock_irqsave(&mucse->link_lock, flags);
-		if (magic != ST_VALID_MAGIC) {
-			/* Do not change the cached state for an invalid event.
+		/* Link-down events do not carry valid speed/duplex information
+		 * and may have a zero port_magic. Validate it only for link up.
+		 */
+		if (mucse_link_is_up(hw, req) && magic != ST_VALID_MAGIC) {
+			/* Keep the cached state for an invalid link-up event.
 			 * Use an invalid speed encoding to make firmware report
 			 * again.
 			 */
-- 
2.50.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH net] net: rnpgbe: Accept link-down events without speed magic
  2026-10-26  7:54 [PATCH net] net: rnpgbe: Accept link-down events without speed magic Dong Yibo
@ 2026-10-26  8:00 ` netdev-bot+sinfo
  2026-10-26  9:26   ` Yibo Dong
  2026-10-29 11:30 ` patchwork-bot+netdevbpf
  1 sibling, 1 reply; 5+ messages in thread
From: netdev-bot+sinfo @ 2026-10-26  8:00 UTC (permalink / raw)
  To: Dong Yibo
  Cc: andrew+netdev, davem, edumazet, kuba, pabeni, vadim.fedorenko,
	netdev, linux-kernel, yaojun

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net] net: rnpgbe: Accept link-down events without speed magic
  2026-10-26  8:00 ` netdev-bot+sinfo
@ 2026-10-26  9:26   ` Yibo Dong
  2026-10-28 12:40     ` Simon Horman
  0 siblings, 1 reply; 5+ messages in thread
From: Yibo Dong @ 2026-10-26  9:26 UTC (permalink / raw)
  To: netdev-bot+sinfo
  Cc: andrew+netdev, davem, edumazet, kuba, pabeni, vadim.fedorenko,
	netdev, linux-kernel, yaojun

On Mon, Oct 26, 2026 at 08:00:22AM +0000, netdev-bot+sinfo@kernel.org wrote:
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
> 
>  - What hardware the change was tested on. For driver fixes please
>    mention the device (and if relevant firmware version) used for
>    testing, or say that the change was not tested on real hardware.
> 
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.
> 
Hi,

The issue was encountered during rnpgbe development and hardware
regression testing.

The fix was tested on MUCSE N210 and N500 adapters with firmware
1.1.8.0, using PCI passthrough to a VM. Physical N500 is used as
link partners.

With the unpatched driver, administratively bringing down the link
partner left the VM interface reporting carrier up throughout a
seven-second observation period. With the patch applied, the VM
interface correctly reported carrier down.

The comparison was repeated three times per adapter for both driver
versions. After bringing the link partner back up, bidirectional
ping passed in every case.

If another revision is needed, I will include this information in
the commit message.

Thanks,
Dong Yibo

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net] net: rnpgbe: Accept link-down events without speed magic
  2026-10-26  9:26   ` Yibo Dong
@ 2026-10-28 12:40     ` Simon Horman
  0 siblings, 0 replies; 5+ messages in thread
From: Simon Horman @ 2026-10-28 12:40 UTC (permalink / raw)
  To: Yibo Dong
  Cc: netdev-bot+sinfo, andrew+netdev, davem, edumazet, kuba, pabeni,
	vadim.fedorenko, netdev, linux-kernel, yaojun

On Mon, Oct 26, 2026 at 05:26:15PM +0800, Yibo Dong wrote:
> On Mon, Oct 26, 2026 at 08:00:22AM +0000, netdev-bot+sinfo@kernel.org wrote:
> > Hi!
> > 
> > This is an automated message. This series looks like a fix, but its
> > commit messages seem to be missing some information:
> > 
> >  - How the issue was discovered, e.g. hit in production, hit during
> >    development, syzbot report, manual code inspection, LLM or static
> >    analysis tool scan.
> > 
> >  - What hardware the change was tested on. For driver fixes please
> >    mention the device (and if relevant firmware version) used for
> >    testing, or say that the change was not tested on real hardware.
> > 
> > Please do not repost the series just to address the above. Instead,
> > reply to this email with the missing information, so that reviewers
> > can take it into account. If the series needs another revision for
> > other reasons, please include the information in the commit messages
> > then.
> > 
> > The evaluation is done by an LLM so it may be wrong, if you think
> > that is the case please reply and explain.
> > 
> Hi,
> 
> The issue was encountered during rnpgbe development and hardware
> regression testing.
> 
> The fix was tested on MUCSE N210 and N500 adapters with firmware
> 1.1.8.0, using PCI passthrough to a VM. Physical N500 is used as
> link partners.
> 
> With the unpatched driver, administratively bringing down the link
> partner left the VM interface reporting carrier up throughout a
> seven-second observation period. With the patch applied, the VM
> interface correctly reported carrier down.
> 
> The comparison was repeated three times per adapter for both driver
> versions. After bringing the link partner back up, bidirectional
> ping passed in every case.
> 
> If another revision is needed, I will include this information in
> the commit message.

Reviewed-by: Simon Horman <horms@kernel.org>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net] net: rnpgbe: Accept link-down events without speed magic
  2026-10-26  7:54 [PATCH net] net: rnpgbe: Accept link-down events without speed magic Dong Yibo
  2026-10-26  8:00 ` netdev-bot+sinfo
@ 2026-10-29 11:30 ` patchwork-bot+netdevbpf
  1 sibling, 0 replies; 5+ messages in thread
From: patchwork-bot+netdevbpf @ 2026-10-29 11:30 UTC (permalink / raw)
  To: Yibo Dong
  Cc: andrew+netdev, davem, edumazet, kuba, pabeni, vadim.fedorenko,
	netdev, linux-kernel, yaojun

Hello:

This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Mon, 26 Oct 2026 15:54:45 +0800 you wrote:
> The interface can continue reporting carrier up after the link goes
> down because the driver ignores the firmware's link-down notification.
> 
> Firmware reports link-down events with a zero port_magic and no
> valid speed or duplex information. The driver requires ST_VALID_MAGIC
> for every link event and returns before updating the cached link state
> when this check fails. It also writes an invalid driver snapshot to
> firmware instead of acknowledging the link-down state.
> 
> [...]

Here is the summary with links:
  - [net] net: rnpgbe: Accept link-down events without speed magic
    https://git.kernel.org/netdev/net/c/6815a2513eff

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-10-29 11:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-26  7:54 [PATCH net] net: rnpgbe: Accept link-down events without speed magic Dong Yibo
2026-10-26  8:00 ` netdev-bot+sinfo
2026-10-26  9:26   ` Yibo Dong
2026-10-28 12:40     ` Simon Horman
2026-10-29 11:30 ` patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox