aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-09-28e1000e: Add support for Meteor LakeGravatar Sasha Neftin 5-0/+21
Add devices IDs for the next LOM generations that will be available on the next Intel Client platform (Meteor Lake) This patch provides the initial support for these devices Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Clean up nvm_info structureGravatar Sasha Neftin 1-3/+0
flash_bank_size and flash_base_addr field not in use and can be removed from a nvm_info structure Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Reject schedules with a base_time in the futureGravatar Vinicius Costa Gomes 1-2/+23
When we set the BASET registers of i225 with a base_time in the future, i225 will "hold" all packets until that base_time is reached, causing a lot of TX Hangs. As this behaviour seems contrary to the expectations of the IEEE 802.1Q standard (section 8.6.9, especially 8.6.9.4.5), let's start by rejecting these types of schedules. If this is too limiting, we can for example, setup a timer to configure the BASET registers closer to the start time, only blocking the packets for a "short" while. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Export a way to read the PTP timerGravatar Vinicius Costa Gomes 2-4/+4
The next patch will need a way to retrieve the current timestamp from the NIC's PTP clock. The 'i225' suffix is removed, if anything model specific is needed, those specifics should be hidden by this function. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Remove reset disable flagGravatar Sasha Neftin 1-1/+0
Boolean reset disable flag not applicable for i225 device and could be removed. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Save PTP time before a resetGravatar Vinicius Costa Gomes 3-3/+29
Many TSN features depend on the internal PTP clock, so the internal PTP jumping when the adapter is reset can cause problems, usually in the form of "TX Hangs" warnings in the driver. The solution is to save the PTP time before a reset and restore it after the reset is done. The value of the PTP time is saved before a reset and we use the difference from CLOCK_MONOTONIC from reset time to now, to correct what's going to be the new PTP time. This is heavily inspired by commit bf4bf09bdd91 ("i40e: save PTP time before a device reset"). Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Remove references to SYSTIMR registerGravatar Vinicius Costa Gomes 1-10/+2
In i225, it's no longer necessary to use the SYSTIMR register to latch the timer value, the timestamp is latched when SYSTIML is read. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Expose LPI countersGravatar Sasha Neftin 3-0/+7
Completion to commit 900d1e8b346b ("igc: Add LPI counters") LPI counters exposed by statistics update method. A EEE TX LPI counter reflect the transmitter entries EEE (IEEE 802.3az) into the LPI state. A EEE RX LPI counter reflect the receiver link partner entries into EEE(IEEE 802.3az) LPI state. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Clean RX descriptor error flagsGravatar Andre Guedes 2-16/+3
i225 advanced receive descriptor doesn't have the following extend error bits: CE, SE, SEQ, CXE. In addition to that, the bit TCPE is called L4E in the datasheet. Clean up the code accordingly, and get rid of the macro IGC_RXDEXT_ERR_FRAME_ERR_MASK since it doesn't make much sense anymore. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Remove timeout check from ptp_tx workGravatar Andre Guedes 1-6/+0
The Tx timestamp timeout is already checked by the watchdog_task which runs periodically. In addition to that, from the ptp_tx work perspective, if __IGC_PTP_TX_IN_PROGRESS flag is set we always want handle the timestamp stored in hardware and update the skb. So remove the timeout check in igc_ptp_tx_work() function. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Don't reschedule ptp_tx workGravatar Andre Guedes 1-5/+4
The ptp_tx work is scheduled only if TSICR.TXTS bit is set, therefore TSYNCTXCTL.TXTT_0 bit is expected to be set when we check it igc_ptp_tx_ work(). If it isn't, something is really off and rescheduling the ptp_tx work to check it later doesn't help much. This patch changes the code to WARN_ON_ONCE() if this situation ever happens. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Rename IGC_TSYNCTXCTL_VALID macroGravatar Andre Guedes 2-2/+2
Rename the IGC_TSYNCTXCTL_VALID macro to IGC_TSYNCTXCTL_TXTT_0 so it matches the datasheet. Signed-off-by: Andre Guedes <andre.guedes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igc: Add new device ID'sGravatar Sasha Neftin 3-0/+15
Add new device ID's for the next step of the silicon and reflect i221 and i226 parts Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igb: read PBA number from flashGravatar Gal Hammer 1-1/+3
Fixed flash presence check for 82576 controllers so the part number string is read and displayed correctly. Signed-off-by: Gal Hammer <ghammer@redhat.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28igb: add XDP supportGravatar Sven Auhagen 3-36/+481
Add XDP support to the IGB driver. The implementation follows the IXGBE XDP implementation closely and I used the following patches as basis: 1. commit 924708081629 ("ixgbe: add XDP support for pass and drop actions") 2. commit 33fdc82f0883 ("ixgbe: add support for XDP_TX action") 3. commit ed93a3987128 ("ixgbe: tweak page counting for XDP_REDIRECT") Due to the hardware constraints of the devices using the IGB driver we must share the TX queues with XDP which means locking the TX queue for XDP. I ran tests on an older device to get better numbers. Test machine: Intel(R) Atom(TM) CPU C2338 @ 1.74GHz (2 Cores) 2x Intel I211 Routing Original Driver Network Stack: 382 Kpps Routing XDP Redirect (xdp_fwd_kern): 1.48 Mpps XDP Drop: 1.48 Mpps Using XDP we can achieve line rate forwarding even on an older Intel Atom CPU. Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-09-28Merge branch 'udp_tunnel-convert-Intel-drivers-with-shared-tables'Gravatar David S. Miller 15-451/+531
Jakub Kicinski says: ==================== udp_tunnel: convert Intel drivers with shared tables This set converts Intel drivers which have the ability to spawn multiple netdevs, but have only one UDP tunnel port table. Appropriate support is added to the core infra in patch 1, followed by netdevsim support and a selftest. The table sharing works by core attaching the same table structure to all devices sharing the table. This means the reference count has to accommodate potentially large values. Once core is ready i40e and ice are converted. These are complex drivers, but we got a tested-by from Aaron, so we should be good :) Compared to v1 I've made sure the selftest is executable. Other than that patches 8 and 9 are actually from the Mellanox conversion series were kept out to avoid Mellanox vs Intel conflicts. Last patch is new, some docs to let users knows ethtool can now display UDP tunnel info. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28docs: vxlan: add info about device featuresGravatar Jakub Kicinski 1-0/+28
Add some information about VxLAN-related netdev features and how to dump port table via ethtool. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28selftests: net: add a test for static UDP tunnel portsGravatar Jakub Kicinski 1-0/+58
Check UDP_TUNNEL_NIC_INFO_STATIC_IANA_VXLAN works as expected. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28netdevsim: support the static IANA VXLAN port flagGravatar Jakub Kicinski 2-0/+5
Allow setting UDP_TUNNEL_NIC_INFO_STATIC_IANA_VXLAN. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28ice: convert to new udp_tunnel infrastructureGravatar Jakub Kicinski 5-206/+135
Convert ice to the new infra, use share port tables. Leave a tiny bit more error checking in place than usual, because this driver really does quite a bit of magic. We need to calculate the number of VxLAN and GENEVE entries the firmware has reserved. Thanks to the conversion the driver will no longer sleep in an atomic section. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28ice: remove unused args from ice_get_open_tunnel_port()Gravatar Jakub Kicinski 4-12/+6
ice_get_open_tunnel_port() is always passed TNL_ALL as the second parameter. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28i40e: convert to new udp_tunnel infrastructureGravatar Jakub Kicinski 2-219/+51
Make use of the "shared port table" to convert i40e to the new infra. i40e did not have any reference tracking, locking is also dodgy because rtnl gets released while talking to FW, so port may get removed from the table while it's getting added etc. On the good side i40e does not seem to be using the ports for TX so we can remove the table from the driver state completely. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28selftests: net: add a test for shared UDP tunnel info tablesGravatar Jakub Kicinski 1-0/+109
Add a test run of checks validating the shared UDP tunnel port tables function as we expect. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28netdevsim: shared UDP tunnel port table supportGravatar Jakub Kicinski 2-2/+22
Add the ability to simulate a device with a shared UDP tunnel port table. Try to reject the configurations and actions which are not supported by the core, so we don't get syzcaller etc. warning reports. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28netdevsim: add warnings on unexpected UDP tunnel port errorsGravatar Jakub Kicinski 1-4/+9
We should never see a removal of a port which is not in the table or adding a port to an occupied entry in the table. To make sure such errors don't escape the checks in the test script add a warning/kernel spat. Error injection will not trigger those, nor should it ever put us in a bad state. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28udp_tunnel: add the ability to share port tablesGravatar Jakub Kicinski 2-10/+110
Unfortunately recent Intel NIC designs share the UDP port table across netdevs. So far the UDP tunnel port state was maintained per netdev, we need to extend that to cater to Intel NICs. Expect NICs to allocate the info structure dynamically and link to the state from there. All the shared NICs will record port offload information in the one instance of the table so we need to make sure that the use count can accommodate larger numbers. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28Merge branch 'DP83869-WoL-and-Speed-optimization'Gravatar David S. Miller 1-0/+292
Dan Murphy says: ==================== DP83869 WoL and Speed optimization Add the WoL and Speed Optimization (aka downshift) support for the DP83869 Ethernet PHY. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28net: phy: dp83869: Add speed optimization featureGravatar Dan Murphy 1-0/+116
Set the speed optimization bit on the DP83869 PHY. Speed optimization, also known as link downshift, enables fallback to 100M operation after multiple consecutive failed attempts at Gigabit link establishment. Such a case could occur if cabling with only four wires (two twisted pairs) were connected instead of the standard cabling with eight wires (four twisted pairs). The number of failed link attempts before falling back to 100M operation is configurable. By default, four failed link attempts are required before falling back to 100M. Signed-off-by: Dan Murphy <dmurphy@ti.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28net: phy: dp83869: support Wake on LANGravatar Dan Murphy 1-0/+176
This adds WoL support on TI DP83869 for magic, magic secure, unicast and broadcast. Signed-off-by: Dan Murphy <dmurphy@ti.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28net: ethernet: ave: Replace alloc_etherdev() with devm_alloc_etherdev()Gravatar Kunihiko Hayashi 1-21/+11
Use devm_alloc_etherdev() to simplify the code instead of alloc_etherdev(). Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-28net: vlan: Fixed signedness in vlan_group_prealloc_vid()Gravatar Florian Fainelli 1-1/+2
After commit d0186842ec5f ("net: vlan: Avoid using BUG() in vlan_proto_idx()"), vlan_proto_idx() was changed to return a signed integer, however one of its called: vlan_group_prealloc_vid() was still using an unsigned integer for its return value, fix that. Fixes: d0186842ec5f ("net: vlan: Avoid using BUG() in vlan_proto_idx()") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27Merge branch 'bnxt_en-Update-for-net-next'Gravatar David S. Miller 5-184/+810
Michael Chan says: ==================== bnxt_en: Update for net-next. This patch series adds 2 main features to the bnxt_en driver: 200G link speed support and FEC support with some refactoring of the link speed logic. The firmware interface is updated to have proper support for these 2 features. The ethtool preset max channel value is also adjusted properly to account for XDP and TCs. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: Improve preset max value for ethtool -l.Gravatar Michael Chan 1-2/+7
The current logic that calculates the preset maximum value for combined channel does not take into account the rings used for XDP and mqprio TCs. Each of these features will reduce the number of TX rings. Add the logic to divide the TX rings accordingly based on whether the device is currently in XDP mode and whether TCs are in use. Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: Implement ethtool set_fec_param() method.Gravatar Michael Chan 3-1/+107
This feature allows the user to set the different FEC modes on the NIC port. Any new setting will take effect immediately after a link toggle. Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: Report Active FEC encoding during link up.Gravatar Michael Chan 1-3/+26
The current code is reporting the FEC configured settings during link up. Change it to report the more useful active FEC encoding that may be negotiated or auto detected. Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: Report FEC settings to ethtool.Gravatar Michael Chan 3-3/+109
Implement .get_fecparam() method to report the configured and active FEC settings. Also report the supported and advertised FEC settings to the .get_link_ksettings() method. Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: avoid link reset if speed is not changedGravatar Edwin Peer 1-1/+9
PORT_PHY_CONFIG is always sent with REQ_FLAGS_RESET_PHY set. This flag must be set in order for the firmware to institute the requested PHY change immediately, but it results in a link flap. This is unnecessary and results in an improved user experience if the PHY reconfiguration is avoided when the user requested speed does not constitute a change. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: Handle ethernet link being disabled by firmware.Gravatar Michael Chan 2-3/+29
On some 200G dual port NICs, if one port is configured to 200G, firmware will disable the ethernet link on the other port. Firmware will send notification to the driver for the disabled port when this happens. Define a new field in the link_info structure to keep track of this state. The new phy_state field replaces the unused loop_back field. Log a message when the phy_state changes state. In the disabled state, disallow any PHY configurations on the disabled port as the firmware will fail all calls to configure the PHY in this state. Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: ethtool: support PAM4 link speeds up to 200GGravatar Edwin Peer 1-8/+63
Add ethtool PAM4 link modes for: 50000baseCR_Full 100000baseCR2_Full 200000baseCR4_Full Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: add basic infrastructure to support PAM4 link speedsGravatar Edwin Peer 2-21/+65
The firmware interface has added support for new link speeds using PAM4 modulation. Expand the bnxt_link_info structure to closely mirror the new firmware structures. Add logic to copy the PAM4 capabilities and settings from the firmware. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: refactor bnxt_get_fw_speed()Gravatar Edwin Peer 1-23/+24
It will be necessary to update more than one field in the link_info structure when PAM4 speeds are added in a later patch. Instead of merely translating ethtool speed values to firmware speed values, change the responsiblity of this function to update all the necessary link_info fields required to force the speed change to the desired ethtool value. This also reduces code duplication somewhat at the two call sites, which otherwise both have to independently update link_info fields to turn off auto negotiation advertisements. Also use the appropriate REQ_FORCE_LINK_SPEED definitions. These happen to have the same values, but req_link_speed is utilimately passed as force_link_speed in HWRM_PORT_PHY_CFG which is not defined in terms of REQ_AUTO_LINK_SPEED. Reviewed-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: refactor code to limit speed advertisingGravatar Edwin Peer 1-8/+12
Extract the code for determining an advertised speed is no longer supported into a separate function. This will avoid some code duplication in a later patch when supporting PAM4 speeds, since these speeds are specified in a separate field. Reviewed-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27bnxt_en: Update firmware interface spec to 1.10.1.65.Gravatar Michael Chan 5-113/+361
The main changes include FEC, ECN statistics, HWRM_PORT_PHY_QCFG response size reduction, and a new counter added to ctx_hw_stats_ext struct to support the new 58818 chip. The ctx_hw_stats_ext structure is now the superset supporting the new 58818 chips and the prior P5 chips. Add a new flag to identify the new chip and use constants for the chip specific ring statistics sizes instead of the size of the structure. Because the HWRM_PORT_PHY_QCFG response structure size has shrunk back to 96 bytes, the workaround added earlier to limit the size of this message for forwarding to the VF can be removed. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27ptp: add stub function for ptp_get_msgtype()Gravatar Yangbo Lu 1-0/+8
Added the missing stub function for ptp_get_msgtype(). Fixes: 036c508ba95e ("ptp: Add generic ptp message type function") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27net: marvell: mvpp2: Fix W=1 warning with !CONFIG_ACPIGravatar Andrew Lunn 1-0/+2
rivers/net/ethernet/marvell/mvpp2/mvpp2_main.c:7084:36: warning: ‘mvpp2_acpi_match’ defined but not used [-Wunused-const-variable=] 7084 | static const struct acpi_device_id mvpp2_acpi_match[] = { | ^~~~~~~~~~~~~~~~ Wrap the definition inside #ifdef/#endif. Compile tested only. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27Merge branch 'mlxsw-Expose-transceiver-overheat-counter'Gravatar David S. Miller 10-5/+660
Ido Schimmel says: ==================== mlxsw: Expose transceiver overheat counter Amit says: An overheated transceiver can be the root cause of various network problems such as link flapping. Counting the number of times a transceiver's temperature was higher than its configured threshold can therefore help in debugging such issues. This patch set exposes a transceiver overheat counter via ethtool. This is achieved by configuring the Spectrum ASIC to generate events whenever a transceiver is overheated. The temperature thresholds are queried from the transceiver (if available) and set to the default otherwise. Example: ... transceiver_overheat: 2 Patch set overview: Patches #1-#3 add required device registers Patches #4-#5 add required infrastructure in mlxsw to configure and count overheat events Patches #6-#9 gradually add support for the transceiver overheat counter Patch #10 exposes the transceiver overheat counter via ethtool ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27mlxsw: spectrum_ethtool: Expose transceiver_overheat counterGravatar Amit Cohen 1-1/+56
Add structures for port statistics which read from core and not directly from registers. When netdev's ethtool statistics are queried, query the corresponding module's overheat counter from core and expose it as "transceiver_overheat". Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27mlxsw: Update module's settings when module is plugged inGravatar Amit Cohen 4-0/+137
Module temperature warning events are enabled for modules that have a temperature sensor and configured according to the temperature thresholds queried from the module. When a module is unplugged we are guaranteed not to get temperature warning events. However, when a module is plugged in we need to potentially update its current settings (i.e., event enablement and thresholds). Register to port module plug/unplug events and update module's settings upon plug in events. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27mlxsw: spectrum: Initialize netdev's module overheat counterGravatar Amit Cohen 2-0/+26
The overheat counter is a per-module counter, but it is exposed as part of the corresponding netdev's statistics. It should therefore be presented to user space relative to the netdev's lifetime. Query the counter just before registering the netdev, so that the value exposed to user space will be relative to this initial value. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-27mlxsw: Enable temperature event for all supported port module sensorsGravatar Amit Cohen 2-0/+107
MTWE (Management Temperature Warning Event) is triggered for sensors whose temperature event enable bit is enabled in the MTMP register. Enable events for all the modules that have a temperature sensor. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>