[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250810164941.4oezju3c4vhnunrx@skbuf>
Date: Sun, 10 Aug 2025 19:49:41 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Chukun Pan <amadeus@....edu.cn>, jonas@...boo.se, alsi@...g-olufsen.dk,
conor+dt@...nel.org, davem@...emloft.net,
devicetree@...r.kernel.org, edumazet@...gle.com, heiko@...ech.de,
krzk+dt@...nel.org, kuba@...nel.org, linus.walleij@...aro.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-rockchip@...ts.infradead.org, netdev@...r.kernel.org,
pabeni@...hat.com, robh@...nel.org, ziyao@...root.org
Subject: Re: [PATCH 3/3] arm64: dts: rockchip: Add RTL8367RB-VB switch to
Radxa E24C
On Sun, Aug 10, 2025 at 05:15:59PM +0200, Andrew Lunn wrote:
> Just a guess, but maybe it is a DSA tagger bug? Maybe the user frame
> is a VLAN frame. The tagger is placing the VLAN tag into the DSA
> header, so in effect, the frame is no longer a VLAN frame. But it is
> not calling __vlan_hwaccel_clear_tag() to indicate the skbuf no longer
> needs VLAN processing?
For the original skb to have had a VLAN hwaccel tag, validate_xmit_vlan()
would have had to not push it inside, so vlan_hw_offload_capable() must
have been true for DSA user ports. But we advertise neither the
NETIF_F_HW_VLAN_CTAG_TX nor the NETIF_F_HW_VLAN_STAG_TX netdev feature.
So the VLAN tags in skbs transmitted through DSA user ports should all
be in the skb head.
Powered by blists - more mailing lists