summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/mellanox/mlxsw
AgeCommit message (Collapse)Author
2021-10-13mlxsw: spectrum_qdisc: Introduce per-TC ECN countersPetr Machata
The Qdisc code in mlxsw used to report a number of packets ECN-marked on a port. Because reporting a per-port value as a per-TC value was misleading, this was removed in commit 8a29581eb001 ("mlxsw: spectrum: Move the ECN-marked packet counter to ethtool"). On Spectrum-3, a per-TC number of ECN-marked packets is available in per-TC congestion counter group. Add a new array for the ECN counter, fetch the values from the per-TC congestion group, and pick the value indicated by tclass_num as appropriate. On Spectrum-1 and Spectrum-2, this per-TC value is not available, and zeroes will be reported, as they currently are. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-13mlxsw: reg: Add ecn_marked_tc to Per-TC Congestion CountersPetr Machata
The PPCNT register retrieves per port performance counters. The ecn_marked_tc field in per-TC Congestion counter group contains a count of packets marked as ECN or potentially marked as ECN. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-13mlxsw: reg: Rename MLXSW_REG_PPCNT_TC_CONG_TC to _CNTPetr Machata
The name does not make sense as it is. Clearly there is a typo and the suffix should have been _CNT, like the other enumerators. Fix accordingly. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-13mlxsw: reg: Fix a typo in a group headingPetr Machata
There is no such thing as "traffic group". The group that this is a heading of is "per traffic class counters". Fix the heading. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-12devlink: Delete reload enable/disable interfaceLeon Romanovsky
Commit a0c76345e3d3 ("devlink: disallow reload operation during device cleanup") added devlink_reload_{enable,disable}() APIs to prevent reload operation from racing with device probe/dismantle. After recent changes to move devlink_register() to the end of device probe and devlink_unregister() to the beginning of device dismantle, these races can no longer happen. Reload operations will be denied if the devlink instance is unregistered and devlink_unregister() will block until all in-flight operations are done. Therefore, remove these devlink_reload_{enable,disable}() APIs. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-12devlink: Allow control devlink ops behavior through feature maskLeon Romanovsky
Introduce new devlink call to set feature mask to control devlink behavior during device initialization phase after devlink_alloc() is already called. This allows us to set reload ops based on device property which is not known at the beginning of driver initialization. For the sake of simplicity, this API lacks any type of locking and needs to be called before devlink_register() to make sure that no parallel access to the ops is possible at this stage. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-12mlxsw: pci: Use dev_driver_string() instead of pci_dev->driver->nameUwe Kleine-König
Replace dev->driver_name() by dev_driver_string() for the corresponding struct device. This is a step toward removing pci_dev->driver. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/20211004125935.2300113-8-u.kleine-koenig@pengutronix.de Tested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
2021-10-12mlxsw: spectrum_qdisc: Offload RED qevent markPetr Machata
The RED "mark" qevent can be offloaded under similar conditions as the RED "early_drop" qevent. Therefore recognize its binding type in the TC_SETUP_BLOCK handler and translate to the right SPAN trigger, with the right set of supported actions. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-12mlxsw: spectrum_qdisc: Track permissible actions per bindingPetr Machata
One block can be bound to several qevents. The qevent type that the block is bound to determines which actions make sense in a given context. In the particular case of mlxsw, trap cannot be offloaded on a RED mark qevent, because the trap contract specifies that the packet is dropped in the HW datapath, and the HW trigger that the action is offloaded to is always forwarding the packet (in addition to marking in). Therefore keep track of which actions are permissible at each binding block. When an attempt is made to bind a certain action at a binding point where it is not supported, bounce the request. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-12mlxsw: spectrum_qdisc: Distinguish between ingress and egress triggersPetr Machata
The following patches will configure the MLXSW_SP_SPAN_TRIGGER_ECN mirroring trigger. This trigger is considered "egress", unlike the previously-offloaded _EARLY_DROP. Add a helper to spectrum_span, mlxsw_sp_span_trigger_is_ingress(), to classify triggers to ingress and egress. Pass result of this instead of hardcoding true when calling mlxsw_sp_span_analyzed_port_get()/_put(). Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-12mlxsw: spectrum_qdisc: Pass extack to mlxsw_sp_qevent_entry_configure()Petr Machata
This function will report a new failure in the following patches. Pass extack so that the failure is explicable. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-08mlxsw: item: Annotate item helpers with '__maybe_unused'Ido Schimmel
mlxsw is using helpers to get / set fields in messages exchanged with the device. It is possible that some fields are only set or only get. This causes LLVM to emit warnings such as the following when building with W=1 [1]: drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c:2022:1: warning: unused function 'mlxsw_afa_sampler_mirror_agent_get' The fact that some fields are only set or only get is very much intentional and not indicative of functions that need to be removed. Therefore, annotate the item helpers with '__maybe_unused' to suppress these warnings. [1] https://lkml.org/lkml/2021/9/29/685 Cc: Nathan Chancellor <nathan@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20211008132315.90211-1-idosch@idosch.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-06mlxsw: Add support for transceiver module extended stateIdo Schimmel
Add support for the transceiver module extended state and sub-state added in previous patch. The extended state is meant to describe link issues related to transceiver modules. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-06mlxsw: Add ability to control transceiver modules' power modeIdo Schimmel
Implement support for ethtool_ops::.get_module_power_mode and ethtool_ops::set_module_power_mode. The get operation is implemented using the Management Cable IO and Notifications (MCION) register that reports the operational power mode of the module and its presence. In case a module is not present, its operational power mode is not reported to ethtool and user space. If not set before, the power mode policy is reported as "high", which is the default on Mellanox systems. The set operation is implemented using the Port Module Memory Map Properties (PMMP) register. The register instructs the device's firmware to transition a plugged-in module to / out of low power mode by writing to its memory map. When the power mode policy is set to 'auto', a module will not transition to low power mode as long as any ports using it are administratively up. Example: # devlink port split swp11 count 4 # ethtool --set-module swp11s0 power-mode-policy auto $ ethtool --show-module swp11s0 Module parameters for swp11s0: power-mode-policy auto power-mode low # ip link set dev swp11s0 up # ip link set dev swp11s1 up $ ethtool --show-module swp11s0 Module parameters for swp11s0: power-mode-policy auto power-mode high # ip link set dev swp11s1 down $ ethtool --show-module swp11s0 Module parameters for swp11s0: power-mode-policy auto power-mode high # ip link set dev swp11s0 down $ ethtool --show-module swp11s0 Module parameters for swp11s0: power-mode-policy auto power-mode low Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-06mlxsw: reg: Add Management Cable IO and Notifications registerIdo Schimmel
Add the Management Cable IO and Notifications register. It will be used to retrieve the power mode status of a module in subsequent patches and whether a module is present in a cage or not. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-06mlxsw: reg: Add Port Module Memory Map Properties registerIdo Schimmel
Add the Port Module Memory Map Properties register. It will be used to set the power mode of a module in subsequent patches. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-10-06mlxsw: spectrum_buffers: silence uninitialized warningDan Carpenter
Static checkers and runtime checkers such as KMSan will complain that we do not initialize the last 6 bytes of "cb_priv". The caller only uses the first two bytes so it doesn't cause a runtime issue. Still worth fixing though. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-05ethernet: use eth_hw_addr_set() for dev->addr_len casesJakub Kicinski
Convert all Ethernet drivers from memcpy(... dev->addr_len) to eth_hw_addr_set(): @@ expression dev, np; @@ - memcpy(dev->dev_addr, np, dev->addr_len) + eth_hw_addr_set(dev, np) In theory addr_len may not be ETH_ALEN, but we don't expect non-Ethernet devices to live under this directory, and only the following cases of setting addr_len exist: - cxgb4 for mgmt device, and the drivers which set it to ETH_ALEN: s2io, mlx4, vxge. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-27mlxsw: core: Register devlink instance lastLeon Romanovsky
Make sure that devlink is open to receive user input when all parameters are initialized. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: Add support for IP-in-IP with IPv6 underlay for Spectrum-2 and aboveAmit Cohen
Currently, mlxsw driver supports IP-in-IP only with IPv4 underlay. Add support for IPv6 underlay for Spectrum-2 and above. Most of the configurations are same to IPv4, the main difference between IPv4 and IPv6 is related to saving IP addresses. IPv6 addresses are saved as part of KVD and the relevant registers hold pointer to them. Add API for that as part of ipip_ops, so then only Spectrum-2 and above will save IPv6 addresses in this way. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: spectrum_router: Increase parsing depth for IPv6 decapsulationAmit Cohen
The Spectrum ASIC has a configurable limit on how deep into the packet it parses. By default, the limit is 96 bytes. For IP-in-IP packets, with IPv6 outer and inner headers, the default parsing depth is not enough and without increasing it such packets cannot be properly decapsulated. Use the existing API to set parsing depth, call it once for each decapsulation entry when it is created/destroyed. There is no need to protect the code with new mutex because 'router->lock' is already taken in these code paths. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: Add IPV6_ADDRESS kvdl entry typeAmit Cohen
Add support for allocating and freeing KVD entries for IPv6 addresses. These addresses are programmed by the RIPS register and referenced by the RATR and RTDP registers for IPv6 underlay encapsulation and decapsulation, respectively. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: spectrum_ipip: Add mlxsw_sp_ipip_gre6_opsAmit Cohen
Add operations for IP-in-IP GRE6. For now the function can_offload() returns false and the other functions warn as they should never be called. A later patch will add dedicated operations for Spectrum-2 which will support IPv6 underlay, so use 'mlxsw_sp1_' prefix for the new operations. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: Create separate ipip_ops_arr for different ASICsAmit Cohen
Currently, there is support for IP-in-IP only with IPv4 underlay for all supported Spectrum ASICs. The next patches will add support for IPv6 underlay only for Spectrum-2 and above. Add infrastructure for splitting IP-in-IP support between different ASICs - create separate ipip_ops_arr and add ipips_init function to set the right ops. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: reg: Add support for ritr_loopback_ipip6_pack()Amit Cohen
The RITR register is used to configure the router interface table. For IP-in-IP, it stores the underlay source IP address for encapsulation and also the ingress RIF for the underlay lookup. Add support for IPv6 IP-in-IP configuration. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: reg: Add support for ratr_ipip6_entry_pack()Amit Cohen
The RATR register is used to configure the Router Adjacency (next-hop) Table. For IP-in-IP entry, underlay destination IPv4 is saved as part of this register and underlay destination IPv6 is saved by RIPS register and RATR saves pointer to it. Add function for setting IPv6 IP-in-IP configuration. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: reg: Add support for rtdp_ipip6_pack()Amit Cohen
The RTDP register is used for configuring the tunnel decapsulation properties of NVE and IP-in-IP. Linux tunnels verify packets before decapsulation based on the packet's source IP, which must match tunnel remote IP. RTDP is used to configure decapsulation so that it filters out packets that are not IPv6 or have the wrong source IP or wrong GRE key. For IP-in-IP entry, source IPv4 is saved as part of this register and source IPv6 is saved by RIPS register and RTDP saves pointer to it. Create common function for configuring both IPv4 and IPv6 and add dedicated functions for each protocol. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: reg: Add Router IP version Six RegisterAmit Cohen
The RIPS register is used to store IPv6 addresses for use by the NVE and IP-in-IP. For IPv6 underlay support, RATR register needs to hold a pointer to the remote IPv6 address for encapsulation and RTDP register needs to hold a pointer to the local IPv6 address for decapsulation check. Add the required register for saving IPv6 addresses. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: Take tunnel's type into account when searching underlay deviceAmit Cohen
The function __mlxsw_sp_ipip_netdev_ul_dev_get() returns the underlay device that corresponds to the overlay device that it gets. Currently, this function assumes that the tunnel is IPv4 GRE, because it is the only one that is supported by mlxsw driver. This assumption will no longer be correct when IPv6 GRE support is added, resulting in wrong underlay device being returned. Instead, check 'ol_dev->type' and return the underlay device accordingly. Move the function to spectrum_ipip.c because spectrum_router.c should not be aware to tunnel type. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: spectrum_ipip: Create common function for ↵Amit Cohen
mlxsw_sp_ipip_ol_netdev_change_gre() The function mlxsw_sp_ipip_ol_netdev_change_gre4() contains code that can be shared between IPv4 and IPv6. The only difference is the way that arguments are taken from tunnel parameters, which are different between IPv4 and IPv6. For that, add structure 'mlxsw_sp_ipip_parms' to hold all the required parameters for the function and save it as part of 'struct mlxsw_sp_ipip_entry' instead of the existing structure that is not shared between IPv4 and IPv6. Add new operation as part of 'mlxsw_sp_ipip_ops' to initialize the new structure. Then mlxsw_sp_ipip_ol_netdev_change_gre{4,6}() will prepare the new structure and both will call the same function. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: spectrum_router: Fix arguments alignmentAmit Cohen
Suppress the following checkpatch.pl check [1] by adding a variable to store the IP-in-IP options. Noticed while adding equivalent IPv6 code in subsequent patches. [1] CHECK: Alignment should match open parenthesis + mlxsw_reg_ritr_loopback_ipip4_pack(ritr_pl, lb_cf.lb_ipipt, + + MLXSW_REG_RITR_LOOPBACK_IPIP_OPTIONS_GRE_KEY_PRESET, Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: spectrum_ipip: Pass IP tunnel parameters by reference and as 'const'Amit Cohen
Currently, there are several functions that handle 'struct ip_tunnel_parm' and 'struct __ip6_tnl_parm'. Change the mentioned functions to get IP tunnel parameters by reference and as 'const'. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-24mlxsw: spectrum_router: Create common function for fib_entry_type_unset() codeAmit Cohen
mlxsw_sp_fib4_entry_type_unset() is not specific for IPv4 FIB entry, move the code to mlxsw_sp_fib_entry_type_unset(), and call this function from mlxsw_sp_fib4_entry_type_unset() so then it will be used for IPv6 also. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-22mlxsw: spectrum_router: Start using new trap adjacency entryIdo Schimmel
Start using the trap adjacency entry that was added in the previous patch and remove the existing one which is no longer needed. Note that the name of the old entry was inaccurate as the entry did not discard packets, but trapped them. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-22mlxsw: spectrum_router: Add trap adjacency entry upon first nexthop groupIdo Schimmel
In commit 0c3cbbf96def ("mlxsw: Add specific trap for packets routed via invalid nexthops"), mlxsw started allocating a new adjacency entry during driver initialization, to trap packets routed via invalid nexthops. This behavior was later altered in commit 983db6198f0d ("mlxsw: spectrum_router: Allocate discard adjacency entry when needed") to only allocate the entry upon the first route that requires it. The motivation for the change is explained in the commit message. The problem with the current behavior is that the entry shows up as a "leak" in a new BPF resource monitoring tool [1]. This is caused by the asymmetry of the allocation/free scheme. While the entry is allocated upon the first route that requires it, it is only freed during de-initialization of the driver. Instead, track the number of active nexthop groups and allocate the adjacency entry upon the creation of the first group. Free it when the number of active groups reaches zero. The next patch will convert mlxsw to start using the new entry and remove the old one. [1] https://github.com/Mellanox/mlxsw/tree/master/Debugging/libbpf-tools/resmon Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-22devlink: Make devlink_register to be voidLeon Romanovsky
devlink_register() can't fail and always returns success, but all drivers are obligated to check returned status anyway. This adds a lot of boilerplate code to handle impossible flow. Make devlink_register() void and simplify the drivers that use that API call. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Acked-by: Simon Horman <simon.horman@corigine.com> Acked-by: Vladimir Oltean <olteanv@gmail.com> # dsa Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: Add support for transceiver modules resetIdo Schimmel
Implement support for ethtool_ops::reset in order to reset transceiver modules. The module backing the netdev is reset when the 'ETH_RESET_PHY' flag is set. After a successful reset, the flag is cleared by the driver and other flags are ignored. This is in accordance with the interface documentation: "The reset() operation must clear the flags for the components which were actually reset. On successful return, the flags indicate the components which were not reset, either because they do not exist in the hardware or because they cannot be reset independently. The driver must never reset any components that were not requested." Reset is useful in order to allow a module to transition out of a fault state. From section 6.3.2.12 in CMIS 5.0: "Except for a power cycle, the only exit path from the ModuleFault state is to perform a module reset by taking an action that causes the ResetS transition signal to become TRUE (see Table 6-11)". An error is returned when the netdev is administratively up: # ip link set dev swp11 up # ethtool --reset swp11 phy ETHTOOL_RESET 0x40 Cannot issue ETHTOOL_RESET: Invalid argument # ip link set dev swp11 down # ethtool --reset swp11 phy ETHTOOL_RESET 0x40 Components reset: 0x40 An error is returned when the module is shared by multiple ports (split ports) and the "phy-shared" flag is not set: # devlink port split swp11 count 4 # ethtool --reset swp11s0 phy ETHTOOL_RESET 0x40 Cannot issue ETHTOOL_RESET: Invalid argument # ethtool --reset swp11s0 phy-shared ETHTOOL_RESET 0x400000 Components reset: 0x400000 # devlink port unsplit swp11s0 # ethtool --reset swp11 phy ETHTOOL_RESET 0x40 Components reset: 0x40 An error is also returned when one of the ports using the module is administratively up: # devlink port split swp11 count 4 # ip link set dev swp11s1 up # ethtool --reset swp11s0 phy-shared ETHTOOL_RESET 0x400000 Cannot issue ETHTOOL_RESET: Invalid argument # ip link set dev swp11s1 down # ethtool --reset swp11s0 phy-shared ETHTOOL_RESET 0x400000 Components reset: 0x400000 Reset is performed by writing to the "rst" bit of the PMAOS register, which instructs the firmware to assert the reset signal connected to the module for a fixed amount of time. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: Make PMAOS pack function more genericIdo Schimmel
The PMAOS register has enable bits (e.g., PMAOS.ee) that allow changing only a subset of the fields, which is exactly what subsequent patches will need to do. Instead of passing multiple arguments to its pack function, only pass the module index and let the rest be set by the different callers. No functional changes intended. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: reg: Add fields to PMAOS registerIdo Schimmel
The Ports Module Administrative and Operational Status (PMAOS) register configures and retrieves the per-module status. Extend it with fields required to support various module settings such as reset and power mode. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: Track per-module port statusIdo Schimmel
In the common port module core, track the number of logical ports that are mapped to the port module and the number of logical ports using it that are administratively up. This will be used by later patches to potentially veto and control certain operations on the module, such as reset and setting its power mode. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: spectrum: Do not return an error in mlxsw_sp_port_module_unmap()Ido Schimmel
The return value is never checked. Allows us to simplify a later patch. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: spectrum: Do not return an error in ndo_stop()Ido Schimmel
The return value is not checked by the networking stack. Allows us to simplify a later patch. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: core_env: Convert 'module_info_lock' to a mutexIdo Schimmel
After the previous patch, the lock is always taken in process context so it can be converted to a mutex. It is needed for future changes where we will need to be able to sleep when holding the lock. Convert the lock to a mutex. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: core_env: Defer handling of module temperature warning eventsIdo Schimmel
Module temperature events are currently handled in softIRQ context, requiring the 'module_info_lock' to be a spin lock. In future patchsets we will need to be able to hold the lock while sleeping. Therefore, defer handling of these events using a work queue so that the next patch will be able to convert the lock to a mutex. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: core: Remove mlxsw_core_is_initialized()Ido Schimmel
After the previous patch, the switch driver is always initialized last, making this function redundant. Remove it. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-15mlxsw: core: Initialize switch driver lastIdo Schimmel
Commit 961cf99a074f ("mlxsw: core: Re-order initialization sequence") changed the initialization sequence so that the switch driver (e.g., mlxsw_spectrum) is initialized before registration with the hwmon and thermal subsystems. This was done in order to avoid situations where hwmon/thermal code uses features not supported by current firmware version, which is only validated as part of switch driver initialization. Later, commit b79cb787ac70 ("mlxsw: Move fw flashing code into core.c") moved firmware validation and flashing code from the switch driver to mlxsw_core so that it is performed before driver initialization. Therefore, change the initialization sequence back to its original form. In addition to being more straightforward, it will allow us to simplify parts of the code in subsequent patches and future patchsets. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-14mlxsw: reg: Remove PMTM registerJiri Pirko
It is not used anymore, remove it. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-14mlxsw: spectrum: Use PMTDB register to obtain split infoJiri Pirko
Newly introduced PMTDB register is there to provide all needed info about particular requested port split configuration. Use it instead of figuring the info out manually in the driver. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-14mlxsw: reg: Add Port Module To local DataBase RegisterJiri Pirko
The PMTDB register allows to query the possible module<->local port mapping than can be used in PMLP. It does not represent the actual/current mapping of the local to module. Actual mapping is only defined by PMLP. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-14mlxsw: spectrum: Use PLLP to get front panel number and split numberJiri Pirko
Instead of relying on the values coming from the PMLP register, use PLLP to get the information about port front panel number and split number. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>