diff options
| author | Ovidiu Panait <ovidiu.panait.rb@renesas.com> | 2026-09-28 20:34:41 +0000 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-10-05 16:36:45 -0700 |
| commit | da17990421d79f1bfb4142f9d767fd33daecc3d8 (patch) | |
| tree | 0f4e5e8aeeb24b239d599a9787c11932ff70aa59 /tools/perf/scripts/python | |
| parent | c63ce7b9c7e7b68267899e4a0fc14b35d2c1dfcc (diff) | |
| download | linux-da17990421d79f1bfb4142f9d767fd33daecc3d8.tar.gz linux-da17990421d79f1bfb4142f9d767fd33daecc3d8.zip | |
net: stmmac: Disable S-Tag processing on dwmac4
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 a 802.1ad outer tag are incorrectly passed up the stack as
having an 802.1Q tag. This causes QinQ ping between two hosts to fail.
vlan_rx_hw() is shared by dwxgmac2 and dwmac4: on dwxgmac2 the tag type
is available in the RDES3 write-back descriptor (the ET_LT field), so the
outer tag type can be determined based on that info. However, dwmac4
doesn't seem to provide the tag type. The Length/Type field in RDES3 only
indicates whether the packet is single or double-tagged, not which tag
type was stripped.
Since dwmac4 cannot report the stripped tag type, it cannot support
hardware S-Tag stripping correctly. Therefore, restrict the
NETIF_F_HW_VLAN_STAG_RX and NETIF_F_HW_VLAN_STAG_FILTER advertisement
to dwxgmac2 only.
With this, 802.1ad tags are left in place and handled by the software
VLAN path.
Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping")
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260928203441.34876-6-ovidiu.panait.rb@renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
