linux-kernel - Re: [PATCH net-next 09/11] net: dsa: rzn1-a5psw: Add support for management port frame length adjustment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+V-a8ve6vV_O1XwPX0sn+Qqm5QoYrf6Xu5gansxW05waMf43Q@mail.gmail.com>
Date: Tue, 9 Dec 2025 16:02:19 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Clément Léger <clement.leger@...tlin.com>, 
	Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Simon Horman <horms@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>, 
	Russell King <linux@...linux.org.uk>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Magnus Damm <magnus.damm@...il.com>, linux-renesas-soc@...r.kernel.org, 
	netdev@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH net-next 09/11] net: dsa: rzn1-a5psw: Add support for
 management port frame length adjustment

Hi Vladimir,

Thank you for the review. Sorry for the late reply.

On Fri, Nov 21, 2025 at 9:05 PM Vladimir Oltean <olteanv@...il.com> wrote:
>
> On Fri, Nov 21, 2025 at 11:35:35AM +0000, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Extend the RZN1 A5PSW driver to support SoC-specific adjustments to the
> > management (CPU) port frame length. Some SoCs, such as the RZ/T2H and
> > RZ/N2H, require additional headroom on the management port to account
> > for a special management tag added to frames. Without this adjustment,
> > frames may be incorrectly detected as oversized and subsequently
> > discarded.
> >
> > Introduce a new field, `management_port_frame_len_adj`, in
> > `struct a5psw_of_data` to represent this adjustment, and apply it in
> > `a5psw_port_change_mtu()` when configuring the frame length for the
> > CPU port.
> >
> > This change prepares the driver for use on RZ/T2H and RZ/N2H SoCs.
>
> In the next change you set this to 40. What's the reason behind such a
> high value (need to set the management port A5PSW_FRM_LENGTH value to
> 1574 bytes to pass L2 payload of 1500 bytes)? It sounds like this needs
> to be called out more clearly for what it is - a hardware bug.
>
Regarding the question about the relatively large adjustment value:
according to the hardware manual,
“Set the FRM_LENGTH register in port 3 (CPU port) to more than or
equal to the initial value. When you want to limit the frame length of
the received frame, use FRM_LENGTH registers in port 0 to port 2.”

In practice, with the default MTU (i.e. without applying the +40-byte
adjustment), RX traffic operates correctly. For example, running
iperf3 in reverse mode shows no issues, and frames are received
without errors. However, in the forward direction (TX from the CPU
port), throughput drops to zero and iperf3 fails.

When the MTU of the CPU-facing interface is increased (e.g. ip link
set lan0 mtu 1540), TX traffic immediately starts working correctly.
Likewise, increasing the FRM_LENGTH on the switch side for the CPU
port resolves the problem, which indicates that the frame length
configuration on this port is directly involved.

Given this behaviour, it appears that the management (CPU) port
requires additional headroom to successfully transmit frames, even
though RX succeeds without it. The STMMAC driver is used as the
controller driver for the management port, we are trying to determine
whether there is any known interaction, alignment constraint, or
undocumented overhead that would explain the need for this extra
margin.

Could you please advise on how to handle this issue?

Cheers,
Prabhakar