| 442ecdc8 | 27-Jul-2026 |
Luiz Angelo Daros de Luca <luizluca@gmail.com> |
net: dsa: realtek: use devm_mutex_init for l2_lock
With CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() needs to be called
before the lock is discarded. Use devm_mutex_init() instead so the
cleanup is
net: dsa: realtek: use devm_mutex_init for l2_lock
With CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() needs to be called
before the lock is discarded. Use devm_mutex_init() instead so the
cleanup is handled automatically.
Fixes: 336e3e4a1ab37 ("net: dsa: realtek: rtl8365mb: add FDB support")
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Alvin Šipraga <alvin.sipraga@analog.com>
Link: https://patch.msgid.link/20260726-realtek_mutext-v2-4-5d62ba998791@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| a95f3e9b | 27-Jul-2026 |
Luiz Angelo Daros de Luca <luizluca@gmail.com> |
net: dsa: realtek: use devm_mutex_init for vlan_lock
With CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() needs to be called
before the lock is discarded. Use devm_mutex_init() instead so the
cleanup
net: dsa: realtek: use devm_mutex_init for vlan_lock
With CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() needs to be called
before the lock is discarded. Use devm_mutex_init() instead so the
cleanup is handled automatically.
Fixes: 9da2c8672f771 ("net: dsa: realtek: rtl8365mb: add VLAN support")
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Alvin Šipraga <alvin.sipraga@analog.com>
Link: https://patch.msgid.link/20260726-realtek_mutext-v2-3-5d62ba998791@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 050e07f8 | 27-Jul-2026 |
Luiz Angelo Daros de Luca <luizluca@gmail.com> |
net: dsa: realtek: use devm_mutex_init for regmap lock
With CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() needs to be called
before the lock is discarded. Use devm_mutex_init() instead so the
cleanu
net: dsa: realtek: use devm_mutex_init for regmap lock
With CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() needs to be called
before the lock is discarded. Use devm_mutex_init() instead so the
cleanup is handled automatically.
Fixes: 907e772f6f6de ("net: dsa: realtek: allow subdrivers to externally lock regmap")
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Alvin Šipraga <alvin.sipraga@analog.com>
Link: https://patch.msgid.link/20260726-realtek_mutext-v2-2-5d62ba998791@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 98713734 | 12-Jul-2026 |
Johan Alvarado <contact@c127.dev> |
net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S
In addition to SGMII, the RTL8367S SerDes also supports HSGMII, which
carries 2.5 Gbps with the same signaling as SGMII at 2.5x clock ra
net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S
In addition to SGMII, the RTL8367S SerDes also supports HSGMII, which
carries 2.5 Gbps with the same signaling as SGMII at 2.5x clock rate.
The chip info table already declares HSGMII as a supported interface
mode for external interface 1.
Extend the SerDes PCS to handle HSGMII, which phylink represents as
2500base-x:
- Select the HSGMII SerDes tuning parameters and external interface
mode, and mux the SerDes to MAC8 in HSGMII mode, from pcs_config()
according to the interface. The parameters are again lifted from the
GPL-licensed Realtek rtl8367c vendor driver, and again only cover
the tuning variant for a non-zero chip option, so the mode is gated
on the option probed at setup.
- Advertise 2500base-x and MAC_2500FD on ports whose external
interface supports HSGMII.
- Accept SPEED_2500 in the forced link configuration. The MAC speed
field has no 2.5 Gbps value: the rate is determined by the HSGMII
SerDes configuration, and the vendor driver programs the 1 Gbps
value here, so do the same.
- Raise the port 6 ingress and egress rate limiters to their maximum
at setup time, as the vendor switch init does unconditionally for
the whole chip family. The chip resets them to 0x1FFFF (~1.048 Gbps
in units of 8 Kbps), which caps the aggregate HSGMII throughput at
roughly 1 Gbps. The vendor documentation describes the reset
default as disabling the limiter, but the cap is real: on an
RTL8367S-based Mercusys MR85X running an OpenWrt backport of this
series, several clients on 1 Gbps user ports were limited to about
1.02 Gbps combined across the HSGMII CPU port until these limiters
were raised, after which throughput reached about 2 Gbps [1]. The
related HSGMII scheduler line rate (LINE_RATE_HSG_H) is already set
to its maximum by the common init jam table.
Tested on a Mercusys MR80X v2.20, where the RTL8367S is connected to
the SoC over HSGMII.
Link: https://github.com/openwrt/openwrt/pull/19445#issuecomment-4505613294 [1]
Suggested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Suggested-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Johan Alvarado <contact@c127.dev>
Tested-by: Stanisław Pal <kuncy7@gmail.com>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Tested-by: Stanislaw Pal <kuncy7@gmail.com>
Link: https://patch.msgid.link/20260711-rtl8367s-sgmii-v6-2-88f7944ddca7@c127.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| b269a059 | 30-Jun-2026 |
Linus Walleij <linusw@kernel.org> |
net: dsa: realtek: rtl8366rb: Switch to generic learning enablement
Instead of just writing the learning disablement register in setup
and a custom handling of BR_LEARNING, implement the generic RTL
net: dsa: realtek: rtl8366rb: Switch to generic learning enablement
Instead of just writing the learning disablement register in setup
and a custom handling of BR_LEARNING, implement the generic RTL83xx
.port_set_learning() callback for setting learning on a port, and
call this in the per-port loop in .setup().
Instead of the custom rtl83366rb_port_bridge_flags() function for
setting learning mode on each port, use the RTL83xx generic
rtl83xx_port_bridge_flags() callback.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-5-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
| e058ab0c | 30-Jun-2026 |
Linus Walleij <linusw@kernel.org> |
net: dsa: realtek: rtl8366rb: Disable STP learning on all ports in setup
When we loop over all ports in the switch .setup() callback,
make sure to disable learning on all user ports. This is what
is
net: dsa: realtek: rtl8366rb: Disable STP learning on all ports in setup
When we loop over all ports in the switch .setup() callback,
make sure to disable learning on all user ports. This is what
is normally expected and what the RTL8365MB is doing.
Move the code around to accommodate for the new call.
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-4-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
| cc61d5d7 | 30-Jun-2026 |
Linus Walleij <linusw@kernel.org> |
net: dsa: realtek: rtl8366rb: Use DSA port iterators
Instead of custom loops for intializing the ports (including the
CPU port) use the DSA helpers dsa_switch_for_each_port() and
dsa_switch_for_each
net: dsa: realtek: rtl8366rb: Use DSA port iterators
Instead of custom loops for intializing the ports (including the
CPU port) use the DSA helpers dsa_switch_for_each_port() and
dsa_switch_for_each_cpu_port() following the pattern in RTL8365MB by
accumulatong masks for the upstream and downstream ports.
This gives us similar enough code to the RTL8365MB that we
can start using more generic rtl83xx helpers.
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-3-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
| 82ddf181 | 30-Jun-2026 |
Linus Walleij <linusw@kernel.org> |
net: dsa: realtek: rtl8366rb: Switch to generic port_bridge* handlers
The RTL8366RB is using its own sub-standard port isolation code.
Implement the required isolation helpers, use these directly i
net: dsa: realtek: rtl8366rb: Switch to generic port_bridge* handlers
The RTL8366RB is using its own sub-standard port isolation code.
Implement the required isolation helpers, use these directly in
the port setup callback, and switch over to the standard port
isolation code.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260630-rtl8366rb-improvements-v2-2-05eb9d6a37f5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
| 660a9e39 | 06-Jun-2026 |
Luiz Angelo Daros de Luca <luizluca@gmail.com> |
net: dsa: realtek: rtl8365mb: add bridge port flags
Implement support for bridge port flags to control learning and flooding
behavior. This patch maps hardware functionalities to the following
bridg
net: dsa: realtek: rtl8365mb: add bridge port flags
Implement support for bridge port flags to control learning and flooding
behavior. This patch maps hardware functionalities to the following
bridge flags:
- BR_LEARNING
- BR_FLOOD
- BR_MCAST_FLOOD
- BR_BCAST_FLOOD
By default, all flooding types are enabled during port setup to ensure
standard bridge behavior.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260606-realtek_forward-v13-9-b9e409687cbe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 183bd68b | 06-Jun-2026 |
Alvin Šipraga <alsi@bang-olufsen.dk> |
net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave}
Implement hardware offloading of bridge functionality. This is achieved
by using the per-port isolation registers, which contain a forwardi
net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave}
Implement hardware offloading of bridge functionality. This is achieved
by using the per-port isolation registers, which contain a forwarding
port mask. The switch will refuse to forward packets ingressed on a
given port to a port which is not in its forwarding mask.
For each bridge that is offloaded, use the DSA-provided bridge number
for the Extended Filtering ID (EFID). When using Independent VLAN
Learning (IVL), the forwarding database is keyed with the tuple
{VID, MAC, EFID}. There are 8 EFIDs available (0~7), but we reserve the
default EFID 0 for standalone ports where learning is disabled. This
fits nicely because DSA indexes the bridge number starting from 1.
Because of the limited number of EFIDs, we have to set the
max_num_bridges property of our switch to 7: we can't offload more than
that or we will fail to offer IVL as at least two bridges would end up
having to share an EFID.
All ports start isolated, forwarding exclusively to CPU ports, and
with VLAN transparent, ignoring VLAN membership. Once a member in a
bridge, the port isolation is expanded to include the bridge members.
When that bridge enables VLAN filtering, the VLAN transparent feature is
disabled, letting the switch filter based on VLAN setup.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Co-developed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260606-realtek_forward-v13-8-b9e409687cbe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 336e3e4a | 06-Jun-2026 |
Alvin Šipraga <alsi@bang-olufsen.dk> |
net: dsa: realtek: rtl8365mb: add FDB support
Implement support for FDB and MDB management for the RTL8365MB series
switches.
The hardware supports IVL by keying the unicast forwarding database wit
net: dsa: realtek: rtl8365mb: add FDB support
Implement support for FDB and MDB management for the RTL8365MB series
switches.
The hardware supports IVL by keying the unicast forwarding database with
the {MAC, VID, EFID} tuple. The Extended Filtering ID (EFID) is 3 bits
wide, providing 8 unique filtering domains. This driver reserves EFID 0
for standalone ports, effectively limiting the hardware offload to a
maximum of 7 bridges. The multicast database uses a {MAC, VID} key, with
ports from different bridges sharing the same multicast group.
Introduce a mutex lock (l2_lock) to protect concurrent L2 table updates.
Add support for forwarding database operations, including unicast and
multicast entry handling as well as fast aging support.
Set DSA switch flags assisted_learning_on_cpu_port and fdb_isolation.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Co-developed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260606-realtek_forward-v13-7-b9e409687cbe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 9da2c867 | 06-Jun-2026 |
Alvin Šipraga <alsi@bang-olufsen.dk> |
net: dsa: realtek: rtl8365mb: add VLAN support
Realtek RTL8365MB switches (a.k.a. RTL8367C family) use two different
structures for VLANs:
- VLAN4K: A full table with 4096 entries defining port mem
net: dsa: realtek: rtl8365mb: add VLAN support
Realtek RTL8365MB switches (a.k.a. RTL8367C family) use two different
structures for VLANs:
- VLAN4K: A full table with 4096 entries defining port membership and
tagging.
- VLANMC: A smaller table with 32 entries used primarily for PVID
assignment.
In this hardware, a port's PVID must point to an index in the VLANMC
table rather than a VID directly. Since the VLANMC table is limited to
32 entries, the driver implements a dynamic allocation scheme to
maximize resource usage:
- VLAN4K is treated by the driver as the source of truth for membership.
- A VLANMC entry is only allocated when a port is configured to use a
specific VID as its PVID.
- VLANMC entries are deleted when no longer needed as a PVID by any port.
Although VLANMC has a members field, the switch only checks membership
in the VLAN4K table. This driver will use VLANMC members field as way to
track which ports are using that entry as PVID.
VLANMC index 0, although a valid entry, is reserved in this driver as a
neutral PVID value for ports not using a specific PVID.
In the subsequent RTL8367D switch family, VLANMC table was
removed and PVID assignment was delegated to a dedicated set of
registers.
The use of FIELD_PREP for reconstructing LO/HI values was suggested by
Yury Norov.
Fix for vlan_setup and vlan_filtering was suggested by Abdulkader
Alrezej.
Suggested-by: Yury Norov <ynorov@nvidia.com>
Suggested-by: Abdulkader Alrezej <abdulkader.alrezej@gmail.com>
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Co-developed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260606-realtek_forward-v13-6-b9e409687cbe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| fbafdd3b | 06-Jun-2026 |
Alvin Šipraga <alsi@bang-olufsen.dk> |
net: dsa: realtek: rtl8365mb: add table lookup interface
Add a generic table lookup interface to centralize access to
the RTL8365MB internal tables.
This interface abstracts the low-level table acc
net: dsa: realtek: rtl8365mb: add table lookup interface
Add a generic table lookup interface to centralize access to
the RTL8365MB internal tables.
This interface abstracts the low-level table access logic and
will be used by subsequent commits to implement FDB and VLAN
operations.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Co-developed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260606-realtek_forward-v13-5-b9e409687cbe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 0e692c27 | 06-Jun-2026 |
Alvin Šipraga <alsi@bang-olufsen.dk> |
net: dsa: realtek: rtl8365mb: prepare for multiple source files
Rename rtl8365mb.c to rtl8365mb_main.c in preparation for subsequent
commits which add additional source files to the driver.
The tra
net: dsa: realtek: rtl8365mb: prepare for multiple source files
Rename rtl8365mb.c to rtl8365mb_main.c in preparation for subsequent
commits which add additional source files to the driver.
The trailing backslash in the Makefile is deliberate. It allows for new
files to be added without clobbering git history.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Co-developed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260606-realtek_forward-v13-4-b9e409687cbe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 51a4a223 | 06-Jun-2026 |
Luiz Angelo Daros de Luca <luizluca@gmail.com> |
net: dsa: realtek: rtl8365mb: use dsa helpers for port iteration
Convert open-coded port iteration loops to use the DSA helpers and
restructure rtl8365mb_setup() into clear blocking, user, and
CPU p
net: dsa: realtek: rtl8365mb: use dsa helpers for port iteration
Convert open-coded port iteration loops to use the DSA helpers and
restructure rtl8365mb_setup() into clear blocking, user, and
CPU port phases.
As part of this refactoring, unused ports are explicitly placed into a
blocked, isolated state with learning disabled, ensuring safe default
hardware behavior. The driver also does not allocate a virtual IRQ
mapping for unused ports. To accommodate this, a guard check is added to
the interrupt handler (rtl8365mb_irq) to safely skip ports without a
valid IRQ mapping. The irq domain teardown, however, does clean all
ports as external PHYs may still map the IRQ.
Furthermore, since the new initialization loop starts with all ports
administratively isolated by default, CPU port forwarding and isolation
masks are explicitly configured at the end of the setup phase to prevent
egress traffic from being blocked.
Suggested-by: Abdulkader Alrezej <abdulkader.alrezej@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260606-realtek_forward-v13-3-b9e409687cbe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
| 36c572fd | 06-Jun-2026 |
Luiz Angelo Daros de Luca <luizluca@gmail.com> |
net: dsa: realtek: rtl8365mb: reject unsupported topologies
Explicitly enforce the presence of a CPU port (-EINVAL) and reject DSA
cascade links (-EOPNOTSUPP) during setup to prevent silent failures
net: dsa: realtek: rtl8365mb: reject unsupported topologies
Explicitly enforce the presence of a CPU port (-EINVAL) and reject DSA
cascade links (-EOPNOTSUPP) during setup to prevent silent failures.
These topologies were already non-functional. Without a CPU port, the
driver does not activate CPU tagging. Additionally, the switch hardware
was not designed to be cascaded, and DSA links never worked because
CPU tagging is not enabled for them.
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260606-realtek_forward-v13-2-b9e409687cbe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|