summaryrefslogtreecommitdiffstats
path: root/drivers/net/dsa/realtek (follow)
Commit message (Collapse)AuthorAgeFilesLines
* module: Convert symbol namespace to string literalPeter Zijlstra2024-12-026-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clean up the existing export namespace code along the same lines of commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo) to __section("foo")") and for the same reason, it is not desired for the namespace argument to be a macro expansion itself. Scripted using git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file; do awk -i inplace ' /^#define EXPORT_SYMBOL_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /^#define MODULE_IMPORT_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /MODULE_IMPORT_NS/ { $0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g"); } /EXPORT_SYMBOL_NS/ { if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) { if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ && $0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ && $0 !~ /^my/) { getline line; gsub(/[[:space:]]*\\$/, ""); gsub(/[[:space:]]/, "", line); $0 = $0 " " line; } $0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/, "\\1(\\2, \"\\3\")", "g"); } } { print }' $file; done Requested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc Acked-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* net: dsa: Switch back to struct platform_driver::remove()Uwe Kleine-König2024-10-054-4/+4
| | | | | | | | | | | | | | | | After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/net/dsa to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/36da477cb9fa0bffec32d50c2cf3d18e94a0e7e3.1727949050.git.u.kleine-koenig@baylibre.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8366rb: Make use of irq_get_trigger_type()Vasileios Amoiridis2024-09-071-1/+1
| | | | | | | | | | Convert irqd_get_trigger_type(irq_get_irq_data(irq)) cases to the more simple irq_get_trigger_type(irq). Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> Link: https://patch.msgid.link/20240904151018.71967-3-vassilisamir@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8365mb: Make use of irq_get_trigger_type()Vasileios Amoiridis2024-09-071-1/+1
| | | | | | | | | | Convert irqd_get_trigger_type(irq_get_irq_data(irq)) cases to the more simple irq_get_trigger_type(irq). Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Link: https://patch.msgid.link/20240904151018.71967-2-vassilisamir@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: Use for_each_child_of_node_scoped()Jinjie Ruan2024-09-031-5/+3
| | | | | | | | | | | | | Avoid need to manually handle of_node_put() by using for_each_child_of_node_scoped(), which can simplfy code. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: dsa: realtek: make use of dev_err_cast_probe()Hongbo Li2024-08-291-5/+3
| | | | | | | | | | Using dev_err_cast_probe() to simplify the code. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Link: https://patch.msgid.link/20240828121805.3696631-1-lihongbo22@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: provide own phylink MAC operationsRussell King (Oracle)2024-04-304-18/+46
| | | | | | | | | | | Convert realtek to provide its own phylink MAC operations, thus avoiding the shim layer in DSA's port.c. We need to provide a stub for the mandatory mac_config() method for rtl8366rb. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/E1s11qJ-00AHi0-Kk@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: dsa: realtek: add LED drivers for rtl8366rbLuiz Angelo Daros de Luca2024-04-291-39/+265
| | | | | | | | | | | | | | | | | | | This commit introduces LED drivers for rtl8366rb, enabling LEDs to be described in the device tree using the same format as qca8k. Each port can configure up to 4 LEDs. If all LEDs in a group use the default state "keep", they will use the default behavior after a reset. Changing the brightness of one LED, either manually or by a trigger, will disable the default hardware trigger and switch the entire LED group to manually controlled LEDs. Once in this mode, there is no way to revert to hardware-controlled LEDs (except by resetting the switch). Software triggers function as expected with manually controlled LEDs. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: do not assert reset on removeLuiz Angelo Daros de Luca2024-04-291-5/+2
| | | | | | | | | | | | | | | | | | 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 <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: keep default LED state in rtl8366rbLuiz Angelo Daros de Luca2024-04-291-67/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: support reset controllerLuiz Angelo Daros de Luca2024-02-283-5/+41
| | | | | | | | | | | | | | 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 <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: fix digital interface select macro for EXT0Luiz Angelo Daros de Luca2024-02-141-2/+2
| | | | | | | | | | | | | 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 <luizluca@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240212-realtek-fix_ext0-v1-1-f3d2536d191a@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: embed dsa_switch into realtek_privLuiz Angelo Daros de Luca2024-02-124-16/+19
| | | | | | | | | | | Embed dsa_switch within realtek_priv to eliminate the need for a second memory allocation. Suggested-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: use the same mii bus driver for both interfacesLuiz Angelo Daros de Luca2024-02-126-97/+14
| | | | | | | | | | | | | | | | | | | 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 <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: migrate user_mii_bus setup to realtek_dsaLuiz Angelo Daros de Luca2024-02-123-56/+70
| | | | | | | | | | | | | | | 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-<switch id> 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 <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: clean user_mii_bus setupLuiz Angelo Daros de Luca2024-02-121-10/+3
| | | | | | | | | | | | | | | | | | | | 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 <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: get internal MDIO node by nameLuiz Angelo Daros de Luca2024-02-121-1/+1
| | | | | | | | | | | | | | | | | 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 <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: merge rtl83xx and interface modules into realtek_dsaLuiz Angelo Daros de Luca2024-02-125-14/+12
| | | | | | | | | | | | 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 <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: common rtl83xx moduleLuiz Angelo Daros de Luca2024-02-128-273/+322
| | | | | | | | | | | | | | | | | | | | | Some code can be shared between both interface modules (MDIO and SMI) and among variants. These interface functions migrated to a common module: - rtl83xx_lock - rtl83xx_unlock - rtl83xx_probe - rtl83xx_register_switch - rtl83xx_unregister_switch - rtl83xx_shutdown - rtl83xx_remove The reset during probe was moved to the end of the common probe. This way, we avoid a reset if anything else fails. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: keep variant reference in realtek_privLuiz Angelo Daros de Luca2024-02-123-12/+7
| | | | | | | | | | | | | | | Instead of copying values from the variant, we can keep a reference in realtek_priv. This is a preliminary change for sharing code betwen interfaces. It will allow to move most of the probe into a common module while still allow code specific to each interface to read variant fields. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: convert variants into real driversLuiz Angelo Daros de Luca2024-02-127-73/+292
| | | | | | | | | | | | | | | | | | Previously, the interface modules realtek-smi and realtek-mdio served as a platform and an MDIO driver, respectively. Each interface module redundantly specified the same compatible strings for both variants and referenced symbols from the variants. Now, each variant module has been transformed into a unified driver serving both as a platform and an MDIO driver. This modification reverses the relationship between the interface and variant modules, with the variant module now utilizing symbols from the interface modules. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: introduce REALTEK_DSA namespaceLuiz Angelo Daros de Luca2024-02-125-11/+15
| | | | | | | | | | Create a namespace to group the exported symbols. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: drop cleanup from realtek_opsLuiz Angelo Daros de Luca2024-02-121-1/+0
| | | | | | | | | | | It was never used and never referenced. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: Rewrite RTL8366RB MTU handlingLinus Walleij2023-12-121-18/+30
| | | | | | | | | | | | | | | | | | | | | | | The MTU callbacks are in layer 1 size, so for example 1500 bytes is a normal setting. Cache this size, and only add the layer 2 framing right before choosing the setting. On the CPU port this will however include the DSA tag since this is transmitted from the parent ethernet interface! Add the layer 2 overhead such as ethernet and VLAN framing and FCS before selecting the size in the register. This will make the code easier to understand. The rtl8366rb_max_mtu() callback returns a bogus MTU just subtracting the CPU tag, which is the only thing we should NOT subtract. Return the correct layer 1 max MTU after removing headers and checksum. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: dsa: realtek: Rename bogus RTL8368S variableLinus Walleij2023-12-121-5/+6
| | | | | | | | | | | Rename the register name to RTL8366RB instead of the bogus RTL8368S (internal product name?) Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: Convert some ethtool_sprintf() to ethtool_puts()justinstitt@google.com2023-12-082-2/+2
| | | | | | | | | | | | | | | | | | | This patch converts some basic cases of ethtool_sprintf() to ethtool_puts(). The conversions are used in cases where ethtool_sprintf() was being used with just two arguments: | ethtool_sprintf(&data, buffer[i].name); or when it's used with format string: "%s" | ethtool_sprintf(&data, "%s", buffer[i].name); which both now become: | ethtool_puts(&data, buffer[i].name); Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: Use conduit and user termsFlorian Fainelli2023-10-243-16/+16
| | | | | | | | | | | | | Use more inclusive terms throughout the DSA subsystem by moving away from "master" which is replaced by "conduit" and "slave" which is replaced by "user". No functional changes. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20231023181729.1191071-2-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8365mb: replace deprecated strncpy with ethtool_sprintfJustin Stitt2023-10-111-2/+1
| | | | | | | | | | | | | | | | | | | | `strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. ethtool_sprintf() is designed specifically for get_strings() usage. Let's replace strncpy in favor of this more robust and easier to understand interface. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20231009-strncpy-drivers-net-dsa-realtek-rtl8365mb-c-v1-1-0537fe9fb08c@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: replace deprecated strncpy with ethtool_sprintfJustin Stitt2023-10-111-6/+2
| | | | | | | | | | | | | | | | | | | | `strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. ethtool_sprintf() is designed specifically for get_strings() usage. Let's replace strncpy in favor of this more robust and easier to understand interface. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20231009-strncpy-drivers-net-dsa-realtek-rtl8366-core-c-v1-1-74e1b5190778@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: Convert to platform remove callback returning voidUwe Kleine-König2023-09-201-5/+3
| | | | | | | | | | | | | | | | | | | | The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: rtl8366rb: Implement setting up link on CPU portLinus Walleij2023-09-151-9/+35
| | | | | | | | | | | | | | | | | | | | | We auto-negotiate most ports in the RTL8366RB driver, but the CPU port is hard-coded to 1Gbit, full duplex, tx and rx pause. This isn't very nice. People may configure speed and duplex differently in the device tree. Actually respect the arguments passed to the function for the CPU port, which get passed properly after Russell's patch "net: dsa: realtek: add phylink_get_caps implementation" After this the link is still set up properly. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: add phylink_get_caps implementationRussell King (Oracle)2023-08-201-0/+28
| | | | | | | | | | | | | | | | | | | | The user ports use RSGMII, but we don't have that, and DT doesn't specify a phy interface mode, so phylib defaults to GMII. These support 1G, 100M and 10M with flow control. It is unknown whether asymetric pause is supported at all speeds. The CPU port uses MII/GMII/RGMII/REVMII by hardware pin strapping, and support speeds specific to each, with full duplex only supported in some modes. Flow control may be supported again by hardware pin strapping, and theoretically is readable through a register but no information is given in the datasheet for that. So, we do a best efforts - and be lenient. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: Remove redundant of_match_ptr()Ruan Jinjie2023-08-162-2/+2
| | | | | | | | | | | The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: Explicitly include correct DT includesRob Herring2023-07-272-2/+1
| | | | | | | | | | | | | | | | | | The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20230724211859.805481-1-robh@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2023-03-301-1/+4
|\ | | | | | | | | | | | | | | | | | | Conflicts: drivers/net/ethernet/mediatek/mtk_ppe.c 3fbe4d8c0e53 ("net: ethernet: mtk_eth_soc: ppe: add support for flow accounting") 924531326e2d ("net: ethernet: mtk_eth_soc: add missing ppe cache flush when deleting a flow") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: dsa: realtek: fix out-of-bounds accessAhmad Fatoum2023-03-251-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The probe function sets priv->chip_data to (void *)priv + sizeof(*priv) with the expectation that priv has enough trailing space. However, only realtek-smi actually allocated this chip_data space. Do likewise in realtek-mdio to fix out-of-bounds accesses. These accesses likely went unnoticed so far, because of an (unused) buf[4096] member in struct realtek_priv, which caused kmalloc to round up the allocated buffer to a big enough size, so nothing of value was overwritten. With a different allocator (like in the barebox bootloader port of the driver) or with KASAN, the memory corruption becomes quickly apparent. Fixes: aac94001067d ("net: dsa: realtek: add new mdio interface for drivers") Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20230323103735.2331786-1-a.fatoum@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: realtek: rtl8365mb: add change_mtuLuiz Angelo Daros de Luca2023-03-171-4/+36
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rtl8365mb was using a fixed MTU size of 1536, which was probably inspired by the rtl8366rb's initial frame size. However, unlike that family, the rtl8365mb family can specify the max frame size in bytes, rather than in fixed steps. DSA calls change_mtu for the CPU port once the max MTU value among the ports changes. As the max frame size is defined globally, the switch is configured only when the call affects the CPU port. The available specifications do not directly define the max supported frame size, but it mentions a 16k limit. This driver will use the 0x3FFF limit as it is used in the vendor API code. However, the switch sets the max frame size to 16368 bytes (0x3FF0) after it resets. change_mtu uses MTU size, or ethernet payload size, while the switch works with frame size. The frame size is calculated considering the ethernet header (14 bytes), a possible 802.1Q tag (4 bytes), the payload size (MTU), and the Ethernet FCS (4 bytes). The CPU tag (8 bytes) is consumed before the switch enforces the limit. During setup, the driver will use the default 1500-byte MTU of DSA to set the maximum frame size. The current sum will be VLAN_ETH_HLEN+1500+ETH_FCS_LEN, which results in 1522 bytes. Although it is lower than the previous initial value of 1536 bytes, the driver will increase the frame size for a larger MTU. However, if something requires more space without increasing the MTU, such as QinQ, we would need to add the extra length to the rtl8365mb_port_change_mtu() formula. MTU was tested up to 2018 (with 802.1Q) as that is as far as mt7620 (where rtl8367s is stacked) can go. The register was manually manipulated byte-by-byte to ensure the MTU to frame size conversion was correct. For frames without 802.1Q tag, the frame size limit will be 4 bytes over the required size. There is a jumbo register, enabled by default at 6k frame size. However, the jumbo settings do not seem to limit nor expand the maximum tested MTU (2018), even when jumbo is disabled. More tests are needed with a device that can handle larger frames. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: remove unnecessary set_drvdata()Yang Yingliang2022-09-232-4/+0
| | | | | | | | | | | Remove unnecessary set_drvdata(NULL) function in ->remove(), the driver_data will be set to NULL in device_unbind_cleanup() after calling ->remove(). Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Alvin Šipraga <alsi@bang-olufsen.dk> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8365mb: handle PHY interface modes correctlyAlvin Šipraga2022-06-171-107/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Realtek switches in the rtl8365mb family always have at least one port with a so-called external interface, supporting PHY interface modes such as RGMII or SGMII. The purpose of this patch is to improve the driver's handling of these ports. A new struct rtl8365mb_chip_info is introduced together with a static array of such structs. An instance of this struct is added for each supported switch, distinguished by its chip ID and version. Embedded in each chip_info struct is an array of struct rtl8365mb_extint, describing the external interfaces available. This is more specific than the old rtl8365mb_extint_port_map, which was only valid for switches with up to 6 ports. The struct rtl8365mb_extint also contains a bitmask of supported PHY interface modes, which allows the driver to distinguish which ports support RGMII. This corrects a previous mistake in the driver whereby it was assumed that any port with an external interface supports RGMII. This is not actually the case: for example, the RTL8367S has two external interfaces, only the second of which supports RGMII. The first supports only SGMII and HSGMII. This new design will make it easier to add support for other interface modes. Finally, rtl8365mb_phylink_get_caps() is fixed up to return supported capabilities based on the external interface properties described above. This addresses Vladimir's point in the linked thread that the capabilities are not actually a function of the DSA port type: Although most typical applications will treat the ports with internal PHY as user ports, there is no actual hardware limitation preventing one from using them as a CPU port. Equally, ports with external interface(s) may well be treated as user ports, even though it is typical to use those ports as CPU ports. Link: https://lore.kernel.org/netdev/20220510192301.5djdt3ghoavxulhl@bang-olufsen.dk/ Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8365mb: remove learn_limit_max private data memberAlvin Šipraga2022-06-171-6/+1
| | | | | | | | The variable is just assigned the value of a macro, so it can be removed. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8365mb: correct the max number of portsAlvin Šipraga2022-06-171-2/+1
| | | | | | | | | | | | | | | | | | The maximum number of ports is actually 11, according to two observations: 1. The highest port ID used in the vendor driver is 10. Since port IDs are indexed from 0, and since DSA follows the same numbering system, this means up to 11 ports are to be presumed. 2. The registers with port mask fields always amount to a maximum port mask of 0x7FF, corresponding to a maximum 11 ports. In view of this, I also deleted the comment. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8365mb: remove port_mask private data memberAlvin Šipraga2022-06-171-7/+1
| | | | | | | | | There is no real need for this variable: the line change interrupt mask is sufficiently masked out when getting linkup_ind and linkdown_ind in the interrupt handler. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8365mb: rename macro RTL8367RB -> RTL8367RB_VBAlvin Šipraga2022-06-171-3/+3
| | | | | | | | | | The official name of this switch is RTL8367RB-VB, not RTL8367RB. There is also an RTL8367RB-VC which is rather different. Change the name of the CHIP_ID/_VER macros for reasons of consistency. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8365mb: fix GMII caps for ports with internal PHYAlvin Šipraga2022-06-091-29/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit a18e6521a7d9 ("net: phylink: handle NA interface mode in phylink_fwnode_phy_connect()"), phylib defaults to GMII when no phy-mode or phy-connection-type property is specified in a DSA port node of the device tree. The same commit caused a regression in rtl8365mb whereby phylink would fail to connect, because the driver did not advertise support for GMII for ports with internal PHY. It should be noted that the aforementioned regression is not because the blamed commit was incorrect: on the contrary, the blamed commit is correcting the previous behaviour whereby unspecified phy-mode would cause the internal interface mode to be PHY_INTERFACE_MODE_NA. The rtl8365mb driver only worked by accident before because it _did_ advertise support for PHY_INTERFACE_MODE_NA, despite NA being reserved for internal use by phylink. With one mistake fixed, the other was exposed. Commit a5dba0f207e5 ("net: dsa: rtl8365mb: add GMII as user port mode") then introduced implicit support for GMII mode on ports with internal PHY to allow a PHY connection for device trees where the phy-mode is not explicitly set to "internal". At this point everything was working OK again. Subsequently, commit 6ff6064605e9 ("net: dsa: realtek: convert to phylink_generic_validate()") broke this behaviour again by discarding the usage of rtl8365mb_phy_mode_supported() - where this GMII support was indicated - while switching to the new .phylink_get_caps API. With the new API, rtl8365mb_phy_mode_supported() is no longer needed. Remove it altogether and add back the GMII capability - this time to rtl8365mb_phylink_get_caps() - so that the above default behaviour works for ports with internal PHY again. Fixes: 6ff6064605e9 ("net: dsa: realtek: convert to phylink_generic_validate()") Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20220607184624.417641-1-alvin@pqrs.dk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: rtl8366rb: Serialize indirect PHY register accessAlvin Šipraga2022-05-161-12/+25
| | | | | | | | | | | | Lock the regmap during the whole PHY register access routines in rtl8366rb. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20220513213618.2742895-1-linus.walleij@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: remove port argument from ->change_tag_protocol()Vladimir Oltean2022-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | DSA has not supported (and probably will not support in the future either) independent tagging protocols per CPU port. Different switch drivers have different requirements, some may need to replicate some settings for each CPU port, some may need to apply some settings on a single CPU port, while some may have to configure some global settings and then some per-CPU-port settings. In any case, the current model where DSA calls ->change_tag_protocol for each CPU port turns out to be impractical for drivers where there are global things to be done. For example, felix calls dsa_tag_8021q_register(), which makes no sense per CPU port, so it suppresses the second call. Let drivers deal with replication towards all CPU ports, and remove the CPU port argument from the function prototype. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: realtek: remove realtek,rtl8367s stringLuiz Angelo Daros de Luca2022-04-202-5/+0
| | | | | | | | | | | | | | | There is no need to add new compatible strings for each new supported chip version. The compatible string is used only to select the subdriver (rtl8365mb.c or rtl8366rb.c). Once in the subdriver, it will detect the chip model by itself, ignoring which compatible string was used. Link: https://lore.kernel.org/netdev/20220414014055.m4wbmr7tdz6hsa3m@bang-olufsen.dk/ Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: don't parse compatible string for RTL8366SAlvin Šipraga2022-04-131-5/+0
| | | | | | | | | | | | This switch is not even supported, but if someone were to actually put this compatible string "realtek,rtl8366s" in their device tree, they would be greeted with a kernel panic because the probe function would dereference NULL. So let's just remove it. Link: https://lore.kernel.org/all/CACRpkdYdKZs0WExXc3=0yPNOwP+oOV60HRz7SRoGjZvYHaT=1g@mail.gmail.com/ Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: fix Kconfig to assure consistent driver linkageAlvin Šipraga2022-04-131-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel test robot reported a build failure: or1k-linux-ld: drivers/net/dsa/realtek/realtek-smi.o:(.rodata+0x16c): undefined reference to `rtl8366rb_variant' ... with the following build configuration: CONFIG_NET_DSA_REALTEK=y CONFIG_NET_DSA_REALTEK_SMI=y CONFIG_NET_DSA_REALTEK_RTL8365MB=y CONFIG_NET_DSA_REALTEK_RTL8366RB=m The problem here is that the realtek-smi interface driver gets built-in, while the rtl8366rb switch subdriver gets built as a module, hence the symbol rtl8366rb_variant is not reachable when defining the OF device table in the interface driver. The Kconfig dependencies don't help in this scenario because they just say that the subdriver(s) depend on at least one interface driver. In fact, the subdrivers don't depend on the interface drivers at all, and can even be built even in their absence. Somewhat strangely, the interface drivers can also be built in the absence of any subdriver, BUT, if a subdriver IS enabled, then it must be reachable according to the linkage of the interface driver: effectively what the IS_REACHABLE() macro achieves. If it is not reachable, the above kind of linker error will be observed. Rather than papering over the above build error by simply using IS_REACHABLE(), we can do a little better and admit that it is actually the interface drivers that have a dependency on the subdrivers. So this patch does exactly that. Specifically, we ensure that: 1. The interface drivers' Kconfig symbols must have a value no greater than the value of any subdriver Kconfig symbols. 2. The subdrivers should by default enable both interface drivers, since most users probably want at least one of them; those interface drivers can be explicitly disabled however. What this doesn't do is prevent a user from building only a subdriver, without any interface driver. To that end, add an additional line of help in the menu to guide users in the right direction. Link: https://lore.kernel.org/all/202204110757.XIafvVnj-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Fixes: aac94001067d ("net: dsa: realtek: add new mdio interface for drivers") Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: realtek: make interface drivers depend on OFAlvin Šipraga2022-03-251-0/+2
| | | | | | | | | | | | | | | | | The kernel test robot reported build warnings with a randconfig that built realtek-{smi,mdio} without CONFIG_OF set. Since both interface drivers are using OF and will not probe without, add the corresponding dependency to Kconfig. Link: https://lore.kernel.org/all/202203231233.Xx73Y40o-lkp@intel.com/ Link: https://lore.kernel.org/all/202203231439.ycl0jg50-lkp@intel.com/ Fixes: aac94001067d ("net: dsa: realtek: add new mdio interface for drivers") Fixes: 765c39a4fafe ("net: dsa: realtek: convert subdrivers into modules") Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Link: https://lore.kernel.org/r/20220323124225.91763-1-alvin@pqrs.dk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-22 20:04:08 +0100