summaryrefslogtreecommitdiffstats
path: root/drivers/net/dsa
Commit message (Collapse)AuthorAgeFilesLines
* net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocolTobias Waldekranz2021-04-201-0/+39
| | | | | | | | | | | | | | | | For devices that supports both regular and Ethertyped DSA tags, allow the user to change the protocol. Additionally, because there are ethernet controllers that do not handle regular DSA tags in all cases, also allow the protocol to be changed on devices with undocumented support for EDSA. But, in those cases, make sure to log the fact that an undocumented feature has been enabled. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: Mark chips with undocumented EDSA tag supportTobias Waldekranz2021-04-202-35/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | All devices are capable of using regular DSA tags. Support for Ethertyped DSA tags sort into three categories: 1. No support. Older chips fall into this category. 2. Full support. Datasheet explicitly supports configuring the CPU port to receive FORWARDs with a DSA tag. 3. Undocumented support. Datasheet lists the configuration from category 2 as "reserved for future use", but does empirically behave like a category 2 device. So, instead of listing the one true protocol that should be used by a particular chip, specify the level of support for EDSA (support for regular DSA is implicit on all chips). As before, we use EDSA for all chips that fully supports it. In upcoming changes, we will use this information to support dynamically changing the tag protocol. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: simulate Amethyst PHY model numberMarek Behún2021-04-201-0/+1
| | | | | | | | | | Amethyst internal PHYs also report empty model number in MII_PHYSID2. Fill in switch product number, as is done for Topaz and Peridot. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: felix: disable always guard band bit for TAS configXiaoliang Yang2021-04-201-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | ALWAYS_GUARD_BAND_SCH_Q bit in TAS config register is descripted as this: 0: Guard band is implemented for nonschedule queues to schedule queues transition. 1: Guard band is implemented for any queue to schedule queue transition. The driver set guard band be implemented for any queue to schedule queue transition before, which will make each GCL time slot reserve a guard band time that can pass the max SDU frame. Because guard band time could not be set in tc-taprio now, it will use about 12000ns to pass 1500B max SDU. This limits each GCL time interval to be more than 12000ns. This patch change the guard band to be only implemented for nonschedule queues to schedule queues transition, so that there is no need to reserve guard band on each GCL. Users can manually add guard band time for each schedule queues in their configuration if they want. Signed-off-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2021-04-171-17/+13
|\ | | | | | | | | | | | | | | | | drivers/net/ethernet/stmicro/stmmac/stmmac_main.c - keep the ZC code, drop the code related to reinit net/bridge/netfilter/ebtables.c - fix build after move to net_generic Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: phy: marvell: fix detection of PHY on Topaz switchesPali Rohár2021-04-121-17/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor reading"), Linux reports the temperature of Topaz hwmon as constant -75°C. This is because switches from the Topaz family (88E6141 / 88E6341) have the address of the temperature sensor register different from Peridot. This address is instead compatible with 88E1510 PHYs, as was used for Topaz before the above mentioned commit. Create a new mapping table between switch family and PHY ID for families which don't have a model number. And define PHY IDs for Topaz and Peridot families. Create a new PHY ID and a new PHY driver for Topaz's internal PHY. The only difference from Peridot's PHY driver is the HWMON probing method. Prior this change Topaz's internal PHY is detected by kernel as: PHY [...] driver [Marvell 88E6390] (irq=63) And afterwards as: PHY [...] driver [Marvell 88E6341 Family] (irq=63) Signed-off-by: Pali Rohár <pali@kernel.org> BugLink: https://github.com/globalscaletechnologies/linux/issues/1 Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor reading") Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mt7530: Add support for EEE featuresRené van Dorst2021-04-132-1/+56
| | | | | | | | | | | | | | This patch adds EEE support. Signed-off-by: René van Dorst <opensource@vdorst.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2021-04-091-22/+173
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: MAINTAINERS - keep Chandrasekar drivers/net/ethernet/mellanox/mlx5/core/en_main.c - simple fix + trust the code re-added to param.c in -next is fine include/linux/bpf.h - trivial include/linux/ethtool.h - trivial, fix kdoc while at it include/linux/skmsg.h - move to relevant place in tcp.c, comment re-wrapped net/core/skmsg.c - add the sk = sk // sk = NULL around calls net/tipc/crypto.c - trivial Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bitsMartin Blumenstingl2021-04-081-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a few more bits in the GSWIP_MII_CFG register for which we did rely on the boot-loader (or the hardware defaults) to set them up properly. For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK bit and also we should un-set it for non-RMII PHYs. The GSWIP_MII_CFG_RMII_CLK bit is ignored for other PHY connection modes. The GSWIP IP also supports in-band auto-negotiation for RGMII PHYs when the GSWIP_MII_CFG_RGMII_IBS bit is set. Clear this bit always as there's no known hardware which uses this (so it is not tested yet). Clear the xMII isolation bit when set at initialization time if it was previously set by the bootloader. Not doing so could lead to no traffic (neither RX nor TX) on a port with this bit set. While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to manage it because this bit is self-clearning when set. We still add it here to get a better overview of the GSWIP_MII_CFG register. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Cc: stable@vger.kernel.org Suggested-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: lantiq_gswip: Don't use PHY auto pollingMartin Blumenstingl2021-04-081-26/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PHY auto polling on the GSWIP hardware can be used so link changes (speed, link up/down, etc.) can be detected automatically. Internally GSWIP reads the PHY's registers for this functionality. Based on this automatic detection GSWIP can also automatically re-configure it's port settings. Unfortunately this auto polling (and configuration) mechanism seems to cause various issues observed by different people on different devices: - FritzBox 7360v2: the two Gbit/s ports (connected to the two internal PHY11G instances) are working fine but the two Fast Ethernet ports (using an AR8030 RMII PHY) are completely dead (neither RX nor TX are received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This makes the PHY auto polling state machine (rightfully?) think that the established link speed (when the other side is Gbit/s capable) is 1Gbit/s. - None of the Ethernet ports on the Zyxel P-2812HNU-F1 (two are connected to the internal PHY11G GPHYs while the other three are external RGMII PHYs) are working. Neither RX nor TX traffic was observed. It is not clear which part of the PHY auto polling state- machine caused this. - FritzBox 7412 (only one LAN port which is connected to one of the internal GPHYs running in PHY22F / Fast Ethernet mode) was seeing random disconnects (link down events could be seen). Sometimes all traffic would stop after such disconnect. It is not clear which part of the PHY auto polling state-machine cauased this. - TP-Link TD-W9980 (two ports are connected to the internal GPHYs running in PHY11G / Gbit/s mode, the other two are external RGMII PHYs) was affected by similar issues as the FritzBox 7412 just without the "link down" events Switch to software based configuration instead of PHY auto polling (and letting the GSWIP hardware configure the ports automatically) for the following link parameters: - link up/down - link speed - full/half duplex - flow control (RX / TX pause) After a big round of manual testing by various people (who helped test this on OpenWrt) it turns out that this fixes all reported issues. Additionally it can be considered more future proof because any "quirk" which is implemented for a PHY on the driver side can now be used with the GSWIP hardware as well because Linux is in control of the link parameters. As a nice side-effect this also solves a problem where fixed-links were not supported previously because we were relying on the PHY auto polling mechanism, which cannot work for fixed-links as there's no PHY from where it can read the registers. Configuring the link settings on the GSWIP ports means that we now use the settings from device-tree also for ports with fixed-links. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Fixes: 3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set the xMII clock") Cc: stable@vger.kernel.org Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: lantiq_gswip: Let GSWIP automatically set the xMII clockMartin Blumenstingl2021-03-251-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The xMII interface clock depends on the PHY interface (MII, RMII, RGMII) as well as the current link speed. Explicitly configure the GSWIP to automatically select the appropriate xMII interface clock. This fixes an issue seen by some users where ports using an external RMII or RGMII PHY were deaf (no RX or TX traffic could be seen). Most likely this is due to an "invalid" xMII clock being selected either by the bootloader or hardware-defaults. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: mscc: ocelot: remove redundant dev_err call in vsc9959_mdio_bus_alloc()Guobin Huang2021-03-291-3/+1
| | | | | | | | | | | | | | | | | | | | There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Guobin Huang <huangguobin4@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: hellcreek: Remove redundant dev_err call in hellcreek_probe()Guobin Huang2021-03-281-6/+2
| | | | | | | | | | | | | | | | | | | | There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Guobin Huang <huangguobin4@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mt7530: clean up core and TRGMII clock setupIlya Lipnitskiy2021-03-281-16/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Three minor changes: - When disabling PLL, there is no need to call core_write_mmd_indirect directly, use the core_write wrapper instead like the rest of the code in the function does. This change helps with consistency and readability. Move the comment to the definition of core_read_mmd_indirect where it belongs. - Disable both core and TRGMII Tx clocks prior to reconfiguring. Previously, only the core clock was disabled, but not TRGMII Tx clock. So disable both, then configure them, then re-enable both, for consistency. - The core clock enable bit (REG_GSWCK_EN) is written redundantly three times. Simplify the code and only write the register only once at the end of clock reconfiguration to enable both core and TRGMII Tx clocks. Tested on Ubiquiti ER-X running the GMAC0 and MT7530 in TRGMII mode. Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: b53: spi: add missing MODULE_DEVICE_TABLEQinglang Miao2021-03-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller2021-03-253-37/+40
|\| | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mt7530: setup core clock even in TRGMII modeIlya Lipnitskiy2021-03-121-27/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A recent change to MIPS ralink reset logic made it so mt7530 actually resets the switch on platforms such as mt7621 (where bit 2 is the reset line for the switch). That exposed an issue where the switch would not function properly in TRGMII mode after a reset. Reconfigure core clock in TRGMII mode to fix the issue. Tested on Ubiquiti ER-X (MT7621) with TRGMII mode enabled. Fixes: 3f9ef7785a9c ("MIPS: ralink: manage low reset lines") Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: bcm_sf2: Qualify phydev->dev_flags based on portFlorian Fainelli2021-03-101-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Similar to commit 92696286f3bb37ba50e4bd8d1beb24afb759a799 ("net: bcmgenet: Set phydev->dev_flags only for internal PHYs") we need to qualify the phydev->dev_flags based on whether the port is connected to an internal or external PHY otherwise we risk having a flags collision with a completely different interpretation depending on the driver. Fixes: aa9aef77c761 ("net: dsa: bcm_sf2: communicate integrated PHY revision to PHY driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: b53: VLAN filtering is global to all usersFlorian Fainelli2021-03-101-7/+7
| | | | | | | | | | | | | | | | | | | | | | The bcm_sf2 driver uses the b53 driver as a library but does not make usre of the b53_setup() function, this made it fail to inherit the vlan_filtering_is_global attribute. Fix this by moving the assignment to b53_switch_alloc() which is used by bcm_sf2. Fixes: 7228b23e68f7 ("net: dsa: b53: Let DSA handle mismatched VLAN filtering settings") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: bcm_sf2: use 2 Gbps IMP port link on BCM4908Rafał Miłecki2021-03-101-1/+4
| | | | | | | | | | | | | | | | | | | | BCM4908 uses 2 Gbps link between switch and the Ethernet interface. Without this BCM4908 devices were able to achieve only 2 x ~895 Mb/s. This allows handling e.g. NAT traffic with 940 Mb/s. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: ocelot: replay switchdev events when joining bridgeVladimir Oltean2021-03-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The premise of this change is that the switchdev port attributes and objects offloaded by ocelot might have been missed when we are joining an already existing bridge port, such as a bonding interface. The patch pulls these switchdev attributes and objects from the bridge, on behalf of the 'bridge port' net device which might be either the ocelot switch interface, or the bonding upper interface. The ocelot_net.c belongs strictly to the switchdev ocelot driver, while ocelot.c is part of a library shared with the DSA felix driver. The ocelot_port_bridge_leave function (part of the common library) used to call ocelot_port_vlan_filtering(false), something which is not necessary for DSA, since the framework deals with that already there. So we move this function to ocelot_switchdev_unsync, which is specific to the switchdev driver. The code movement described above makes ocelot_port_bridge_leave no longer return an error code, so we change its type from int to void. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: hellcreek: Report switch name and IDKurt Kanzenbach2021-03-221-0/+18
| | | | | | | | | | | | | | | | | | | | | | Report the driver name, ASIC ID and the switch name via devlink. This is a useful information for user space tooling. Signed-off-by: Kurt Kanzenbach <kurt@kmk-computers.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: lantiq: verify compatible strings against hardwareAleksander Jan Bajkowski2021-03-221-1/+19
| | | | | | | | | | | | | | | | Verify compatible string against hardware. Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: lantiq: allow to use all GPHYs on xRX300 and xRX330Aleksander Jan Bajkowski2021-03-221-29/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows to use all PHYs on GRX300 and GRX330. The ARX300 has 3 and the GRX330 has 4 integrated PHYs connected to different ports compared to VRX200. Each integrated PHY can work as single Gigabit Ethernet PHY (GMII) or as double Fast Ethernet PHY (MII). Allowed port configurations: xRX200: GMAC0: RGMII, MII, REVMII or RMII port GMAC1: RGMII, MII, REVMII or RMII port GMAC2: GPHY0 (GMII) GMAC3: GPHY0 (MII) GMAC4: GPHY1 (GMII) GMAC5: GPHY1 (MII) or RGMII port xRX300: GMAC0: RGMII port GMAC1: GPHY2 (GMII) GMAC2: GPHY0 (GMII) GMAC3: GPHY0 (MII) GMAC4: GPHY1 (GMII) GMAC5: GPHY1 (MII) or RGMII port xRX330: GMAC0: RGMII, GMII or RMII port GMAC1: GPHY2 (GMII) GMAC2: GPHY0 (GMII) GMAC3: GPHY0 (MII) or GPHY3 (GMII) GMAC4: GPHY1 (GMII) GMAC5: GPHY1 (MII), RGMII or RMII port Tested on D-Link DWR966 (xRX330) with OpenWRT. Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: fix up kerneldoc some moreVladimir Oltean2021-03-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 0b5294483c35 ("net: dsa: mv88e6xxx: scratch: Fixup kerneldoc") has addressed some but not all kerneldoc warnings for the Global 2 Scratch register accessors. Namely, we have some mismatches between the function names in the kerneldoc and the ones in the actual code. Let's adjust the comments so that they match the functions they're sitting next to. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | dsa: simplify Kconfig symbols and dependenciesAlexander Lobakin2021-03-221-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Remove CONFIG_HAVE_NET_DSA. CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers should have selected CONFIG_NET_DSA manually. Currently, all drivers has explicit 'depends on NET_DSA', so this is no more needed. 2. CONFIG_HAVE_NET_DSA dependencies became CONFIG_NET_DSA's ones. - dropped !S390 dependency which was introduced to be sure NET_DSA can select CONFIG_PHYLIB. DSA migrated to Phylink almost 3 years ago and the PHY library itself doesn't depend on !S390 since commit 870a2b5e4fcd ("phylib: remove !S390 dependeny from Kconfig"); - INET dependency is kept to be sure we can select NET_SWITCHDEV; - NETDEVICES dependency is kept to be sure we can select PHYLINK. 3. DSA drivers menu now depends on NET_DSA. Instead on 'depends on NET_DSA' on every single driver, the entire menu now depends on it. This eliminates a lot of duplicated lines from Kconfig with no loss (when CONFIG_NET_DSA=m, drivers also can be only m or n). This also has a nice side effect that there's no more empty menu on configurations without DSA. 4. Kbuild will now descend into 'drivers/net/dsa' only when CONFIG_NET_DSA is y or m. This is safe since no objects inside this folder can be built without DSA core, as well as when CONFIG_NET_DSA=m, no objects can be built-in. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Revert "net: dsa: sja1105: Clear VLAN filtering offload netdev feature"Vladimir Oltean2021-03-201-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit e9bf96943b408e6c99dd13fb01cb907335787c61. The topic of the reverted patch is the support for switches with global VLAN filtering, added by commit 061f6a505ac3 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation"). Be there a switch with 4 ports swp0 -> swp3, and the following setup: ip link add br0 type bridge vlan_filtering 1 ip link set swp0 master br0 ip link set swp1 master br0 What would happen with VLAN-tagged traffic received on standalone ports swp2 and swp3? Well, it would get dropped, were it not for the .ndo_vlan_rx_add_vid and .ndo_vlan_rx_kill_vid implementations (called from vlan_vid_add and vlan_vid_del respectively). Basically, for DSA switches where VLAN filtering is a global attribute, we enforce the standalone ports to have 'rx-vlan-filter: off [fixed]' in their ethtool features, which lets the user know that all VLAN-tagged packets that are not explicitly added in the RX filtering list are dropped. As for the sja1105 driver, at the time of the reverted patch, it was operating in a pretty handicapped mode when it had ports under a bridge with vlan_filtering=1. Specifically, it was unable to terminate traffic through the CPU port (for further explanation see "Traffic support" in Documentation/networking/dsa/sja1105.rst). However, since then, the sja1105 driver has made considerable progress, and that limitation is no longer as severe now. Specifically, since commit 2cafa72e516f ("net: dsa: sja1105: add a new best_effort_vlan_filtering devlink parameter"), the driver is able to perform CPU termination even when some ports are under bridges with vlan_filtering=1. Then, since commit 8841f6e63f2c ("net: dsa: sja1105: make devlink property best_effort_vlan_filtering true by default"), this even became the default operating mode. So we can now take advantage of the logic in the DSA core. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: Offload bridge broadcast flooding flagTobias Waldekranz2021-03-181-1/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These switches have two modes of classifying broadcast: 1. Broadcast is multicast. 2. Broadcast is its own unique thing that is always flooded everywhere. This driver uses the first option, making sure to load the broadcast address into all active databases. Because of this, we can support per-port broadcast flooding by (1) making sure to only set the subset of ports that have it enabled whenever joining a new bridge or VLAN, and (2) by updating all active databases whenever the setting is changed on a port. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: Offload bridge learning flagTobias Waldekranz2021-03-183-8/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | Allow a user to control automatic learning per port. Many chips have an explicit "LearningDisable"-bit that can be used for this, but we opt for setting/clearing the PAV instead, as it works on all devices at least as far back as 6083. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: Flood all traffic classes on standalone portsTobias Waldekranz2021-03-181-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In accordance with the comment in dsa_port_bridge_leave, standalone ports shall be configured to flood all types of traffic. This change aligns the mv88e6xxx driver with that policy. Previously a standalone port would initially not egress any unknown traffic, but after joining and then leaving a bridge, it would. This does not matter that much since we only ever send FROM_CPUs on standalone ports, but it seems prudent to make sure that the initial values match those that are applied after a bridging/unbridging cycle. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: Use standard helper for broadcast addressTobias Waldekranz2021-03-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | Use the conventional declaration style of a MAC address in the kernel (u8 addr[ETH_ALEN]) for the broadcast address, then set it using the existing helper. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: Remove some bureaucracy around querying the VTUTobias Waldekranz2021-03-181-25/+20
| | | | | | | | | | | | | | | | | | | | | | The hardware has a somewhat quirky protocol for reading out the VTU entry for a particular VID. But there is no reason why we cannot create a better API for ourselves in the driver. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: Provide generic VTU iteratorTobias Waldekranz2021-03-181-36/+64
| | | | | | | | | | | | | | | | | | | | | | Move the intricacies of correctly iterating over the VTU to a common implementation. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: Avoid useless attempts to fast-age LAGsTobias Waldekranz2021-03-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a port is a part of a LAG, the ATU will create dynamic entries belonging to the LAG ID when learning is enabled. So trying to fast-age those out using the constituent port will have no effect. Unfortunately the hardware does not support move operations on LAGs so there is no obvious way to transform the request to target the LAG instead. Instead we document this known limitation and at least avoid wasting any time on it. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: bcm_sf2: fix BCM4908 RGMII reg(s)Rafał Miłecki2021-03-182-4/+8
| | | | | | | | | | | | | | | | | | BCM4908 has only 1 RGMII reg for controlling port 7. Fixes: 73b7a6047971 ("net: dsa: bcm_sf2: support BCM4908's integrated switch") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: bcm_sf2: add function finding RGMII registerRafał Miłecki2021-03-182-9/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simple macro like REG_RGMII_CNTRL_P() is insufficient as: 1. It doesn't validate port argument 2. It doesn't support chipsets with non-lineral RGMII regs layout Missing port validation could result in getting register offset from out of array. Random memory -> random offset -> random reads/writes. It affected e.g. BCM4908 for REG_RGMII_CNTRL_P(7). Fixes: a78e86ed586d ("net: dsa: bcm_sf2: Prepare for different register layouts") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: b53: mmap: Add device tree supportÁlvaro Fernández Rojas2021-03-181-0/+55
| | | | | | | | | | | | | | Add device tree support to b53_mmap.c while keeping platform devices support. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: implement .port_set_policy for AmethystMarek Behún2021-03-173-27/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 16-bit Port Policy CTL register from older chips is on 6393x changed to Port Policy MGMT CTL, which can access more data, but indirectly and via 8-bit registers. The original 16-bit value is divided into first two 8-bit register in the Port Policy MGMT CTL. We can therefore use the previous code to compute the mask and shift, and then - if 0 <= shift < 8, we access register 0 in Port Policy MGMT CTL - if 8 <= shift < 16, we access register 1 in Port Policy MGMT CTL There are in fact other possible policy settings for Amethyst which could be added here, but this can be done in the future. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Pavana Sharma <pavana.sharma@digi.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: add support for mv88e6393x familyPavana Sharma2021-03-178-0/+771
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Marvell 88E6393X device is a single-chip integration of a 11-port Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers and three 10-Gigabit interfaces. This patch adds functionalities specific to mv88e6393x family (88E6393X, 88E6193X and 88E6191X). The main differences between previous devices and this one are: - port 0 can be a SERDES port - all SERDESes are one-lane, eg. no XAUI nor RXAUI - on the other hand the SERDESes can do USXGMII, 10GBASER and 5GBASER (on 6191X only one SERDES is capable of more than 1g; USXGMII is not yet supported with this change) - Port Policy CTL register is changed to Port Policy MGMT CTL register, via which several more registers can be accessed indirectly - egress monitor port is configured differently - ingress monitor/CPU/mirror ports are configured differently and can be configured per port (ie. each port can have different ingress monitor port, for example) - port speed AltBit works differently than previously - PHY registers can be also accessed via MDIO address 0x18 and 0x19 (on previous devices they could be accessed only via Global 2 offsets 0x18 and 0x19, which means two indirections; this feature is not yet leveraged with thiis commit) Co-developed-by: Ashkan Boldaji <ashkan.boldaji@digi.com> Signed-off-by: Ashkan Boldaji <ashkan.boldaji@digi.com> Signed-off-by: Pavana Sharma <pavana.sharma@digi.com> Co-developed-by: Marek Behún <kabel@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: wrap .set_egress_port methodMarek Behún2021-03-172-35/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | There are two implementations of the .set_egress_port method, and both of them, if successful, set chip->*gress_dest_port variable. To avoid code repetition, wrap this method into mv88e6xxx_set_egress_port. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Pavana Sharma <pavana.sharma@digi.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: change serdes lane parameter type from u8 type to intPavana Sharma2021-03-175-99/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | Returning 0 is no more an error case with MV88E6393 family which has serdes lane numbers 0, 9 or 10. So with this change .serdes_get_lane will return lane number or -errno (-ENODEV or -EOPNOTSUPP). Signed-off-by: Pavana Sharma <pavana.sharma@digi.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: b53: support legacy tagsÁlvaro Fernández Rojas2021-03-172-5/+8
| | | | | | | | | | | | | | | | These tags are used on BCM5325, BCM5365 and BCM63xx switches. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: b53: relax is63xx() conditionÁlvaro Fernández Rojas2021-03-171-4/+0
| | | | | | | | | | | | | | | | BCM63xx switches are present on bcm63xx and bmips devices. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mt7530: support MDB and bridge flag operationsDENG Qingfang2021-03-162-4/+121
| | | | | | | | | | | | | | | | | | | | | | Support port MDB and bridge flag operations. As the hardware can manage multicast forwarding itself, offload_fwd_mark can be unconditionally set to true. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: sja1105: fix error return code in sja1105_cls_flower_add()Wei Yongjun2021-03-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The return value 'rc' maybe overwrite to 0 in the flow_action_for_each loop, the error code from the offload not support error handling will not set. This commit fix it to return -EOPNOTSUPP. Fixes: 6a56e19902af ("flow_offload: reject configuration of packet-per-second policing in offload drivers") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: b53: spi: allow device tree probingÁlvaro Fernández Rojas2021-03-161-0/+13
| | | | | | | | | | | | | | Add missing of_match_table to allow device tree probing. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: hellcreek: Offload bridge port flagsKurt Kanzenbach2021-03-151-25/+104
| | | | | | | | | | | | | | | | The switch implements unicast and multicast filtering per port. Add support for it. By default filtering is disabled. Signed-off-by: Kurt Kanzenbach <kurt@kmk-computers.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: bcm_sf2: Fill in BCM4908 CFP entriesFlorian Fainelli2021-03-141-1/+1
| | | | | | | | | | | | | | | | The BCM4908 switch has 256 CFP entrie, update that setting so CFP can be used. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: hellcreek: Add devlink FDB regionKurt Kanzenbach2021-03-132-0/+63
| | | | | | | | | | | | | | | | | | Allow to dump the FDB table via devlink. This is a useful debugging feature. Signed-off-by: Kurt Kanzenbach <kurt@kmk-computers.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: hellcreek: Move common code to helperKurt Kanzenbach2021-03-131-42/+43
| | | | | | | | | | | | | | | | | | | | There are two functions which need to populate fdb entries. Move that to a helper function. Signed-off-by: Kurt Kanzenbach <kurt@kmk-computers.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-18 03:15:18 +0000