summaryrefslogtreecommitdiffstats
path: root/drivers/net/dsa/mv88e6xxx (follow)
Commit message (Collapse)AuthorAgeFilesLines
* net: dsa: mv88e6xxx: remove wait and update routinesVivien Didelot2019-08-127-67/+22
| | | | | | | | | | | | | | Now that we have proper Wait Bit and Wait Mask routines, remove the unused mv88e6xxx_wait routine and its Global 1 and Global 2 variants. The indirect tables such as the Device Mapping Table or Priority Override Table make use of an Update bit to distinguish reading (0) from writing (1) operations. After a write operation occurs, the bit self clears right away so there's no need to wait on it. Thus keep things simple and remove the mv88e6xxx_update helper as well. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: wait for AVB Busy bitVivien Didelot2019-08-121-2/+27
| | | | | | | | | | The AVB is not an indirect table using an Update bit, but a unit using a Busy bit. This means that we must ensure that this bit is cleared before setting it and wait until it gets cleared again after writing an operation. Reflect that. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: introduce wait bit routineVivien Didelot2019-08-128-50/+73
| | | | | | | | | | | | | | | Many portions of the driver need to wait until a given bit is set or cleared. Some busses even have a specific implementation for this operation. In preparation for such variant, implement a generic Wait Bit routine that can be used by the driver core functions. This allows us to get rid of the custom implementations we may find in the driver. Note that for the EEPROM bits, BUSY and RUNNING bits are independent, thus it is more efficient to wait independently for each bit instead of waiting for their mask. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: introduce wait mask routineVivien Didelot2019-08-124-52/+41
| | | | | | | | | | | | | The current mv88e6xxx_wait routine is used to wait for a given mask to be cleared to zero. However in some cases, the driver may have to wait for a given mask to be of a certain non-zero value. Thus provide a generic wait mask routine that will be used to implement the current mv88e6xxx_wait function, and use it to wait for 88E6185 PPU states. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: wait for 88E6185 PPU disabledVivien Didelot2019-08-121-1/+1
| | | | | | | | | | | The PPU state of 88E6185 can be either "Disabled at Reset" or "Disabled after Initialization". Because we intentionally clear the PPU Enabled bit before checking its state, it is safe to wait for the MV88E6185_G1_STS_PPU_STATE_DISABLED state explicitly instead of waiting for any state different than MV88E6185_G1_STS_PPU_STATE_POLLING. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller2019-08-071-27/+2
|\ | | | | | | | | | | Just minor overlapping changes in the conflicts here. Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: drop adjust_link to enabled phylinkHubert Feurstein2019-08-051-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have to drop the adjust_link callback in order to finally migrate to phylink. Otherwise we get the following warning during startup: "mv88e6xxx 2188000.ethernet-1:10: Using legacy PHYLIB callbacks. Please migrate to PHYLINK!" The warning is generated in the function dsa_port_link_register_of in dsa/port.c: int dsa_port_link_register_of(struct dsa_port *dp) { struct dsa_switch *ds = dp->ds; if (!ds->ops->adjust_link) return dsa_port_phylink_register(dp); dev_warn(ds->dev, "Using legacy PHYLIB callbacks. Please migrate to PHYLINK!\n"); [...] } Signed-off-by: Hubert Feurstein <h.feurstein@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: mv88e6xxx: use link-down-define instead of plain valueHubert Feurstein2019-07-301-1/+1
| | | | | | | | | | | | | | | | Using the define here makes the code more expressive. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: chip: Add of_node_put() before returnNishka Dasgupta2019-07-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | Each iteration of for_each_available_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: add PTP support for MV88E6250 familyHubert Feurstein2019-08-034-11/+78
| | | | | | | | | | | | | | | | | | This adds PTP support for the MV88E6250 family. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: order ptp structs numerically ascendingHubert Feurstein2019-08-032-18/+18
| | | | | | | | | | | | | | | | As it is done for all the other structs within this driver. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: setup message port is not supported in the 6250 familiyHubert Feurstein2019-08-032-3/+32
| | | | | | | | | | | | | | | | | | The MV88E6250 family doesn't support the MV88E6XXX_PORT_CTL1_MESSAGE_PORT bit. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: introduce invalid_port_mask in mv88e6xxx_infoHubert Feurstein2019-08-032-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | With this it is possible to mark certain chip ports as invalid. This is required for example for the MV88E6220 (which is in general a MV88E6250 with 7 ports) but the ports 2-4 are not routed to pins. If a user configures an invalid port, an error is returned. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: add support for MV88E6220Hubert Feurstein2019-08-033-1/+28
| | | | | | | | | | | | | | | | | | The MV88E6220 is almost the same as MV88E6250 except that the ports 2-4 are not routed to pins. So the usable ports are 0, 1, 5 and 6. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: call vtu_getnext directly in vlan_addVivien Didelot2019-08-011-49/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wrapping mv88e6xxx_vtu_getnext makes the code less easy to read and _mv88e6xxx_port_vlan_add is the only function requiring the preparation of a new VLAN entry. To simplify things up, remove the mv88e6xxx_vtu_get wrapper and explicit the VLAN lookup in _mv88e6xxx_port_vlan_add. This rework also avoids programming the broadcast entries again when changing a port's membership, e.g. from tagged to untagged. At the same time, rename the helper using an old underscore convention. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: call vtu_getnext directly in vlan_delVivien Didelot2019-08-011-6/+15
| | | | | | | | | | | | | | | | | | | | | | Wrapping mv88e6xxx_vtu_getnext makes the code less easy to read. Explicit the call to mv88e6xxx_vtu_getnext in _mv88e6xxx_port_vlan_del and the return value expected by switchdev in case of software VLANs. At the same time, rename the helper using an old underscore convention. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: call vtu_getnext directly in db load/purgeVivien Didelot2019-08-011-9/+22
| | | | | | | | | | | | | | | | | | | | mv88e6xxx_vtu_getnext is simple enough to call it directly in the mv88e6xxx_port_db_load_purge function and explicit the return code expected by switchdev for software VLANs when an hardware VLAN does not exist. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: explicit entry passed to vtu_getnextVivien Didelot2019-08-011-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | mv88e6xxx_vtu_getnext interprets two members from the input mv88e6xxx_vtu_entry structure: the (excluded) vid member to start the iteration from, and the valid argument specifying whether the VID must be written or not (only required once at the start of a loop). Explicit the assignation of these two fields right before calling mv88e6xxx_vtu_getnext, as it is done in the mv88e6xxx_vtu_get wrapper. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: lock mutex in vlan_prepareVivien Didelot2019-08-011-12/+6
| | | | | | | | | | | | | | | | | | Lock the mutex in the mv88e6xxx_port_vlan_prepare function called by the DSA stack, instead of doing it in the internal mv88e6xxx_port_check_hw_vlan helper. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: avoid some redundant vtu load/purge operationsRasmus Villemoes2019-07-291-1/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have an ERPS (Ethernet Ring Protection Switching) setup involving mv88e6250 switches which we're in the process of switching to a BSP based on the mainline driver. Breaking any link in the ring works as expected, with the ring reconfiguring itself quickly and traffic continuing with almost no noticable drops. However, when plugging back the cable, we see 5+ second stalls. This has been tracked down to the userspace application in charge of the protocol missing a few CCM messages on the good link (the one that was not unplugged), causing it to broadcast a "signal fail". That message eventually reaches its link partner, which responds by blocking the port. Meanwhile, the first node has continued to block the port with the just plugged-in cable, breaking the network. And the reason for those missing CCM messages has in turn been tracked down to the VTU apparently being too busy servicing load/purge operations that the normal lookups are delayed. Initial state, the link between C and D is blocked in software. _____________________ / \ | | A ----- B ----- C *---- D Unplug the cable between C and D. _____________________ / \ | | A ----- B ----- C * * D Reestablish the link between C and D. _____________________ / \ | | A ----- B ----- C *---- D Somehow, enough VTU/ATU operations happen inside C that prevents the application from receving the CCM messages from B in a timely manner, so a Signal Fail message is sent by C. When B receives that, it responds by blocking its port. _____________________ / \ | | A ----- B *---* C *---- D Very shortly after this, the signal fail condition clears on the BC link (some CCM messages finally make it through), so C unblocks the port. However, a guard timer inside B prevents it from removing the blocking before 5 seconds have elapsed. It is not unlikely that our userspace ERPS implementation could be smarter and/or is simply buggy. However, this patch fixes the symptoms we see, and is a small optimization that should not break anything (knock wood). The idea is simply to avoid doing an VTU load of an entry identical to the one already present. To do that, we need to know whether mv88e6xxx_vtu_get() actually found an existing entry, or has just prepared a struct mv88e6xxx_vtu_entry for us to load. To that end, let vlan->valid be an output parameter. The other two callers of mv88e6xxx_vtu_get() are not affected by this patch since they pass new=false. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2019-07-091-0/+2
|\ | | | | | | | | | | Two cases of overlapping changes, nothing fancy. Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: wait after reset deactivationBaruch Siach2019-06-291-0/+2
| | | | | | | | | | | | | | | | | | Add a 1ms delay after reset deactivation. Otherwise the chip returns bogus ID value. This is observed with 88E6390 (Peridot) chip. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: introduce helpers for handling chip->reg_lockRasmus Villemoes2019-06-239-148/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a no-op that simply moves all locking and unlocking of ->reg_lock into trivial helpers. I did that to be able to easily add some ad hoc instrumentation to those helpers to get some information on contention and hold times of the mutex. Perhaps others want to do something similar at some point, so this frees them from doing the 'sed -i' yoga, and have a much smaller 'git diff' while fiddling. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2019-06-221-1/+1
|\| | | | | | | | | | | Minor SPDX change conflict. Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: mv88e6xxx: fix shift of FID bits in mv88e6185_g1_vtu_loadpurge()Rasmus Villemoes2019-06-191-1/+1
| | | | | | | | | | | | | | | | | | The comment is correct, but the code ends up moving the bits four places too far, into the VTUOp field. Fixes: 11ea809f1a74 (net: dsa: mv88e6xxx: support 256 databases) Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: fix shift of FID bits in mv88e6250_g1_vtu_loadpurge()Rasmus Villemoes2019-06-191-1/+1
| | | | | | | | | | | | | | | | | | The comment is correct, but the code ends up moving the bits four places too far, into the VTUOp field. Fixes: bec8e5725281 (net: dsa: mv88e6xxx: implement vtu_getnext and vtu_loadpurge for mv88e6250) Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Revert "net: dsa: mv88e6xxx: do not flood CPU with unknown multicast"David S. Miller2019-06-151-5/+7
| | | | | | | | | | | | | | | | This reverts commit 422efd032775757c41e9579facd9656a87bf4f00. It breaks ipv6. Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: do not flood CPU with unknown multicastVivien Didelot2019-06-151-7/+5
| | | | | | | | | | | | | | | | | | | | The DSA ports must flood unknown unicast and multicast, but the switch must not flood the CPU ports with unknown multicast, as this results in a lot of undesirable traffic that the network stack needs to filter in software. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: dsa: mv88e6xxx: lock mutex in port_fdb_dumpVivien Didelot2019-06-121-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | During a port FDB dump operation, the mutex protecting the concurrent access to the switch registers is currently held by the internal mv88e6xxx_port_db_dump and mv88e6xxx_port_db_dump_fid helpers. It must be held at the higher level in mv88e6xxx_port_fdb_dump which is called directly by DSA through ds->ops->port_fdb_dump. Fix this. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2019-06-0722-111/+23
|\| | | | | | | | | | | | | Some ISDN files that got removed in net-next had some changes done in mainline, take the removals. Signed-off-by: David S. Miller <davem@davemloft.net>
| * Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds2019-06-071-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull networking fixes from David Miller: 1) Free AF_PACKET po->rollover properly, from Willem de Bruijn. 2) Read SFP eeprom in max 16 byte increments to avoid problems with some SFP modules, from Russell King. 3) Fix UDP socket lookup wrt. VRF, from Tim Beale. 4) Handle route invalidation properly in s390 qeth driver, from Julian Wiedmann. 5) Memory leak on unload in RDS, from Zhu Yanjun. 6) sctp_process_init leak, from Neil HOrman. 7) Fix fib_rules rule insertion semantic change that broke Android, from Hangbin Liu. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (33 commits) pktgen: do not sleep with the thread lock held. net: mvpp2: Use strscpy to handle stat strings net: rds: fix memory leak in rds_ib_flush_mr_pool ipv6: fix EFAULT on sendto with icmpv6 and hdrincl ipv6: use READ_ONCE() for inet->hdrincl as in ipv4 Revert "fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied" net: aquantia: fix wol configuration not applied sometimes ethtool: fix potential userspace buffer overflow Fix memory leak in sctp_process_init net: rds: fix memory leak when unload rds_rdma ipv6: fix the check before getting the cookie in rt6_get_cookie ipv4: not do cache for local delivery if bc_forwarding is enabled s390/qeth: handle error when updating TX queue count s390/qeth: fix VLAN attribute in bridge_hostnotify udev event s390/qeth: check dst entry before use s390/qeth: handle limited IPv4 broadcast in L3 TX path net: fix indirect calls helpers for ptype list hooks. net: ipvlan: Fix ipvlan device tso disabled while NETIF_F_IP_CSUM is set udp: only choose unbound UDP socket for multicast when not in a VRF net/tls: replace the sleeping lock around RX resync with a bit lock ...
| | * net: dsa: mv88e6xxx: avoid error message on remove from VLAN 0Nikita Yushchenko2019-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When non-bridged, non-vlan'ed mv88e6xxx port is moving down, error message is logged: failed to kill vid 0081/0 for device eth_cu_1000_4 This is caused by call from __vlan_vid_del() with vin set to zero, over call chain this results into _mv88e6xxx_port_vlan_del() called with vid=0, and mv88e6xxx_vtu_get() called from there returns -EINVAL. On symmetric path moving port up, call goes through mv88e6xxx_port_vlan_prepare() that calls mv88e6xxx_port_check_hw_vlan() that returns -EOPNOTSUPP for zero vid. This patch changes mv88e6xxx_vtu_get() to also return -EOPNOTSUPP for zero vid, then this error code is explicitly cleared in dsa_slave_vlan_rx_kill_vid() and error message is no longer logged. Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | Merge tag 'spdx-5.2-rc3-1' of ↵Linus Torvalds2019-05-3122-110/+22
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull yet more SPDX updates from Greg KH: "Here is another set of reviewed patches that adds SPDX tags to different kernel files, based on a set of rules that are being used to parse the comments to try to determine that the license of the file is "GPL-2.0-or-later" or "GPL-2.0-only". Only the "obvious" versions of these matches are included here, a number of "non-obvious" variants of text have been found but those have been postponed for later review and analysis. There is also a patch in here to add the proper SPDX header to a bunch of Kbuild files that we have missed in the past due to new files being added and forgetting that Kbuild uses two different file names for Makefiles. This issue was reported by the Kbuild maintainer. These patches have been out for review on the linux-spdx@vger mailing list, and while they were created by automatic tools, they were hand-verified by a bunch of different people, all whom names are on the patches are reviewers" * tag 'spdx-5.2-rc3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (82 commits) treewide: Add SPDX license identifier - Kbuild treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 225 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 224 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 223 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 222 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 221 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 220 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 218 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 217 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 216 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 215 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 214 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 213 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 211 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 210 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 209 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 207 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 206 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 203 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 201 ...
| | * treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Thomas Gleixner2019-05-3022-110/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | | net: dsa: mv88e6xxx: refactor mv88e6352_g1_resetRasmus Villemoes2019-06-051-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new mv88e6250_g1_reset() is identical to mv88e6352_g1_reset() except for the call of mv88e6352_g1_wait_ppu_polling(), so refactor the 6352 version in term of the 6250 one. No functional change. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: add support for mv88e6250Rasmus Villemoes2019-06-055-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the Marvell 88E6250. I've checked that each member in the ops-structure makes sense, and basic switchdev functionality works fine. It uses the new dual_chip option, and since its port registers start at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to introduce a new compatible string in order for the auto-identification in mv88e6xxx_detect() to work. The chip has four per port 16-bits statistics registers, two of which correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should this be easy...). Wiring up those four statistics seems to require introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones. The chip does have ptp support, and the existing mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work out-of-the-box, but for simplicity (and lack of testing) I'm eliding this. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: implement port_link_state for mv88e6250Rasmus Villemoes2019-06-052-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mv88e6250 has a rather different way of reporting the link, speed and duplex status. A simple difference is that the link bit is bit 12 rather than bit 11 of the port status register. It gets more complicated for speed and duplex, which do not have separate fields. Instead, there's a four-bit PortMode field, and decoding that depends on whether it's a phy or mii port. For the phy ports, only four of the 16 values have defined meaning; the rest are called "reserved", so returning {SPEED,DUPLEX}_UNKNOWN seems reasonable. For the mii ports, most possible values are documented (0x3 and 0x5 are reserved), but I'm unable to make sense of them all. Since the bits simply reflect the Px_MODE[3:0] configuration pins, just support the subset that I'm certain about. Support for other setups can be added later. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: implement port_set_speed for mv88e6250Rasmus Villemoes2019-06-052-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The data sheet also mentions the possibility of selecting 200 Mbps for the MII ports (ports 5 and 6) by setting the ForceSpd field to 0x2 (aka MV88E6065_PORT_MAC_CTL_SPEED_200). However, there's a note that "actual speed is determined by bit 8 above", and flipping back a page, one finds that bits 13:8 are reserved... So without further information on what bit 8 means, let's stick to supporting just 10 and 100 Mbps on all ports. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: implement watchdog_ops for mv88e6250Rasmus Villemoes2019-06-052-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MV88E6352_G2_WDOG_CTL_* bits almost, but not quite, describe the watchdog control register on the mv88e6250. Among those actually referenced in the code, only QC_ENABLE differs (bit 6 rather than bit 5). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: implement vtu_getnext and vtu_loadpurge for mv88e6250Rasmus Villemoes2019-06-052-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are almost identical to the 6185 variants, but have fewer bits for the FID. Bit 10 of the VTU_OP register (offset 0x05) is the VidPolicy bit, which one should probably preserve in mv88e6xxx_g1_vtu_op(), instead of always writing a 0. However, on the 6352 family, that bit is located at bit 12 in the VTU FID register (offset 0x02), and is always unconditionally cleared by the mv88e6xxx_g1_vtu_fid_write() function. Since nothing in the existing driver seems to know or care about that bit, it seems reasonable to not add the boilerplate to preserve it for the 6250 (which would require adding a chip-specific vtu_op function, or adding chip-quirks to the existing one). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: prepare mv88e6xxx_g1_atu_op() for the mv88e6250Rasmus Villemoes2019-06-051-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the currently supported chips have .num_databases either 256 or 4096, so this patch does not change behaviour for any of those. The mv88e6250, however, has .num_databases == 64, and it does not put the upper two bits in ATU control 13:12, but rather in ATU Operation 9:8. So change the logic to prepare for supporting mv88e6250. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: introduce support for two chips using direct smi addressingRasmus Villemoes2019-06-052-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 88e6250 (as well as 6220, 6071, 6070, 6020) do not support multi-chip (indirect) addressing. However, one can still have two of them on the same mdio bus, since the device only uses 16 of the 32 possible addresses, either addresses 0x00-0x0F or 0x10-0x1F depending on the ADDR4 pin at reset [since ADDR4 is internally pulled high, the latter is the default]. In order to prepare for supporting the 88e6250 and friends, introduce mv88e6xxx_info::dual_chip to allow having a non-zero sw_addr while still using direct addressing. Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: add mv88e6250_g1_ieee_pri_mapRasmus Villemoes2019-06-052-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Quite a few of the existing supported chips that use mv88e6085_g1_ieee_pri_map as ->ieee_pri_map (including, incidentally, mv88e6085 itself) actually have a reset value of 0xfa50 in the G1_IEEE_PRI register. The data sheet for the mv88e6095, however, does describe a reset value of 0xfa41. So rather than changing the value in the existing callback, introduce a new variant with the 0xfa50 value. That will be used by the upcoming mv88e6250, and existing chips can be switched over one by one, preferably double-checking both the data sheet and actual hardware in each case - if anybody actually feels this is important enough to care. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: make mv88e6xxx_g1_stats_wait staticRasmus Villemoes2019-06-032-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | mv88e6xxx_g1_stats_wait has no users outside global1.c, so make it static. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: dsa: mv88e6xxx: fix comments and macro names in mv88e6390_g1_mgmt_rsvd2cpuRasmus Villemoes2019-06-032-12/+12
|/ / | | | | | | | | | | | | | | | | | | The macros have an extraneous '800' (after 0180C2 there should be just six nibbles, with X representing one), while the comments have interchanged c2 and 80 and an extra :00. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* / net: dsa: mv88e6xxx: fix handling of upper half of STATS_TYPE_PORTRasmus Villemoes2019-05-301-1/+1
|/ | | | | | | | | | | Currently, the upper half of a 4-byte STATS_TYPE_PORT statistic ends up in bits 47:32 of the return value, instead of bits 31:16 as they should. Fixes: 6e46e2d821bb ("net: dsa: mv88e6xxx: Fix u64 statistics") Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner2019-05-211-0/+1
| | | | | | | | | | | | | | Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* net: dsa: mv88e6xxx: refine SMI supportVivien Didelot2019-05-065-170/+219
| | | | | | | | | | | | | | | The Marvell SOHO switches have several ways to access the internal registers. One of them being the System Management Interface (SMI), using the MDC and MDIO pins, with direct and indirect variants. In preparation for adding support for other register accesses, move the SMI code into its own files. At the same time, refine the code to make it clear that the indirect variant is implemented using the direct variant accessing only two registers for command and data. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: Pass interrupt number in platform dataAndrew Lunn2019-05-041-4/+9
| | | | | | | | | Allow an interrupt number to be passed in the platform data. The driver will then use it if not zero, otherwise it will poll for interrupts. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa :mv88e6xxx: Disable unused portsAndrew Lunn2019-05-041-1/+11
| | | | | | | | | | | | | | If the NO_CPU strap is set, the switch starts in 'dumb hub' mode, with all ports enable. Ports which are then actively used are reconfigured as required when the driver starts. However unused ports are left alone. Change this to disable them, and turn off any SERDES interface. This could save some power and so reduce the temperature a bit. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-23 11:19:43 +0100