aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/dsa
AgeCommit message (Collapse)AuthorFilesLines
2024-02-13net: dsa: realtek: fix digital interface select macro for EXT0Luiz Angelo Daros de Luca1-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>
2024-02-12net: dsa: realtek: embed dsa_switch into realtek_privLuiz Angelo Daros de Luca4-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>
2024-02-12net: dsa: realtek: use the same mii bus driver for both interfacesLuiz Angelo Daros de Luca6-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>
2024-02-12net: dsa: realtek: migrate user_mii_bus setup to realtek_dsaLuiz Angelo Daros de Luca3-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>
2024-02-12net: dsa: realtek: clean user_mii_bus setupLuiz Angelo Daros de Luca1-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>
2024-02-12net: dsa: realtek: get internal MDIO node by nameLuiz Angelo Daros de Luca1-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>
2024-02-12net: dsa: realtek: merge rtl83xx and interface modules into realtek_dsaLuiz Angelo Daros de Luca5-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>
2024-02-12net: dsa: realtek: common rtl83xx moduleLuiz Angelo Daros de Luca8-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>
2024-02-12net: dsa: realtek: keep variant reference in realtek_privLuiz Angelo Daros de Luca3-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>
2024-02-12net: dsa: realtek: convert variants into real driversLuiz Angelo Daros de Luca7-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>
2024-02-12net: dsa: realtek: introduce REALTEK_DSA namespaceLuiz Angelo Daros de Luca5-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>
2024-02-12net: dsa: realtek: drop cleanup from realtek_opsLuiz Angelo Daros de Luca1-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>
2024-02-08net: dsa: b53: unexport and move b53_eee_enable_set()Vladimir Oltean2-16/+13
After commit f86ad77faf24 ("net: dsa: bcm_sf2: Utilize b53_{enable, disable}_port"), bcm_sf2.c no longer calls b53_eee_enable_set(), and all its callers are in b53_common.c. We also need to move it, because it is called within b53_common.c before its definition, and we want to avoid forward declarations. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240206112527.4132299-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: mt7530: do not clear config->supported_interfacesArınç ÜNAL1-2/+0
There's no need to clear the config->supported_interfaces bitmap before reporting the supported interfaces as all bits in the bitmap will already be initialized to zero when the phylink_config structure is allocated. The "config" pointer points to &dp->phylink_config, and "dp" is allocated by dsa_port_touch() with kzalloc(), so all its fields are filled with zeroes. There's no code that would change the bitmap beforehand. Remove it. Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20240206-for-netnext-mt7530-improvements-2-v5-7-d7d92a185cb1@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: mt7530: correct port capabilities of MT7988Arınç ÜNAL1-1/+1
On the switch on the MT7988 SoC, as shown in Block Diagram 8.1.1.3 on page 125 of "MT7988A Wi-Fi 7 Generation Router Platform: Datasheet (Open Version) v0.1", there are only 4 PHYs. That's port 0 to 3. Set the case for ports which connect to switch PHYs to '0 ... 3'. Port 4 and 5 are not used at all in this design. Link: https://wiki.banana-pi.org/Banana_Pi_BPI-R4#Documents [1] Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20240206-for-netnext-mt7530-improvements-2-v5-6-d7d92a185cb1@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: mt7530: remove pad_setup function pointerArınç ÜNAL2-37/+2
The pad_setup function pointer was introduced with 88bdef8be9f6 ("net: dsa: mt7530: Extend device data ready for adding a new hardware"). It was being used to set up the core clock and port 6 of the MT7530 switch, and pll of the MT7531 switch. All of these were moved to more appropriate locations, and it was never used for the switch on the MT7988 SoC. Therefore, this function pointer hasn't got a use anymore. Remove it. Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20240206-for-netnext-mt7530-improvements-2-v5-5-d7d92a185cb1@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: mt7530: call port 6 setup from mt7530_mac_config()Arınç ÜNAL1-8/+11
mt7530_pad_clk_setup() is called if port 6 is enabled. It used to do more things than setting up port 6. That part was moved to more appropriate locations, mt7530_setup() and mt7530_pll_setup(). Now that all it does is set up port 6, rename it to mt7530_setup_port6(), and move it to a more appropriate location, under mt7530_mac_config(). Change mt7530_setup_port6() to void as there're no error cases. Leave an empty mt7530_pad_clk_setup() to satisfy the pad_setup function pointer. This is the code path for setting up the ports before: dsa_switch_ops :: phylink_mac_config() -> mt753x_phylink_mac_config() -> mt753x_mac_config() -> mt753x_info :: mac_port_config() -> mt7530_mac_config() -> mt7530_setup_port5() -> mt753x_pad_setup() -> mt753x_info :: pad_setup() -> mt7530_pad_clk_setup() This is after: dsa_switch_ops :: phylink_mac_config() -> mt753x_phylink_mac_config() -> mt753x_mac_config() -> mt753x_info :: mac_port_config() -> mt7530_mac_config() -> mt7530_setup_port5() -> mt7530_setup_port6() Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20240206-for-netnext-mt7530-improvements-2-v5-4-d7d92a185cb1@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: mt7530: simplify mt7530_pad_clk_setup()Arınç ÜNAL1-51/+40
This code is from before this driver was converted to phylink API. Phylink deals with the unsupported interface cases before mt7530_pad_clk_setup() is run. Therefore, the default case would never run. However, it must be defined nonetheless to handle all the remaining enumeration values, the phy-modes. Switch to if statement for RGMII and return which simplifies the code and saves an indent. Set P6_INTF_MODE, which is the three least significant bits of the MT7530_P6ECR register, to 0 for RGMII even though it will already be 0 after reset. This is to keep supporting dynamic reconfiguration of the port in the case the interface changes from TRGMII to RGMII. Disable the TRGMII clocks for all cases. They will be enabled if TRGMII is being used. Read XTAL after checking for RGMII as it's only needed for the TRGMII interface mode. Reviewed-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240206-for-netnext-mt7530-improvements-2-v5-3-d7d92a185cb1@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: mt7530: move XTAL check to mt7530_setup()Arınç ÜNAL1-7/+6
The crystal frequency concerns the switch core. The frequency should be checked when the switch is being set up so the driver can reject the unsupported hardware earlier and without requiring port 6 to be used. Move it to mt7530_setup(). Drop the unnecessary function printing. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20240206-for-netnext-mt7530-improvements-2-v5-2-d7d92a185cb1@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: mt7530: empty default case on mt7530_setup_port5()Arınç ÜNAL1-4/+1
There're two code paths for setting up port 5: mt7530_setup() -> mt7530_setup_port5() mt753x_phylink_mac_config() -> mt753x_mac_config() -> mt7530_mac_config() -> mt7530_setup_port5() On the first code path, priv->p5_intf_sel is either set to P5_INTF_SEL_PHY_P0 or P5_INTF_SEL_PHY_P4 when mt7530_setup_port5() is run. On the second code path, priv->p5_intf_sel is set to P5_INTF_SEL_GMAC5 when mt7530_setup_port5() is run. Empty the default case which will never run but is needed nonetheless to handle all the remaining enumeration values. Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20240206-for-netnext-mt7530-improvements-2-v5-1-d7d92a185cb1@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: b53: remove eee_enabled/eee_active in b53_get_mac_eee()Russell King (Oracle)1-6/+0
b53_get_mac_eee() sets both eee_enabled and eee_active, and then returns zero. dsa_slave_get_eee(), which calls this function, will then continue to call phylink_ethtool_get_eee(), which will return -EOPNOTSUPP if there is no PHY present, otherwise calling phy_ethtool_get_eee() which in turn will call genphy_c45_ethtool_get_eee(). genphy_c45_ethtool_get_eee() will overwrite eee_enabled and eee_active with its own interpretation from the PHYs settings and negotiation result. Thus, when there is no PHY, dsa_slave_get_eee() will fail with -EOPNOTSUPP, meaning eee_enabled and eee_active will not be returned to userspace. When there is a PHY, eee_enabled and eee_active will be overwritten by phylib, making the setting of these members in b53_get_mac_eee() entirely unnecessary. Remove this code, thus simplifying b53_get_mac_eee(). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/E1rWbNI-002cCz-4x@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-07net: dsa: mv88e6xxx: Return -ENODEV when C45 not supportedAndrew Lunn1-1/+1
MDIO bus drivers can return -ENODEV when they know the bus does not have a device at the given address, e.g. because of hardware limitation. One such limitation is that the bus does not support C45 at all. This is more efficient than returning 0xffff, since it immediately stops the probing on the given address, where as further reads can be made when 0xffff is returned. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-05net: dsa: qca8k: consistently use "ret" rather than "err" for error codesVladimir Oltean1-8/+8
It was pointed out during the review [1] of commit 68e1010cda79 ("net: dsa: qca8k: put MDIO bus OF node on qca8k_mdio_register() failure") that the rest of the qca8k driver uses "int ret" rather than "int err". Make everything consistent in that regard, not only qca8k_mdio_register(), but also qca8k_setup_mdio_bus(). [1] https://lore.kernel.org/netdev/qyl2w3ownx5q7363kqxib52j5htar4y6pkn7gen27rj45xr4on@pvy5agi6o2te/ Suggested-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-05net: dsa: qca8k: put MDIO controller OF node if unavailableVladimir Oltean1-2/+1
It was pointed out during the review [1] of commit e66bf63a7f67 ("net: dsa: qca8k: skip MDIO bus creation if its OF node has status = "disabled"") that we now leak a reference to the "mdio" OF node if it is disabled. This is only a concern when using dynamic OF as far as I can tell (like probing on an overlay), since OF nodes are never freed in the regular case. Additionally, I'm unaware of any actual device trees (in production or elsewhere) which have status = "disabled" for the MDIO OF node. So handling this as a simple enhancement. [1] https://lore.kernel.org/netdev/CAJq09z4--Ug+3FAmp=EimQ8HTQYOWOuVon-PUMGB5a1N=RPv4g@mail.gmail.com/ Suggested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-01Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski3-5/+3
Cross-merge networking fixes after downstream PR. No conflicts or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-01net: dsa: Add KSZ8567 switch supportPhilippe Schenker4-1/+52
This commit introduces support for the KSZ8567, a robust 7-port Ethernet switch. The KSZ8567 features two RGMII/MII/RMII interfaces, each capable of gigabit speeds, complemented by five 10/100 Mbps MAC/PHYs. Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240130083419.135763-2-dev@pschenker.ch Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-31net: dsa: mv88e6xxx: Fix failed probe due to unsupported C45 readsAndrew Lunn1-1/+1
Not all mv88e6xxx device support C45 read/write operations. Those which do not return -EOPNOTSUPP. However, when phylib scans the bus, it considers this fatal, and the probe of the MDIO bus fails, which in term causes the mv88e6xxx probe as a whole to fail. When there is no device on the bus for a given address, the pull up resistor on the data line results in the read returning 0xffff. The phylib core code understands this when scanning for devices on the bus. C45 allows multiple devices to be supported at one address, so phylib will perform a few reads at each address, so although thought not the most efficient solution, it is a way to avoid fatal errors. Make use of this as a minimal fix for stable to fix the probing problems. Follow up patches will rework how C45 operates to make it similar to C22 which considers -ENODEV as a none-fatal, and swap mv88e6xxx to using this. Cc: stable@vger.kernel.org Fixes: 743a19e38d02 ("net: dsa: mv88e6xxx: Separate C22 and C45 transactions") Reported-by: Tim Menninger <tmenninger@purestorage.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240129224948.1531452-1-andrew@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-31ethtool: replace struct ethtool_eee with a new struct ethtool_keee on kernel ↵Heiner Kallweit8-19/+19
side In order to pass EEE link modes beyond bit 32 to userspace we have to complement the 32 bit bitmaps in struct ethtool_eee with linkmode bitmaps. Therefore, similar to ethtool_link_settings and ethtool_link_ksettings, add a struct ethtool_keee. In a first step it's an identical copy of ethtool_eee. This patch simply does a s/ethtool_eee/ethtool_keee/g for all users. No functional change intended. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-29net: dsa: qca8k: fix illegal usage of GPIOMichal Vokáč1-2/+1
When working with GPIO, its direction must be set either when the GPIO is requested by gpiod_get*() or later on by one of the gpiod_direction_*() functions. Neither of this is done here which results in undefined behavior on some systems. As the reset GPIO is used right after it is requested here, it makes sense to configure it as GPIOD_OUT_HIGH right away. With that, the following gpiod_set_value_cansleep(1) becomes redundant and can be safely removed. Fixes: a653f2f538f9 ("net: dsa: qca8k: introduce reset via gpio feature") Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/1706266175-3408-1-git-send-email-michal.vokac@ysoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: do not run mt7530_setup_port5() if port 5 is disabledArınç ÜNAL1-6/+3
There's no need to run all the code on mt7530_setup_port5() if port 5 is disabled. The only case for calling mt7530_setup_port5() from mt7530_setup() is when PHY muxing is enabled. That is because port 5 is not defined as a port on the devicetree, therefore, it cannot be controlled by phylink. Because of this, run mt7530_setup_port5() if priv->p5_intf_sel is P5_INTF_SEL_PHY_P0 or P5_INTF_SEL_PHY_P4. Remove the P5_DISABLED case from mt7530_setup_port5(). Stop initialising the interface variable as the remaining cases will always call mt7530_setup_port5() with it initialised. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-7-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: do not set priv->p5_interface on mt7530_setup_port5()Arınç ÜNAL1-2/+0
Running mt7530_setup_port5() from mt7530_setup() used to handle all cases of configuring port 5, including phylink. Setting priv->p5_interface under mt7530_setup_port5() makes sure that mt7530_setup_port5() from mt753x_phylink_mac_config() won't run. The commit ("net: dsa: mt7530: improve code path for setting up port 5") makes so that mt7530_setup_port5() from mt7530_setup() runs only on non-phylink cases. Get rid of unnecessarily setting priv->p5_interface under mt7530_setup_port5() as port 5 phylink configuration will be done by running mt7530_setup_port5() from mt753x_phylink_mac_config() now. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-6-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: improve code path for setting up port 5Arınç ÜNAL1-9/+8
There're two code paths for setting up port 5: mt7530_setup() -> mt7530_setup_port5() mt753x_phylink_mac_config() -> mt753x_mac_config() -> mt7530_mac_config() -> mt7530_setup_port5() Currently mt7530_setup_port5() from mt7530_setup() always runs. If port 5 is used as a CPU, DSA, or user port, mt7530_setup_port5() from mt753x_phylink_mac_config() won't run. That is because priv->p5_interface set on mt7530_setup_port5() will match state->interface on mt753x_phylink_mac_config() which will stop running mt7530_setup_port5() again. Therefore, mt7530_setup_port5() will never run from mt753x_phylink_mac_config(). Address this by not running mt7530_setup_port5() from mt7530_setup() if port 5 is used as a CPU, DSA, or user port. This driver isn't in the dsa_switches_apply_workarounds[] array so phylink will always be present. To keep the cases where port 5 isn't controlled by phylink working as before, preserve the mt7530_setup_port5() call from mt7530_setup(). Do not set priv->p5_intf_sel to P5_DISABLED. It is already set to that when "priv" is allocated. Move setting the interface to a more specific location. It's supposed to be overwritten if PHY muxing is detected. Improve the comment which explains the process. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-5-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: improve comments regarding switch portsArınç ÜNAL1-10/+20
There's no logic to numerically order the CPU ports. Just state the port number instead. Remove the irrelevant PHY muxing information from mt7530_mac_port_get_caps(). Explain the supported MII modes instead. Remove the out of place PHY muxing information from mt753x_phylink_mac_config(). The function is for MT7530, MT7531, and the switch on the MT7988 SoC but there's no PHY muxing on MT7531 or the switch on the MT7988 SoC. These comments were gradually introduced with the commits below. commit ca366d6c889b ("net: dsa: mt7530: Convert to PHYLINK API") commit 38f790a80560 ("net: dsa: mt7530: Add support for port 5") commit 88bdef8be9f6 ("net: dsa: mt7530: Extend device data ready for adding a new hardware") commit c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-4-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: store port 5 SGMII capability of MT7531Arınç ÜNAL3-39/+22
Introduce the p5_sgmii field to store the information for whether port 5 has got SGMII or not. Instead of reading the MT7531_TOP_SIG_SR register multiple times, the register will be read once and the value will be stored on the p5_sgmii field. This saves unnecessary reads of the register. Move the comment about MT7531AE and MT7531BE to mt7531_setup(), where the switch is identified. Get rid of mt7531_dual_sgmii_supported() now that priv->p5_sgmii stores the information. Address the code where mt7531_dual_sgmii_supported() is used. Get rid of mt7531_is_rgmii_port() which just prints the opposite of priv->p5_sgmii. Instead of calling mt7531_pll_setup() then returning, do not call it if port 5 is SGMII. Remove P5_INTF_SEL_GMAC5_SGMII. The p5_interface_select enum is supposed to represent the mode that port 5 is being used in, not the hardware information of port 5. Set p5_intf_sel to P5_INTF_SEL_GMAC5 instead, if port 5 is not dsa_is_unused_port(). Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-3-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: use p5_interface_select as data type for p5_intf_selArınç ÜNAL1-2/+2
Use the p5_interface_select enumeration as the data type for the p5_intf_sel field. This ensures p5_intf_sel can only take the values defined in the p5_interface_select enumeration. Remove the explicit assignment of 0 to P5_DISABLED as the first enum item is automatically assigned 0. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-2-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-29net: dsa: mt7530: always trap frames to active CPU port on MT7530Arınç ÜNAL2-6/+35
On the MT7530 switch, the CPU_PORT field indicates which CPU port to trap frames to, regardless of the affinity of the inbound user port. When multiple CPU ports are in use, if the DSA conduit interface is down, trapped frames won't be passed to the conduit interface. To make trapping frames work including this case, implement ds->ops->conduit_state_change() on this subdriver and set the CPU_PORT field to the numerically smallest CPU port whose conduit interface is up. Introduce the active_cpu_ports field to store the information of the active CPU ports. Correct the macros, CPU_PORT is bits 4 through 6 of the register. Add a comment to explain frame trapping for this switch. Currently, the driver doesn't support the use of multiple CPU ports so this is not necessarily a bug fix. Suggested-by: Vladimir Oltean <olteanv@gmail.com> Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122-for-netnext-mt7530-improvements-1-v3-1-042401f2b279@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: dsa: microchip: implement PHY loopback configuration for KSZ8794 and ↵Oleksij Rempel2-7/+70
KSZ8873 Correct the PHY loopback bit handling in the ksz8_w_phy_bmcr and ksz8_r_phy_bmcr functions for KSZ8794 and KSZ8873 variants in the ksz8795 driver. Previously, the code erroneously used Bit 7 of port register 0xD for both chip variants, which is actually for LED configuration. This update ensures the correct registers and bits are used for the PHY loopback feature: - For KSZ8794: Use 0xF / Bit 7. - For KSZ8873: Use 0xD / Bit 0. The lack of loopback support was seen on KSZ8873 system by using "ethtool -t lanX". After this patch, the ethtool selftest will work, but only if port is not part of a bridge. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20240124123314.734815-4-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: dsa: microchip: Remove redundant optimization in ksz8_w_phy_bmcrOleksij Rempel1-67/+29
Remove the manual checks for register value changes in the ksz8_w_phy_bmcr function. Instead, rely on regmap_update_bits() for optimizing register updates. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20240124123314.734815-3-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: dsa: microchip: ksz8: move BMCR specific code to separate functionOleksij Rempel1-126/+240
Isolate the Basic Mode Control Register (BMCR) operations in the ksz8795 driver by moving the BMCR-related code segments from the ksz8_r_phy() and ksz8_w_phy() functions to newly created ksz8_r_phy_bmcr() and ksz8_w_phy_bmcr() functions. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20240124123314.734815-2-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: dsa: mt7530: select MEDIATEK_GE_PHY for NET_DSA_MT7530_MDIOArınç ÜNAL1-1/+1
Quoting from commit 4223f8651287 ("net: dsa: mt7530: make NET_DSA_MT7530 select MEDIATEK_GE_PHY"): Make MediaTek MT753x DSA driver enable MediaTek Gigabit PHYs driver to properly control MT7530 and MT7531 switch PHYs. A noticeable change is that the behaviour of switchport interfaces going up-down-up-down is no longer there. Now, the switch can be used without the PHYs but, at the moment, every hardware design out there that I have seen uses them. For that, it would make the most sense to force the selection of MEDIATEK_GE_PHY for the MDIO interface which currently controls the MT7530 and MT7531 switches. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122053451.8004-1-arinc.unal@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-26net: dsa: mt7530: fix 10M/100M speed on MT7988 switchDaniel Golle1-2/+1
Setup PMCR port register for actual speed and duplex on internally connected PHYs of the MT7988 built-in switch. This fixes links with speeds other than 1000M. Fixes: 110c18bfed41 ("net: dsa: mt7530: introduce driver for MT7988 built-in switch") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/a5b04dfa8256d8302f402545a51ac4c626fdba25.1706071272.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-25net: dsa: mt7530: support OF-based registration of switch MDIO busArınç ÜNAL1-8/+26
Currently the MDIO bus of the switches the MT7530 DSA subdriver controls can only be registered as non-OF-based. Bring support for registering the bus OF-based. The subdrivers that control switches [with MDIO bus] probed on OF must follow this logic to support all cases properly: No switch MDIO bus defined: Populate ds->user_mii_bus, register the MDIO bus, set the interrupts for PHYs if "interrupt-controller" is defined at the switch node. This case should only be covered for the switches which their dt-bindings documentation didn't document the MDIO bus from the start. This is to keep supporting the device trees that do not describe the MDIO bus on the device tree but the MDIO bus is being used nonetheless. Switch MDIO bus defined: Don't populate ds->user_mii_bus, register the MDIO bus, set the interrupts for PHYs if ["interrupt-controller" is defined at the switch node and "interrupts" is defined at the PHY nodes under the switch MDIO bus node]. Switch MDIO bus defined but explicitly disabled: If the device tree says status = "disabled" for the MDIO bus, we shouldn't need an MDIO bus at all. Instead, just exit as early as possible and do not call any MDIO API. The use of ds->user_mii_bus is inappropriate when the MDIO bus of the switch is described on the device tree [1], which is why we don't populate ds->user_mii_bus in that case. Link: https://lore.kernel.org/netdev/20231213120656.x46fyad6ls7sqyzv@skbuf/ [1] Suggested-by: David Bauer <mail@david-bauer.net> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20240122053431.7751-1-arinc.unal@arinc9.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-01-16net: dsa: vsc73xx: Add null pointer check to vsc73xx_gpio_probeKunwu Chan1-0/+2
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver") Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Suggested-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240111072018.75971-1-chentao@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-01-05net: dsa: bcm_sf2: drop priv->master_mii_dnVladimir Oltean2-4/+3
There used to be a of_node_put(priv->master_mii_dn) call in bcm_sf2_mdio_unregister(), which was accidentally deleted in commit 6ca80638b90c ("net: dsa: Use conduit and user terms"). But it's not needed - we don't need to hold a reference on the "brcm,unimac-mdio" OF node for that long, since we don't do anything with it. We can release it as soon as we finish bcm_sf2_mdio_register(). Also reduce "if (err && dn)" to just "if (err)". We know "dn", aka the former priv->master_mii_dn, is non-NULL. Otherwise, of_mdio_find_bus(dn) would not have been able to find the bus behind "brcm,unimac-mdio". Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-05net: dsa: bcm_sf2: stop assigning an OF node to the ds->user_mii_busVladimir Oltean1-1/+0
The bcm_sf2 driver does something strange. Instead of calling of_mdiobus_register() with an OF node argument, it manually assigns the bus->dev->of_node and then calls the non-OF mdiobus_register(). This circumvents some code from __of_mdiobus_register() from running, which sets the auto-scan mask, parses some device tree properties, etc. I'm going to go out on a limb and say that the OF node isn't, in fact, needed at all, and can be removed. The MDIO diversion as initially implemented in commit 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus") looked quite different than it is now, after commit 771089c2a485 ("net: dsa: bcm_sf2: Ensure that MDIO diversion is used"). Initially, it made sense, as bcm_sf2 was registering another set of driver ops for the "brcm,unimac-mdio" OF node. But now, it deletes all phandles, which makes "phy-handle"s unable to find PHYs, which means that it always goes through the OF-unaware dsa_user_phy_connect(). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-05net: dsa: qca8k: use "dev" consistently within qca8k_mdio_register()Vladimir Oltean1-4/+5
Accessed either through priv->dev or ds->dev, it is the same device structure. Keep a single variable which holds a reference to it, and use it consistently. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-05net: dsa: qca8k: consolidate calls to a single devm_of_mdiobus_register()Vladimir Oltean1-13/+11
__of_mdiobus_register() already calls __mdiobus_register() if the OF node provided as argument is NULL. We can take advantage of that and simplify the 2 code path, calling devm_of_mdiobus_register() only once for both cases. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-05net: dsa: qca8k: assign ds->user_mii_bus only for the non-OF caseVladimir Oltean3-4/+6
To simplify reasoning about why the DSA framework provides the ds->user_mii_bus functionality, drivers should only use it if they need to. The qca8k driver appears to also use it simply as storage for a pointer, which is not a good enough reason to make the core much more difficult to follow. ds->user_mii_bus is useful for only 2 cases: 1. The driver probes on platform_data (no OF) 2. The driver probes on OF, but there is no OF node for the MDIO bus. It is unclear if case (1) is supported with qca8k. It might not be: the driver might crash when of_device_get_match_data() returns NULL and then it dereferences priv->info without NULL checking. Anyway, let us limit the ds->user_mii_bus usage only to the above cases, and not assign it when an OF node is present. The bus->phy_mask assignment follows along with the movement, because __of_mdiobus_register() overwrites this bus field anyway. The value set by the driver only matters for the non-OF code path. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-05net: dsa: qca8k: skip MDIO bus creation if its OF node has status = "disabled"Vladimir Oltean1-3/+5
Currently the driver calls the non-OF devm_mdiobus_register() rather than devm_of_mdiobus_register() for this case, but it seems to rather be a confusing coincidence, and not a real use case that needs to be supported. If the device tree says status = "disabled" for the MDIO bus, we shouldn't need an MDIO bus at all. Instead, just exit as early as possible and do not call any MDIO API. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-01-05net: dsa: qca8k: put MDIO bus OF node on qca8k_mdio_register() failureVladimir Oltean1-5/+16
of_get_child_by_name() gives us an OF node with an elevated refcount, which should be dropped when we're done with it. This is so that, if (of_node_check_flag(node, OF_DYNAMIC)) is true, the node's memory can eventually be freed. There are 2 distinct paths to be considered in qca8k_mdio_register(): - devm_of_mdiobus_register() succeeds: since commit 3b73a7b8ec38 ("net: mdio_bus: add refcounting for fwnodes to mdiobus"), the MDIO core treats this well. - devm_of_mdiobus_register() or anything up to that point fails: it is the duty of the qca8k driver to release the OF node. This change addresses the second case by making sure that the OF node reference is not leaked. The "mdio" node may be NULL, but of_node_put(NULL) is safe. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>