From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Ovidiu Panait <ovidiu.panait.rb@renesas.com>,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com, joabreu@synopsys.com,
jun.ann.lai@intel.com, yi.fang.gan@intel.com,
boon.khai.ng@altera.com, matthew.gerlach@altera.com,
"Nazle Asmade,
Muhammad Nazim Amirul"
<muhammad.nazim.amirul.nazle.asmade@altera.com>
Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 0/5] net: stmmac: Fix double VLAN 802.1ad tag handling
Date: Wed, 29 Jul 2026 13:35:44 +0200 [thread overview]
Message-ID: <af97a4a2-9a1d-4b36-9055-d05124bf4ab9@bootlin.com> (raw)
In-Reply-To: <20260729095110.164157-1-ovidiu.panait.rb@renesas.com>
+ Nazim Amirul
On 7/29/26 11:51, Ovidiu Panait wrote:
> Currently, hardware VLAN stripping is broken for 802.1ad tags. vlan_rx_hw()
> hardcodes ETH_P_8021Q when putting the hardware tag into the skb, rather
> than using the actual protocol from the packet. Because of this, packets
> that contain an 802.1ad outer tag are incorrectly passed up the stack as
> having an 802.1Q tag.
>
> This issue was observed on the Renesas RZ/V2H platform (which has a dwmac4
> IP), when testing QinQ ping:
>
> # DUT
> ip link add link end0 name end0.100 type vlan proto 802.1ad id 100
> ip link add link end0.100 name end0.100.200 type vlan proto 802.1q id 200
> ip addr add 172.16.3.2/24 dev end0.100.200
> ip link set end0 up
> ip link set end0.100 up
> ip link set end0.100.200 up
>
> # Peer
> ip link add link eth0 name eth0.100 type vlan proto 802.1ad id 100
> ip link add link eth0.100 name eth0.100.200 type vlan proto 802.1q id 200
> ip addr add 172.16.3.1/24 dev eth0.100.200
> ip link set eth0 up
> ip link set eth0.100 up
> ip link set eth0.100.200 up
> ping 172.16.3.2
> -- FAIL --
>
> This series addresses the issue for both dwmac4 and dwxgmac2:
> - dwmac4: since dwmac4 does not expose the tag type in the RDES3
> descriptor, it cannot support hardware double VLAN stripping correctly.
> This series disables double VLAN stripping for it, so the 802.1ad tags
> are left in place and are handled by the software VLAN path.
>
> - dwxgmac2: the RDES3 descriptor does report the type, so the code was
> updated to read it instead of hardcoding ETH_P_8021Q.
>
> Note: patch 5/5 was compile tested only, as I do not have the hardware.
> However, it uses the same codepath as dwmac4, so it has the same issue.
Nazim Amirul, as you seem to have access to some AgileX5 with XGMAC, can you
see if you can reproduce the issue on your side and if this series solves it ?
Thanks :)
Maxime
next prev parent reply other threads:[~2026-07-29 11:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 9:51 [PATCH net 0/5] net: stmmac: Fix double VLAN 802.1ad tag handling Ovidiu Panait
2026-07-29 9:51 ` [PATCH net 1/5] net: stmmac: Remove VLAN perfect matching dead code Ovidiu Panait
2026-07-29 11:29 ` Maxime Chevallier
2026-07-29 15:02 ` Ovidiu Panait
2026-07-29 15:08 ` Maxime Chevallier
2026-07-29 9:51 ` [PATCH net 2/5] net: stmmac: Enable double VLAN processing only when supported Ovidiu Panait
2026-07-29 9:51 ` [PATCH net 3/5] net: stmmac: Move double VLAN handling to a dedicated op Ovidiu Panait
2026-07-29 9:51 ` [PATCH net 4/5] net: stmmac: Disable double VLAN stripping on dwmac4 Ovidiu Panait
2026-07-29 9:51 ` [PATCH net 5/5] net: stmmac: Fix double VLAN stripping on dwxgmac2 Ovidiu Panait
2026-07-29 11:30 ` [PATCH net 0/5] net: stmmac: Fix double VLAN 802.1ad tag handling Maxime Chevallier
2026-07-29 11:35 ` Maxime Chevallier [this message]
2026-07-29 16:29 ` Andrew Lunn
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=af97a4a2-9a1d-4b36-9055-d05124bf4ab9@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=boon.khai.ng@altera.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=jun.ann.lai@intel.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=matthew.gerlach@altera.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=muhammad.nazim.amirul.nazle.asmade@altera.com \
--cc=netdev@vger.kernel.org \
--cc=ovidiu.panait.rb@renesas.com \
--cc=pabeni@redhat.com \
--cc=yi.fang.gan@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox