All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Théo Lebrun" <theo.lebrun@bootlin.com>
To: "Kevin Hao" <haokexin@gmail.com>,
	"Taedcke, Christian" <christian.taedcke-oss@weidmueller.com>
Cc: <christian.taedcke@weidmueller.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	"Clark Williams" <clrkwllms@kernel.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Robert Hancock" <robert.hancock@calian.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-rt-devel@lists.linux.dev>, <stable@vger.kernel.org>
Subject: Re: [PATCH net 1/2] net: macb: reprogram TBQP after shuffling the TX ring on link-up
Date: Fri, 10 Jul 2026 15:56:32 +0200	[thread overview]
Message-ID: <DJUXYXEQMUJ4.31H82KQMG29UC@bootlin.com> (raw)
In-Reply-To: <ak2-XJHVc3Cg6ZEk@xiaowei>

Hello Kevin & Christian,

On Wed Jul 8, 2026 at 5:05 AM CEST, Kevin Hao wrote:
>> I agree that the TRM says the transmit pointer is reset while TE is low. My
>> question is whether this describes an internal pointer being reloaded from TBQP,
>> or whether TBQP itself is restored to the original ring base.
>
> The Zynq UltraScale TRM [1] describes the receive-buffer queue pointer as follows:
>
>   An internal counter represents the receive-buffer queue pointer and it is not
>   visible through the CPU interface.
>
> I could not find a similar description for the transmit-buffer queue pointer,
> but I believe it behaves the same way. From a software perspective, it should
> be safe to assume that the TBQP is reset to point to the start of the transmit
> descriptor list upon reset. This assumption is supported by the description
> of the transmit_q_ptr (GEM) Register [2]:
>
>   Reading this register returns the location of the descriptor currently being accessed.
>   Since the DMA handles two frames at once, this may not necessarily be pointing to the
>   current frame being transmitted.
>
> [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm
> [2] https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/transmit_q_ptr-GEM-Register

For what it's worth, I agree with Kevin.

It should be rather easy to detect if the patch is needed, with more
logging. Dump TBQP before link-down & dump it at link-up. The code
expects TBQP to reset to the ring start automatically whereas this
commit message says the TBQP after link-up is some offset into the ring.

Lastly, the cover letter mentions that [PATCH 1/2] alone isn't enough.
But it doesn't mention that [PATCH 2/2] alone doesn't solve the issue.
This would be a useful test as well.

On Tue Jul 7, 2026 at 3:36 PM CEST, Taedcke, Christian wrote:
> Thank you for the quick review! This is my first Linux kernel
> contribution, so I appreciate your feedback here.

Welcome!

Thanks,

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


  reply	other threads:[~2026-07-10 13:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06 14:02 [PATCH net 0/2] net: macb: fix TXUBR interrupt storm on link flapping Christian Taedcke via B4 Relay
2026-07-06 14:02 ` Christian Taedcke
2026-07-06 14:02 ` [PATCH net 1/2] net: macb: reprogram TBQP after shuffling the TX ring on link-up Christian Taedcke via B4 Relay
2026-07-06 14:02   ` Christian Taedcke
2026-07-06 15:04   ` Sebastian Andrzej Siewior
2026-07-07 13:36     ` Taedcke, Christian
2026-07-10  8:08       ` Sebastian Andrzej Siewior
2026-07-07  9:13   ` Kevin Hao
2026-07-07 14:29     ` Taedcke, Christian
2026-07-08  3:05       ` Kevin Hao
2026-07-10 13:56         ` Théo Lebrun [this message]
2026-07-07 14:02   ` sashiko-bot
2026-07-06 14:02 ` [PATCH net 2/2] net: macb: mask TXUBR during TX NAPI poll to prevent IRQ storms Christian Taedcke via B4 Relay
2026-07-06 14:02   ` Christian Taedcke
2026-07-06 15:05   ` Sebastian Andrzej Siewior
2026-07-07 13:41     ` Taedcke, Christian
2026-07-07 14:02   ` sashiko-bot
2026-07-10 16:43   ` Théo Lebrun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DJUXYXEQMUJ4.31H82KQMG29UC@bootlin.com \
    --to=theo.lebrun@bootlin.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bigeasy@linutronix.de \
    --cc=christian.taedcke-oss@weidmueller.com \
    --cc=christian.taedcke@weidmueller.com \
    --cc=clrkwllms@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=haokexin@gmail.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robert.hancock@calian.com \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.