summaryrefslogtreecommitdiffstats
path: root/drivers/net
Commit message (Collapse)AuthorAgeFilesLines
* mlxsw: spectrum_router: Avoid allocating NH counters twicePetr Machata2024-03-111-0/+3
| | | | | | | | | | | | mlxsw_sp_nexthop_counter_disable() decays to a nop when called on a disabled counter, but mlxsw_sp_nexthop_counter_enable() can't similarly be called on an enabled counter. This would be useful in the following patches. Add the missing condition. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/0cc9050e196366c1387ab5ee47f1cee8ecde9c86.1709901020.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* mlxsw: spectrum: Allow fetch-and-clear of flow countersPetr Machata2024-03-115-9/+11
| | | | | | | | | | | | For the report_delta-like interface like a previous patch has added for collection of NH group statistics, it's easiest to read the counter and have the HW clear it right away. Thus, change mlxsw_sp_flow_counter_get() to take a bool indicating whether this should be done. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/6a096ede8ee92d5041e3832242c3bbc137198aba.1709901020.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* mlxsw: spectrum_router: Have mlxsw_sp_nexthop_counter_enable() return intPetr Machata2024-03-113-12/+36
| | | | | | | | | | In order to be able to diagnose failures in counter allocation, have the function mlxsw_sp_nexthop_counter_enable() return an error code. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/e0bb5c0cc6234ade2ade1e92abac991359c3f446.1709901020.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* mlxsw: spectrum_router: Rename two functionsPetr Machata2024-03-113-19/+19
| | | | | | | | | | | | | The function mlxsw_sp_nexthop_counter_alloc() doesn't directly allocate anything, and mlxsw_sp_nexthop_counter_free() doesn't directly free. For the following patches, we will need names for functions that actually do those things. Therefore rename to mlxsw_sp_nexthop_counter_enable() and mlxsw_sp_nexthop_counter_disable() to free up the namespace. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/f59272958697a718f090f59f892d32beabcd8972.1709901020.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: netconsole: Add continuation line prefix to userdata messagesMatthew Wood2024-03-111-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a space (' ') prefix to every userdata line to match docs for dev-kmsg. To account for this extra character in each userdata entry, reduce userdata entry names (directory name) from 54 characters to 53. According to the dev-kmsg docs, a space is used for subsequent lines to mark them as continuation lines. > A line starting with ' ', is a continuation line, adding > key/value pairs to the log message, which provide the machine > readable context of the message, for reliable processing in > userspace. Testing for this patch:: cd /sys/kernel/config/netconsole && mkdir cmdline0 cd cmdline0 mkdir userdata/test && echo "hello" > userdata/test/value mkdir userdata/test2 && echo "hello2" > userdata/test2/value echo "message" > /dev/kmsg Outputs:: 6.8.0-rc5-virtme,12,493,231373579,-;message test=hello test2=hello2 And I confirmed all testing works as expected from the original patchset Fixes: df03f830d099 ("net: netconsole: cache userdata formatted string in netconsole_target") Signed-off-by: Matthew Wood <thepacketgeek@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20240308002525.248672-1-thepacketgeek@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* r8169: switch to new function phy_support_eeeHeiner Kallweit2024-03-111-2/+1
| | | | | | | | | | Switch to new function phy_support_eee. This allows to simplify the code because data->tx_lpi_enabled is now populated by phy_ethtool_get_eee(). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/92462328-5c9b-4d82-9ce4-ea974cda4900@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: phy: simplify a check in phy_check_link_statusHeiner Kallweit2024-03-111-2/+2
| | | | | | | | | | | | Handling case err == 0 in the other branch allows to simplify the code. In addition I assume in "err & phydev->eee_cfg.tx_lpi_enabled" it should have been a logical and operator. It works as expected also with the bitwise and, but using a bitwise and with a bool value looks ugly to me. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/de37bf30-61dd-49f9-b645-2d8ea11ddb5d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: phy: marvell-88x2222: Remove unused of_gpio.hAndy Shevchenko2024-03-111-2/+0
| | | | | | | | | of_gpio.h is deprecated and subject to remove. The driver doesn't use it, simply remove the unused header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240307122346.3677534-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mt7530: disable LEDs before resetJustin Swartz2024-03-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable LEDs just before resetting the MT7530 to avoid situations where the ESW_P4_LED_0 and ESW_P3_LED_0 pin states may cause an unintended external crystal frequency to be selected. The HT_XTAL_FSEL (External Crystal Frequency Selection) field of HWTRAP (the Hardware Trap register) stores a 2-bit value that represents the state of the ESW_P4_LED_0 and ESW_P4_LED_0 pins (seemingly) sampled just after the MT7530 has been reset, as: ESW_P4_LED_0 ESW_P3_LED_0 Frequency ----------------------------------------- 0 1 20MHz 1 0 40MHz 1 1 25MHz The value of HT_XTAL_FSEL is bootstrapped by pulling ESW_P4_LED_0 and ESW_P3_LED_0 up or down accordingly, but: if a 40MHz crystal has been selected and the ESW_P3_LED_0 pin is high during reset, or a 20MHz crystal has been selected and the ESW_P4_LED_0 pin is high during reset, then the value of HT_XTAL_FSEL will indicate that a 25MHz crystal is present. By default, the state of the LED pins is PHY controlled to reflect the link state. To illustrate, if a board has: 5 ports with active low LED control, and HT_XTAL_FSEL bootstrapped for 40MHz. When the MT7530 is powered up without any external connection, only the LED associated with Port 3 is illuminated as ESW_P3_LED_0 is low. In this state, directly after mt7530_setup()'s reset is performed, the HWTRAP register (0x7800) reflects the intended HT_XTAL_FSEL (HWTRAP bits 10:9) of 40MHz: mt7530-mdio mdio-bus:1f: mt7530_read: 00007800 == 00007dcf >>> bin(0x7dcf >> 9 & 0b11) '0b10' But if a cable is connected to Port 3 and the link is active before mt7530_setup()'s reset takes place, then HT_XTAL_FSEL seems to be set for 25MHz: mt7530-mdio mdio-bus:1f: mt7530_read: 00007800 == 00007fcf >>> bin(0x7fcf >> 9 & 0b11) '0b11' Once HT_XTAL_FSEL reflects 25MHz, none of the ports are functional until the MT7621 (or MT7530 itself) is reset. By disabling the LED pins just before reset, the chance of an unintended HT_XTAL_FSEL value is reduced. Signed-off-by: Justin Swartz <justin.swartz@risingedge.co.za> Link: https://lore.kernel.org/r/20240305043952.21590-1-justin.swartz@risingedge.co.za Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: mdio_bus: Remove unused of_gpio.hAndy Shevchenko2024-03-111-2/+0
| | | | | | | | | of_gpio.h is deprecated and subject to remove. The driver doesn't use it, simply remove the unused header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240307122231.3677241-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: wan: fsl_qmc_hdlc: Add framer supportHerve Codina2024-03-111-5/+234
| | | | | | | | | | | | | Add framer support in the fsl_qmc_hdlc driver in order to be able to signal carrier changes to the network stack based on the framer status Also use this framer to provide information related to the E1/T1 line interface on IF_GET_IFACE and configure the line interface according to IF_IFACE_{E1,T1} information. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: wan: fsl_qmc_hdlc: Add runtime timeslots changes supportHerve Codina2024-03-111-1/+150
| | | | | | | | | | | | | QMC channels support runtime timeslots changes but nothing is done at the QMC HDLC driver to handle these changes. Use existing IFACE ioctl in order to configure the timeslots to use. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: wan: Add support for QMC HDLCHerve Codina2024-03-113-0/+432
| | | | | | | | | | | The QMC HDLC driver provides support for HDLC using the QMC (QUICC Multichannel Controller) to transfer the HDLC data. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch '100GbE' of ↵David S. Miller2024-03-113-5/+145
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== ethtool: ice: Support for RSS settings to GTP Takeru Hayasaka enables RSS functionality for GTP packets on ice driver with ethtool. A user can include TEID and make RSS work for GTP-U over IPv4 by doing the following:`ethtool -N ens3 rx-flow-hash gtpu4 sde` In addition to gtpu(4|6), we now support gtpc(4|6),gtpc(4|6)t,gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d. gtpc(4|6): Used for GTP-C in IPv4 and IPv6, where the GTP header format does not include a TEID. gtpc(4|6)t: Used for GTP-C in IPv4 and IPv6, with a GTP header format that includes a TEID. gtpu(4|6): Used for GTP-U in both IPv4 and IPv6 scenarios. gtpu(4|6)e: Used for GTP-U with extended headers in both IPv4 and IPv6. gtpu(4|6)u: Used when the PSC (PDU session container) in the GTP-U extended header includes Uplink, applicable to both IPv4 and IPv6. gtpu(4|6)d: Used when the PSC in the GTP-U extended header includes Downlink, for both IPv4 and IPv6. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * ice: Implement RSS settings for GTP using ethtoolTakeru Hayasaka2024-03-063-5/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following the addition of new GTP RSS hash options to ethtool.h, this patch implements the corresponding RSS settings for GTP packets in the Intel ice driver. It enables users to configure RSS for GTP-U and GTP-C traffic over IPv4 and IPv6, utilizing the newly defined hash options. The implementation covers the handling of gtpu(4|6), gtpc(4|6), gtpc(4|6)t, gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d traffic, providing enhanced load distribution for GTP traffic across multiple processing units. Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
* | Merge tag 'mlx5-socket-direct-v3' of ↵Jakub Kicinski2024-03-0830-172/+989
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== Support Multi-PF netdev (Socket Direct) This series adds support for combining multiple devices (PFs) of the same port under one netdev instance. Passing traffic through different devices belonging to different NUMA sockets saves cross-numa traffic and allows apps running on the same netdev from different numas to still feel a sense of proximity to the device and achieve improved performance. We achieve this by grouping PFs together, and creating the netdev only once all group members are probed. Symmetrically, we destroy the netdev once any of the PFs is removed. The channels are distributed between all devices, a proper configuration would utilize the correct close numa when working on a certain app/cpu. We pick one device to be a primary (leader), and it fills a special role. The other devices (secondaries) are disconnected from the network in the chip level (set to silent mode). All RX/TX traffic is steered through the primary to/from the secondaries. Currently, we limit the support to PFs only, and up to two devices (sockets). * tag 'mlx5-socket-direct-v3' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: Documentation: networking: Add description for multi-pf netdev net/mlx5: Enable SD feature net/mlx5e: Block TLS device offload on combined SD netdev net/mlx5e: Support per-mdev queue counter net/mlx5e: Support cross-vhca RSS net/mlx5e: Let channels be SD-aware net/mlx5e: Create EN core HW resources for all secondary devices net/mlx5e: Create single netdev per SD group net/mlx5: SD, Add debugfs net/mlx5: SD, Add informative prints in kernel log net/mlx5: SD, Implement steering for primary and secondaries net/mlx5: SD, Implement devcom communication and primary election net/mlx5: SD, Implement basic query and instantiation net/mlx5: SD, Introduce SD lib net/mlx5: Add MPIR bit in mcam_access_reg ==================== Link: https://lore.kernel.org/r/20240307084229.500776-1-saeed@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | net/mlx5: Enable SD featureTariq Toukan2024-03-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Have an actual mlx5_sd instance in the core device, and fix the getter accordingly. This allows SD stuff to flow, the feature becomes supported only here. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5e: Block TLS device offload on combined SD netdevTariq Toukan2024-03-072-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) Each TX TLS device offloaded context has its own TIS object. Extra work is needed to get it working in a SD environment, where a stream can move between different SQs (belonging to different mdevs). 2) Each RX TLS device offloaded context needs a DEK object from the DEK pool. Extra work is needed to get it working in a SD environment, as the DEK pool currently falsely depends on TX cap, and is on the primary device only. Disallow this combination for now. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5e: Support per-mdev queue counterTariq Toukan2024-03-0710-69/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each queue counter object counts some events (in hardware) for the RQs that are attached to it, like events of packet drops due to no receive WQE (rx_out_of_buffer). Each RQ can be attached to a queue counter only within the same vhca. To still cover all RQs with these counters, we create multiple instances, one per vhca. The result that's shown to the user is now the sum of all instances. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5e: Support cross-vhca RSSTariq Toukan2024-03-0710-57/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement driver support for the HW feature that allows RX steering of one device to target other device's RQs. In SD multi-pf netdev mode, we set the secondaries into silent mode, disconnecting them from the network. This feature is then used to steer traffic from the primary to the secondaries. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5e: Let channels be SD-awareTariq Toukan2024-03-078-27/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Distribute the channels between the different SD-devices to acheive local numa node performance on multiple numas. Each channel works against one specific mdev, creating all datapath queues against it. We distribute channels to mdevs in a round-robin policy. Example for 2 mdevs and 6 channels: +-------+---------+ | ch ix | mdev ix | +-------+---------+ | 0 | 0 | | 1 | 1 | | 2 | 0 | | 3 | 1 | | 4 | 0 | | 5 | 1 | +-------+---------+ This round-robin distribution policy is preferred over another suggested intuitive distribution, in which we first distribute one half of the channels to mdev #0 and then the second half to mdev #1. We prefer round-robin for a reason: it is less influenced by changes in the number of channels. The mapping between channel index and mdev is fixed, no matter how many channels the user configures. As the channel stats are persistent to channels closure, changing the mapping every single time would turn the accumulative stats less representing of the channel's history. Per-channel objects should stop using the primary mdev (priv->mdev) directly, and instead move to using their own channel's mdev. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5e: Create EN core HW resources for all secondary devicesTariq Toukan2024-03-072-10/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | Traffic queues will be created on all devices, including the secondaries. Create the needed core layer resources for them as well. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5e: Create single netdev per SD groupTariq Toukan2024-03-071-7/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Integrate the SD library calls into the auxiliary_driver ops in preparation for creating a single netdev for the multiple PFs belonging to the same SD group. SD is still disabled at this stage. It is enabled by a downstream patch when all needed parts are implemented. The netdev is created whenever the SD group, with all its participants, are ready. It is later destroyed whenever any of the participating PFs drops. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5: SD, Add debugfsTariq Toukan2024-03-071-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add debugfs entries that describe the Socket-Direct group. Example: $ grep -H . /sys/kernel/debug/mlx5/0000\:08\:00.0/multi-pf/* /sys/kernel/debug/mlx5/0000:08:00.0/multi-pf/group_id:0x00000101 /sys/kernel/debug/mlx5/0000:08:00.0/multi-pf/primary:0000:08:00.0 vhca 0x0 /sys/kernel/debug/mlx5/0000:08:00.0/multi-pf/secondary_0:0000:09:00.0 vhca 0x2 Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5: SD, Add informative prints in kernel logTariq Toukan2024-03-071-0/+21
| | | | | | | | | | | | | | | | | | | | | Print to kernel log when an SD group moves from/to ready state. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5: SD, Implement steering for primary and secondariesTariq Toukan2024-03-071-1/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement the needed SD steering adjustments for the primary and secondaries. While the SD multiple PFs are used to avoid cross-numa memory, when it comes to chip level all traffic goes only through the primary device. The secondaries are forced to silent mode, to guarantee they are not involved in any unexpected ingress/egress traffic. In RX, secondary devices will not have steering objects. Traffic will be steered from the primary device to the RQs of a secondary device using advanced cross-vhca RX steering capabilities. In TX, the primary creates a new TX flow table, which is aliased by the secondaries. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5: SD, Implement devcom communication and primary electionTariq Toukan2024-03-072-2/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use devcom to communicate between the different devices. Add a new devcom component type for this. Each device registers itself to the devcom component <SD, group ID>. Once all devices of a component are registered, the component becomes ready, and a primary device is elected. In principle, any of the devices can act as a primary, they are all capable, and a random election would've worked. However, we aim to achieve predictability and consistency, hence each group always choses the same device, with the lowest PCI BUS number, as primary. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5: SD, Implement basic query and instantiationTariq Toukan2024-03-071-1/+109
| | | | | | | | | | | | | | | | | | | | | | | | Add implementation for querying the MPIR register for Socket-Direct attributes, and instantiating a SD struct accordingly. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
| * | net/mlx5: SD, Introduce SD libTariq Toukan2024-03-074-1/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add Socket-Direct API with empty/minimal implementation. We fill-in the implementation gradually in downstream patches. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
* | | Merge tag 'ieee802154-for-net-next-2024-03-07' of ↵Jakub Kicinski2024-03-084-16/+8
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next Stefan Schmidt says: ==================== pull-request: ieee802154-next 2024-03-07 Various cross tree patches for ieee802154v drivers and a resource leak fix for ieee802154 llsec. Andy Shevchenko changed GPIO header usage for at86rf230 and mcr20a to only include needed headers. Bo Liu converted the at86rf230, mcr20a and mrf24j40 driver regmap support to use the maple tree register cache. Fedor Pchelkin fixed a resource leak in the llsec key deletion path. Ricardo B. Marliere made wpan_phy_class const. Tejun Heo removed WQ_UNBOUND from a workqueue call in ca8210. * tag 'ieee802154-for-net-next-2024-03-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next: ieee802154: cfg802154: make wpan_phy_class constant ieee802154: mcr20a: Remove unused of_gpio.h ieee802154: at86rf230: Replace of_gpio.h by proper one mac802154: fix llsec key resources release in mac802154_llsec_key_del ieee802154: ca8210: Drop spurious WQ_UNBOUND from alloc_ordered_workqueue() call net: ieee802154: mrf24j40: convert to use maple tree register cache net: ieee802154: mcr20a: convert to use maple tree register cache net: ieee802154: at86rf230: convert to use maple tree register cache ==================== Link: https://lore.kernel.org/r/20240307195105.292085-1-stefan@datenfreihafen.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | | ieee802154: mcr20a: Remove unused of_gpio.hAndy Shevchenko2024-03-061-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of_gpio.h is deprecated and subject to remove. The driver doesn't use it, simply remove the unused header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Message-ID: <20240304175320.1199496-1-andriy.shevchenko@linux.intel.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
| * | | ieee802154: at86rf230: Replace of_gpio.h by proper oneAndy Shevchenko2024-03-061-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of_gpio.h is deprecated and subject to remove. The driver doesn't use it directly, replace it with what is really being used. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Message-ID: <20240304174218.1198411-1-andriy.shevchenko@linux.intel.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
| * | | ieee802154: ca8210: Drop spurious WQ_UNBOUND from alloc_ordered_workqueue() callTejun Heo2024-02-261-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Workqueue is in the process of cleaning up the distinction between unbound workqueues w/ @nr_active==1 and ordered workqueues. Explicit WQ_UNBOUND isn't needed for alloc_ordered_workqueue() and will trigger a warning in the future. Let's remove it. This doesn't cause any functional changes. Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Message-ID: <ZcF1El7fn5xkeoB1@slm.duckdns.org> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
| * | | net: ieee802154: mrf24j40: convert to use maple tree register cacheBo Liu2024-02-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Message-ID: <20240202064659.39434-1-liubo03@inspur.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
| * | | net: ieee802154: mcr20a: convert to use maple tree register cacheBo Liu2024-02-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Message-ID: <20240202064611.39346-1-liubo03@inspur.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
| * | | net: ieee802154: at86rf230: convert to use maple tree register cacheBo Liu2024-02-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Message-ID: <20240202064512.39259-1-liubo03@inspur.com> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
* | | | Merge tag 'wireless-next-2024-03-08' of ↵Jakub Kicinski2024-03-08102-998/+2580
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.9 The fourth "new features" pull request for v6.9 with changes both in stack and in drivers. The theme in this pull request is to fix sparse warnings but we still have some left in wireless subsystem. Otherwise quite normal. Major changes: rtw89 * NL80211_EXT_FEATURE_SCAN_RANDOM_SN support * NL80211_EXT_FEATURE_SET_SCAN_DWELL support rtw88 * support for more rtw8811cu and rtw8821cu devices mt76 * mt76x2u: add Netgear WNDA3100v3 USB * mt7915: newer ADIE version support * mt7925: radio temperature sensor support * mt7996: remove GCMP IGTK offload * tag 'wireless-next-2024-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (125 commits) wifi: rtw89: wow: move release offload packet earlier for WoWLAN mode wifi: rtw89: wow: set security engine options for 802.11ax chips only wifi: rtw89: update suspend/resume for different generation wifi: rtw89: wow: update config mac function with different generation wifi: rtw89: update DMA function with different generation wifi: rtw89: wow: update WoWLAN status register for different generation wifi: rtw89: wow: update WoWLAN reason register for different chips wifi: brcm80211: handle pmk_op allocation failure wifi: rtw89: coex: Add coexistence policy to decrease WiFi packet CRC-ERR wifi: rtw89: coex: When Bluetooth not available don't set power/gain wifi: rtw89: coex: add return value to ensure H2C command is success or not wifi: rtw89: coex: Reorder H2C command index to align with firmware wifi: rtw89: coex: add BTC ctrl_info version 7 and related logic wifi: rtw89: coex: add init_info H2C command format version 7 wifi: rtw89: 8922a: add coexistence helpers of SW grant wifi: rtw89: mac: add coexistence helpers {cfg/get}_plt wifi: cw1200: restore endian swapping wifi: wlcore: sdio: Rate limit wl12xx_sdio_raw_{read,write}() failures warns wifi: rtlwifi: Remove rtl_intf_ops.read_efuse_byte wifi: rtw88: 8821c: Fix false alarm count ... ==================== Link: https://lore.kernel.org/r/20240308100429.B8EA2C433F1@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * \ \ \ Merge tag 'ath-next-20240305' of ↵Kalle Valo2024-03-058-72/+26
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath ath.git patches for v6.9 Only some minor cleanup in ath11k and ath12k. Adding Jeff as the maintainer for ath10k, ath11k and ath12k DT bindings.
| | * | | | wifi: ath12k: fix license in p2p.c and p2p.hKalle Valo2024-02-282-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ath12k uses BSD-3-Clause-Clear, not ISC. Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://msgid.link/20240226180745.3195805-1-kvalo@kernel.org
| | * | | | wifi: ath11k: constify MHI channel and controller configsJeff Johnson2024-02-281-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unlike the event configuration which can be modified by MHI, the channel and controller configurations are expected to be const. And since they are not modified locally, constify them to prevent runtime modification. No functional changes, compile tested only. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://msgid.link/20240223-mhi-const-wifi-ath11k-v1-1-51b9d42d2639@quicinc.com
| | * | | | wifi: ath12k: add rcu lock for ath12k_wmi_p2p_noa_event()Kang Yang2024-02-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Warning will appear when running P2P GO: WARNING: suspicious RCU usage drivers/net/wireless/ath/ath12k/mac.c:583 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by swapper/0/0. stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.8.0-rc4-wt-ath+ #4 Call Trace: <IRQ> dump_stack_lvl+0x82/0xa0 dump_stack+0x14/0x20 lockdep_rcu_suspicious+0x214/0x3b0 ath12k_mac_get_ar_by_vdev_id+0x192/0x220 [ath12k] ath12k_wmi_op_rx+0x2d7/0x1b40 [ath12k] ath12k_mac_get_ar_by_vdev_id() requires its callers to have called rcu_read_lock(), but in ath12k_wmi_p2p_noa_event() it is called without doing so, and hence the warning was triggered. Add rcu_read_lock() and rcu_read_unlock() to avoid warning. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 9411eecb60cb ("wifi: ath12k: implement handling of P2P NoA event") Reported-by: Kalle Valo <quic_kvalo@quicinc.com> Closes: https://lore.kernel.org/linux-wireless/87o7cusyvw.fsf@kernel.org/ Signed-off-by: Kang Yang <quic_kangyang@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://msgid.link/20240223054505.438839-1-quic_kangyang@quicinc.com
| | * | | | wifi: ath11k: decrease MHI channel buffer length to 8KBBaochen Qiang2024-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently buf_len field of ath11k_mhi_config_qca6390 is assigned with 0, making MHI use a default size, 64KB, to allocate channel buffers. This is likely to fail in some scenarios where system memory is highly fragmented and memory compaction or reclaim is not allowed. There is a fail report which is caused by it: kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb Workqueue: events_unbound async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/0x1b0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0 __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] device_for_each_child+0x5c/0xa0 ? __pfx_pci_pm_resume+0x10/0x10 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e] ? srso_alias_return_thunk+0x5/0xfbef5 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec] ? srso_alias_return_thunk+0x5/0xfbef5 dpm_run_callback+0x8c/0x1e0 device_resume+0x104/0x340 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x32/0x120 process_one_work+0x168/0x330 worker_thread+0x2f5/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe8/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Actually those buffers are used only by QMI target -> host communication. And for WCN6855 and QCA6390, the largest packet size for that is less than 6KB. So change buf_len field to 8KB, which results in order 1 allocation if page size is 4KB. In this way, we can at least save some memory, and as well as decrease the possibility of allocation failure in those scenarios. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Reported-by: Vlastimil Babka <vbabka@suse.cz> Closes: https://lore.kernel.org/ath11k/96481a45-3547-4d23-ad34-3a8f1d90c1cd@suse.cz/ Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://msgid.link/20240223053111.29170-1-quic_bqiang@quicinc.com
| | * | | | wifi: ath11k: thermal: don't try to register multiple timesKalle Valo2024-02-231-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Every time the firmware boots we call ath11k_core_qmi_firmware_ready() which ends up calling ath11k_thermal_register(). So we try to register thermal devices multiple times. And when we power off the firmware during suspend/hibernation (implemented in the next patch) we get a warning in resume: hwmon hwmon4: PM: parent phy0 should not be sleeping Workaround this similarly like ath11k_mac_register() does by testing ATH11K_FLAG_REGISTERED. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://msgid.link/20240221024725.10057-6-quic_bqiang@quicinc.com
| | * | | | wifi: ath11k: fix warning on DMA ring capabilities eventBaochen Qiang2024-02-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are seeing below warning in both reset and suspend/resume scenarios: [69663.691847] ath11k_pci 0000:02:00.0: Already processed, so ignoring dma ring caps This is because ab->num_db_cap is not cleared in ath11k_wmi_free_dbring_caps(), so clear it to avoid such warnings. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://msgid.link/20240221024725.10057-5-quic_bqiang@quicinc.com
| | * | | | wifi: ath11k: do not dump SRNG statistics during resumeBaochen Qiang2024-02-231-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both the firmware reset feature and the power management suspend/resume feature share common power-down and power-up functionality. One aspect of the power-up functionality is the handling of the ATH11K_QMI_EVENT_FW_INIT_DONE event. When this event is received, a call is made to ath11k_hal_dump_srng_stats(), with the purpose to collect information that may be useful in debugging the cause of a firmware reset. Unfortunately, since this functionality is shared between both the firmware reset path and the power management resume path, the kernel log is flooded with messages during resume. Since these messages are not useful during resume, and in fact can be confusing and can increase the time it takes to resume, update the logic to only call ath11k_hal_dump_srng_stats() during firmware reset. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://msgid.link/20240221024725.10057-4-quic_bqiang@quicinc.com
| | * | | | wifi: ath11k: remove MHI LOOPBACK channelsBaochen Qiang2024-02-231-56/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no driver to match these two channels, so remove them. This fixes warnings from MHI subsystem during suspend: mhi mhi0_LOOPBACK: 1: Failed to reset channel, still resetting mhi mhi0_LOOPBACK: 0: Failed to reset channel, still resetting Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://msgid.link/20240221024725.10057-3-quic_bqiang@quicinc.com
| | * | | | wifi: ath11k: rearrange IRQ enable/disable in reset pathBaochen Qiang2024-02-231-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For non WoW suspend/resume, ath11k host powers down whole hardware when suspend and powers up it when resume, the code path it goes through is very like the ath11k reset logic. In order to reuse that logic, rearrange IRQ handling in the reset path. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://msgid.link/20240221024725.10057-2-quic_bqiang@quicinc.com
| * | | | | wifi: rtw89: wow: move release offload packet earlier for WoWLAN modeChin-Yen Lee2024-03-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now WoWLAN firmware will disable PCIE DMA after driver call cfg_wake function, and it will lead to release offload packet fail because driver can't receive completion notification from firmware. We move release offload packet earlier to avoid this error. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-8-pkshih@realtek.com
| * | | | | wifi: rtw89: wow: set security engine options for 802.11ax chips onlyChin-Yen Lee2024-03-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The security engine is set for management frames by default for 802.11be chips, so no need to set it in WoWLAN flow. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-7-pkshih@realtek.com
| * | | | | wifi: rtw89: update suspend/resume for different generationChin-Yen Lee2024-03-054-1/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The setting during suspend or resume is different between different generation, so update it. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240302005828.13666-6-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-14 04:38:26 +0000