summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2025-09-18bnxt_en: Implement ethtool .set_tunable() for ETHTOOL_PFC_PREVENTION_TOUTMichael Chan
Support the setting of the tunable if it is supported by firmware. The supported range is 0 to the maximum msec value reported by firmware. PFC_STORM_PREVENTION_AUTO is also supported and 0 means it is disabled. Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-11-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Implement ethtool .get_tunable() for ETHTOOL_PFC_PREVENTION_TOUTMichael Chan
Return the current PFC watchdog timeout value if it is supported. Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-10-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Use VLAN_ETH_HLEN when possibleKalesh AP
Replace ETH_HLEN + VLAN_HLEN with VLAN_ETH_HLEN. Cosmetic change and no functional changes intended. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-9-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Support for RoCE resources dynamically shared within VFs.Anantha Prabhu
Add support for dynamic RoCE SRIOV resource configuration. Instead of statically dividing the RoCE resources by the number of VFs, provide the maximum resources and let the FW dynamically dsitribute to the VFs on the fly. Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Anantha Prabhu <anantha.prabhu@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-8-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Add err_qpc backing store handlingKashyap Desai
New backing store component err_qpc is added to the existing host logging interface for FW traces. Allocate the backing store memory if this memory type is supported. Copy this memory when collecting the coredump. Reviewed-by: Shruti Parab <shruti.parab@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-7-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Add fw log trace support for 5731X/5741X chipsShruti Parab
These older chips now support the fw log traces via backing store qcaps_v2. No other backing store memory types are supported besides the fw trace types. Reviewed-by: Hongguang Gao <hongguang.gao@broadcom.com> Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by: Shruti Parab <shruti.parab@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-6-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Improve bnxt_backing_store_cfg_v2()Michael Chan
Improve the logic that determines the last_type in this function. The different context memory types are configured in a loop. The last_type signals the last context memory type to be configured which requires the ALL_DONE flag to be set for the FW. The existing logic makes some assumptions that TIM is the last_type when RDMA is enabled or FTQM is the last_type when only L2 is enabled. Improve it to just search for the last_type so that we don't need to make these assumptions that won't necessary be true for future devices. Reviewed-by: Shruti Parab <shruti.parab@broadcom.com> Reviewed-by: Hongguang Gao <hongguang.gao@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-5-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Optimize bnxt_sriov_disable()Kalesh AP
bnxt_sriov_disable() is invoked from 2 places: 1. When the user deletes the VFs. 2. During the unload of the PF driver instance. Inside bnxt_sriov_disable(), driver invokes bnxt_restore_pf_fw_resources() which in turn causes a close/open_nic(). There is no harm doing this in the unload path, although it is inefficient and unnecessary. Optimize the function to make it more efficient. Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-4-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Remove unnecessary VF check in bnxt_hwrm_nvm_req()Kalesh AP
The driver registers the supported configuration parameters with the devlink stack only on the PF using devlink_params_register(). Hence there is no need for a VF check inside bnxt_hwrm_nvm_req(). Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-3-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18bnxt_en: Drop redundant if block in bnxt_dl_flash_update()Kalesh AP
The devlink stack has sanity checks and it invokes flash_update() only if it is supported by the driver. The VF driver does not advertise the support for flash_update in struct devlink_ops. This makes if condition inside bnxt_dl_flash_update() redundant. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250917040839.1924698-2-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18Merge branch 'add-basic-psp-encryption-for-tcp-connections'Paolo Abeni
Daniel Zahka says: ================== add basic PSP encryption for TCP connections This is v13 of the PSP RFC [1] posted by Jakub Kicinski one year ago. General developments since v1 include a fork of packetdrill [2] with support for PSP added, as well as some test cases, and an implementation of PSP key exchange and connection upgrade [3] integrated into the fbthrift RPC library. Both [2] and [3] have been tested on server platforms with PSP-capable CX7 NICs. Below is the cover letter from the original RFC: Add support for PSP encryption of TCP connections. PSP is a protocol out of Google: https://github.com/google/psp/blob/main/doc/PSP_Arch_Spec.pdf which shares some similarities with IPsec. I added some more info in the first patch so I'll keep it short here. The protocol can work in multiple modes including tunneling. But I'm mostly interested in using it as TLS replacement because of its superior offload characteristics. So this patch does three things: - it adds "core" PSP code PSP is offload-centric, and requires some additional care and feeding, so first chunk of the code exposes device info. This part can be reused by PSP implementations in xfrm, tunneling etc. - TCP integration TLS style Reuse some of the existing concepts from TLS offload, such as attaching crypto state to a socket, marking skbs as "decrypted", egress validation. PSP does not prescribe key exchange protocols. To use PSP as a more efficient TLS offload we intend to perform a TLS handshake ("inline" in the same TCP connection) and negotiate switching to PSP based on capabilities of both endpoints. This is also why I'm not including a software implementation. Nobody would use it in production, software TLS is faster, it has larger crypto records. - mlx5 implementation That's mostly other people's work, not 100% sure those folks consider it ready hence the RFC in the title. But it works :) Not posted, queued a branch [4] are follow up pieces: - standard stats - netdevsim implementation and tests [1] https://lore.kernel.org/netdev/20240510030435.120935-1-kuba@kernel.org/ [2] https://github.com/danieldzahka/packetdrill [3] https://github.com/danieldzahka/fbthrift/tree/dzahka/psp [4] https://github.com/kuba-moo/linux/tree/psp Comments we intend to defer to future series: - we prefer to keep the version field in the tx-assoc netlink request, because it makes parsing keys require less state early on, but we are willing to change in the next version of this series. - using a static branch to wrap psp_enqueue_set_decrypted() and other functions called from tcp. - using INDIRECT_CALL for tls/psp in sk_validate_xmit_skb(). We prefer to address this in a dedicated patch series, so that this series does not need to modify the way tls_validate_xmit_skb() is declared and stubbed out. v12: https://lore.kernel.org/netdev/20250916000559.1320151-1-kuba@kernel.org/ v11: https://lore.kernel.org/20250911014735.118695-1-daniel.zahka@gmail.com v10: https://lore.kernel.org/netdev/20250828162953.2707727-1-daniel.zahka@gmail.com/ v9: https://lore.kernel.org/netdev/20250827155340.2738246-1-daniel.zahka@gmail.com/ v8: https://lore.kernel.org/netdev/20250825200112.1750547-1-daniel.zahka@gmail.com/ v7: https://lore.kernel.org/netdev/20250820113120.992829-1-daniel.zahka@gmail.com/ v6: https://lore.kernel.org/netdev/20250812003009.2455540-1-daniel.zahka@gmail.com/ v5: https://lore.kernel.org/netdev/20250723203454.519540-1-daniel.zahka@gmail.com/ v4: https://lore.kernel.org/netdev/20250716144551.3646755-1-daniel.zahka@gmail.com/ v3: https://lore.kernel.org/netdev/20250702171326.3265825-1-daniel.zahka@gmail.com/ v2: https://lore.kernel.org/netdev/20250625135210.2975231-1-daniel.zahka@gmail.com/ v1: https://lore.kernel.org/netdev/20240510030435.120935-1-kuba@kernel.org/ ================== Links: https://patch.msgid.link/20250917000954.859376-1-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> --- * add-basic-psp-encryption-for-tcp-connections: net/mlx5e: Implement PSP key_rotate operation net/mlx5e: Add Rx data path offload psp: provide decapsulation and receive helper for drivers net/mlx5e: Configure PSP Rx flow steering rules net/mlx5e: Add PSP steering in local NIC RX net/mlx5e: Implement PSP Tx data path psp: provide encapsulation helper for drivers net/mlx5e: Implement PSP operations .assoc_add and .assoc_del net/mlx5e: Support PSP offload functionality psp: track generations of device key net: psp: update the TCP MSS to reflect PSP packet overhead net: psp: add socket security association code net: tcp: allow tcp_timewait_sock to validate skbs before handing to device net: move sk_validate_xmit_skb() to net/core/dev.c psp: add op for rotation of device key tcp: add datapath logic for PSP with inline key exchange net: modify core data structures for PSP datapath support psp: base PSP device support psp: add documentation
2025-09-18Merge tag 'ib-mfd-gpio-hwmon-i2c-can-rtc-watchdog-v6.18' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into gpio/for-next Pull changes from the immutable branch between MFD, GPIO, HWMON, I2C, CAN, RTC and Watchdog trees containing GPIO support for Nuvoton NCT6694.
2025-09-18net/mlx5e: Implement PSP key_rotate operationRaed Salem
Implement .key_rotate operation where when invoked will cause the HW to use a new master key to derive PSP spi/key pairs with complience with PSP spec. Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250917000954.859376-20-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18net/mlx5e: Add Rx data path offloadRaed Salem
On receive flow inspect received packets for PSP offload indication using the cqe, for PSP offloaded packets set SKB PSP metadata i.e spi, header length and key generation number to stack for further processing. Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250917000954.859376-19-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18net/mlx5e: Configure PSP Rx flow steering rulesRaed Salem
Set the Rx PSP flow steering rule where PSP packet is identified and decrypted using the dedicated UDP destination port number 1000. If packet is decrypted then a PSP marker and syndrome are added to metadata so SW can use it later on in Rx data path. The rule is set as part of init_rx netdev profile implementation. Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250917000954.859376-17-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18net/mlx5e: Add PSP steering in local NIC RXRaed Salem
Introduce decrypt FT, the RX error FT, and the default rules. The PSP (PSP) RX decrypt flow table is pointed by the TTC (Traffic Type Classifier) UDP steering rules. The decrypt flow table has two flow groups. The first flow group keeps the decrypt steering rule programmed always when PSP packet is recognized using the dedicated udp destination port number 1000, if packet is decrypted then a PSP marker is set in metadata_regB[30]. The second flow group has a default rule to forward all non-offloaded PSP packet to the TTC UDP default RSS TIR. The RX error flow table is the destination of the decrypt steering rules in the PSP RX decrypt flow table. It has two fixed rule one with single copy action that copies psp_syndrome to metadata_regB[23:29]. The PSP marker and syndrome is used to filter out non-psp packet and to return the PSP crypto offload status in Rx flow. The marker is used to identify such packet in driver so the driver could set SKB PSP metadata. The destination of RX error flow table is the TTC UDP default RSS TIR. The second rule will drop packets that failed to be decrypted (like in case illegal SPI or expired SPI is used). Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250917000954.859376-16-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18net/mlx5e: Implement PSP Tx data pathRaed Salem
Setup PSP offload on Tx data path based on whether skb indicates that it is intended for PSP or not. Support driver side encapsulation of the UDP headers, PSP headers, and PSP trailer for the PSP traffic that will be encrypted by the NIC. Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250917000954.859376-15-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18net/mlx5e: Implement PSP operations .assoc_add and .assoc_delRaed Salem
Implement .assoc_add and .assoc_del PSP operations used in the tx control path. Allocate the relevant hardware resources when a new key is registered using .assoc_add. Destroy the key when .assoc_del is called. Use a atomic counter to keep track of the current number of keys being used by the device. Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250917000954.859376-13-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18net/mlx5e: Support PSP offload functionalityRaed Salem
Add PSP offload related structs, layouts, and enumerations. Implement .set_config and .rx_spi_alloc PSP device operations. Driver does not need to make use of the .set_config operation. Stub .assoc_add and .assoc_del PSP operations. Introduce the MLX5_EN_PSP configuration option for enabling PSP offload support on mlx5 devices. Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250917000954.859376-12-daniel.zahka@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: add OTP health reporterJakub Kicinski
OTP memory ("fuses") are used for secure boot and anti-rollback protection. The OTP memory is ECC protected. Check for its health periodically to notice when the chip is starting to go bad. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-10-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: report FW uptime in health diagnoseJakub Kicinski
FW crashes are detected based on uptime going back, expose the uptime via devlink health diagnose. $ devlink -j health diagnose pci/0000:01:00.0 reporter fw {"last_heartbeat":{"fw_uptime":{"sec":201,"msec":76}}} $ devlink -j health diagnose pci/0000:01:00.0 reporter fw last_heartbeat: fw_uptime: sec: 201 msec: 76 Reviewed-by: Lee Trager <lee@trager.us> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-9-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: add FW health reporterJakub Kicinski
Add a health reporter to catch FW crashes. Dumping the reporter if FW has not crashed will create a snapshot of FW memory. Reviewed-by: Lee Trager <lee@trager.us> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-8-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: support FW communication for core dumpJakub Kicinski
To read FW core dump we need to issue two commands to FW: - first get the FW core dump info - second read the dump chunk by chunk Implement these two FW commands. Subsequent commits will use them to expose FW dump via devlink heath. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-7-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: support allocating FW completions with extra spaceJakub Kicinski
Support allocating extra space after the FW completion. This makes it easy to pass extra variable size buffer space to FW response handlers without worrying about synchronization (completion itself is already refcounted). Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-6-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: reprogram TCAMs after FW crashJakub Kicinski
FW may mess with the TCAM after it boots, to try to restore the traffic flow to the BMC (it may not be aware that the host is already up). Make sure that we reprogram the TCAMs after detecting a crash. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-5-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: factor out clearing the action TCAMJakub Kicinski
We'll want to wipe the driver TCAM state after FW crash, to force a re-programming. Factor out the clearing logic. Remove the micro- -optimization to skip clearing the BMC entry twice, it doesn't hurt. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-4-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: use fw uptime to detect fw crashesJakub Kicinski
Currently we only detect FW crashes when it stops responding to heartbeat messages. FW has a watchdog which will reset it in case of crashes. Use FW uptime sent in the ownership and heartbeat messages to detect that the watchdog has fired (uptime went down). Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-3-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: make fbnic_fw_log_write() parameter constJakub Kicinski
Make the log message parameter const, it's not modified and this lets us pass in strings which are const for the caller. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916231420.1693955-2-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18net: renesas: rswitch: simplify rswitch_stop()Yury Norov (NVIDIA)
rswitch_stop() opencodes for_each_set_bit(). CC: Simon Horman <horms@kernel.org> Reviewed-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250916163516.486827-1-yury.norov@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-18eth: fbnic: support devmem TxJakub Kicinski
Support devmem Tx. We already use skb_frag_dma_map(), we just need to make sure we don't try to unmap the frags. Check if frag is unreadable and mark the ring entry. # ./tools/testing/selftests/drivers/net/hw/devmem.py TAP version 13 1..3 ok 1 devmem.check_rx ok 2 devmem.check_tx ok 3 devmem.check_tx_chunks # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0 Acked-by: Mina Almasry <almasrymina@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250916145401.1464550-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-17net/mlx5e: Use the 'num_doorbells' devlink paramCosmin Ratiu
Use the new devlink param to control how many doorbells mlx5e devices allocate and use. The maximum number of doorbells configurable is capped to the maximum number of channels. This only applies to the Ethernet part, the RDMA devices using mlx5 manage their own doorbells. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Use multiple CQ doorbellsCosmin Ratiu
Channel doorbells are now also used by all channel CQs. A new 'uar' parameter is added to 'struct mlx5e_create_cq_param', which is then used in mlx5e_alloc_cq. A single UAR page has two TX doorbells and a single CQ doorbell, so every consecutive pair of 'struct mlx5_sq_bfreg' (TX doorbells) uses the same underlying 'struct mlx5_uars_page' (CQ doorbell). So by using c->bfreg->up, CQs from every consecutive channel pair will share the same CQ doorbell. Non-channel associated CQs keep using the global CQ doorbell. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Use multiple TX doorbellsCosmin Ratiu
First, allocate more doorbells in mlx5e_create_mdev_resources: - one doorbell remains 'global' and will be used by all non-channel associated SQs (e.g. ASO, HWS, PTP, ...). - allocate additional 'num_doorbells' doorbells. This defaults to minimum between 8 and max number of channels. mlx5e_channel_pick_doorbell() now spreads out channel SQs across available doorbells. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Prepare for using different CQ doorbellsCosmin Ratiu
Completion queues (CQs) in mlx5 use the same global doorbell, which may become contended when accessed concurrently from many cores. This patch prepares the CQ management code for supporting different doorbells per CQ. This will be used in downstream patches to allow separate doorbells to be used by channels CQs. The main change is moving the 'uar' pointer from struct mlx5_core_cq to struct mlx5e_cq, as the uar page to be used is better off stored directly there. Other users of mlx5_core_cq also store the UAR to be used separately and therefore the pointer being removed is dead weight for them. As evidence, in this patch there are two users which set the mcq.uar pointer but didn't use it, Software Steering and old Innova CQ creation code. Instead, they rang the doorbell directly from another pointer. The 'uar' pointer added to struct mlx5e_cq remains in a hot cacheline (as before), because it may get accessed for each packet. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Prepare for using multiple TX doorbellsCosmin Ratiu
The driver allocates a single doorbell per device and uses it for all Send Queues (SQs). This can become a bottleneck due to the high number of concurrent MMIO accesses when ringing the same doorbell from many channels. This patch makes the doorbells used by channel queues configurable. mlx5e_channel_pick_doorbell() is added to select the doorbell to be used for a given channel, picking the default for now. When opening a channel, the selected doorbell is saved to the channel struct and used whenever channel-related queues are created. Finally, 'uar_page' is added to 'struct mlx5e_create_sq_param' to control which doorbell to use when allocating an SQ, since that can happen outside channel context (e.g. for PTP). Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5: Store the global doorbell in mlx5_privCosmin Ratiu
The global doorbell is used for more than just Ethernet resources, so move it out of mlx5e_hw_objs into a common place (mlx5_priv), to avoid non-Ethernet modules (e.g. HWS, ASO) depending on Ethernet structs. Use this opportunity to consolidate it with the 'uar' pointer already there, which was used as an RX doorbell. Underneath the 'uar' pointer is identical to 'bfreg->up', so store a single resource and use that instead. For CQ doorbells, care is taken to always use bfreg->up->index instead of bfreg->index, which may refer to a subsequent UAR page from the same ALLOC_UAR batch on some NICs. This paves the way for cleanly supporting multiple doorbells in the Ethernet driver. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5e: Remove unused 'xsk' param of mlx5e_build_xdpsq_paramCosmin Ratiu
This was added in commit [1], but its only use removed in commit [2]. The parameter is unused, so remove it from the function parameter list. [1] commit 9ded70fa1d81 ("net/mlx5e: Don't prefill WQEs in XDP SQ in the multi buffer mode") [2] commit 1a9304859b3a ("net/mlx5: XDP, Enable TX side XDP multi-buffer support") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5: Remove unused 'offset' field from mlx5_sq_bfregCosmin Ratiu
The 'offset' field was introduced in the original commit [1] and never used until commit [2], which added an unnecessary use. Remove the field and refactor the write-combining test to use a local variable instead. [1] commit a6d51b68611e ("net/mlx5: Introduce blue flame register allocator") [2] commit d98995b4bf98 ("net/mlx5: Reimplement write combining test") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net/mlx5: Fix typo of MLX5_EQ_DOORBEL_OFFSETCosmin Ratiu
Also convert it to a simple define. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-18wifi: rtw89: wow: enable TKIP related featureChih-Kang Chang
For chips that supports TKIP HW encryption and decryption, enable TKIP cipher for WoWLAN feature. Additionally, the TX MIC KEY and RX MIC KEY is opposite in FW. Therefore, reverse the MIC KEY direction in H2C format, and also reverse it from AOAC report before reporting to mac80211. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065434.39324-1-pkshih@realtek.com
2025-09-17net: dsa: mv88e6xxx: move mv88e6xxx_hwtstamp_work() prototypeRussell King (Oracle)
Since mv88e6xxx_hwtstamp_work() is defined in hwtstamp.c, its prototype should be in hwtstamp.h, so move it there. Remove it's redundant stub definition, as both hwtstamp.c (the function provider) and ptp.c (the consumer) are both dependent on the same config symbol. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove unused 88E6165 register definitionsRussell King (Oracle)
Remove the unused 88E6165 register definitions. For the port registers, add a comment describing that each arrival and departure offset is for a set of four registers that correspond with status, two timestamp registers and the PTP sequence ID captured from the packet. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove duplicated register definitionRussell King (Oracle)
There are two identical MV88E6XXX_PTP_GC_ETYPE definitions in ptp.h, and MV88E6XXX_PTP_ETHERTYPE in hwtstamp.h which all refer to the exact same register. As the code that accesses this register is in hwtstamp.c, use the hwtstamp.h definition, and remove the unnecessary duplicated definition in ptp.h Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: remove unused TAI definitionsRussell King (Oracle)
Remove the TAI definitions that the code never uses. Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-17net: dsa: mv88e6xxx: rename TAI definitions according to coreRussell King (Oracle)
The TAI_EVENT_STATUS and TAI_CFG definitions are only used for the 88E6352-family of TAI implementations. Rename them as such, and remove the TAI_EVENT_TIME_* definitions that are unused (although we read them as a block.) Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-18wifi: rtw89: 8922a: add TAS feature supportKuan-Chung Chen
Add TAS support for 8922AE. Unlike AX ICs, BE ICs introduce a TAS timer switch. The firmware starts a TAS timer to periodically collect TX power information and notify the driver via C2H events. To avoid unnecessary C2H events, the TAS timer is enabled during core_start(). Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065429.39269-1-pkshih@realtek.com
2025-09-18wifi: rtw89: open C2H event waiting window first before sending H2C commandZong-Zhe Yang
Some H2C commands need to wait for target C2H events to confirm they are executed well. The characteristics of a target C2H event will be encoded into a value, called condition. Then, the corresponding H2C command will wait for it. And, C2H events will complete a condition according to their own characteristics. So, when conditions of both side match, the corresponding H2C command will be completed. Originally, condition waiting window is opened after the H2C command is sent. However, for CPU-bound systems, target C2H event might be already done before the H2C command opens condition waiting window. Without that, C2H event won't match condition, and it will complete nothing. Finally, H2C command wait will time out. Hence, now open condition waiting window first for H2C commands which need to wait for target C2H events. The waiting function is split to two parts, prepare and evaluate. And, waiting side becomes the below where prepare part and evaluate part must be a pair. waiting prepare: condition (open condition waiting window) Do the needed things to trigger completing side. Record errors that will cause no real completer. waiting evaluate: prepare, errors (start waiting for completion if things are fine; otherwise, clean up and return final result.) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065352.39082-1-pkshih@realtek.com
2025-09-18wifi: rtw89: renew a completion for each H2C command waiting C2H eventZong-Zhe Yang
Logically before a waiting side which has already timed out turns the atomic status back to idle, a completing side could still pass atomic condition and call complete. It will make the following H2C commands, waiting C2H events, get a completion unexpectedly early. Hence, renew a completion for each H2C command waiting a C2H event. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065343.39023-1-pkshih@realtek.com
2025-09-18wifi: rtw89: 8852b: enable beacon tracking supportKuan-Chung Chen
Enable beacon tracking support on 8852B to improve connection stability. 8852B firmware has supported the power level H2C since version 0.29.128. This H2C is one of the required elements for beacon tracking, allowing control of the maximum receive window while in power save mode. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065337.38966-1-pkshih@realtek.com
2025-09-18wifi: rtw89: debug: support SER L0 simulationZong-Zhe Yang
SER (system error recovery) can deal with different crash types by different levels of processes. Now, add a debug function to trigger MAC error in purpose for SER L0 simulation/verification. And, extend dbgfs fw_crash to accept different parameters. # simulate MAC error (one kind of SER L0) echo 3 > fw_crash Normally, FW won't report SER L0 cases to driver. Instead, they will be handled by FW directly. If unfortunately FW handling fails, SER will rise to L1 and be reported to driver. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250915065329.38911-1-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-10 11:44:36 +0000