Remove SerDes initialization/configuration calls from the DSA driver in
'rtl93xx_phylink_mac_config' and let our PCS driver setup the SerDes now
that the driver is able to do that.
Adjust some details in rtl93xx_phylink_mac_config to ensure the MAC is
properly disabled MAC before configuring the SerDes. This was done
within the SerDes code before.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20539
Signed-off-by: Robert Marko <robimarko@gmail.com>
Originally, phylink_mac_config first disabled the MAC, then triggered
the SerDes setup and then re-enabled MAC. SerDes setup has been moved to
the PCS driver now but pcs_config is called AFTER phylink_mac_config by
phylink subsystem.
Thus, just disable the MAC in phylink_mac_config. After PCS has setup
the SerDes, the MAC should be properly brought up in a mac_link_up call
coming from the phylink subsystem.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20369
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Remove SerDes initialization/configuration calls from the DSA driver in
'rtl931x_phylink_mac_config' and let our PCS driver setup the SerDes now
that the driver is able to do that.
pcs_config of the PCS driver is automatically called by phylink, thus
there's no need to call it on our own.
Note that in rtl931x_phylink_mac_config the MAC is enabled before
pcs_config is called. While this seems to work, it isn't good and needs
to be fixed.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20369
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In rtpcs_931x_setup_serdes, quit early on USXGMII mode. This restores
the behaviour introduced in c18476d0c5 to prevent the current buggy
procedure to destroy a working configuration established by U-Boot
before.
Also include the valuable comment from the code to keep the information.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20369
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Adjust the SerDes page numbers to account for the different mapping used
by 'mdio-realtek-otto' and 'mdio-realtek-otto-serdes' drivers.
While importing the SerDes configuration code from PHY driver to PCS
driver, all helper calls to access the SerDes registers had to be
adjusted to use the proper helpers within the PCS driver. However, there
is one important implication of this: 'mdio-realtek-otto' and
'mdio-realtek-otto-serdes' use a slightly different page mapping.
While the old helpers in 'mdio-realtek-otto' used a page mapping of
0x00/0x100/0x200, 'mdio-realtek-otto-serdes' uses a mapping of
0x00/0x40/0x80 to provide consumers with the ability to only operate on
frontend SerDes. Thus, all page numbers > 63/0x3f have to be adjusted
like the following:
before: rtsds_931x_write_field(sds, 0x101, ... // old helper calls
after: rtpcs_sds_write(ctrl, sds, 0x41, ...
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20369
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Let's start this transition with RTL931X.
Import all functions starting with 'rtl931x_' or 'rtsds_931x' from PHY
driver into the PCS driver, rename all functions to match a common
naming scheme and adjust signature, helper calls and function calls
accordingly to make it work within the PCS driver.
This is just copy&paste and tries to do only mandatory adjustments. The
code will be refactored in succeeding commits.
Also remove 'unused' attribute from helpers as they are used now.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20369
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
rev B1 is identical to rev A1 except for different PHYs on the 2.5gbps ports (lan9 and lan10)
Both revisions of xgs1210-12 are also switched to use rt-loader to avoid
problems due to overwriting the compressed image in memory when flashing
with the oem firmware (and also to save flash space with respect to gzip
compression)
Signed-off-by: Josh Bendavid <joshbendavid@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20161
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The DSA driver must flush the HW FDB when a port changes from
learning/forwarding to disabled/blocking/listening.
But the implementation for RTL931x was writing the port information
starting at bit 11 (bit 11 of the second 32-bit L2_TBL_FLUSH_CTRL
register). But this offset is the AGG_VID and not the port. The actual
position is 43 (bit 11 of the first register).
As result, the FDB was always only flushed for the port 0 and not for the
selected port.
Fixes: 9ed6097054 ("realtek: Add HW support for RTL931X for PIE, L2 and STP aging")
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20422
Signed-off-by: Robert Marko <robimarko@gmail.com>
BPDU frames like STP must be processed by each switch (bridge) which
supports STP. It must not be forwarded to avoid confusing the STP state of
other STP participants. It is essential to be an active participant of STP.
The software bridge automatically takes care of forwarding the BPDUs to
other ports when STP is disabled and the hardware switch should not
interfere.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20414
Signed-off-by: Robert Marko <robimarko@gmail.com>
Right now the phylink capability function enables 2.5G and 10G modes on
Maple and Cypress, which they mostly (other than two SERDES on Cypress)
don't support. This causes these modes to be selected and break the link
as they are not supported by hardware.
I looked into doing this properly, but it cannot just be done based on
SoC, but needs to take the whole topology into account as a given MAC
might have very different capabilities depending on what SERDES are
assigned to it. So for now just use 1G and QSGMII for RTL83xx and 10G
for RTL93xx. This mostly works, except it will downgrade some 10G links
on RTL839x, but since there are also 1G SFPs on these this cannot be
solved without fully accounting for the global MAC and SERDES
configuration.
So this makes all of the 1G SFP slots work again, while keeping most of
the 10G SFP+ slots working at 10G with minimal changes.
Signed-off-by: Lorenz Brun <lorenz@brun.one>
Link: https://github.com/openwrt/openwrt/pull/20374
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
If the devicetree contains the appropriate nodes to configure the MAC
addresses for each physical DSA port, then these MAC addresses must be used
in OpenWrt and not some automatically generated ones. Otherwise the device
often ends up with addresses which are locally administered and not
matching any expected port-to-MAC scheme.
Devices which only get the MAC address for eth0 must still auto-generate
these MAC addresses until the devicetree was updated to also include the
correct ones.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20241
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
If the lan_mac cannot be found, it is still used (as empty string) in
various operations. This is not valid and other 02_network scripts checking
for a non-empty string before using it. This should also be adopted for the
realtek 02_network.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20241
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The preferred prefix for the Realtek DSA driver code is "rtldsa" and no
longer "rtl83xx". This makes sure that the different drivers have
non-conflicting prefixes and because of this non-conflicting function
names.
Suggested-by: Felix Baumann <felix.bau@gmx.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20360
Signed-off-by: Robert Marko <robimarko@gmail.com>
If two ports are in isolation mode then these ports are not supposed to be
able to communicate between each other. This can be achieved in the realtek
switch by removing the other isolated port(s) from the port list of an
isolated port.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20360
Signed-off-by: Robert Marko <robimarko@gmail.com>
The realtek driver is now in full control of the port matrix. It doesn't
need to rely on the current state of the HW to adjust it. The new port
matrix is calculated automatically using rtldsa_update_port_member() and
then written to the registers/tables.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20360
Signed-off-by: Robert Marko <robimarko@gmail.com>
It is not necessary to read the back the current port members for a
specific port for enabling/disabling a port. All these members which are
expected to be in the HW port matrix of an active port are already stored
in the port specific member "pm".
And when a port is disabled, the port must no longer forwarding traffic to
any other port. Just writing 0 to the members is therefore good enough and
no read-back of the old HW state is necessary.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20360
Signed-off-by: Robert Marko <robimarko@gmail.com>
The leave and join callbacks for DSA were using their own implementation of
the port member handling code. This makes the implementation of additional
functionality based on the port member matrix complicated because it needs
to be implemented in both places and also in the new code path for the
introduced feature.
By sharing this code, it is much easier to guarantee that all code paths
behave the same. This approach is already implemented by other DSA drivers
like qca8k, mt7530 or ksz.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20360
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add more SerDes access helpers for the upcoming code import from PHY
driver. There, similar helpers are used to read and write full SerDes
registers or only parts of them (aka bitfields).
The helpers are expected to replace the following used in PHY SerDes
code:
- rtl9300_sds_field_r
- rtl9300_sds_field_w
- rtsds_931x_read
- rtsds_931x_read_field
- rtsds_931x_write
- rtsds_931x_write_field
Mark the helpers as unused for now to make the compiler happy. This will
be removed as soon as they are used.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20352
Signed-off-by: Robert Marko <robimarko@gmail.com>
The A1 and B1 devices are largely the same. The differences
seem to be:
- RTL8218D (A1) vs RTL8218E (B1) PHY for the eight 1 Gbps TP ports
- Aquantia (A1) vs RTL8261N (B1) PHY for the three 10 Gbps TP ports
RTL8218D/E share the same driver and support was added already by
commit c8c187f0f0 ("realtek: add support for RTL8218E").
The RTL8261N is also already supported but it's located at
different addresses compared to the A1 device. This requires
the device tree to be split. As a result, the devices are require
different images.
I found the smi addresses on the forum:
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/3622
And I can conform on my B1 device that this is working.
Co-developed-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Thomas Martitz <thomas.martitz@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/20150
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
There are switches which share the same overall hardware design but remove
just a couple of components for the low cost variant. For example, a 8+2
(ethernet+SFP) switch might have a low cost variant which only has 8
ethernet ports. In this case, the PCB will be shared but components for SFP
will just be dropped.
The LED shift registers will be the same between the two switches but the
ports are different. But since the rtl930x_led_init code is trying to
calculate the number of LEDs using the LED ports, the ethernet status ports
will then suddenly be shifted by two ports.
It is therefore necessary to have a mechanism to overwrite the detection of
the ethernet ports in the LED initialization and force some ports to
"virtually there" for the LED controller.
This functionality was already implemented for Plasma Cloud PSX8 (RTL930x)
but some devices using RTL931x might also benefit from a similar feature.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <se@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20300
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The LED sets must be configured before per-port LEDs are actually assigned.
At the same time, the LED set configuration was basically unreadable and
the RTL930x from commit 2cfb1ecf10 ("rtl930x: Rework per port LED
configuration") does a better job. Instead of moving the old implementation
around, just adopt the one from RTL930x.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20300
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
of_property_count_u32_elems returns the number of u32 and not the number of
bytes. It must therefore be checked against the number of u32 in set_config
and not the bytes in set_config.
Fixes: 2cfb1ecf10 ("rtl930x: Rework per port LED configuration")
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20300
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
There are switches which share the same overall hardware design but remove
just a couple of components for the low cost variant. For example, a 8+2
(ethernet+SFP) switch might have a low cost variant which only has 8
ethernet ports. In this case, the PCB will be shared but components for SFP
will just be dropped.
The LED shift registers will be the same between the two switches but the
ports are different. But since the rtl930x_led_init code is trying to
calculate the number of LEDs using the LED ports, the ethernet status ports
will then suddenly be shifted by two ports.
It is therefore necessary to have a mechanism to overwrite the detection of
the ethernet ports in the LED initialization and force some ports to
"virtually there" for the LED controller.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <se@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20300
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The first RTL931x devices make their way into OpenWrt. Their copper
ports are driven by different interfaces modes like 10G_QXGMII or
Realtek proprietary XSGMII. The DSA driver has no proper handling
for theses modes implemented yet. So a lot is auto-mapped to USXGMII
internally. As soon as the SerDes setup activates this (wrong) mode
the PHY connectivity breaks.
Disable this mode for now and rely on the proper U-Boot setup.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20292
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Realtek NAND kernel configuration has some shortcomings.
Fix this as follows:
- MTD_NAND_ECC_REALTEK selects MTD_NAND_ECC and this selects
MTD_NAND_CORE. For consistency add both config options.
- The partition layout of the Linksys switches requires some tricky
concatenation to keep dual boot active. Add CONFIG_MTD_VIRT_CONCAT
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/20255
Signed-off-by: Robert Marko <robimarko@gmail.com>
