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

["Théo Lebrun" <theo.lebrun@bootlin.com>]

Hello Zijin,

Also your To/Cc list is weird, make sure to use
scripts/get_maintainer.pl (or use b4 for patch
management which uses it automatically).

On Mon Sep 21, 2026 at 10:58 AM CEST, Théo Lebrun wrote:
> Hello Zijin,
>
> You sent the same patch 3 times?
> Message-ID: <20260920095839.62852-1-taozj888@163.com>
> Message-ID: <20260920100658.65087-1-taozj888@163.com>
> Message-ID: <20260920100920.65773-1-taozj888@163.com>
>
> Also you are missing the prefix [PATCH net] or [PATCH net-next].
> Read up about this here (and read the full page):
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> On Sun Sep 20, 2026 at 11:58 AM CEST, Zijin Tao wrote:
>> 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 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
>> ...
>
> This whole patch is LLM generated? I don't think this "PHYT0036:00"
> device name could ever exist. Please don't hallucinate kernel logs.
>
> In both cases, I prefer the commit message to either indicate whether it
> is a theoretical bugfix or a bug hit in practice. I know I've faced
> such a log spam on MACB in the past, but I don't remember which log
> line it was.
>
>> in gem_rx() by received a large number of packets without
>> RX_SOF or RX_EOF flag set.
>>
>> The unlimited print here would greatly bother and delay
>> the system booting process unless the source stop sending
>> packets.
>
> I don't understand the relation to the booting process here.
>
>> So rate limit the netdev error information print in the receive
>> and transmit data path.
>>
>> Signed-off-by: Zijin Tao <taozj888@163.com>

Thanks Zijin,

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