kernel/linux.git/drivers/net/dsa/realtek, branch linux-6.9.y

net: dsa: realtek: do not assert reset on remove

2024-06-27T11:52:14+00:00

[ Upstream commit 4f580e9aced1816398c1c64f178302a22b8ea6e2 ] The necessity of asserting the reset on removal was previously questioned, as DSA's own cleanup methods should suffice to prevent traffic leakage[1]. When a driver has subdrivers controlled by devres, they will be unregistered after the main driver's .remove is executed. If it asserts a reset, the subdrivers will be unable to communicate with the hardware during their cleanup. For LEDs, this means that they will fail to turn off, resulting in a timeout error. [1] https://lore.kernel.org/r/20240123215606.26716-9-luizluca@gmail.com/ Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: dsa: realtek: keep default LED state in rtl8366rb

2024-06-27T11:52:14+00:00

[ Upstream commit 5edc6585aafefa3d44fb8a84adf241d90227f7a3 ] This switch family supports four LEDs for each of its six ports. Each LED group is composed of one of these four LEDs from all six ports. LED groups can be configured to display hardware information, such as link activity, or manually controlled through a bitmap in registers RTL8366RB_LED_0_1_CTRL_REG and RTL8366RB_LED_2_3_CTRL_REG. After a reset, the default LED group configuration for groups 0 to 3 indicates, respectively, link activity, link at 1000M, 100M, and 10M, or RTL8366RB_LED_CTRL_REG as 0x5432. These configurations are commonly used for LED indications. However, the driver was replacing that configuration to use manually controlled LEDs (RTL8366RB_LED_FORCE) without providing a way for the OS to control them. The default configuration is deemed more useful than fixed, uncontrollable turned-on LEDs. The driver was enabling/disabling LEDs during port_enable/disable. However, these events occur when the port is administratively controlled (up or down) and are not related to link presence. Additionally, when a port N was disabled, the driver was turning off all LEDs for group N, not only the corresponding LED for port N in any of those 4 groups. In such cases, if port 0 was brought down, the LEDs for all ports in LED group 0 would be turned off. As another side effect, the driver was wrongly warning that port 5 didn't have an LED ("no LED for port 5"). Since showing the administrative state of ports is not an orthodox way to use LEDs, it was not worth it to fix it and all this code was dropped. The code to disable LEDs was simplified only changing each LED group to the RTL8366RB_LED_OFF state. Registers RTL8366RB_LED_0_1_CTRL_REG and RTL8366RB_LED_2_3_CTRL_REG are only used when the corresponding LED group is configured with RTL8366RB_LED_FORCE and they don't need to be cleaned. The code still references an LED controlled by RTL8366RB_INTERRUPT_CONTROL_REG, but as of now, no test device has actually used it. Also, some magic numbers were replaced by macros. Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: dsa: realtek: support reset controller

2024-02-28T08:21:41+00:00

Add support for resetting the device using a reset controller, complementing the existing GPIO reset functionality (reset-gpios). Although the reset is optional and the driver performs a soft reset during setup, if the initial reset pin state was asserted, the driver will not detect the device until the reset is deasserted. Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Linus Walleij Reviewed-by: Alvin Šipraga Signed-off-by: David S. Miller

net: dsa: realtek: fix digital interface select macro for EXT0

2024-02-14T02:53:11+00:00

While no supported devices currently utilize EXT0, the register reserves the bits for an EXT0. EXT0 is utilized by devices from the generation prior to rtl8365mb, such as those supported by the driver library rtl8367b. Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Alvin Šipraga Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20240212-realtek-fix_ext0-v1-1-f3d2536d191a@gmail.com Signed-off-by: Jakub Kicinski

net: dsa: realtek: embed dsa_switch into realtek_priv

2024-02-12T10:42:17+00:00

Embed dsa_switch within realtek_priv to eliminate the need for a second memory allocation. Suggested-by: Alvin Šipraga Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Vladimir Oltean Reviewed-by: Linus Walleij Signed-off-by: David S. Miller

net: dsa: realtek: use the same mii bus driver for both interfaces

2024-02-12T10:42:17+00:00

The realtek-mdio will now use this driver instead of the generic DSA driver ("dsa user smi"), which should not be used with OF[1]. With a single ds_ops for both interfaces, the ds_ops in realtek_priv is no longer necessary. Now, the realtek_variant.ds_ops can be used directly. The realtek_priv.setup_interface() has been removed as we can directly call the new common function. [1] https://lkml.kernel.org/netdev/20220630200423.tieprdu5fpabflj7@bang-olufsen.dk/T/ Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Vladimir Oltean Reviewed-by: Linus Walleij Signed-off-by: David S. Miller

net: dsa: realtek: migrate user_mii_bus setup to realtek_dsa

2024-02-12T10:42:17+00:00

In the user MDIO driver, despite numerous references to SMI, including its compatible string, there's nothing inherently specific about the SMI interface in the user MDIO bus. Consequently, the code has been migrated to the rtl83xx module. All references to SMI have been eliminated. The MDIO bus id was changed from Realtek- to the switch devname suffixed with :user_mii, giving more information about the bus it is referencing. Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Linus Walleij Signed-off-by: David S. Miller

net: dsa: realtek: clean user_mii_bus setup

2024-02-12T10:42:17+00:00

Remove the line assigning dev.of_node in mdio_bus as subsequent of_mdiobus_register will always overwrite it. As discussed in [1], allow the DSA core to be simplified, by not assigning ds->user_mii_bus when the MDIO bus is described in OF, as it is unnecessary. Since commit 3b73a7b8ec38 ("net: mdio_bus: add refcounting for fwnodes to mdiobus"), we can put the "mdio" node just after the MDIO bus registration. [1] https://lkml.kernel.org/netdev/20231213120656.x46fyad6ls7sqyzv@skbuf/T/#u Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Vladimir Oltean Reviewed-by: Linus Walleij Signed-off-by: David S. Miller

net: dsa: realtek: get internal MDIO node by name

2024-02-12T10:42:17+00:00

The binding docs requires for SMI-connected devices that the switch must have a child node named "mdio" and with a compatible string of "realtek,smi-mdio". Meanwile, for MDIO-connected switches, the binding docs only requires a child node named "mdio". This patch changes the driver to use the common denominator for both interfaces, looking for the MDIO node by name, ignoring the compatible string. Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Linus Walleij Signed-off-by: David S. Miller

net: dsa: realtek: merge rtl83xx and interface modules into realtek_dsa

2024-02-12T10:42:17+00:00

Since rtl83xx and realtek-{smi,mdio} are always loaded together, we can optimize resource usage by consolidating them into a single module. Signed-off-by: Luiz Angelo Daros de Luca Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Linus Walleij Signed-off-by: David S. Miller