- 29 Oct, 2021 40 commits
-
-
Brett Creeley authored
Currently raw hex values are used to define specific bits for each capability/offload in virtchnl.h. Using raw hex values makes it unclear which bits are used/available. Fix this by using the BIT() macro so it's immediately obvious which bits are used/available. Also, move the VIRTCHNL_VF_CAP_ADV_LINK_SPEED define in the correct place to line up with the other bit values and add a comment for its purpose. Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Tested-by:
Tony Brelinski <tony.brelinski@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Brett Creeley authored
Remove unused define that is currently marked as reserved. This will open up space for a new feature if/when it's introduced. Also, there is no reason to keep unused defines around. Suggested-by:
-
Marcin Szycik authored
Disable showing bus-info information for port representors in switchdev mode. This fixes a bug that caused displaying wrong netdev descriptions in lshw tool - one port representor displayed PF branding string, and in turn one PF displayed a "generic" description. The bug occurs when many devices show the same bus-info in ethtool, which was the case in switchdev mode (PF and its port representors displayed the same bus-info). The bug occurs only if a port representor netdev appears before PF netdev in /proc/net/dev. In the examples below: ens6fX is PF ens6fXvY is VF ethX is port representor One irrelevant column was removed from output Before: $ sudo lshw -c net -businfo Bus info Device Description ========================================= pci@0000:02:00.0 eth102 Ethernet Controller E810-XXV for SFP pci@0000:02:00.1 ens6f1 Ethernet Controller E810-XXV for SFP pci@0000:02:01.0 ens6f0v0 Ethernet Adaptive Virtual Function pci@0000:02:01.1 ens6f0v1 Ethernet Adaptive Virtual Function pci@0000:02:01.2 ens6f0v2 Ethernet Adaptive Virtual Function pci@0000:02:00.0 ens6f0 Ethernet interface Notice that eth102 and ens6f0 have the same bus-info and their descriptions are swapped. After: $ sudo lshw -c net -businfo Bus info Device Description ========================================= pci@0000:02:00.0 ens6f0 Ethernet Controller E810-XXV for SFP pci@0000:02:00.1 ens6f1 Ethernet Controller E810-XXV for SFP pci@0000:02:01.0 ens6f0v0 Ethernet Adaptive Virtual Function pci@0000:02:01.1 ens6f0v1 Ethernet Adaptive Virtual Function pci@0000:02:01.2 ens6f0v2 Ethernet Adaptive Virtual Function Fixes: 7aae80ce ("ice: add port representor ethtool ops and stats") Signed-off-by:
Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by:
Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by:
-
Marcin Szycik authored
When spawning VFs in switchdev mode, internal filter list of VSIs is cleared, which includes MAC rules. However MAC entries stay on netdev's multicast list, which causes error message when bringing link up after spawning VFs ("Failed to delete MAC filters"). __dev_mc_sync() is called and tries to unsync addresses that were already removed internally when adding VFs. This can be reproduced with: 1) Load ice driver 2) Change PF to switchdev mode 3) Bring PF link up 4) Bring PF link down 5) Create a VF on PF 6) Bring PF link up Added clearing of netdev's multicast (and also unicast) list when spawning VFs in switchdev mode, so the state of internal rule list and netdev's MAC list is consistent. Fixes: 1a1c40df ("ice: set and release switchdev environment") Signed-off-by: -
Brett Creeley authored
Currently, the vlan_promisc flag is used exclusively by VF VSI to determine whether or not to toggle VLAN pruning along with trusted/true-promiscuous mode. This is not needed for a couple of reasons. First, trusted/true-promiscuous mode is only supposed to allow all MAC filters within VLANs that a VF has added filters for, so VLAN pruning should not be disabled. Second, the boolean argument makes the function confusing and unintuitive. Remove this flag. Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'wireless-drivers-next-2021-10-29' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.16 Fourth set of patches for v5.16. Mostly fixes this time, wcn36xx and iwlwifi have some new features but nothing really out of ordinary. We have one conflict with kspp tree. Major changes: ath11k * fix QCA6390 A-MSDU handling (CVE-2020-24588) wcn36xx * enable hardware scan offload for 5Ghz band * add missing 5GHz channels 136 and 144 iwlwifi * support a new ACPI table revision * improvements in the device selection code * new hardware support * support for WiFi 6E enablement via BIOS * support firmware API version 67 * support for 160MHz in ranging measurements ==================== Link: https://lore.kernel.org/r/20211029134707.DE2B0C4360D@smtp.codeaurora.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Arnd Bergmann authored
The driver no longer depends on this option, but it fails to build if it's disabled because the skb->tc_skip_classify is hidden behind an #ifdef: drivers/net/ifb.c:81:8: error: no member named 'tc_skip_classify' in 'struct sk_buff' skb->tc_skip_classify = 1; Use the same #ifdef around the assignment. Fixes: 046178e7 ("ifb: Depend on netfilter alternatively to tc") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Volodymyr Mytnyk authored
Add firmware (FW) version 4.0 support for Marvell Prestera driver. Major changes have been made to new v4.0 FW ABI to add support of new features, introduce the stability of the FW ABI and ensure better forward compatibility for the future driver vesrions. Current v4.0 FW feature set support does not expect any changes to ABI, as it was defined and tested through long period of time. The ABI may be extended in case of new features, but it will not break the backward compatibility. ABI major changes done in v4.0: - L1 ABI, where MAC and PHY API configuration are split. - ACL has been split to low-level TCAM and Counters ABI to provide more HW ACL capabilities for future driver versions. To support backward support, the addition compatibility layer is required in the driver which will have two different codebase under "if FW-VER elif FW-VER else" conditions that will be removed in the future anyway, So, the idea was to break backward support and focus on more stable FW instead of supporting old version with very minimal and limited set of features/capabilities. Improve FW msg validation: * Use __le64, __le32, __le16 types in msg to/from FW to catch endian mismatch by sparse. * Use BUILD_BUG_ON for structures sent/recv to/from FW. Co-developed-by:
Vadym Kochan <vkochan@marvell.com> Signed-off-by:
Yevhen Orlov <yevhen.orlov@plvision.eu> Signed-off-by:
Taras Chornyi <tchornyi@marvell.com> Signed-off-by:
Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by:
-
Jakub Kicinski authored
devlink_alloc() and devlink_register() are both GPL. A non-GPL module won't get far, so for consistency we can make all symbols GPL without risking any real life breakage. Signed-off-by:
-
Jean Sacren authored
Both !data[IFLA_BAREUDP_PORT] and !data[IFLA_BAREUDP_ETHERTYPE] are checked. We should remove the checks of data[IFLA_BAREUDP_PORT] and data[IFLA_BAREUDP_ETHERTYPE] that follow since they are always true. Put both statements together in group and balance the space on both sides of '=' sign. Signed-off-by:
Jean Sacren <sakiwit@gmail.com> Signed-off-by:
-
Jean Sacren authored
Remove additional character in the source to properly indent if branch. Signed-off-by:
-
Yuiko Oshino authored
Increase the rx ring size (LAN743X_RX_RING_SIZE) to improve rx performance on some platforms. Tested on x86 PC with EVB-LAN7430. The iperf3.7 TCPIP improved from 881 Mbps to 922 Mbps, and UDP improved from 817 Mbps to 936 Mbps. Signed-off-by:
Yuiko Oshino <yuiko.oshino@microchip.com> Signed-off-by:
-
David S. Miller authored
Jeremy Kerr says: ==================== MCTP flow support For certain MCTP transport bindings, the binding driver will need to be aware of request/response pairing. For example, the i2c binding may need to set multiplexer configuration when expecting a response from a device behind a mux. This series implements a mechanism for informing the driver about these flows, so it can implement transport-specific behaviour when a flow is in progress (ie, a response is expected, and/or we time-out on that expectation). We use a skb extension to notify the driver about the presence of a flow, and a new dev->ops callback to notify about a flow's destruction. ==================== Signed-off-by: -
Jeremy Kerr authored
Now that we have an extension for MCTP data in skbs, populate the flow when a key has been created for the packet, and add a device driver operation to inform of flow destruction. Includes a fix for a warning with test builds: Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by:
-
Jeremy Kerr authored
This change adds a new skb extension for MCTP, to represent a request/response flow. The intention is to use this in a later change to allow i2c controllers to correctly configure a multiplexer over a flow. Since we have a cleanup function in the core path (if an extension is present), we'll need to make CONFIG_MCTP a bool, rather than a tristate. Includes a fix for a build warning with clang: Reported-by:
-
Jeremy Kerr authored
In a future change, we will want the key available for future use after allocating a new tag. This change returns the key from mctp_alloc_local_tag, rather than just key->tag. Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== arch, misc: use eth_hw_addr_set() Convert remaining misc drivers to use helpers to write to netdev->dev_addr. This is the last set :) :) ==================== Signed-off-by: -
Jakub Kicinski authored
Commit 406f42fa ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it go through appropriate helpers. Signed-off-by:
-
Jakub Kicinski authored
Commit 406f42fa ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it go through appropriate helpers. Signed-off-by:
Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by:
-
Jakub Kicinski authored
Commit 406f42fa ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it go through appropriate helpers. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2021-10-28 This series contains updates to ice driver only. Michal adds support for eswitch drop and redirect filters from and to tunnel devices. From meaning from uplink to VF and to means from VF to uplink. This is accomplished by adding support for indirect TC tunnel notifications and adding appropriate training packets and match fields for UDP tunnel headers. He also adds returning virtchannel responses for blocked operations as returning a response is still needed. Marcin sets netdev min and max MTU values on port representors to allow for MTU changes over default values. Brett adds detecting and reporting of PHY firmware load issues for devices which support this. Nathan Chancellor fixes a clang warning for implicit fallthrough. Wang Hai fixes a return value for failed allocation. ==================== Signed-off-by: -
Aleksander Jan Bajkowski authored
All SoCs with this IP core support 8 burst length. Hauke suggested to hardcode this value and simplify the driver. Link: https://lkml.org/lkml/2021/9/14/1533Signed-off-by:
Aleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by:
-
Aleksander Jan Bajkowski authored
All SoCs with this IP core support 8 burst length. Hauke suggested to hardcode this value and simplify the driver. Link: https://lkml.org/lkml/2021/9/14/1533Signed-off-by:
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: devlink enhancements This patch series implements some devlink enhancements for bnxt_en. They include: 1. devlink reload to reinitialize driver or to activate new firmware. 2. Support enable_remote_dev_reset to enable/disable other functions resetting the device. 3. Consolidate and improve the health reporters. 4. Support live firmware patch. 5. Provide devlink dev info "fw" version on older firmware. v2: In patch 3, don't use devlink_reload_disable() and devlink_reload_enable() which are no longer available in the latest kernel. Instead, check that the netdev is not in unregistered state before proceeding with reload. In patch 14, use min_t() instead of min() to fix the mismatched type warning. ==================== Signed-off-by: -
Michael Chan authored
Add 'enable_remote_dev_reset' documentation to bnxt.rst. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Vikas Gupta authored
On older firmware that doesn't support the HWRM_NVM_GET_DEV_INFO command that returns detailed stored firmware versions, fallback to use the same firmware package version that is reported to ethtool. Refactor bnxt_get_pkgver() in bnxt_ethtool.c so that devlink can call and get the package version. Signed-off-by:
Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
-
Edwin Peer authored
Live patches are activated by using the 'limit no_reset' option when performing a devlink dev reload fw_activate operation. These packages must first be installed on the device in the usual way. For example, via devlink dev flash or ethtool -f. The devlink device info has also been enhanced to render stored and running live patch versions. Signed-off-by:
-
Michael Chan authored
The main changes are firmware live patch support and 2 additional FEC standard counters. Add the matching FEC counters to ethtool counter array. Firmware older than 220 does not return the proper size of the extended RX counters so we need to cap it at the smaller legacy size. Otherwise the new FEC counters may show up with garbage values. Reviewed-by:
-
Edwin Peer authored
Populate the dump with firmware 'live' coredump data. This includes the information stored in NVRAM by the firmware exception handler prior to recovery. Thus, the live dump includes the desired crash context. Firmware does not support HWRM calls after RESET_NOTIFY, so there is no supported way to capture a coredump during the auto dump phase. Detect this and abort when called from devlink_health_report(). Signed-off-by:
-
Edwin Peer authored
Tools other than 'ethtool -w' may be used to produce a coredump. For devlink health, such dumps could even be driver initiated in response to a health event. In these cases, the kernel thread information will be placed in the coredump record instead. v2: use min_t() instead of min() to fix the mismatched type warning Signed-off-by:
-
Vasundhara Volam authored
Recent firmware provides coredump and crashdump size info via DBG_QCFG command. Read the dump sizes from firmware, instead of computing in the driver. This patch reduces the time taken to collect the dump via ethtool. Signed-off-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
-
Vasundhara Volam authored
Firmware sets compression flags for each segment, add this information while filling segment header. Signed-off-by:
-
Edwin Peer authored
Change bnxt_get_coredump() and bnxt_get_coredump_length() to non-static functions. Signed-off-by:
-
Edwin Peer authored
The coredump functionality will be used by devlink health. Refactor these functions that get coredump and coredump length. There is no functional change, but the following checkpatch warnings were addressed: - strscpy is preferred over strlcpy. - sscanf results should be checked, with an additional warning. Signed-off-by:
-
Edwin Peer authored
Add firmware event counters as well as health state severity. In the unhealthy state, recommend a remedy and inform the user as to its impact. Readability of the devlink tool's output is negatively impacted by adding these fields to the diagnosis. The single line of text, as rendered by devlink health diagnose, benefits from more terse descriptions, which can be substituted without loss of clarity, even in pretty printed JSON mode. Signed-off-by:
-
Edwin Peer authored
Merge 'fw' and 'fw_fatal' health reporters. There is no longer a need to distinguish between firmware reporters. Only bonafide errors are reported now and no reports were being generated for the 'fw' reporter. Signed-off-by:
-
Edwin Peer authored
Firmware resets initiated by the user are not errors and should not be reported via devlink. Once only unsolicited resets remain, it is no longer sensible to maintain a separate fw_reset reporter. Signed-off-by:
-
Edwin Peer authored
The recovery election messages are often mistaken for errors. Improve the wording to clarify the meaning of these frequent and expected events. Also, take the first step towards more inclusive language. Signed-off-by:
-
Edwin Peer authored
The reported parameter value should not take into account the state of remote drivers. Firmware will reject remote resets as appropriate, thus it is not strictly necessary to check HOT_RESET_ALLOWED before attempting to initiate a reset. But we add the check so that we can provide more intuitive messages when reset is not permitted. This firmware setting needs to be restored from all functions after a firmware reset. Signed-off-by:
-
Edwin Peer authored
Similar to reload driver_reinit, the RTNL lock is held across reload down and up to prevent interleaving state changes. But we need to subsequently release the RTNL lock while waiting for firmware reset to complete. Also keep a statistic on fw_activate resets initiated remotely from other functions. Signed-off-by:
-
