summaryrefslogtreecommitdiff
path: root/drivers/net/dsa/mv88e6xxx/chip.c
AgeCommit message (Collapse)AuthorFilesLines
2022-06-14net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_registerMiaoqian Lin1-0/+1
[ Upstream commit 02ded5a173619b11728b8bf75a3fd995a2c1ff28 ] of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak. Fixes: a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-15net: dsa: mv88e6xxx: Enable port policy support on 6097Tobias Waldekranz1-0/+1
[ Upstream commit 585d42bb57bb358d48906660a8de273b078810b1 ] This chip has support for the same per-port policy actions found in later versions of LinkStreet devices. Fixes: f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-28net: dsa: mv88e6xxx: use correct .stats_set_histogram() on TopazMarek Behún1-2/+2
commit 11527f3c4725640e6c40a2b7654e303f45e82a6c upstream. Commit 40cff8fca9e3 ("net: dsa: mv88e6xxx: Fix stats histogram mode") introduced wrong .stats_set_histogram() method for Topaz family. The Peridot method should be used instead. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 40cff8fca9e3 ("net: dsa: mv88e6xxx: Fix stats histogram mode") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: dsa: mv88e6xxx: enable .rmu_disable() on TopazMarek Behún1-0/+2
commit 3709488790022c85720f991bff50d48ed5a36e6a upstream. Commit 9e5baf9b36367 ("net: dsa: mv88e6xxx: add RMU disable op") introduced .rmu_disable() method with implementation for several models, but forgot to add Topaz, which can use the Peridot implementation. Use the Peridot implementation of .rmu_disable() on Topaz. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 9e5baf9b36367 ("net: dsa: mv88e6xxx: add RMU disable op") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-25net: dsa: mv88e6xxx: enable .port_set_policy() on TopazMarek Behún1-0/+2
commit 7da467d82d1ed4fb317aff836f99709169e73f10 upstream. Commit f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") introduced .port_set_policy() method with implementation for several models, but forgot to add Topaz, which can use the 6352 implementation. Use the 6352 implementation of .port_set_policy() on Topaz. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-21net: phy: marvell: fix detection of PHY on Topaz switchesPali Rohár1-17/+13
commit 1fe976d308acb6374c899a4ee8025a0a016e453e upstream. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-10net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_addDENG Qingfang1-1/+5
commit f72f2fb8fb6be095b98af5d740ac50cffd0b0cae upstream. Having multiple destination ports for a unicast address does not make sense. Make port_db_load_purge override existent unicast portvec instead of adding a new port bit. Fixes: 884729399260 ("net: dsa: mv88e6xxx: handle multiple ports in ATU") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20210130134334.10243-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-02net: dsa: mv88e6xxx: Wait for EEPROM done after HW resetAndrew Lunn1-0/+2
[ Upstream commit a3dcb3e7e70c72a68a79b30fc3a3adad5612731c ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-19net: dsa: mv88e6xxx: MV88E6097 does not support jumbo configurationChris Packham1-1/+0
[ Upstream commit 0f3c66a3c7b4e8b9f654b3c998e9674376a51b0f ] The MV88E6097 chip does not support configuring jumbo frames. Prior to commit 5f4366660d65 only the 6352, 6351, 6165 and 6320 chips configured jumbo mode. The refactor accidentally added the function for the 6097. Remove the erroneous function pointer assignment. Fixes: 5f4366660d65 ("net: dsa: mv88e6xxx: Refactor setting of jumbo frames") Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-10net: dsa: mv88e6xxx: add RXNFC supportVivien Didelot1-0/+213
Implement the .get_rxnfc and .set_rxnfc DSA operations to configure a port's Layer 2 Policy Control List (PCL) via ethtool. Currently only dropping frames based on MAC Destination or Source Address (including the option VLAN parameter) is supported. Signed-off-by: Vivien Didelot <vivien.didelot@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>
2019-09-10net: dsa: mv88e6xxx: introduce .port_set_policyVivien Didelot1-0/+9
Introduce a new .port_set_policy operation to configure a port's Policy Control List, based on mapping such as DA, SA, Etype and so on. Models similar to 88E6352 and 88E6390 are supported at the moment. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-10net: dsa: mv88e6xxx: complete ATU state definitionsVivien Didelot1-11/+8
Marvell has different values for the state of a MAC address, depending on its multicast bit. This patch completes the definitions for these states. At the same time, use 0 which is intuitive enough and simplifies the code a bit, instead of the UC or MC unused value. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-01net: dsa: mv88e6xxx: centralize SERDES IRQ handlingVivien Didelot1-27/+69
The .serdes_irq_setup are all following the same steps: get the SERDES lane, get the IRQ mapping, request the IRQ, then enable it. So do the .serdes_irq_free implementations: get the SERDES lane, disable the IRQ, then free it. This patch removes these operations in favor of generic functions. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-01net: dsa: mv88e6xxx: introduce .serdes_irq_statusVivien Didelot1-0/+11
Introduce a new .serdes_irq_status operation to prepare the abstraction of IRQ thread from the SERDES IRQ setup code. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-01net: dsa: mv88e6xxx: introduce .serdes_irq_enableVivien Didelot1-0/+11
Introduce a new .serdes_irq_enable operation to prepare the abstraction of IRQ enabling from the SERDES IRQ setup code. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-01net: dsa: mv88e6xxx: pass lane to .serdes_powerVivien Didelot1-3/+5
Now the first step of all .serdes_power implementations is getting the lane mapping. Since we have an operation for that, call it in the wrapper and pass the lane down to the .serdes_power operation. This also allows to avoid querying the SERDES lane twice in mv88e6xxx_port_set_cmode. At the same time provide mv88e6xxx_serdes_power_{up,down} helpers and prefer up/down instead of on/off as in the documentation. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-01net: dsa: mv88e6xxx: implement mv88e6352_serdes_get_laneVivien Didelot1-0/+4
Even though 88E6352 has no dedicated lane for SERDES interfaces, it uses a similar code as the other .serdes_get_lane implementations to check the port's CMODE and ensure that SERDES operations are doable. For consistency, implement mv88e6352_serdes_get_lane for the 88E6352 and similar switches which simply returns an unused 0xff lane address. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-01net: dsa: mv88e6xxx: introduce .serdes_irq_mappingVivien Didelot1-0/+11
Introduce a new .serdes_irq_mapping operation to prepare the abstraction of IRQ mapping from the SERDES IRQ setup code. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-30net: dsa: mv88e6xxx: fix freeing unused SERDES IRQVivien Didelot1-1/+2
Now mv88e6xxx does not enable its ports at setup itself and let the DSA core handle this, unused ports are disabled without being powered on first. While that is expected, the SERDES powering code was assuming that a port was already set up before powering it down, resulting in freeing an unused IRQ. The patch fixes this assumption. Fixes: b759f528ca3d ("net: dsa: mv88e6xxx: enable SERDES after setup") Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Marek Behún <marek.behun@nic.cz> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-30net: dsa: mv88e6xxx: keep CMODE writable code privateVivien Didelot1-8/+0
This is a follow-up patch for commit 7a3007d22e8d ("net: dsa: mv88e6xxx: fully support SERDES on Topaz family"). Since .port_set_cmode is only called from mv88e6xxx_port_setup_mac and mv88e6xxx_phylink_mac_config, it is fine to keep this "make writable" code private to the mv88e6341_port_set_cmode implementation, instead of adding yet another operation to the switch info structure. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-28net: dsa: mv88e6xxx: fully support SERDES on Topaz familyMarek Behún1-0/+14
Currently we support SERDES on the Topaz family in a limited way: no IRQs and the cmode is not writable, thus the mode is determined by strapping pins. Marvell's examples though show how to make cmode writable on port 5 and support SGMII autonegotiation. It is done by writing hidden registers, for which we already have code. This patch adds support for making the cmode for the SERDES port writable on the Topaz family, via a new chip operation, .port_set_cmode_writable, which is called from mv88e6xxx_port_setup_mac just before .port_set_cmode. SERDES IRQs are also enabled for Topaz. Tested on Turris Mox. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-28net: dsa: mv88e6xxx: simplify SERDES code for Topaz and PeridotMarek Behún1-8/+10
By adding an additional serdes_get_lane implementation (for Topaz), we can merge the implementations of other SERDES functions (powering and IRQs). We can skip checking port numbers, since the serdes_get_lane() methods inform if there is no lane on a port or if the lane cannot be used for given cmode. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-28net: dsa: mv88e6xxx: create serdes_get_lane chip operationMarek Behún1-0/+6
Create a serdes_get_lane() method in the mv88e6xxx operations structure. Use it instead of calling the different implementations. Also change the methods so that their return value is used only for error. The lane number is put into a place referred to by a pointer given as argument. If the port does not have a lane, return -ENODEV. Lanes are phy addresses, so use u8 as their type. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-28net: dsa: mv88e6xxx: update code operating on hidden registersMarek Behún1-56/+2
This patch moves the functions operating on the hidden debug registers into it's own file, port_hidden.c. The functions prefix is renamed from mv88e6390_hidden_ to mv88e6xxx_port_hidden_, to be consistent with the rest of this driver. The macros are prefixed with MV88E6XXX_ prefix, and are changed not to use the BIT() macro nor bit shifts, since the rest of the port.h file does not use it. We also add the support for setting the Block Address field when operating hidden registers. Marvell's mdio examples for SERDES settings on Topaz use Block Address 0x7 when reading/writing hidden registers, and although the specification says that block must be set to 0xf, those settings are reachable only with Block Address 0x7. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-20net: dsa: mv88e6xxx: wrap SERDES IRQ in power functionVivien Didelot1-13/+19
Now that mv88e6xxx_serdes_power is only called after driver setup, we can wrap the SERDES IRQ code directly within it for clarity. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-20net: dsa: mv88e6xxx: enable SERDES after setupVivien Didelot1-31/+4
SERDES is powered on for CPU and DSA ports and powered down for unused ports at setup time. But now that DSA calls mv88e6xxx_port_enable and mv88e6xxx_port_disable for all ports, the SERDES power can now be handled after setup inconditionally for all ports. Using the port enable and disable callbacks also have the benefit to handle the SERDES IRQ for non user ports as well. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-20net: dsa: mv88e6xxx: do not change STP state on port disablingVivien Didelot1-3/+0
When disabling a port, that is not for the driver to decide what to do with the STP state. This is already handled by the DSA layer. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-20net: dsa: do not enable or disable non user portsVivien Didelot1-0/+6
The .port_enable and .port_disable operations are currently only called for user ports, hence assuming they have a slave device. In preparation for using these operations for other port types as well, simply guard all implementations against non user ports and return directly in such case. Note that bcm_sf2_sw_suspend() currently calls bcm_sf2_port_disable() (and thus b53_disable_port()) against the user and CPU ports, so do not guards those functions. They will be called for unused ports in the future, but that was expected by those drivers anyway. Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-16net: dsa: mv88e6xxx: check for mode change in port_setup_macMarek Behún1-1/+3
The mv88e6xxx_port_setup_mac checks if the requested MAC settings are different from the current ones, and if not, does nothing (since chaning them requires putting the link down). In this check it only looks if the triplet [link, speed, duplex] is being changed. This patch adds support to also check if the mode parameter (of type phy_interface_t) is requested to be changed. The current mode is computed by the ->port_link_state() method, and if it is different from PHY_INTERFACE_MODE_NA, we check for equality with the requested mode. In the implementations of the mv88e6250_port_link_state() method we set the current mode to PHY_INTERFACE_MODE_NA - so the code does not check for mode change on 6250. In the mv88e6352_port_link_state() method, we use the cached cmode of the port to determine the mode as phy_interface_t (and if it is not enough, eg. for RGMII, we also look at the port control register for RX/TX timings). Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-12net: dsa: mv88e6xxx: remove wait and update routinesVivien Didelot1-22/+0
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>
2019-08-12net: dsa: mv88e6xxx: introduce wait bit routineVivien Didelot1-2/+12
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>
2019-08-12net: dsa: mv88e6xxx: introduce wait mask routineVivien Didelot1-18/+24
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>
2019-08-07Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller1-27/+2
Just minor overlapping changes in the conflicts here. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-05net: dsa: mv88e6xxx: drop adjust_link to enabled phylinkHubert Feurstein1-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>
2019-08-03net: dsa: mv88e6xxx: add PTP support for MV88E6250 familyHubert Feurstein1-0/+4
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>
2019-08-03net: dsa: mv88e6xxx: setup message port is not supported in the 6250 familiyHubert Feurstein1-3/+31
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>
2019-08-03net: dsa: mv88e6xxx: introduce invalid_port_mask in mv88e6xxx_infoHubert Feurstein1-0/+9
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>
2019-08-03net: dsa: mv88e6xxx: add support for MV88E6220Hubert Feurstein1-0/+25
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>
2019-08-01net: dsa: mv88e6xxx: call vtu_getnext directly in vlan_addVivien Didelot1-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>
2019-08-01net: dsa: mv88e6xxx: call vtu_getnext directly in vlan_delVivien Didelot1-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>
2019-08-01net: dsa: mv88e6xxx: call vtu_getnext directly in db load/purgeVivien Didelot1-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>
2019-08-01net: dsa: mv88e6xxx: explicit entry passed to vtu_getnextVivien Didelot1-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>
2019-08-01net: dsa: mv88e6xxx: lock mutex in vlan_prepareVivien Didelot1-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>
2019-07-30net: dsa: mv88e6xxx: use link-down-define instead of plain valueHubert Feurstein1-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>
2019-07-29net: dsa: mv88e6xxx: avoid some redundant vtu load/purge operationsRasmus Villemoes1-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>
2019-07-23net: dsa: mv88e6xxx: chip: Add of_node_put() before returnNishka Dasgupta1-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>
2019-07-09Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-0/+2
Two cases of overlapping changes, nothing fancy. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-29net: dsa: mv88e6xxx: wait after reset deactivationBaruch Siach1-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>
2019-06-23net: dsa: mv88e6xxx: introduce helpers for handling chip->reg_lockRasmus Villemoes1-88/+88
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>
2019-06-15Revert "net: dsa: mv88e6xxx: do not flood CPU with unknown multicast"David S. Miller1-5/+7
This reverts commit 422efd032775757c41e9579facd9656a87bf4f00. It breaks ipv6. Signed-off-by: David S. Miller <davem@davemloft.net>