summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-19gpu: host1x: Do not assume that a NULL domain means no DMA IOMMUJason Gunthorpe
Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain could have been left as NULL. The NULL domain is specially recognized by host1x_iommu_attach() as meaning it is not the DMA domain and should be replaced with the special shared domain. This happened prior to the below commit because tegra-smmu was using the NULL domain to mean IDENTITY. Now that the domain is properly labled the test in DRM doesn't see NULL. Check for IDENTITY as well to enable the special domains. This is the same issue and basic fix as seen in commit fae6e669cdc5 ("drm/tegra: Do not assume that a NULL domain means no DMA IOMMU"). Fixes: c8cc2655cc6c ("iommu/tegra-smmu: Implement an IDENTITY domain") Reported-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Closes: https://lore.kernel.org/all/c6a6f114-3acd-4d56-a13b-b88978e927dc@tecnico.ulisboa.pt/ Tested-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/0-v1-10dcc8ce3869+3a7-host1x_identity_jgg@nvidia.com
2025-03-19r8169: switch away from deprecated pcim_iomap_tableHeiner Kallweit
Avoid using deprecated pcim_iomap_table by switching to pcim_iomap_region. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/a36b4cf3-c792-40fa-8164-5dc9d5f14dd0@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19ASoC: ops: Apply platform_max after deciding control typeCharles Keepax
It doesn't really make sense for the type of a control to change based on the platform_max field. platform_max allows a specific system to limit values of a control for safety but it seems reasonable the control type should remain the same between different systems, even if it is restricted down to just two values. Move the application of platform_max to after control type determination in soc_info_volsw(). Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250319175123.3835849-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19ASoC: ops: Remove some unnecessary local variablesCharles Keepax
Remove some local variables that aren't adding much in terms of clarity or space saving. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250319175123.3835849-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19ASoC: ops: Factor out common code from get callbacksCharles Keepax
There are only two differences between snd_soc_get_volsw() and snd_soc_get_volsw_sx(). The maximum field is handled differently, and snd_soc_get_volsw() supports double controls with both values in the same register. Factor out the common code into a new helper and pass in the appropriate max value such that it is handled correctly for each control. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250319175123.3835849-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19Merge branch 'net-bring-back-dev_addr_sem'Paolo Abeni
Stanislav Fomichev says: ==================== net: bring back dev_addr_sem Kohei reports an issue with dev_addr_sem conversion to netdev instance lock in [0]. Based on the discussion, switching to netdev instance lock to protect the address might not work for the devices that are not using netdev ops lock. Bring dev_addr_sem instance lock back but fix the ordering. 0: https://lore.kernel.org/netdev/20250308203835.60633-2-enjuk@amazon.com ==================== Link: https://patch.msgid.link/20250312190513.1252045-1-sdf@fomichev.me Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net: reorder dev_addr_sem lockStanislav Fomichev
Lockdep complains about circular lock in 1 -> 2 -> 3 (see below). Change the lock ordering to be: - rtnl_lock - dev_addr_sem - netdev_ops (only for lower devices!) - team_lock (or other per-upper device lock) 1. rtnl_lock -> netdev_ops -> dev_addr_sem rtnl_setlink rtnl_lock do_setlink IFLA_ADDRESS on lower netdev_ops dev_addr_sem 2. rtnl_lock -> team_lock -> netdev_ops rtnl_newlink rtnl_lock do_setlink IFLA_MASTER on lower do_set_master team_add_slave team_lock team_port_add dev_set_mtu netdev_ops 3. rtnl_lock -> dev_addr_sem -> team_lock rtnl_newlink rtnl_lock do_setlink IFLA_ADDRESS on upper dev_addr_sem netif_set_mac_address team_set_mac_address team_lock 4. rtnl_lock -> netdev_ops -> dev_addr_sem rtnl_lock dev_ifsioc dev_set_mac_address_user __tun_chr_ioctl rtnl_lock dev_set_mac_address_user tap_ioctl rtnl_lock dev_set_mac_address_user dev_set_mac_address_user netdev_lock_ops netif_set_mac_address_user dev_addr_sem v2: - move lock reorder to happen after kmalloc (Kuniyuki) Cc: Kohei Enju <enjuk@amazon.com> Fixes: df43d8bf1031 ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20250312190513.1252045-3-sdf@fomichev.me Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Revert "net: replace dev_addr_sem with netdev instance lock"Stanislav Fomichev
This reverts commit df43d8bf10316a7c3b1e47e3cc0057a54df4a5b8. Cc: Kohei Enju <enjuk@amazon.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Fixes: df43d8bf1031 ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250312190513.1252045-2-sdf@fomichev.me Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19tc-tests: Update tc police action tests for tc buffer size rounding fixes.Jonathan Lennox
Before tc's recent change to fix rounding errors, several tests which specified a burst size of "1m" would translate back to being 1048574 bytes (2b less than 1Mb). sprint_size prints this as "1024Kb". With the tc fix, the burst size is instead correctly reported as 1048576 bytes (precisely 1Mb), which sprint_size prints as "1Mb". This updates the expected output in the tests' matchPattern values to accept either the old or the new output. Signed-off-by: Jonathan Lennox <jonathan.lennox@8x8.com> Link: https://patch.msgid.link/20250312174804.313107-1-jonathan.lennox@8x8.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19block: correct locking order for protecting blk-wbt parametersNilay Shroff
The commit '245618f8e45f ("block: protect wbt_lat_usec using q-> elevator_lock")' introduced q->elevator_lock to protect updates to blk-wbt parameters when writing to the sysfs attribute wbt_ lat_usec and the cgroup attribute io.cost.qos. However, both these attributes also acquire q->rq_qos_mutex, leading to the following lockdep warning: ====================================================== WARNING: possible circular locking dependency detected 6.14.0-rc5+ #138 Not tainted ------------------------------------------------------ bash/5902 is trying to acquire lock: c000000085d495a0 (&q->rq_qos_mutex){+.+.}-{4:4}, at: wbt_init+0x164/0x238 but task is already holding lock: c000000085d498c8 (&q->elevator_lock){+.+.}-{4:4}, at: queue_wb_lat_store+0xb0/0x20c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&q->elevator_lock){+.+.}-{4:4}: __mutex_lock+0xf0/0xa58 ioc_qos_write+0x16c/0x85c cgroup_file_write+0xc4/0x32c kernfs_fop_write_iter+0x1b8/0x29c vfs_write+0x410/0x584 ksys_write+0x84/0x140 system_call_exception+0x134/0x360 system_call_vectored_common+0x15c/0x2ec -> #0 (&q->rq_qos_mutex){+.+.}-{4:4}: __lock_acquire+0x1b6c/0x2ae0 lock_acquire+0x140/0x430 __mutex_lock+0xf0/0xa58 wbt_init+0x164/0x238 queue_wb_lat_store+0x1dc/0x20c queue_attr_store+0x12c/0x164 sysfs_kf_write+0x6c/0xb0 kernfs_fop_write_iter+0x1b8/0x29c vfs_write+0x410/0x584 ksys_write+0x84/0x140 system_call_exception+0x134/0x360 system_call_vectored_common+0x15c/0x2ec other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->elevator_lock); lock(&q->rq_qos_mutex); lock(&q->elevator_lock); lock(&q->rq_qos_mutex); *** DEADLOCK *** 6 locks held by bash/5902: #0: c000000051122400 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x84/0x140 #1: c00000007383f088 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x174/0x29c #2: c000000008550428 (kn->active#182){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x180/0x29c #3: c000000085d493a8 (&q->q_usage_counter(io)#5){++++}-{0:0}, at: blk_mq_freeze_queue_nomemsave+0x28/0x40 #4: c000000085d493e0 (&q->q_usage_counter(queue)#5){++++}-{0:0}, at: blk_mq_freeze_queue_nomemsave+0x28/0x40 #5: c000000085d498c8 (&q->elevator_lock){+.+.}-{4:4}, at: queue_wb_lat_store+0xb0/0x20c stack backtrace: CPU: 17 UID: 0 PID: 5902 Comm: bash Kdump: loaded Not tainted 6.14.0-rc5+ #138 Hardware name: IBM,9043-MRX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_028) hv:phyp pSeries Call Trace: [c0000000721ef590] [c00000000118f8a8] dump_stack_lvl+0x108/0x18c (unreliable) [c0000000721ef5c0] [c00000000022563c] print_circular_bug+0x448/0x604 [c0000000721ef670] [c000000000225a44] check_noncircular+0x24c/0x26c [c0000000721ef740] [c00000000022bf28] __lock_acquire+0x1b6c/0x2ae0 [c0000000721ef870] [c000000000229240] lock_acquire+0x140/0x430 [c0000000721ef970] [c0000000011cfbec] __mutex_lock+0xf0/0xa58 [c0000000721efaa0] [c00000000096c46c] wbt_init+0x164/0x238 [c0000000721efaf0] [c0000000008f8cd8] queue_wb_lat_store+0x1dc/0x20c [c0000000721efb50] [c0000000008f8fa0] queue_attr_store+0x12c/0x164 [c0000000721efc60] [c0000000007c11cc] sysfs_kf_write+0x6c/0xb0 [c0000000721efca0] [c0000000007bfa4c] kernfs_fop_write_iter+0x1b8/0x29c [c0000000721efcf0] [c0000000006a281c] vfs_write+0x410/0x584 [c0000000721efdc0] [c0000000006a2cc8] ksys_write+0x84/0x140 [c0000000721efe10] [c000000000031b64] system_call_exception+0x134/0x360 [c0000000721efe50] [c00000000000cedc] system_call_vectored_common+0x15c/0x2ec >From the above log it's apparent that method which writes to sysfs attr wbt_lat_usec acquires q->elevator_lock first, and then acquires q->rq_ qos_mutex. However the another method which writes to io.cost.qos, acquires q->rq_qos_mutex first, and then acquires q->rq_qos_mutex. So this could potentially cause the deadlock. A closer look at ioc_qos_write shows that correcting the lock order is non-trivial because q->rq_qos_mutex is acquired in blkg_conf_open_bdev and released in blkg_conf_exit. The function blkg_conf_open_bdev is responsible for parsing user input and finding the corresponding block device (bdev) from the user provided major:minor number. Since we do not know the bdev until blkg_conf_open_bdev completes, we cannot simply move q->elevator_lock acquisition before blkg_conf_open_ bdev. So to address this, we intoduce new helpers blkg_conf_open_bdev_ frozen and blkg_conf_exit_frozen which are just wrappers around blkg_ conf_open_bdev and blkg_conf_exit respectively. The helper blkg_conf_ open_bdev_frozen is similar to blkg_conf_open_bdev, but additionally freezes the queue, acquires q->elevator_lock and ensures the correct locking order is followed between q->elevator_lock and q->rq_qos_mutex. Similarly another helper blkg_conf_exit_frozen in addition to unfreezing the queue ensures that we release the locks in correct order. By using these helpers, now we maintain the same locking order in all code paths where we update blk-wbt parameters. Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202503171650.cc082b66-lkp@intel.com Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Link: https://lore.kernel.org/r/20250319105518.468941-3-nilay@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-03-19block: release q->elevator_lock in ioc_qos_writeNilay Shroff
The ioc_qos_write method acquires q->elevator_lock to protect updates to blk-wbt parameters. Once these updates are complete, the lock should be released before returning from ioc_qos_write. However, in one code path, the release of q->elevator_lock was mistakenly omitted, potentially leading to a lock leak. This commit fixes the issue by ensuring that q->elevator_lock is properly released in all return paths of ioc_qos_write. Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202503171650.cc082b66-lkp@intel.com Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250319105518.468941-2-nilay@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-03-19net: stmmac: dwmac-rk: Provide FIFO sizes for DWMAC 1000Chen-Yu Tsai
The DWMAC 1000 DMA capabilities register does not provide actual FIFO sizes, nor does the driver really care. If they are not provided via some other means, the driver will work fine, only disallowing changing the MTU setting. Provide the FIFO sizes through the driver's platform data to enable MTU changes. The FIFO sizes are confirmed to be the same across RK3288, RK3328, RK3399 and PX30, based on their respective manuals. It is likely that Rockchip synthesized their DWMAC 1000 with the same parameters on all their chips that have it. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250312163426.2178314-1-wens@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19cgroup/rstat: avoid disabling irqs for O(num_cpu)Eric Dumazet
cgroup_rstat_flush_locked() grabs the irq safe cgroup_rstat_lock while iterating all possible cpus. It only drops the lock if there is scheduler or spin lock contention. If neither, then interrupts can be disabled for a long time. On large machines this can disable interrupts for a long enough time to drop network packets. On 400+ CPU machines I've seen interrupt disabled for over 40 msec. Prevent rstat from disabling interrupts while processing all possible cpus. Instead drop and reacquire cgroup_rstat_lock for each cpu. This approach was previously discussed in https://lore.kernel.org/lkml/ZBz%2FV5a7%2F6PZeM7S@slm.duckdns.org/, though this was in the context of an non-irq rstat spin lock. Benchmark this change with: 1) a single stat_reader process with 400 threads, each reading a test memcg's memory.stat repeatedly for 10 seconds. 2) 400 memory hog processes running in the test memcg and repeatedly charging memory until oom killed. Then they repeat charging and oom killing. v6.14-rc6 with CONFIG_IRQSOFF_TRACER with stat_reader and hogs, finds interrupts are disabled by rstat for 45341 usec: # => started at: _raw_spin_lock_irq # => ended at: cgroup_rstat_flush # # # _------=> CPU# # / _-----=> irqs-off/BH-disabled # | / _----=> need-resched # || / _---=> hardirq/softirq # ||| / _--=> preempt-depth # |||| / _-=> migrate-disable # ||||| / delay # cmd pid |||||| time | caller # \ / |||||| \ | / stat_rea-96532 52d.... 0us*: _raw_spin_lock_irq stat_rea-96532 52d.... 45342us : cgroup_rstat_flush stat_rea-96532 52d.... 45342us : tracer_hardirqs_on <-cgroup_rstat_flush stat_rea-96532 52d.... 45343us : <stack trace> => memcg1_stat_format => memory_stat_format => memory_stat_show => seq_read_iter => vfs_read => ksys_read => do_syscall_64 => entry_SYSCALL_64_after_hwframe With this patch the CONFIG_IRQSOFF_TRACER doesn't find rstat to be the longest holder. The longest irqs-off holder has irqs disabled for 4142 usec, a huge reduction from previous 45341 usec rstat finding. Running stat_reader memory.stat reader for 10 seconds: - without memory hogs: 9.84M accesses => 12.7M accesses - with memory hogs: 9.46M accesses => 11.1M accesses The throughput of memory.stat access improves. The mode of memory.stat access latency after grouping by of 2 buckets: - without memory hogs: 64 usec => 16 usec - with memory hogs: 64 usec => 8 usec The memory.stat latency improves. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Greg Thelen <gthelen@google.com> Tested-by: Greg Thelen <gthelen@google.com> Acked-by: Michal Koutný <mkoutny@suse.com> Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-03-19selftests: drv-net: use defer in the ping testJakub Kicinski
Make sure the test cleans up after itself. The XDP off statements at the end of the test may not be reached. Fixes: 75cc19c8ff89 ("selftests: drv-net: add xdp cases for ping.py") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250312131040.660386-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Merge branch 'net-mlx5-hw-steering-cleanups'Paolo Abeni
Tariq Toukan says: ==================== net/mlx5: HW Steering cleanups This short series by Yevgeny contains several small HW Steering cleanups: - Patch 1: removing unused FW commands - Patch 2: using list_move() instead of list_del/add - Patch 3: printing the unsupported combination of match fields ==================== Link: https://patch.msgid.link/1741780194-137519-1-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net/mlx5: HWS, log the unsupported mask in definerYevgeny Kliteynik
If a user requested to match on an unsupported combination of fields, print the unsupported combination in the error message. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1741780194-137519-4-git-send-email-tariqt@nvidia.com Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net/mlx5: HWS, use list_move() instead of del/addYevgeny Kliteynik
Wherever applicable, use list_move function instead of list_del + list_add. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1741780194-137519-3-git-send-email-tariqt@nvidia.com Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net/mlx5: HWS, remove unused code for alias flow tablesYevgeny Kliteynik
Alias flow tables are not in use by HWS - remove the unused code. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1741780194-137519-2-git-send-email-tariqt@nvidia.com Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Merge branch 'net-stmmac-deprecate-snps-en-tx-lpi-clockgating-property'Paolo Abeni
Russell King says: ==================== net: stmmac: deprecate "snps,en-tx-lpi-clockgating" property This series deprecates the "snps,en-tx-lpi-clockgating" property for stmmac. MII Transmit clock gating, where the MAC hardware supports gating this clock, is a function of the connected PHY capabilities, which it reports through its status register. GMAC versions that support transmit clock gating twiddle the LPITCSE bit accordingly in the LPI control/status register, which is handled by the GMAC core specific code. So, "snps,en-tx-lpi-clockgating" not something that is a GMAC property, but is a work-around for phylib not providing an interface to determine whether the PHY allows the transmit clock to be disabled. This series converts the two SoCs that make use of this property (which, I hasten to add, is set in the SoC code) to use the PHY capability bit instead of a DT property, then removes the DT property from the .dtsi, deprecates it in the snps,dwmac binding, and finally in the stmmac code. I am expecting some discussion on how to merge this, as I think the order in which these changes is made is important - we don't want to deprecate the old way until the new code has landed. ==================== Link: https://patch.msgid.link/Z9FVHEf3uUqtKzyt@shell.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net: stmmac: deprecate "snps,en-tx-lpi-clockgating" propertyRussell King (Oracle)
Whether the MII transmit clock can be stopped is primarily a property of the PHY (there is a capability bit that should be checked first.) Whether the MAC is capable of stopping the transmit clock is a separate issue, but this is already handled by the core DesignWare MAC code. Therefore, snps,en-tx-lpi-clockgating is technically incorrect, and this commit adds a warning should a DT be encountered with the property present. However, we keep backwards compatibility. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/E1tsIUK-005vGk-H7@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19dt-bindings: deprecate "snps,en-tx-lpi-clockgating" propertyRussell King (Oracle)
Whether the MII transmit clock can be stopped is primarily a property of the PHY (there is a capability bit that should be checked first.) Whether the MAC is capable of stopping the transmit clock is a separate issue, but this is already handled by the core DesignWare MAC code. Therefore, snps,en-tx-lpi-clockgating is technically incorrect, so this commit deprecates the property in the binding. Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tsIUF-005vGd-C5@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19ARM: dts: stm32: remove "snps,en-tx-lpi-clockgating" propertyRussell King (Oracle)
Whether the MII transmit clock can be stopped is primarily a property of the PHY (there is a capability bit that should be checked first.) Whether the MAC is capable of stopping the transmit clock is a separate issue, but this is already handled by the core DesignWare MAC code. As commit "net: stmmac: stm32: use PHY capability for TX clock stop" adds the flag to use the PHY capability, remove the DT property that is now unecessary. Cc: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tsIUA-005vGX-8A@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19riscv: dts: starfive: remove "snps,en-tx-lpi-clockgating" propertyRussell King (Oracle)
Whether the MII transmit clock can be stopped is primarily a property of the PHY (there is a capability bit that should be checked first.) Whether the MAC is capable of stopping the transmit clock is a separate issue, but this is already handled by the core DesignWare MAC code. As commit "net: stmmac: starfive: use PHY capability for TX clock stop" adds the flag to use the PHY capability, remove the DT property that is now unecessary. Cc: Samin Guo <samin.guo@starfivetech.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tsIU5-005vGR-4c@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net: stmmac: stm32: use PHY capability for TX clock stopRussell King (Oracle)
Whether the MII transmit clock can be stopped is primarily a property of the PHY (there is a capability bit that should be checked first.) Whether the MAC is capable of stopping the transmit clock is a separate issue, but this is already handled by the core DesignWare MAC code. Add the flag to allow the stmmac core to use the PHY capability. Cc: Christophe Roullier <christophe.roullier@st.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tsIU0-005vGL-17@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net: stmmac: starfive: use PHY capability for TX clock stopRussell King (Oracle)
Whether the MII transmit clock can be stopped is primarily a property of the PHY (there is a capability bit that should be checked first.) Whether the MAC is capable of stopping the transmit clock is a separate issue, but this is already handled by the core DesignWare MAC code. Add the flag to allow the stmmac core to use the PHY capability. Cc: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tsITu-005vGF-TM@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net: stmmac: allow platforms to use PHY tx clock stop capabilityRussell King (Oracle)
Allow platform glue to instruct stmmac to make use of the PHY transmit clock stop capability when deciding whether to allow the transmit clock from the DWMAC core to be stopped. Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tsITp-005vG9-Px@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Merge tag 'ieee802154-for-net-next-2025-03-10' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next Stefan Schmidt says: ==================== pull-request: ieee802154-next 2025-03-10 An update from ieee802154 for your *net-next* tree: Andy Shevchenko reworked the ca8210 driver to use the gpiod API and fixed a few problems of the driver along the way. * tag 'ieee802154-for-net-next-2025-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next: dt-bindings: ieee802154: ca8210: Update polarity of the reset pin ieee802154: ca8210: Switch to using gpiod API ieee802154: ca8210: Get platform data via dev_get_platdata() ieee802154: ca8210: Use proper setters and getters for bitwise types ==================== Link: https://patch.msgid.link/20250310185752.2683890-1-stefan@datenfreihafen.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19ata: ahci: simplify init functionTomas Henzl
This patch moves all the IRQ vector allocations into a single function. Instead of having the allocations spread out over two separate call sites everything will be handled in ahci_init_irq. Also a direct call into pci(m)_intx will be removed. The main part of this change is done by adding a PCI_IRQ_INTX flag into an already existing pci_alloc_irq_vectors invocation. In the current implementation of the pci_alloc_irq_vectors is the sequence of calls msi-x -> msi -> legacy irq and whatever there succeeds stops the call chain. That makes it impossible to merge all instances into as a single call to pci_alloc_irq_vectors since the order of calls there is: multiple msi-x a single msi a single msi-x a legacy irq. The two last steps can be merged into a single one which are the msi-x and legacy irq option. When PCI_IRQ_INTX flag is set the pci_alloc_irq_vectors succeeds in almost all cases - that makes it possible to convert ahci_init_irq(msi) into a void function. The exception is when dev->irq is zero then the pci_alloc_irq_vectors may return with an error code also pci_intx isn't called from pci_alloc_irq_vectors and thus certain pci calls aren't performed. That's just a negligible issue as later in ahci_init_one the (zero) value of dev->irq is via pci_irq_vector assigned to hpriv->irq. That value is then later tested in ahci_host_activate->ata_host_activate where it is welcomed with a WARN_ON message and fails with setting up irq and then the probe function (ahci_init_one) fails. The special zero value's meaning is that polling mode is being be set up which isn't the case. No functional change. Signed-off-by: Tomas Henzl <thenzl@redhat.com> Link: https://lore.kernel.org/r/20250319155030.16410-1-thenzl@redhat.com Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-03-19RISC-V: KVM: Teardown riscv specific bits after kvm_exitAtish Patra
During a module removal, kvm_exit invokes arch specific disable call which disables AIA. However, we invoke aia_exit before kvm_exit resulting in the following warning. KVM kernel module can't be inserted afterwards due to inconsistent state of IRQ. [25469.031389] percpu IRQ 31 still enabled on CPU0! [25469.031732] WARNING: CPU: 3 PID: 943 at kernel/irq/manage.c:2476 __free_percpu_irq+0xa2/0x150 [25469.031804] Modules linked in: kvm(-) [25469.031848] CPU: 3 UID: 0 PID: 943 Comm: rmmod Not tainted 6.14.0-rc5-06947-g91c763118f47-dirty #2 [25469.031905] Hardware name: riscv-virtio,qemu (DT) [25469.031928] epc : __free_percpu_irq+0xa2/0x150 [25469.031976] ra : __free_percpu_irq+0xa2/0x150 [25469.032197] epc : ffffffff8007db1e ra : ffffffff8007db1e sp : ff2000000088bd50 [25469.032241] gp : ffffffff8131cef8 tp : ff60000080b96400 t0 : ff2000000088baf8 [25469.032285] t1 : fffffffffffffffc t2 : 5249207570637265 s0 : ff2000000088bd90 [25469.032329] s1 : ff60000098b21080 a0 : 037d527a15eb4f00 a1 : 037d527a15eb4f00 [25469.032372] a2 : 0000000000000023 a3 : 0000000000000001 a4 : ffffffff8122dbf8 [25469.032410] a5 : 0000000000000fff a6 : 0000000000000000 a7 : ffffffff8122dc10 [25469.032448] s2 : ff60000080c22eb0 s3 : 0000000200000022 s4 : 000000000000001f [25469.032488] s5 : ff60000080c22e00 s6 : ffffffff80c351c0 s7 : 0000000000000000 [25469.032582] s8 : 0000000000000003 s9 : 000055556b7fb490 s10: 00007ffff0e12fa0 [25469.032621] s11: 00007ffff0e13e9a t3 : ffffffff81354ac7 t4 : ffffffff81354ac7 [25469.032664] t5 : ffffffff81354ac8 t6 : ffffffff81354ac7 [25469.032698] status: 0000000200000100 badaddr: ffffffff8007db1e cause: 0000000000000003 [25469.032738] [<ffffffff8007db1e>] __free_percpu_irq+0xa2/0x150 [25469.032797] [<ffffffff8007dbfc>] free_percpu_irq+0x30/0x5e [25469.032856] [<ffffffff013a57dc>] kvm_riscv_aia_exit+0x40/0x42 [kvm] [25469.033947] [<ffffffff013b4e82>] cleanup_module+0x10/0x32 [kvm] [25469.035300] [<ffffffff8009b150>] __riscv_sys_delete_module+0x18e/0x1fc [25469.035374] [<ffffffff8000c1ca>] syscall_handler+0x3a/0x46 [25469.035456] [<ffffffff809ec9a4>] do_trap_ecall_u+0x72/0x134 [25469.035536] [<ffffffff809f5e18>] handle_exception+0x148/0x156 Invoke aia_exit and other arch specific cleanup functions after kvm_exit so that disable gets a chance to be called first before exit. Fixes: 54e43320c2ba ("RISC-V: KVM: Initial skeletal support for AIA") Fixes: eded6754f398 ("riscv: KVM: add basic support for host vs guest profiling") Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/r/20250317-kvm_exit_fix-v1-1-aa5240c5dbd2@rivosinc.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-03-19Merge tag 'ata-6.14-final' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fix from Niklas Cassel: - Fix a regression on ATI AHCI controllers, where certain Samsung drives fails to be detected on a warm boot when LPM is enabled. LPM on ATI AHCI works fine with other drives. Likewise, the Samsung drives works fine with LPM with other AHI controllers. Thus, just like the weirdo ATA_QUIRK_NO_NCQ_ON_ATI quirk, add a new ATA_QUIRK_NO_LPM_ON_ATI quirk to disable LPM only on ATI AHCI controllers. * tag 'ata-6.14-final' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-core: Add ATA_QUIRK_NO_LPM_ON_ATI for certain Samsung SSDs
2025-03-19wifi: mt76: mt76x2u: add TP-Link TL-WDN6200 ID to device tableIcenowy Zheng
The TP-Link TL-WDN6200 "Driverless" version cards use a MT7612U chipset. Add the USB ID to mt76x2u driver. Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Link: https://patch.msgid.link/20250317102235.1421726-1-uwu@icenowy.me Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt792x: re-register CHANCTX_STA_CSA only for the mt7921 seriesMing Yen Hsieh
CSA is currently not supported on mt7925, so CSA is only registered for the mt7921 series Cc: stable@vger.kernel.org Fixes: 8aa2f59260eb ("wifi: mt76: mt7921: introduce CSA support") Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250313054044.2638837-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: Update mt7996_tx to MLO supportLorenzo Bianconi
Rework mt7996_tx routine in order to support multi-link setup. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-21-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_ampdu_action to support MLOLorenzo Bianconi
Active/de-active TX/RX BA sessssion for each active links running mt7996_ampdu_action routine. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-20-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework set/get_tsf callabcks to support MLOShayne Chen
This is a preliminary patch in order to enable MLO for MT7996 driver. Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-19-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: set vif default link_id adding/removing vif linksLorenzo Bianconi
This info will be consumed by subsequent patches (e.g. in set/get tsf routines). Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-18-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_mcu_beacon_inband_discov to support MLOShayne Chen
Rework mt7996_mcu_beacon_inband_discov routine in order to support multi-link setup. Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-17-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_mcu_add_obss_spr to support MLOShayne Chen
Rework mt7996_mcu_add_obss_spr routine in order to support multi-link setup. Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-16-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_net_fill_forward_path to support MLOLorenzo Bianconi
Rework mt7996_net_fill_forward_path routine in order to support multi-link setup. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-15-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_update_mu_group to support MLOLorenzo Bianconi
Rework mt7996_update_mu_group routine in order to support multi-link setup. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-14-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_mac_sta_poll to support MLOLorenzo Bianconi
Rework mt7996_mac_sta_poll routine in order to support multi-link setup. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-13-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLOLorenzo Bianconi
Rework mt7996_mac_sta_rc_work routine in order to support multi-link setup. Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Co-developed-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-12-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: remove mt7996_mac_enable_rtscts()Shayne Chen
It is controlled by FW, also, driver should not directly write WTBL to prevent WTBL overwritten issues. Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-11-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_sta_hw_queue_read to support MLOLorenzo Bianconi
Extend mt7996_sta_hw_queue_read to support multi-link setup. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-10-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_set_hw_key to support MLOShayne Chen
Modify mt7996_set_hw_key routine to work in a multi-link setup. This is a preliminary patch to enable MLO for MT7996 driver Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-9-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: Add mt7996_sta_link to mt7996_mcu_add_bss_info signatureLorenzo Bianconi
This is a preliminary patch to introduce MLO support for MT996 driver. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-8-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_sta_set_4addr and ↵Shayne Chen
mt7996_sta_set_decap_offload to support MLO Rework mt7996_sta_set_4addr and mt7996_sta_set_decap_offload routines in order to properly support multi-link. This is a preliminary patch to enable MLO for MT7996 driver. Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-7-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_rx_get_wcid to support MLOShayne Chen
The wcid idx and band idx in the TXS are sometimes mismatched since the FW will select a transmission link according to a private algorithm. That is, the wcid idx in the TXS would be the one registered by the driver rather than the actual wcid idx used during transmission. However, the band idx in the TXS is the band select for transmission. Therefore, we should get the driver-registered wcid in order to notify the driver the packet has been acked; otherwise, the driver will be unable to match the transmitted packet and its TXS. This is a preliminary patch to enable MLO for MT7996 driver. Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-6-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: Rely on wcid_to_sta in mt7996_mac_add_txs_skb()Shayne Chen
This is a preliminary patch to enable MLO for MT7996 driver Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-5-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-03-19wifi: mt76: mt7996: rework mt7996_mac_write_txwi() for MLO supportShayne Chen
Update mt7996_mac_write_txwi routine and all the called subroutines to support MLO. This is a preliminary patch to enable MLO for MT7996 driver Co-developed-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250312-b4-mt7996-mlo-p2-v1-4-015b3d6fd928@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
generated by cgit (git 2.34.1) at 2025-09-14 08:54:56 +0000