kernel/linux.git/net/dsa, branch master

net: dsa: tag_rtl8_4: set KEEP flag

2026-04-12T16:03:55+00:00

KEEP=1 is needed because we should respect the format of the packet as the kernel sends it to us. Unless tx forward offloading is used, the kernel is giving us the packet exactly as it should leave the specified port on the wire. Until now this was not needed because the ports were always functioning in a standalone mode in a VLAN-unaware way, so the switch would not tag or untag frames anyway. But arguably it should have been KEEP=1 all along. Co-developed-by: Alvin Šipraga Signed-off-by: Alvin Šipraga Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260408-realtek_fixes-v1-2-915ff1404d56@gmail.com Signed-off-by: Jakub Kicinski

net: dsa: tag_rtl8_4: update format description

2026-04-12T16:03:54+00:00

Document the updated tag layout fields (EFID, VSEL/VIDX) and clarify which bits are set/cleared when emitting tags. Co-developed-by: Alvin Šipraga Signed-off-by: Alvin Šipraga Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260408-realtek_fixes-v1-1-915ff1404d56@gmail.com Signed-off-by: Jakub Kicinski

dsa: tag_mxl862xx: set dsa_default_offload_fwd_mark()

2026-04-07T01:30:33+00:00

The MxL862xx offloads bridge forwarding in hardware, so set dsa_default_offload_fwd_mark() to avoid duplicate forwarding of packets of (eg. flooded) frames arriving at the CPU port. Link-local frames are directly trapped to the CPU port only, so don't set dsa_default_offload_fwd_mark() on those. Signed-off-by: Daniel Golle Link: https://patch.msgid.link/e1161c90894ddc519c57dc0224b3a0f6bfa1d2d6.1775049897.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

net: dsa: add tag format for MxL862xx switches

2026-02-11T10:27:57+00:00

Add proprietary special tag format for the MaxLinear MXL862xx family of switches. While using the same Ethertype as MaxLinear's GSW1xx switches, the actual tag format differs significantly, hence we need a dedicated tag driver for that. Signed-off-by: Daniel Golle Link: https://patch.msgid.link/c64e6ddb6c93a4fac39f9ab9b2d8bf551a2b118d.1770433307.git.daniel@makrotopia.org Reviewed-by: Vladimir Oltean Signed-off-by: Paolo Abeni

net: dsa: eliminate local type for tc policers

2026-02-10T14:30:11+00:00

David Yang is saying that struct flow_action_entry in include/net/flow_offload.h has gained new fields and DSA's struct dsa_mall_policer_tc_entry, derived from that, isn't keeping up. This structure is passed to drivers and they are completely oblivious to the values of fields they don't see. This has happened before, and almost always the solution was to make the DSA layer thinner and use the upstream data structures. Here, the reason why we didn't do that is because struct flow_action_entry :: police is an anonymous structure. That is easily enough fixable, just name those fields "struct flow_action_police" and reference them from DSA. Make the according transformations to the two users (sja1105 and felix): "rate_bytes_per_sec" -> "rate_bytes_ps". Signed-off-by: Vladimir Oltean Co-developed-by: David Yang Signed-off-by: David Yang Link: https://patch.msgid.link/20260206075427.44733-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni

net: dsa: tag_yt921x: add priority support

2026-02-03T14:09:31+00:00

Required by DCB/QoS support of the switch driver, since the rx packets will have non-zero priorities. Signed-off-by: David Yang Link: https://patch.msgid.link/20260131021854.3405036-3-mmyangfl@gmail.com Reviewed-by: Vladimir Oltean Signed-off-by: Paolo Abeni

net: dsa: tag_yt921x: clarify priority and code fields

2026-02-03T14:09:31+00:00

Packet priority is part of the tag, and the priority and code fields are used by tx and rx. Make revisions to reflect the facts. Signed-off-by: David Yang Link: https://patch.msgid.link/20260131021854.3405036-2-mmyangfl@gmail.com Reviewed-by: Vladimir Oltean Signed-off-by: Paolo Abeni

net: dsa: fix off-by-one in maximum bridge ID determination

2026-01-22T03:52:29+00:00

Prior to the blamed commit, the bridge_num range was from 0 to ds->max_num_bridges - 1. After the commit, it is from 1 to ds->max_num_bridges. So this check: if (bridge_num >= max) return 0; must be updated to: if (bridge_num > max) return 0; in order to allow the last bridge_num value (==max) to be used. This is easiest visible when a driver sets ds->max_num_bridges=1. The observed behaviour is that even the first created bridge triggers the netlink extack "Range of offloadable bridges exceeded" warning, and is handled in software rather than being offloaded. Fixes: 3f9bb0301d50 ("net: dsa: make dp->bridge_num one-based") Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260120211039.3228999-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski