[PATCH net] net: rnpgbe: Accept link-down events without speed magic

[PATCH net] net: rnpgbe: Accept link-down events without speed magic

[Dong Yibo]

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

Re: [PATCH net] net: rnpgbe: Accept link-down events without speed magic

[netdev-bot+sinfo]

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.

Re: [PATCH net] net: rnpgbe: Accept link-down events without speed magic

[Yibo Dong]

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