- 29 Oct, 2021 40 commits
-
-
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:
David S. Miller <davem@davemloft.net>
-
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 <kuba@kernel.org> 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:
-
Edwin Peer authored
The RTNL lock must be held between down and up to prevent interleaving state changes, especially since external state changes might release and allocate different driver resource subsets that would otherwise need to be tracked and carefully handled. If the down function fails, then devlink will not call the corresponding up function, thus the lock is released in the down error paths. v2: Don't use devlink_reload_disable() and devlink_reload_enable(). Instead, check that the netdev is not in unregistered state before proceeding with reload. Signed-off-by:
-
Edwin Peer authored
Resource reservations will also need to be reset after FUNC_DRV_UNRGTR in the following devlink driver_reinit patch. Extract this logic into a reusable function. Signed-off-by:
-
Edwin Peer authored
The device info logged during probe will be reused by the devlink driver_reinit code in a following patch. Extract this logic into the new bnxt_print_device_info() function. The board index needs to be saved in the driver context so that the board information can be retrieved at a later time, outside of the probe function. Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by:
-
Jakub Kicinski authored
Vladimir Oltean says: ==================== Code movement to br_switchdev.c This is one more refactoring patch set for the Linux bridge, where more logic that is specific to switchdev is moved into br_switchdev.c, which is compiled out when CONFIG_NET_SWITCHDEV is disabled. ==================== Link: https://lore.kernel.org/r/20211027162119.2496321-1-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
Rename all recently imported functions in br_switchdev.c to start with a br_switchdev_* prefix. br_fdb_replay_one() -> br_switchdev_fdb_replay_one() br_fdb_replay() -> br_switchdev_fdb_replay() br_vlan_replay_one() -> br_switchdev_vlan_replay_one() br_vlan_replay() -> br_switchdev_vlan_replay() struct br_mdb_complete_info -> struct br_switchdev_mdb_complete_info br_mdb_complete() -> br_switchdev_mdb_complete() br_mdb_switchdev_host_port() -> br_switchdev_host_mdb_one() br_mdb_switchdev_host() -> br_switchdev_host_mdb() br_mdb_replay_one() -> br_switchdev_mdb_replay_one() br_mdb_replay() -> br_switchdev_mdb_replay() br_mdb_queue_one() -> br_switchdev_mdb_queue_one() Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Vladimir Oltean authored
The following functions: br_mdb_complete br_switchdev_mdb_populate br_mdb_replay_one br_mdb_queue_one br_mdb_replay br_mdb_switchdev_host_port br_mdb_switchdev_host br_switchdev_mdb_notify are only accessible from code paths where CONFIG_NET_SWITCHDEV is enabled. So move them to br_switchdev.c, in order for that code to be compiled out if that config option is disabled. Note that br_switchdev.c gets build regardless of whether CONFIG_BRIDGE_IGMP_SNOOPING is enabled or not, whereas br_mdb.c only got built when CONFIG_BRIDGE_IGMP_SNOOPING was enabled. So to preserve correct compilation with CONFIG_BRIDGE_IGMP_SNOOPING being disabled, we must now place an #ifdef around these functions in br_switchdev.c. The offending bridge data structures that need this are br->multicast_lock and br->mdb_list, these are also compiled out of struct net_bridge when CONFIG_BRIDGE_IGMP_SNOOPING is turned off. Signed-off-by:
-
Vladimir Oltean authored
Similar to fdb_notify() and br_switchdev_fdb_notify(), split the switchdev specific logic from br_mdb_notify() into a different function. This will be moved later in br_switchdev.c. Signed-off-by:
-
Vladimir Oltean authored
br_vlan_replay() is relevant only if CONFIG_NET_SWITCHDEV is enabled, so move it to br_switchdev.c. Signed-off-by:
-
Vladimir Oltean authored
br_vlan_replay() needs this, and we're preparing to move it to br_switchdev.c, which will be compiled regardless of whether or not CONFIG_BRIDGE_VLAN_FILTERING is enabled. Signed-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: Offload root TBF as port shaper Petr says: Egress configuration in an mlxsw deployment would generally have an ETS qdisc at root, with a number of bands and a priority dispatch between them. Some of those bands could then have a RED and/or TBF qdiscs attached. When TBF is used like this, mlxsw configures shaper on a subgroup, which is the pair of traffic classes (UC + BUM) corresponding to the band where TBF is installed. This way it is possible to limit traffic on several bands (subgroups) independently by configuring several TBF qdiscs, each on a different band. It is however not possible to limit traffic flowing through the port as such. The ASIC supports this through port shapers (as opposed to the abovementioned subgroup shapers). An obvious way to express this as a user would be to configure a root TBF qdisc, and then add the whole ETS hierarchy as its child. TBF (and RED) can currently be used as a root qdisc. This usage has always been accepted as a special case, when only one subgroup is configured, and that is the subgroup that root TBF and RED configure. However it was never possible to install ETS under that TBF. In this patchset, this limitation is relaxed. TBF qdisc in root position is now always offloaded as a port shaper. Such TBF qdisc does not limit offload of further children. It is thus possible to configure the usual priority classification through ETS, with RED and/or TBF on individual bands, all that below a port-level TBF. For example: (1) # tc qdisc replace dev swp1 root handle 1: tbf rate 800mbit burst 16kb limit 1M (2) # tc qdisc replace dev swp1 parent 1:1 handle 11: ets strict 8 priomap 7 6 5 4 3 2 1 0 (3) # tc qdisc replace dev swp1 parent 11:1 handle 111: tbf rate 600mbit burst 16kb limit 1M (4) # tc qdisc replace dev swp1 parent 11:2 handle 112: tbf rate 600mbit burst 16kb limit 1M Here, (1) configures a 800-Mbps port shaper, (2) adds an ETS element with 8 strictly-prioritized bands, and (3) and (4) configure two more shapers, each 600 Mbps, one under 11:1 (band 0, TCs 7 and 15), one under 11:2 (band 1, TCs 6 and 14). This way, traffic on bands 0 and 1 are each independently capped at 600 Mbps, and at the same time, traffic through the port as a whole is capped at 800 Mbps. In patch #1, TBF is permitted as root qdisc, under which the usual qdisc tree can be installed. In patch #2, the qdisc offloadability selftest is extended to cover the root TBF as well. Patch #3 then tests that the offloaded TBF shapes as expected. ==================== Link: https://lore.kernel.org/r/20211027152001.1320496-1-idosch@idosch.orgSigned-off-by: -
Petr Machata authored
TBF can be used as a root qdisc, in which case it is supposed to configure port shaper. Add a test that verifies that this is so by installing a root TBF with a ETS or PRIO below it, and then expecting individual bands to all be shaped according to the root TBF configuration. Signed-off-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Petr Machata authored
TBF can be used as a root qdisc, with the usual ETS/RED/TBF hierarchy below it. This use should now be offloaded. Add a test that verifies that it is. Signed-off-by:
-
Petr Machata authored
The Spectrum ASIC allows configuration of maximum shaper on all levels of the scheduling hierarchy: TCs, subgroups, groups and also ports. Currently, TBF always configures a subgroup. But a user could reasonably express the intent to configure port shaper by putting TBF to a root position, around ETS / PRIO. Accept this usage and offload appropriately. Signed-off-by:
-
