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_SOF or RX_EOF flag set, especially with unknown packet
type.

The unlimited prints here would greatly bother and delay
the system booting process unless the source stop sending
packets.

So rate limit the netdev error information print in the receive
and transmit data path.

Signed-off-by: Zijin Tao <taozj888@163.com>
---
 drivers/net/ethernet/cadence/macb_main.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index b8234ac4b602..c32d48d03008 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -1617,16 +1617,16 @@ static int gem_rx(struct macb_queue *queue, struct napi_struct *napi,
 		count++;
 
 		if (!(ctrl & MACB_BIT(RX_SOF) && ctrl & MACB_BIT(RX_EOF))) {
-			netdev_err(bp->netdev,
-				   "not whole frame pointed by descriptor\n");
+			if (net_ratelimit())
+				netdev_err(bp->netdev, "not whole frame pointed by descriptor\n");
 			bp->netdev->stats.rx_dropped++;
 			queue->stats.rx_dropped++;
 			break;
 		}
 		skb = queue->rx_skbuff[entry];
 		if (unlikely(!skb)) {
-			netdev_err(bp->netdev,
-				   "inconsistent Rx descriptor chain\n");
+			if (net_ratelimit())
+				netdev_err(bp->netdev, "inconsistent Rx descriptor chain\n");
 			bp->netdev->stats.rx_dropped++;
 			queue->stats.rx_dropped++;
 			break;
@@ -1829,7 +1829,8 @@ static int macb_rx(struct macb_queue *queue, struct napi_struct *napi,
 		unsigned long flags;
 		u32 ctrl;
 
-		netdev_err(bp->netdev, "RX queue corruption: reset it\n");
+		if (net_ratelimit())
+			netdev_err(bp->netdev, "RX queue corruption: reset it\n");
 
 		spin_lock_irqsave(&bp->lock, flags);
 
@@ -2102,7 +2103,8 @@ static int macb_interrupt_misc(struct macb_queue *queue, u32 status)
 
 	if (status & MACB_BIT(HRESP)) {
 		queue_work(system_bh_wq, &bp->hresp_err_bh_work);
-		netdev_err(netdev, "DMA bus error: HRESP not OK\n");
+		if (net_ratelimit())
+			netdev_err(netdev, "DMA bus error: HRESP not OK\n");
 		macb_queue_isr_clear(bp, queue, MACB_BIT(HRESP));
 	}
 
@@ -2511,7 +2513,8 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
 		else
 			hdrlen = skb_tcp_all_headers(skb);
 		if (skb_headlen(skb) < hdrlen) {
-			netdev_err(bp->netdev, "Error - LSO headers fragmented!!!\n");
+			if (net_ratelimit())
+				netdev_err(bp->netdev, "Error - LSO headers fragmented!!!\n");
 			/* if this is required, would need to copy to single buffer */
 			return NETDEV_TX_BUSY;
 		}
-- 
2.34.1

Hello Zijin,

You missed part of my recent feedback [0][1]. Copy paste:

 - 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

 - 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).

In addition, make sure to read the "submitting patches" guide [2].
You missed:
 - replying to all review points one by one using interleaved [4]
 - V2 in subject [3]
 - write up a changelog [4]

Also this one is less well known, but the net subsystem (and many others
nowadays) expect people to reply to Sashiko review emails to say
whether they agree or disagree. Especially if they disagree. You can
mostly skip over the pre-existing issues which don't relate to your
series.

For example Sashiko says you don't cover some log netdev_err() calls.
You can reply explaining why only the ones you touched are important to
deal with.

--

And I see just now I have in my inbox an email from you asking how to do
it properly. Good! But it doesn't show up on lore, I'm not sure why.

Replying to it here:

 - Don't send the same patch but slightly modified. Maintainers need to
   know the latest version. New version means V2/V3/etc, even if
   changes are tiny (like a typo fix in commit message).

 - Don't put V1 for the first revision. I think that's git-format-patch
   default behavior.

 - Using git-format-patch looks something like:

   ⟩ git format-patch -1 998b159fdd78 --subject-prefix="PATCH net" -v2
   v2-0001-net-macb-take-bp-lock-around-NCR-read-modify-writ.patch

   ⟩ grep ^Subject v2-0001-net-macb-take-bp-lock-around-NCR-read-modify-writ.patch
   Subject: [PATCH net v2] net: macb: take bp->lock around NCR read-modify-writes

   ⟩ scripts/get_maintainer.pl v2-0001-*.patch
   "Théo Lebrun" <theo.lebrun@bootlin.com> (maintainer:ATMEL MACB ETHERNET DRIVER)
   Conor Dooley <conor.dooley@microchip.com> (reviewer:ATMEL MACB ETHERNET DRIVER)
   Andrew Lunn <andrew+netdev@lunn.ch> (maintainer:NETWORKING DRIVERS)
   ...

   I think most people call scripts/get_maintainer.pl and write the
   git send-email --to/--cc flags by hand. I've been using b4 for a few
   years now so I don't really know the usual git format-patch workflow.

   Or you can use `git send-email --cc-cmd=scripts/get_maintainer.pl`.

[0]: https://lore.kernel.org/all/DLKVCOXTNGVZ.3CC6KFXDIFJ3X@bootlin.com/
[1]: https://lore.kernel.org/all/DLKVEXS7X14N.XLLMBDDX6ZJW@bootlin.com/
[2]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html
[3]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#subject-line
[4]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#respond-to-review-comments

Thanks,

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

On Sun, 20 Sep 2026 18:09:20 +0800 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 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
> ...

Do you have the HW or you're acting based on LLM output?
If the latter, and since you can't follow the process please
don't post any more such patches.

If you do have the HW to test this - put into the commit message
what HW you have, and covering all the cases.
-- 
pw-bot: cr

Hi Jakub:

Yes, we had the actual HW for our production environment which is based on a chip
that used the Cadence MACB implementation, and it really bothered our booting process
since it received a lot of jumob pkts which are just over the current MTU of the driver
and it has to show those error msgs. 

The issue was reported by our production section. Actually the err msg here should include a timestamp
at the beginning, looks like:
[ 318.594950][ C0] macb PHYT0036:00 eth0: not whole frame pointed by descriptor
[ 318.602366][ C0] macb PHYT0036:00 eth0: not whole frame pointed by descriptor
...

but for simplicity, I just removed that part.

I will put some of the HW info into the commit msg as what you indicated.

Thanks,

Zijin Tao






At 2026-09-24 09:17:46, "Jakub Kicinski" <kuba@kernel.org> wrote:
>On Sun, 20 Sep 2026 18:09:20 +0800 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 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
>> ...
>
>Do you have the HW or you're acting based on LLM output?
>If the latter, and since you can't follow the process please
>don't post any more such patches.
>
>If you do have the HW to test this - put into the commit message
>what HW you have, and covering all the cases.
>-- 
>pw-bot: cr