diff options
| author | Vladimir Oltean <vladimir.oltean@nxp.com> | 2025-11-30 15:16:46 +0200 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2025-12-01 16:45:07 -0800 |
| commit | 30296ac7642652428396222e720718f2661e9425 (patch) | |
| tree | 8ce01633bde7f00501a18704c0b1d4778e4d1113 /tools/testing/selftests/net/lib/py/utils.py | |
| parent | bed59a86e91ad680331ecad4bf8717cbd4f5fc7f (diff) | |
net: dsa: xrs700x: reject unsupported HSR configurations
As discussed here:
https://lore.kernel.org/netdev/20240620090210.drop6jwh7e5qw556@skbuf/
the fact is that the xrs700x.c driver only supports offloading
HSR_PT_SLAVE_A and HSR_PT_SLAVE_B (which were the only port types at the
time the offload was written, _for this driver_).
Up until now, the API did not explicitly tell offloading drivers what
port has what role. So xrs700x can get confused and think that it can
support a configuration which it actually can't. There was a table in
the attached link which gave an example:
$ ip link add name hsr0 type hsr slave1 swp0 slave2 swp1 \
interlink swp2 supervision 45 version 1
HSR_PT_SLAVE_A HSR_PT_SLAVE_B HSR_PT_INTERLINK
----------------------------------------------------------------
user
space 0 1 2
requests
----------------------------------------------------------------
XRS700X
driver 1 2 -
understands
The switch would act as if the ring ports were swp1 and swp2.
Now that we have explicit hsr_get_port_type() API, let's use that to
work around the unintended semantical changes of the offloading API
brought by the introduction of interlink ports in HSR.
Fixes: 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)")
Cc: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: George McCollister <george.mccollister@gmail.com>
Link: https://patch.msgid.link/20251130131657.65080-5-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/testing/selftests/net/lib/py/utils.py')
0 files changed, 0 insertions, 0 deletions
