Re: [PATCH net v4] net: macb: rate limit netdev error info print in the data path

[Théo Lebrun]

Hello taozj888,

I was reviewing your patch but you sent V4 at the same time!

On Wed Oct 7, 2026 at 7:32 AM CEST,  wrote:
> From: taozijin <taozj888@xxxxxxx>

We need full names in kernel patches, you have that in your
Signed-off-by.

> Now the MACB ethernet driver print the netdev error information
> directly by netdev_err(), which would lead to a large number of
> error information print if there was a significant number of
> error or just jumbo packets exceeding the MTU received when booting.
> For example, it would print a large number of:
>
> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
> ...
>
> in gem_rx() by received a large number of packets without
> RX_EOF flag set, especially with unknown packet
> type that would penetrate the hardware offload for the IP packets.
>
> The unlimited prints here would greatly bother and delay
> the system booting process unless the source stop sending
> packets since they occupy the console output bandwidth and
> other processes have to wait for the completion of printing those
> messages.
>
> So rate limit the netdev error information print in the receive
> and transmit data path.
>
> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
> Cc: stable@xxxxxxxxxxxxxxx

What happened? This doesn't match your discussion with Nicolai.
https://lore.kernel.org/netdev/3e1515e162d084e2200eeaa6074bfbaf@xxxxxxxxxxx/

TLDR, because those threads are a mess:
 - why drop start_xmit diff?
 - fix your patch autorship
 - check your changelog!
 - check your fixes!

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

text:
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 07 Oct 2026 11:33:03 +0200
Message-Id: <DLYI3O7PFN94.V7VH3HSLKEMD@xxxxxxxxxxx>
Subject: Re: [PATCH net v4] net: macb: rate limit netdev error info print in
 the data path
Cc: <stable@xxxxxxxxxxxxxxx>, "Conor Dooley" <conor.dooley@xxxxxxxxxxxxx>,
 "Andrew Lunn" <andrew+netdev@xxxxxxx>, "David S. Miller"
 <davem@xxxxxxxxxxxxx>, "Eric Dumazet" <edumazet@xxxxxxxxxx>, "Jakub
 Kicinski" <kuba@xxxxxxxxxx>, "Paolo Abeni" <pabeni@xxxxxxxxxx>, "Jeff
 Garzik" <jeff@xxxxxxxxxx>, "Haavard Skinnemoen" <hskinnemoen@xxxxxxxxx>,
 "open list:NETWORKING DRIVERS" <netdev@xxxxxxxxxxxxxxx>, "open list"
 <linux-kernel@xxxxxxxxxxxxxxx>
To: <taozj888@xxxxxxx>
From: =?utf-8?q?Théo_Lebrun?= <theo.lebrun@xxxxxxxxxxx>
X-Mailer: aerc 0.22.0-0-gc2f86b7abde3
References: <20261007053211.572073-1-taozj888@xxxxxxx>
In-Reply-To: <20261007053211.572073-1-taozj888@xxxxxxx>
X-TUID: MurW8kMqMYNV

Hello taozj888,

I was reviewing your patch but you sent V4 at the same time!

On Wed Oct 7, 2026 at 7:32 AM CEST,  wrote:
> From: taozijin <taozj888@xxxxxxx>

We need full names in kernel patches, you have that in your
Signed-off-by.

> Now the MACB ethernet driver print the netdev error information
> directly by netdev_err(), which would lead to a large number of
> error information print if there was a significant number of
> error or just jumbo packets exceeding the MTU received when booting.
> For example, it would print a large number of:
>
> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
> macb PHYT0036:00 eth0: not whole frame pointed by descriptor
> ...
>
> in gem_rx() by received a large number of packets without
> RX_EOF flag set, especially with unknown packet
> type that would penetrate the hardware offload for the IP packets.
>
> The unlimited prints here would greatly bother and delay
> the system booting process unless the source stop sending
> packets since they occupy the console output bandwidth and
> other processes have to wait for the completion of printing those
> messages.
>
> So rate limit the netdev error information print in the receive
> and transmit data path.
>
> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
> Cc: stable@xxxxxxxxxxxxxxx

What happened? This doesn't match your discussion with Nicolai.
https://lore.kernel.org/netdev/3e1515e162d084e2200eeaa6074bfbaf@xxxxxxxxxxx/

TLDR, because those threads are a mess:
 - why drop start_xmit diff?
 - fix your patch autorship
 - check your changelog!
 - check your fixes!

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com