summaryrefslogtreecommitdiffstats
path: root/drivers/net/dsa
Commit message (Collapse)AuthorAgeFilesLines
...
* | net: dsa: mv88e6xxx: Provide dummy implementations for trunk settersTobias Waldekranz2021-01-151-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Support for Global 2 registers is build-time optional. In the case where it was not enabled the build would fail as no "dummy" implementation of these functions was available. Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: add Arrow SpeedChips XRS700x driverGeorge McCollister2021-01-159-0/+1213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a driver with initial support for the Arrow SpeedChips XRS7000 series of gigabit Ethernet switch chips which are typically used in critical networking applications. The switches have up to three RGMII ports and one RMII port. Management to the switches can be performed over i2c or mdio. Support for advanced features such as PTP and HSR/PRP (IEC 62439-3 Clause 5 & 4) is not included in this patch and may be added at a later date. Signed-off-by: George McCollister <george.mccollister@gmail.com> 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: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: Link aggregation supportTobias Waldekranz2021-01-145-5/+330
| | | | | | | | | | | | | | | | | | | | Support offloading of LAGs to hardware. LAGs may be attached to a bridge in which case VLANs, multicast groups, etc. are also offloaded as usual. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: qca: ar9331: export stats64Oleksij Rempel2021-01-121-1/+162
| | | | | | | | | | | | | | Add stats support for the ar9331 switch. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: felix: the switch does not support DMAVladimir Oltean2021-01-111-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code that sets the DMA mask to 64 bits is bogus, it is taken from the enetc driver together with the rest of the PCI probing boilerplate. Since this patch is touching the error path to delete err_dma, let's also change the err_alloc_felix label which was incorrect. The kzalloc failure does not need a kfree, but it doesn't hurt either, since kfree works with NULL pointers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210109203415.2120142-1-olteanv@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: remove the transactional logic from VLAN objectsVladimir Oltean2021-01-1119-164/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It should be the driver's business to logically separate its VLAN offloading into a preparation and a commit phase, and some drivers don't need / can't do this. So remove the transactional shim from DSA and let drivers propagate errors directly from the .port_vlan_add callback. It would appear that the code has worse error handling now than it had before. DSA is the only in-kernel user of switchdev that offloads one switchdev object to more than one port: for every VLAN object offloaded to a user port, that VLAN is also offloaded to the CPU port. So the "prepare for user port -> check for errors -> prepare for CPU port -> check for errors -> commit for user port -> commit for CPU port" sequence appears to make more sense than the one we are using now: "offload to user port -> check for errors -> offload to CPU port -> check for errors", but it is really a compromise. In the new way, we can catch errors from the commit phase that we previously had to ignore. But we have our hands tied and cannot do any rollback now: if we add a VLAN on the CPU port and it fails, we can't do the rollback by simply deleting it from the user port, because the switchdev API is not so nice with us: it could have simply been there already, even with the same flags. So we don't even attempt to rollback anything on addition error, just leave whatever VLANs managed to get offloaded right where they are. This should not be a problem at all in practice. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: remove the transactional logic from MDB entriesVladimir Oltean2021-01-1111-85/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For many drivers, the .port_mdb_prepare callback was not a good opportunity to avoid any error condition, and they would suppress errors found during the actual commit phase. Where a logical separation between the prepare and the commit phase existed, the function that used to implement the .port_mdb_prepare callback still exists, but now it is called directly from .port_mdb_add, which was modified to return an int code. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Reviewed-by: Linus Wallei <linus.walleij@linaro.org> # RTL8366 Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: switchdev: remove the transaction structure from port attributesVladimir Oltean2021-01-1116-93/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the introduction of the switchdev API, port attributes were transmitted to drivers for offloading using a two-step transactional model, with a prepare phase that was supposed to catch all errors, and a commit phase that was supposed to never fail. Some classes of failures can never be avoided, like hardware access, or memory allocation. In the latter case, merely attempting to move the memory allocation to the preparation phase makes it impossible to avoid memory leaks, since commit 91cf8eceffc1 ("switchdev: Remove unused transaction item queue") which has removed the unused mechanism of passing on the allocated memory between one phase and another. It is time we admit that separating the preparation from the commit phase is something that is best left for the driver to decide, and not something that should be baked into the API, especially since there are no switchdev callers that depend on this. This patch removes the struct switchdev_trans member from switchdev port attribute notifier structures, and converts drivers to not look at this member. In part, this patch contains a revert of my previous commit 2e554a7a5d8a ("net: dsa: propagate switchdev vlan_filtering prepare phase to drivers"). For the most part, the conversion was trivial except for: - Rocker's world implementation based on Broadcom OF-DPA had an odd implementation of ofdpa_port_attr_bridge_flags_set. The conversion was done mechanically, by pasting the implementation twice, then only keeping the code that would get executed during prepare phase on top, then only keeping the code that gets executed during the commit phase on bottom, then simplifying the resulting code until this was obtained. - DSA's offloading of STP state, bridge flags, VLAN filtering and multicast router could be converted right away. But the ageing time could not, so a shim was introduced and this was left for a further commit. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Reviewed-by: Linus Walleij <linus.walleij@linaro.org> # RTL8366RB Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: deny vid 0 on the CPU port and DSA links tooVladimir Oltean2021-01-111-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mv88e6xxx apparently has a problem offloading VID 0, which the 8021q module tries to install as part of commit ad1afb003939 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)"). That mv88e6xxx restriction seems to have been introduced by the "VTU GetNext VID-1 trick to retrieve a single entry" - see commit 2fb5ef09de7c ("net: dsa: mv88e6xxx: extract single VLAN retrieval"). There is one more problem. The mv88e6xxx CPU port and DSA links do not report properly in the prepare phase what are the VLANs that they can offload. They'll say they can offload everything: mv88e6xxx_port_vlan_prepare -> mv88e6xxx_port_check_hw_vlan: /* DSA and CPU ports have to be members of multiple vlans */ if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port)) return 0; Except that if you actually try to commit to it, they'll error out and print this message: [ 32.802438] mv88e6085 d0032004.mdio-mii:12: p9: failed to add VLAN 0t which comes from: mv88e6xxx_port_vlan_add -> mv88e6xxx_port_vlan_join: if (!vid) return -EOPNOTSUPP; What prevents this condition from triggering in real life? The fact that when a DSA_NOTIFIER_VLAN_ADD is emitted, it never targets a DSA link directly. Instead, the notifier will always target either a user port or a CPU port. DSA links just happen to get dragged in by: static bool dsa_switch_vlan_match(struct dsa_switch *ds, int port, struct dsa_notifier_vlan_info *info) { ... if (dsa_is_dsa_port(ds, port)) return true; ... } So for every DSA VLAN notifier, during the prepare phase, it will just so happen that there will be somebody to say "no, don't do that". This will become a problem when the switchdev prepare/commit transactional model goes away. Every port needs to think on its own. DSA links can no longer bluff and rely on the fact that the prepare phase will not go through to the end, because there will be no prepare phase any longer. Fix this issue before it becomes a problem, by having the "vid == 0" check earlier than the check whether we are a CPU port / DSA link or not. Also, the "vid == 0" check becomes unnecessary in the .port_vlan_add callback, so we can remove it. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: switchdev: remove vid_begin -> vid_end range from VLAN objectsVladimir Oltean2021-01-1113-380/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The call path of a switchdev VLAN addition to the bridge looks something like this today: nbp_vlan_init | __br_vlan_set_default_pvid | | | | | br_afspec | | | | | | | v | | | br_process_vlan_info | | | | | | | v | | | br_vlan_info | | | / \ / | | / \ / | | / \ / | | / \ / v v v v v nbp_vlan_add br_vlan_add ------+ | ^ ^ | | | / | | | | / / / | \ br_vlan_get_master/ / v \ ^ / / br_vlan_add_existing \ | / / | \ | / / / \ | / / / \ | / / / \ | / / / v | | v / __vlan_add / / | / / | / v | / __vlan_vid_add | / \ | / v v v br_switchdev_port_vlan_add The ranges UAPI was introduced to the bridge in commit bdced7ef7838 ("bridge: support for multiple vlans and vlan ranges in setlink and dellink requests") (Jan 10 2015). But the VLAN ranges (parsed in br_afspec) have always been passed one by one, through struct bridge_vlan_info tmp_vinfo, to br_vlan_info. So the range never went too far in depth. Then Scott Feldman introduced the switchdev_port_bridge_setlink function in commit 47f8328bb1a4 ("switchdev: add new switchdev bridge setlink"). That marked the introduction of the SWITCHDEV_OBJ_PORT_VLAN, which made full use of the range. But switchdev_port_bridge_setlink was called like this: br_setlink -> br_afspec -> switchdev_port_bridge_setlink Basically, the switchdev and the bridge code were not tightly integrated. Then commit 41c498b9359e ("bridge: restore br_setlink back to original") came, and switchdev drivers were required to implement .ndo_bridge_setlink = switchdev_port_bridge_setlink for a while. In the meantime, commits such as 0944d6b5a2fa ("bridge: try switchdev op first in __vlan_vid_add/del") finally made switchdev penetrate the br_vlan_info() barrier and start to develop the call path we have today. But remember, br_vlan_info() still receives VLANs one by one. Then Arkadi Sharshevsky refactored the switchdev API in 2017 in commit 29ab586c3d83 ("net: switchdev: Remove bridge bypass support from switchdev") so that drivers would not implement .ndo_bridge_setlink any longer. The switchdev_port_bridge_setlink also got deleted. This refactoring removed the parallel bridge_setlink implementation from switchdev, and left the only switchdev VLAN objects to be the ones offloaded from __vlan_vid_add (basically RX filtering) and __vlan_add (the latter coming from commit 9c86ce2c1ae3 ("net: bridge: Notify about bridge VLANs")). That is to say, today the switchdev VLAN object ranges are not used in the kernel. Refactoring the above call path is a bit complicated, when the bridge VLAN call path is already a bit complicated. Let's go off and finish the job of commit 29ab586c3d83 by deleting the bogus iteration through the VLAN ranges from the drivers. Some aspects of this feature never made too much sense in the first place. For example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID flag supposed to mean, when a port can obviously have a single pvid? This particular configuration _is_ denied as of commit 6623c60dc28e ("bridge: vlan: enforce no pvid flag in vlan ranges"), but from an API perspective, the driver still has to play pretend, and only offload the vlan->vid_end as pvid. And the addition of a switchdev VLAN object can modify the flags of another, completely unrelated, switchdev VLAN object! (a VLAN that is PVID will invalidate the PVID flag from whatever other VLAN had previously been offloaded with switchdev and had that flag. Yet switchdev never notifies about that change, drivers are supposed to guess). Nonetheless, having a VLAN range in the API makes error handling look scarier than it really is - unwinding on errors and all of that. When in reality, no one really calls this API with more than one VLAN. It is all unnecessary complexity. And despite appearing pretentious (two-phase transactional model and all), the switchdev API is really sloppy because the VLAN addition and removal operations are not paired with one another (you can add a VLAN 100 times and delete it just once). The bridge notifies through switchdev of a VLAN addition not only when the flags of an existing VLAN change, but also when nothing changes. There are switchdev drivers out there who don't like adding a VLAN that has already been added, and those checks don't really belong at driver level. But the fact that the API contains ranges is yet another factor that prevents this from being addressed in the future. Of the existing switchdev pieces of hardware, it appears that only Mellanox Spectrum supports offloading more than one VLAN at a time, through mlxsw_sp_port_vlan_set. I have kept that code internal to the driver, because there is some more bookkeeping that makes use of it, but I deleted it from the switchdev API. But since the switchdev support for ranges has already been de facto deleted by a Mellanox employee and nobody noticed for 4 years, I'm going to assume it's not a biggie. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> # switchdev and mlxsw Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: bcm_sf2: support BCM4908's integrated switchRafał Miłecki2021-01-094-3/+49
| | | | | | | | | | | | | | | | | | | | | | BCM4908 family SoCs come with integrated Starfighter 2 switch. Its registers layout it a mix of BCM7278 and BCM7445. It has 5 integrated PHYs and 8 ports. It also supports RGMII and SerDes. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210106213202.17459-3-zajec5@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2021-01-082-3/+5
|\| | | | | | | | | | | | | | | | | Trivial conflict in CAN on file rename. Conflicts: drivers/net/can/m_can/tcan4x5x-core.c Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: dsa: lantiq_gswip: Exclude RMII from modes that report 1 GbEAleksander Jan Bajkowski2021-01-071-3/+4
| | | | | | | | | | | | | | | | | | | | | | Exclude RMII from modes that report 1 GbE support. Reduced MII supports up to 100 MbE. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210107195818.3878-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: dsa: fix led_classdev build errorsRandy Dunlap2021-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix build errors when LEDS_CLASS=m and NET_DSA_HIRSCHMANN_HELLCREEK=y. This limits the latter to =m when LEDS_CLASS=m. microblaze-linux-ld: drivers/net/dsa/hirschmann/hellcreek_ptp.o: in function `hellcreek_ptp_setup': (.text+0xf80): undefined reference to `led_classdev_register_ext' microblaze-linux-ld: (.text+0xf94): undefined reference to `led_classdev_register_ext' microblaze-linux-ld: drivers/net/dsa/hirschmann/hellcreek_ptp.o: in function `hellcreek_ptp_free': (.text+0x1018): undefined reference to `led_classdev_unregister' microblaze-linux-ld: (.text+0x1024): undefined reference to `led_classdev_unregister' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202101060655.iUvMJqS2-lkp@intel.com Cc: Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20210106021815.31796-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: ocelot: request DSA to fix up lack of address learning on CPU portVladimir Oltean2021-01-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the following setup: ip link add br0 type bridge ip link set eno0 master br0 ip link set swp0 master br0 ip link set swp1 master br0 ip link set swp2 master br0 ip link set swp3 master br0 Currently, packets received on a DSA slave interface (such as swp0) which should be routed by the software bridge towards a non-switch port (such as eno0) are also flooded towards the other switch ports (swp1, swp2, swp3) because the destination is unknown to the hardware switch. This patch addresses the issue by monitoring the addresses learnt by the software bridge on eno0, and adding/deleting them as static FDB entries on the CPU port accordingly. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: sja1105: Use kzalloc for allocating only one thingZheng Yongjun2021-01-051-1/+1
|/ | | | | | | | | | | | | | | | | | | Use kzalloc rather than kcalloc(1,...) The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ @@ - kcalloc(1, + kzalloc( ...) // </smpl> Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: lantiq_gswip: Fix GSWIP_MII_CFG(p) register accessMartin Blumenstingl2021-01-041-17/+6
| | | | | | | | | | | | | | | | | | | | | There is one GSWIP_MII_CFG register for each switch-port except the CPU port. The register offset for the first port is 0x0, 0x02 for the second, 0x04 for the third and so on. Update the driver to not only restrict the GSWIP_MII_CFG registers to ports 0, 1 and 5. Handle ports 0..5 instead but skip the CPU port. This means we are not overwriting the configuration for the third port (port two since we start counting from zero) with the settings for the sixth port (with number five) anymore. The GSWIP_MII_PCDU(p) registers are not updated because there's really only three (one for each of the following ports: 0, 1, 5). Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: lantiq_gswip: Enable GSWIP_MII_CFG_EN also for internal PHYsMartin Blumenstingl2021-01-041-3/+1
| | | | | | | | | | | | | Enable GSWIP_MII_CFG_EN also for internal PHYs to make traffic flow. Without this the PHY link is detected properly and ethtool statistics for TX are increasing but there's no RX traffic coming in. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Suggested-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: qca: ar9331: fix sleeping function called from invalid context bugOleksij Rempel2020-12-161-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With lockdep enabled, we will get following warning: ar9331_switch ethernet.1:10 lan0 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:00] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13) BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 18, name: kworker/0:1 INFO: lockdep is turned off. irq event stamp: 602 hardirqs last enabled at (601): [<8073fde0>] _raw_spin_unlock_irq+0x3c/0x80 hardirqs last disabled at (602): [<8073a4f4>] __schedule+0x184/0x800 softirqs last enabled at (0): [<80080f60>] copy_process+0x578/0x14c8 softirqs last disabled at (0): [<00000000>] 0x0 CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 5.10.0-rc3-ar9331-00734-g7d644991df0c #31 Workqueue: events deferred_probe_work_func Stack : 80980000 80980000 8089ef70 80890000 804b5414 80980000 00000002 80b53728 00000000 800d1268 804b5414 ffffffde 00000017 800afe08 81943860 0f5bfc32 00000000 00000000 8089ef70 819436c0 ffffffea 00000000 00000000 00000000 8194390c 808e353c 0000000f 66657272 80980000 00000000 00000000 80890000 804b5414 80980000 00000002 80b53728 00000000 00000000 00000000 80d40000 ... Call Trace: [<80069ce0>] show_stack+0x9c/0x140 [<800afe08>] ___might_sleep+0x220/0x244 [<8073bfb0>] __mutex_lock+0x70/0x374 [<8073c2e0>] mutex_lock_nested+0x2c/0x38 [<804b5414>] regmap_update_bits_base+0x38/0x8c [<804ee584>] regmap_update_bits+0x1c/0x28 [<804ee714>] ar9331_sw_unmask_irq+0x34/0x60 [<800d91f0>] unmask_irq+0x48/0x70 [<800d93d4>] irq_startup+0x114/0x11c [<800d65b4>] __setup_irq+0x4f4/0x6d0 [<800d68a0>] request_threaded_irq+0x110/0x190 [<804e3ef0>] phy_request_interrupt+0x4c/0xe4 [<804df508>] phylink_bringup_phy+0x2c0/0x37c [<804df7bc>] phylink_of_phy_connect+0x118/0x130 [<806c1a64>] dsa_slave_create+0x3d0/0x578 [<806bc4ec>] dsa_register_switch+0x934/0xa20 [<804eef98>] ar9331_sw_probe+0x34c/0x364 [<804eb48c>] mdio_probe+0x44/0x70 [<8049e3b4>] really_probe+0x30c/0x4f4 [<8049ea10>] driver_probe_device+0x264/0x26c [<8049bc10>] bus_for_each_drv+0xb4/0xd8 [<8049e684>] __device_attach+0xe8/0x18c [<8049ce58>] bus_probe_device+0x48/0xc4 [<8049db70>] deferred_probe_work_func+0xdc/0xf8 [<8009ff64>] process_one_work+0x2e4/0x4a0 [<800a0770>] worker_thread+0x2a8/0x354 [<800a774c>] kthread+0x16c/0x174 [<8006306c>] ret_from_kernel_thread+0x14/0x1c ar9331_switch ethernet.1:10 lan1 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:02] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13) DSA: tree 0 setup To fix it, it is better to move access to MDIO register to the .irq_bus_sync_unlock call back. Fixes: ec6698c272de ("net: dsa: add support for Atheros AR9331 built-in switch") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20201211110317.17061-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: don't set non-existing learn2all bit for 6220/6250Rasmus Villemoes2020-12-141-3/+10
| | | | | | | | | | | | | | | The 6220 and 6250 switches do not have a learn2all bit in global1, ATU control register; bit 3 is reserverd. On the switches that do have that bit, it is used to control whether learning frames are sent out the ports that have the message_port bit set. So rather than adding yet another chip method, use the existence of the ->port_setup_message_port method as a proxy for determining whether the learn2all bit exists (and should be set). Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Link: https://lore.kernel.org/r/20201210110645.27765-1-rasmus.villemoes@prevas.dk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mt7530: enable MTU normalizationDENG Qingfang2020-12-121-0/+2
| | | | | | | | | | | | MT7530 has a global RX length register, so we are actually changing its MRU. Enable MTU normalization for this reason. Signed-off-by: DENG Qingfang <dqfext@gmail.com> Acked-by: Landen Chao <landen.chao@mediatek.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20201210170322.3433-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2020-12-113-7/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | xdp_return_frame_bulk() needs to pass a xdp_buff to __xdp_return(). strlcpy got converted to strscpy but here it makes no functional difference, so just keep the right code. Conflicts: net/netfilter/nf_tables_api.c Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: mscc: ocelot: fix dropping of unknown IPv4 multicast on SevilleVladimir Oltean2020-12-053-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current assumption is that the felix DSA driver has flooding knobs per traffic class, while ocelot switchdev has a single flooding knob. This was correct for felix VSC9959 and ocelot VSC7514, but with the introduction of seville VSC9953, we see a switch driven by felix.c which has a single flooding knob. So it is clear that we must do what should have been done from the beginning, which is not to overwrite the configuration done by ocelot.c in felix, but instead to teach the common ocelot library about the differences in our switches, and set up the flooding PGIDs centrally. The effect that the bogus iteration through FELIX_NUM_TC has upon seville is quite dramatic. ANA_FLOODING is located at 0x00b548, and ANA_FLOODING_IPMC is located at 0x00b54c. So the bogus iteration will actually overwrite ANA_FLOODING_IPMC when attempting to write ANA_FLOODING[1]. There is no ANA_FLOODING[1] in sevile, just ANA_FLOODING. And when ANA_FLOODING_IPMC is overwritten with a bogus value, the effect is that ANA_FLOODING_IPMC gets the value of 0x0003CF7D: MC6_DATA = 61, MC6_CTRL = 61, MC4_DATA = 60, MC4_CTRL = 0. Because MC4_CTRL is zero, this means that IPv4 multicast control packets are not flooded, but dropped. An invalid configuration, and this is how the issue was actually spotted. Reported-by: Eldar Gasanov <eldargasanov2@gmail.com> Reported-by: Maxim Kochetkov <fido_max@inbox.ru> Tested-by: Eldar Gasanov <eldargasanov2@gmail.com> Fixes: 84705fc16552 ("net: dsa: felix: introduce support for Seville VSC9953 switch") Fixes: 3c7b51bd39b2 ("net: dsa: felix: allow flooding for all traffic classes") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201204175416.1445937-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: simplify the return rtl8366_vlan_prepare()Zheng Yongjun2020-12-091-6/+1
| | | | | | | | | | | | | | | | | | Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.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: mv88e6xxx: convert comma to semicolonZheng Yongjun2020-12-091-1/+1
| | | | | | | | | | | | | | | | Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mt7530: support setting ageing timeDENG Qingfang2020-12-082-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | MT7530 has a global address age control register, so use it to set ageing time. The applied timer is (AGE_CNT + 1) * (AGE_UNIT + 1) seconds Signed-off-by: DENG Qingfang <dqfext@gmail.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: microchip: ksz8795: use num_vlans where possibleMichael Grzeschik2020-12-022-2/+1
| | | | | | | | | | | | | | | | | | | | | | The value of the define VLAN_TABLE_ENTRIES can be derived from num_vlans. This patch is using the variable num_vlans instead and removes the extra define. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: use port_cnt instead of TOTOAL_PORT_NUMMichael Grzeschik2020-12-022-4/+2
| | | | | | | | | | | | | | | | | | | | | | To get the driver working with other chips using different port counts the dyn_mac_table should be flushed depending on the amount of available ports. This patch remove the extra define TOTOAL_PORT_NUM and is making use of the dynamic port_cnt variable instead. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: remove usage of mib_port_countMichael Grzeschik2020-12-024-16/+12
| | | | | | | | | | | | | | | | | | | | | | The variable mib_port_cnt has the same meaning as port_cnt. This driver removes the extra variable and is using port_cnt everywhere instead. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: align port_cnt usage with other microchip driversMichael Grzeschik2020-12-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | The ksz8795 driver is using port_cnt differently to the other microchip DSA drivers. It sets it to the external physical port count, than the whole port count (including the cpu port). This patch is aligning the variables purpose with the other microchip drivers. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: remove superfluous num_ports assignmentMichael Grzeschik2020-12-022-4/+0
| | | | | | | | | | | | | | | | | | | | | | The variable num_ports is already assigned in the init function. The drivers individual init function already handles the different purpose of port_cnt vs port_cnt + 1. This patch removes the extra assignment of the variable. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: use phy_port_cnt where possibleMichael Grzeschik2020-12-022-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | The driver is currently hard coded to SWITCH_PORT_NUM being (TOTAL_PORT_NUM - 1) which is limited to 4 user ports for the ksz8795. The phy_port_cnt is referring to its user ports. The patch removes the extra define and use the assigned variable phy_port_cnt instead so the driver can be used on different switches. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: use mib_cnt where possibleMichael Grzeschik2020-12-022-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The variable mib_cnt is assigned with TOTAL_SWITCH_COUNTER_NUM. This value can also be derived from the array size of mib_names. This patch uses this calculated value instead, removes the extra define and uses mib_cnt everywhere possible instead of the static define TOTAL_SWITCH_COUNTER_NUM. Keeping it in a separate variable instead of using ARRAY_SIZE everywhere instead makes the driver more flexible for future use of devices with different amount of counters. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: use reg_mib_cnt where possibleMichael Grzeschik2020-12-022-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | The extra define SWITCH_COUNTER_NUM is a copy of the KSZ8795_COUNTER_NUM define. This patch initializes reg_mib_cnt with KSZ8795_COUNTER_NUM, makes use of reg_mib_cnt everywhere instead and removes the extra define. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: move variable assignments from detect to initMichael Grzeschik2020-12-021-6/+6
| | | | | | | | | | | | | | | | | | | | | | This patch moves all variable assignments to the init function. It leaves the detect function for its single purpose to detect which chip version is found. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: remove superfluous port_cnt assignmentMichael Grzeschik2020-12-021-2/+0
| | | | | | | | | | | | | | | | | | | | The port_cnt assignment will be done again in the init function. This patch removes the previous assignment in the detect function. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: remove unused last_port variableMichael Grzeschik2020-12-022-2/+0
| | | | | | | | | | | | | | | | | | The variable last_port is not used anywhere, this patch removes it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: Handle error in serdes_get_regsChris Packham2020-11-251-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | If the underlying read operation failed we would end up writing stale data to the supplied buffer. This would end up with the last successfully read value repeating. Fix this by only writing the data when we know the read was good. This will mean that failed values will return 0xffff. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: Add serdes interrupt support for MV88E6097Chris Packham2020-11-253-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | The MV88E6097 presents the serdes interrupts for ports 8 and 9 via the Switch Global 2 registers. There is no additional layer of enablinh/disabling the serdes interrupts like other mv88e6xxx switches. Even though most of the serdes behaviour is the same as the MV88E6185 that chip does not provide interrupts for serdes events so unlike earlier commits the functions added here are specific to the MV88E6097. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: Support serdes ports on MV88E6097/6095/6185Chris Packham2020-11-253-0/+76
| | | | | | | | | | | | | | | | | | | | | | Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for the MV88E6097/6095/6185 so that ports 8 & 9 can be supported as serdes ports and directly connected to other network interfaces or to SFPs without a PHY. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: Don't force link when using in-band-statusChris Packham2020-11-254-4/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a port is configured with 'managed = "in-band-status"' switch chips like the 88E6390 need to propagate the SERDES link state to the MAC because the link state is not correctly detected. This causes problems on the 88E6185/88E6097 where the link partner won't see link state changes because we're forcing the link. To address this introduce a new device specific op port_sync_link() and push the logic from mv88e6xxx_mac_link_up() into that. Provide an implementation for the 88E6185 like devices which doesn't force the link. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz8795: setup SPI modeChristian Eggers2020-11-251-0/+6
| | | | | | | | | | | | | | This should be done in the device driver instead of the device tree. Signed-off-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: ksz9477: setup SPI modeChristian Eggers2020-11-251-0/+6
| | | | | | | | | | | | | | This should be done in the device driver instead of the device tree. Signed-off-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: microchip: support for "ethernet-ports" nodeChristian Eggers2020-11-251-1/+3
| | | | | | | | | | | | | | | | | | The dsa.yaml device tree binding allows "ethernet-ports" (preferred) and "ports". Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: hellcreek: Don't print error message on deferKurt Kanzenbach2020-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | When DSA is not loaded when the driver is probed an error message is printed. But, that's not really an error, just a defer. Use dev_err_probe() instead. Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge https://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2020-11-195-10/+94
|\| | | | | | | Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: dsa: mv88e6xxx: Wait for EEPROM done after HW resetAndrew Lunn2020-11-183-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When the switch is hardware reset, it reads the contents of the EEPROM. This can contain instructions for programming values into registers and to perform waits between such programming. Reading the EEPROM can take longer than the 100ms mv88e6xxx_hardware_reset() waits after deasserting the reset GPIO. So poll the EEPROM done bit to ensure it is complete. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ruslan Sushko <rus@sushko.dev> Link: https://lore.kernel.org/r/20201116164301.977661-1-rus@sushko.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: lantiq: Wait for the GPHY firmware to be readyMartin Blumenstingl2020-11-161-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A user reports (slightly shortened from the original message): libphy: lantiq,xrx200-mdio: probed mdio_bus 1e108000.switch-mii: MDIO device at address 17 is missing. gswip 1e108000.switch lan: no phy at 2 gswip 1e108000.switch lan: failed to connect to port 2: -19 lantiq,xrx200-net 1e10b308.eth eth0: error -19 setting up slave phy This is a single-port board using the internal Fast Ethernet PHY. The user reports that switching to PHY scanning instead of configuring the PHY within device-tree works around this issue. The documentation for the standalone variant of the PHY11G (which is probably very similar to what is used inside the xRX200 SoCs but having the firmware burnt onto that standalone chip in the factory) states that the PHY needs 300ms to be ready for MDIO communication after releasing the reset. Add a 300ms delay after initializing all GPHYs to ensure that the GPHY firmware had enough time to initialize and to appear on the MDIO bus. Unfortunately there is no (known) documentation on what the minimum time to wait after releasing the reset on an internal PHY so play safe and take the one for the external variant. Only wait after the last GPHY firmware is loaded to not slow down the initialization too much ( xRX200 has two GPHYs but newer SoCs have at least three GPHYs). Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20201115165757.552641-1-martin.blumenstingl@googlemail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: dsa: mv88e6xxx: Avoid VTU corruption on 6097Tobias Waldekranz2020-11-141-10/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As soon as you add the second port to a VLAN, all other port membership configuration is overwritten with zeroes. The HW interprets this as all ports being "unmodified members" of the VLAN. In the simple case when all ports belong to the same VLAN, switching will still work. But using multiple VLANs or trying to set multiple ports as tagged members will not work. On the 6352, doing a VTU GetNext op, followed by an STU GetNext op will leave you with both the member- and state- data in the VTU/STU data registers. But on the 6097 (which uses the same implementation), the STU GetNext will override the information gathered from the VTU GetNext. Separate the two stages, parsing the result of the VTU GetNext before doing the STU GetNext. We opt to update the existing implementation for all applicable chips, as opposed to creating a separate callback for 6097, because although the previous implementation did work for (at least) 6352, the datasheet does not mention the masking behavior. Fixes: ef6fcea37f01 ("net: dsa: mv88e6xxx: get STU entry on VTU GetNext") Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Link: https://lore.kernel.org/r/20201112114335.27371-1-tobias@waldekranz.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge https://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2020-11-121-1/+3
|\| | | | | | | Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-24 09:14:45 +0000