* [PATCH v5 0/1] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Devin Wittmayer @ 2026-06-03 19:28 UTC (permalink / raw)
To: linux-wireless
Cc: Johannes Berg, Felix Fietkau, Lorenzo Bianconi, linux-kernel,
Oscar Alfonso Diaz, fjhhz1997, Brite
In-Reply-To: <20260519235713.49109-1-lucid_duck@justthetip.ca>
v4 [1] used list_first_or_null_rcu() plus an rcu_access_pointer() check
on the sole entry's list.next to confirm it was the only chanctx. As
Johannes pointed out [2], list.next is not an __rcu pointer, so that
check trips a sparse warning, and his original loop is cleaner. v5 walks
chanctx_list with list_for_each_entry_rcu() and takes the sole entry
instead, which builds clean.
v5 also switches the stable tag to the noautosel opt-out, since the fix
can crash older drivers and should not be auto-backported.
No functional change from v4, so the v3 Tested-by carries. I rebuilt v5
and reran the monitor injection test on mt7921e here, no crash.
[1] https://lore.kernel.org/linux-wireless/20260519235713.49109-1-lucid_duck@justthetip.ca/
[2] https://lore.kernel.org/linux-wireless/978c9a11cf836680b1fd9365f3b90f028ddf5372.camel@sipsolutions.net/
傅继晗 (1):
wifi: mac80211: fix monitor mode frame capture for real chanctx
drivers
net/mac80211/tx.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH] wifi: cfg80211: enforce HE/EHT cap/oper consistency
From: kernel test robot @ 2026-06-03 18:25 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: oe-kbuild-all, Johannes Berg, Xiang Mei
In-Reply-To: <20260603091812.101894-2-johannes@sipsolutions.net>
Hi Johannes,
kernel test robot noticed the following build errors:
[auto build test ERROR on wireless-next/main]
[also build test ERROR on wireless/main linus/master v7.1-rc6 next-20260602]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Johannes-Berg/wifi-cfg80211-enforce-HE-EHT-cap-oper-consistency/20260603-173706
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260603091812.101894-2-johannes%40sipsolutions.net
patch subject: [PATCH] wifi: cfg80211: enforce HE/EHT cap/oper consistency
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260603/202606032002.XZQOw63p-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260603/202606032002.XZQOw63p-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606032002.XZQOw63p-lkp@intel.com/
All errors (new ones prefixed by >>):
net/wireless/nl80211.c: In function 'nl80211_parse_counter_offsets':
>> net/wireless/nl80211.c:12054:15: error: 'params' undeclared (first use in this function); did you mean 'parameq'?
12054 | if (!!params->he_cap != !!params->he_oper)
| ^~~~~~
| parameq
net/wireless/nl80211.c:12054:15: note: each undeclared identifier is reported only once for each function it appears in
vim +12054 net/wireless/nl80211.c
12020
12021 static int nl80211_parse_counter_offsets(struct cfg80211_registered_device *rdev,
12022 const u8 *data, size_t datalen,
12023 int first_count, struct nlattr *attr,
12024 const u16 **offsets, unsigned int *n_offsets)
12025 {
12026 int i;
12027
12028 *n_offsets = 0;
12029
12030 if (!attr)
12031 return 0;
12032
12033 if (!nla_len(attr) || (nla_len(attr) % sizeof(u16)))
12034 return -EINVAL;
12035
12036 *n_offsets = nla_len(attr) / sizeof(u16);
12037 if (rdev->wiphy.max_num_csa_counters &&
12038 (*n_offsets > rdev->wiphy.max_num_csa_counters))
12039 return -EINVAL;
12040
12041 *offsets = nla_data(attr);
12042
12043 /* sanity checks - counters should fit and be the same */
12044 for (i = 0; i < *n_offsets; i++) {
12045 u16 offset = (*offsets)[i];
12046
12047 if (offset >= datalen)
12048 return -EINVAL;
12049
12050 if (first_count != -1 && data[offset] != first_count)
12051 return -EINVAL;
12052 }
12053
12054 if (!!params->he_cap != !!params->he_oper)
12055 return -EINVAL;
12056
12057 if (!!params->eht_cap != !!params->eht_oper)
12058 return -EINVAL;
12059
12060 return 0;
12061 }
12062
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* RE: [PATCH rtw-next v2 1/5] wifi: rtw89: 8831bu: Add support for ELECOM WD{B,C}-X600DU2M-B
From: Zenm Chen @ 2026-06-03 17:05 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, rtl8821cerfe2, zenmchen
In-Reply-To: <4779f2efe03a44f9973e3ebd9c853331@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> 於 2026年6月1日週一 下午2:10寫道：
>
> Zenm Chen <zenmchen@gmail.com> wrote:
> > Add the ids 056e:4027 and 056e:4028 into the device table to support
> > ELECOM WD{B,C}-X600DU2M-B, two new 8831bu-based adapters.
> >
> > Compile tested only.
> >
> > Link: https://github.com/morrownr/rtw89/commit/9e2db2834b37c6adfc4b872a9ef56c927df22bea
>
> As I saw surface of this Link ".../commit/...", I'd ask you to remove
> the Link, because a github commit isn't so important to be a commit message.
>
> Look deeper.... The Link's content (the comment part) is to indicate where
> you got these USB devices ID, right?
> If so, maybe you can just mention that you collected these ID from [1].
>
> (change to this style instead of formal Link)
> [1] https://github.com/morrownr/rtw89/commit/9e2db2834b37c6adfc4b872a9ef56c927df22bea
>
> Then, if a reviewer wants to save himself time, he can just ignore the link.
>
> Please apply it to this patchset. Thanks.
>
> Ping-Ke
>
Okay, will fix in the next version, thanks!
^ permalink raw reply
* Re: [PATCH] wifi: cfg80211: enforce HE/EHT cap/oper consistency
From: kernel test robot @ 2026-06-03 16:13 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
Cc: llvm, oe-kbuild-all, Johannes Berg, Xiang Mei
In-Reply-To: <20260603091812.101894-2-johannes@sipsolutions.net>
Hi Johannes,
kernel test robot noticed the following build errors:
[auto build test ERROR on wireless-next/main]
[also build test ERROR on wireless/main linus/master v7.1-rc6 next-20260602]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Johannes-Berg/wifi-cfg80211-enforce-HE-EHT-cap-oper-consistency/20260603-173706
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260603091812.101894-2-johannes%40sipsolutions.net
patch subject: [PATCH] wifi: cfg80211: enforce HE/EHT cap/oper consistency
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260603/202606031815.lqRk4eKB-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260603/202606031815.lqRk4eKB-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606031815.lqRk4eKB-lkp@intel.com/
All errors (new ones prefixed by >>):
>> net/wireless/nl80211.c:12054:8: error: use of undeclared identifier 'params'
12054 | if (!!params->he_cap != !!params->he_oper)
| ^~~~~~
net/wireless/nl80211.c:12054:28: error: use of undeclared identifier 'params'
12054 | if (!!params->he_cap != !!params->he_oper)
| ^~~~~~
net/wireless/nl80211.c:12057:8: error: use of undeclared identifier 'params'
12057 | if (!!params->eht_cap != !!params->eht_oper)
| ^~~~~~
net/wireless/nl80211.c:12057:29: error: use of undeclared identifier 'params'
12057 | if (!!params->eht_cap != !!params->eht_oper)
| ^~~~~~
4 errors generated.
vim +/params +12054 net/wireless/nl80211.c
12020
12021 static int nl80211_parse_counter_offsets(struct cfg80211_registered_device *rdev,
12022 const u8 *data, size_t datalen,
12023 int first_count, struct nlattr *attr,
12024 const u16 **offsets, unsigned int *n_offsets)
12025 {
12026 int i;
12027
12028 *n_offsets = 0;
12029
12030 if (!attr)
12031 return 0;
12032
12033 if (!nla_len(attr) || (nla_len(attr) % sizeof(u16)))
12034 return -EINVAL;
12035
12036 *n_offsets = nla_len(attr) / sizeof(u16);
12037 if (rdev->wiphy.max_num_csa_counters &&
12038 (*n_offsets > rdev->wiphy.max_num_csa_counters))
12039 return -EINVAL;
12040
12041 *offsets = nla_data(attr);
12042
12043 /* sanity checks - counters should fit and be the same */
12044 for (i = 0; i < *n_offsets; i++) {
12045 u16 offset = (*offsets)[i];
12046
12047 if (offset >= datalen)
12048 return -EINVAL;
12049
12050 if (first_count != -1 && data[offset] != first_count)
12051 return -EINVAL;
12052 }
12053
12054 if (!!params->he_cap != !!params->he_oper)
12055 return -EINVAL;
12056
12057 if (!!params->eht_cap != !!params->eht_oper)
12058 return -EINVAL;
12059
12060 return 0;
12061 }
12062
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] b43legacy: remove redundant mask bit set
From: Michael Büsch @ 2026-06-03 15:56 UTC (permalink / raw)
To: Jeeva Anandh; +Cc: linux-wireless, b43-dev, linux-kernel
In-Reply-To: <20260603125331.6310-1-anandhjeeva215@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]
On Wed, 3 Jun 2026 12:53:31 +0000
Jeeva Anandh <anandhjeeva215@gmail.com> wrote:
> mask is initialized to 0x0000001F, which already contains
> the 0x0010 bit. Therefore the conditional OR operation is
> redundant and can be removed.
>
> Signed-off-by: Jeeva Anandh <anandhjeeva215@gmail.com>
> ---
> drivers/net/wireless/broadcom/b43legacy/main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c b/drivers/net/wireless/broadcom/b43legacy/main.c
> index 6b3e0b2bbca7..d32bffa6f009 100644
> --- a/drivers/net/wireless/broadcom/b43legacy/main.c
> +++ b/drivers/net/wireless/broadcom/b43legacy/main.c
> @@ -1904,8 +1904,6 @@ static int b43legacy_gpio_init(struct b43legacy_wldev *dev)
> mask |= 0x0200;
> set |= 0x0200;
> }
> - if (dev->dev->id.revision >= 2)
> - mask |= 0x0010; /* FIXME: This is redundant. */
>
> #ifdef CONFIG_SSB_DRIVER_PCICORE
> pcidev = bus->pcicore.dev;
No, please don't just remove these things.
There is a FIXME in the comment, because the author already noticed that this
was strange and that there probably is an unknown reason for this.
Just removing this FIXME without clarifying the underlying reason
does not improve the code quality.
--
Michael Büsch
https://bues.ch/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()
From: Dylan Eskew @ 2026-06-03 15:43 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, linux-wireless,
linux-arm-kernel, linux-mediatek
In-Reply-To: <ah_TG4bkzitM4AER@lore-desk>
Hi Lore,
>> Hi Lore,
> Hi Dylan,
>
>> We have been seeing the token memory leak in our custom kernel. After
>> pulling your patch in, we are still getting the leak (validated with
>> kmemleak). How did you figure out where this potential leak was? I want to
>> determine if we are leaking because of our changes or if there's more areas
>> for token leakage.
> Can you please try to run kmemleak on Felix's tree to check if there are any
> leftover leaks not fixed yet?
Ran kmemleak with Felix's tree. I brought up only a few stations, no
traffic run yet and kmemleak flagged a possible leak, same allocation
location we've seen flagged in our custom kernel.
kmemleak trace:
```
unreferenced object 0xffff88811e6ca380 (size 128):
comm "mt76-tx phy0", pid 1164, jiffies 4295044455
hex dump (first 32 bytes):
44 00 00 1a 0a a0 4c ae 0d 00 00 00 02 78 00 30 D.....L......x.0
00 00 00 00 01 00 00 00 14 00 27 12 00 00 00 08 ..........'.....
backtrace (crc fba2c5a3):
__kmalloc_noprof+0x38e/0x480
mt76_dma_tx_queue_skb+0x522/0x890 [mt76]
__mt76_tx_queue_skb+0x3e/0xa0 [mt76]
mt76_txq_schedule_pending_wcid+0x12b/0x200 [mt76]
mt76_txq_schedule_pending+0x122/0x1b0 [mt76]
mt76_tx_worker_run+0x1b/0xc0 [mt76]
__mt76_worker_fn+0x49/0x90 [mt76]
kthread+0xdc/0x110
ret_from_fork+0x190/0x280
ret_from_fork_asm+0x11/0x20
```
In dma.c, line 19 is the where the kmemleak trace points:
```
10 static struct mt76_txwi_cache *
11 mt76_alloc_txwi(struct mt76_dev *dev)
12 {
13 struct mt76_txwi_cache *t;
14 dma_addr_t addr;
15 u8 *txwi;
16 int size;
17
18 size = L1_CACHE_ALIGN(dev->drv->txwi_size + sizeof(*t));
19 txwi = kzalloc(size, GFP_ATOMIC);
20 if (!txwi)
21 return NULL;
22
23 addr = dma_map_single(dev->dma_dev, txwi, dev->drv->txwi_size,
24 DMA_TO_DEVICE);
25 if (unlikely(dma_mapping_error(dev->dma_dev, addr))) {
26 kfree(txwi);
27 return NULL;
28 }
29
30 t = (struct mt76_txwi_cache *)(txwi + dev->drv->txwi_size);
31 t->dma_addr = addr;
32
33 return t;
34 }
```
Let me know if you need any other information.
-- Dylan
>
> Regards,
> Lorenzo
>
>> -- Dylan
>>
>> On 5/31/26 2:10 AM, Lorenzo Bianconi wrote:
>>> If link_conf or link_sta lookup fails in mt7996_tx_prepare_skb routine,
>>> mt7996 driver leaks an already allocated tx token. Fix the issue
>>> releasing the token in case of error.
>>>
>>> Fixes: 7ef0c7ad735b0 ("wifi: mt76: mt7996: Implement MLD address translation for EAPOL")
>>> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>>> ---
>>> drivers/net/wireless/mediatek/mt76/mt7996/mac.c | 8 ++++++--
>>> drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
>>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> index c98446057282..8c56344d211b 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c
>>> @@ -1067,11 +1067,11 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
>>> link_conf = rcu_dereference(vif->link_conf[wcid->link_id]);
>>> if (!link_conf)
>>> - return -EINVAL;
>>> + goto error_relase_token;
>>> link_sta = rcu_dereference(sta->link[wcid->link_id]);
>>> if (!link_sta)
>>> - return -EINVAL;
>>> + goto error_relase_token;
>>> dma_sync_single_for_cpu(mdev->dma_dev, tx_info->buf[1].addr,
>>> tx_info->buf[1].len, DMA_TO_DEVICE);
>>> @@ -1176,6 +1176,10 @@ int mt7996_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
>>> tx_info->nbuf = MT_CT_DMA_BUF_NUM;
>>> return 0;
>>> +
>>> +error_relase_token:
>>> + mt76_token_release(mdev, id, NULL);
>>> + return -EINVAL;
>>> }
>>> u32 mt7996_wed_init_buf(void *ptr, dma_addr_t phys, int token_id)
>>> diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
>>> index 22f9690634c9..f96d9c471853 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/tx.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/tx.c
>>> @@ -933,7 +933,7 @@ mt76_token_release(struct mt76_dev *dev, int token, bool *wake)
>>> #endif
>>> }
>>> - if (dev->token_count < dev->token_size - MT76_TOKEN_FREE_THR &&
>>> + if (wake && dev->token_count < dev->token_size - MT76_TOKEN_FREE_THR &&
>>> dev->phy.q_tx[0]->blocked)
>>> *wake = true;
>>>
>>> ---
>>> base-commit: 4913f44167cf35a9536e9eec7352e15b2de0c573
>>> change-id: 20260531-mt7996_tx_prepare_skb-token-leack-82e240d8c66f
>>>
>>> Best regards,
^ permalink raw reply
* Re: [PATCH 5.15.y] wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work
From: Sasha Levin @ 2026-06-03 15:14 UTC (permalink / raw)
To: stable, Duoming Zhou
Cc: Sasha Levin, Johannes Berg, Arend van Spriel, Franky Lin,
Hante Meuleman, Chi-hsien Lin, Wright Feng, Chung-hsien Hsu,
Kalle Valo, David S . Miller, Jakub Kicinski, Piotr Haber,
John W . Linville, Pieter-Paul Giesberts, Robert Garcia,
linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list,
netdev, linux-kernel
In-Reply-To: <20260528055431.4124445-1-rob_garcia@163.com>
Queued for 5.15.y, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2 RESEND 0/5] wifi: mediatek: drop redundant USB device references
From: Johan Hovold @ 2026-06-03 14:51 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Jakub Kicinski
Cc: Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, linux-wireless, linux-mediatek,
linux-kernel
In-Reply-To: <20260430083335.215239-1-johan@kernel.org>
On Thu, Apr 30, 2026 at 10:33:30AM +0200, Johan Hovold wrote:
> [ This is a resend (with trimmed CC) of the five Mediatek patches which
> still haven't been picked up from [1]. ]
>
> Driver core holds a reference to the USB interface and its parent USB
> device while the interface is bound to a driver and there is no need to
> take additional references unless the structures are needed after
> disconnect.
>
> Drop redundant device references to reduce cargo culting, make it easier
> to spot drivers where an extra reference is needed, and reduce the risk
> of memory leaks when drivers fail to release them.
> [1] https://lore.kernel.org/all/20260306085144.12064-1-johan@kernel.org/
>
>
> Johan Hovold (5):
> wifi: mt76: drop redundant device reference
> wifi: mt76x0u: drop redundant device reference
> wifi: mt76x2u: drop redundant device reference
> wifi: mt76: mt792xu: drop redundant device reference
> wifi: mt7601u: drop redundant device reference
It's now been three months since these were first posted.
Can someone please pick them up?
Johan
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7925: add regulatory wiphy self manager support
From: kernel test robot @ 2026-06-03 14:41 UTC (permalink / raw)
To: JB Tsai, nbd, lorenzo
Cc: oe-kbuild-all, linux-wireless, linux-mediatek, Deren.Wu,
Sean.Wang, Quan.Zhou, Ryder.Lee, Leon.Yen, litien.chang,
Charlie-cy.Wu, jb.tsai
In-Reply-To: <20260603075331.1234691-1-jb.tsai@mediatek.com>
Hi JB,
kernel test robot noticed the following build warnings:
[auto build test WARNING on wireless-next/main]
[also build test WARNING on wireless/main linus/master v7.1-rc6 next-20260602]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/JB-Tsai/wifi-mt76-mt7925-add-regulatory-wiphy-self-manager-support/20260603-155908
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260603075331.1234691-1-jb.tsai%40mediatek.com
patch subject: [PATCH] wifi: mt76: mt7925: add regulatory wiphy self manager support
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260603/202606031619.GjGn8yRe-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260603/202606031619.GjGn8yRe-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606031619.GjGn8yRe-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/wireless/mediatek/mt76/mt7925/regd.c: In function 'mt7925_regd_update':
>> drivers/net/wireless/mediatek/mt76/mt7925/regd.c:361:57: warning: passing argument 2 of 'regulatory_set_wiphy_regd' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
361 | return regulatory_set_wiphy_regd(wiphy, &mt7925_regd_ww);
| ^~~~~~~~~~~~~~~
In file included from include/net/mac80211.h:22,
from drivers/net/wireless/mediatek/mt76/mt7925/../mt76.h:18,
from drivers/net/wireless/mediatek/mt76/mt7925/../mt76_connac.h:7,
from drivers/net/wireless/mediatek/mt76/mt7925/../mt76_connac_mcu.h:7,
from drivers/net/wireless/mediatek/mt76/mt7925/../mt792x.h:10,
from drivers/net/wireless/mediatek/mt76/mt7925/mt7925.h:7,
from drivers/net/wireless/mediatek/mt76/mt7925/regd.c:4:
include/net/cfg80211.h:8082:59: note: expected 'struct ieee80211_regdomain *' but argument is of type 'const struct ieee80211_regdomain *'
8082 | struct ieee80211_regdomain *rd);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
vim +361 drivers/net/wireless/mediatek/mt76/mt7925/regd.c
286
287 int mt7925_regd_update(struct mt792x_phy *phy, char *alpha2)
288 {
289 struct wiphy *wiphy = phy->mt76->hw->wiphy;
290 struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
291 struct mt792x_dev *dev = mt792x_hw_dev(hw);
292 struct mt7925_regd_rule *mt7925_rule;
293 struct mt76_dev *mdev = &dev->mt76;
294 struct ieee80211_regdomain *regd;
295 struct ieee80211_reg_rule *rule;
296 struct mt7925_regd_rule_ev *ev;
297 int i, num_of_rules = 0;
298 struct sk_buff *skb;
299 int ret = 0;
300
301 if (dev->hw_full_reset)
302 return 0;
303
304 if (!MT7925_REGD_SUPPORTED(phy))
305 return -EOPNOTSUPP;
306
307 mt792x_mutex_acquire(dev);
308 skb = mt7925_regd_query_regdb(phy, alpha2);
309 mt792x_mutex_release(dev);
310
311 if (!skb)
312 return -EINVAL;
313
314 ev = (struct mt7925_regd_rule_ev *)(skb->data + 4);
315 num_of_rules = le32_to_cpu(ev->n_reg_rules);
316
317 if (!num_of_rules ||
318 WARN_ON_ONCE(num_of_rules > NL80211_MAX_SUPP_REG_RULES)) {
319 ret = -EINVAL;
320 goto err;
321 }
322
323 regd = kzalloc(struct_size(regd, reg_rules, num_of_rules), GFP_KERNEL);
324 if (!regd) {
325 ret = -ENOMEM;
326 goto err;
327 }
328
329 for (i = 0; i < num_of_rules; i++) {
330 mt7925_rule = &ev->reg_rule[i];
331 rule = ®d->reg_rules[i];
332
333 rule->freq_range.start_freq_khz =
334 MHZ_TO_KHZ(mt7925_rule->start_freq);
335 rule->freq_range.end_freq_khz =
336 MHZ_TO_KHZ(mt7925_rule->end_freq);
337 rule->freq_range.max_bandwidth_khz =
338 MHZ_TO_KHZ(mt7925_rule->max_bw);
339 /* not used by fw */
340 rule->power_rule.max_antenna_gain = DBI_TO_MBI(6);
341 rule->power_rule.max_eirp = DBM_TO_MBM(22);
342 rule->flags = mt7925_rule->flags;
343 }
344
345 regd->n_reg_rules = num_of_rules;
346 regd->dfs_region = ev->dfs_region;
347
348 memcpy(regd->alpha2, alpha2, 2);
349 memcpy(mdev->alpha2, alpha2, 2);
350
351 dev->regd_change = true;
352 mt7925_mcu_regd_update(dev, alpha2, ENVIRON_ANY);
353
354 ret = regulatory_set_wiphy_regd(wiphy, regd);
355
356 kfree(regd);
357 err:
358 dev_kfree_skb(skb);
359
360 if (ret < 0)
> 361 return regulatory_set_wiphy_regd(wiphy, &mt7925_regd_ww);
362
363 return ret;
364 }
365 EXPORT_SYMBOL_GPL(mt7925_regd_update);
366
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* pull-request: iwlwifi-next-2026-06-03
From: Korenblit, Miriam Rachel @ 2026-06-03 14:31 UTC (permalink / raw)
To: linux-wireless
The following changes since commit 6aded6c10490d5b24325e46f22b327876b669f72:
Merge tag 'rtw-next-2026-06-03' of https://github.com/pkshih/rtw (2026-06-03 14:12:11 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git/ tags/iwlwifi-next-2026-06-03
for you to fetch changes up to a6136ca2dd9773d6bcd45e8290403536c9c71054:
wifi: iwlwifi: bump maximum core version for BZ/SC/DR to 106 (2026-06-03 17:02:55 +0300)
----------------------------------------------------------------
wifi: iwlwifi-next : updates - 2026-06-03
This pull request contains iwlwifi features and cleanups. Notably:
- Bump max core version for BZ/SC/DR to 106.
- Add KUnit tests for link grading, RSSI adjustment, and beacon
handling;
- Drop core101 support and remove TLC config v4/v5 compatibility code.
- Fixes:
Fix PCIe write pointer detection
Fix STEP_URM register address
Remove unneeded WoWLAN warning
reduce NIC wakeups during dump.
Revert MODULE_FIRMWARE relocation change
----------------------------------------------------------------
Avinash Bhatt (3):
wifi: iwlwifi: mld: add KUnit tests for duplicated beacon RSSI adjustment
wifi: iwlwifi: mld: add KUnit tests for PSD/EIRP RSSI adjustment
wifi: iwlwifi: mld: add KUnit tests for link grading
Emmanuel Grumbach (2):
wifi: iwlwifi: add support for AX231
wifi: iwlwifi: bump maximum core version for BZ/SC/DR to 106
Ilan Peer (1):
wifi: iwlwifi: mld: Require HT support for NAN
Israel Kozitz (1):
wifi: iwlwifi: mld: support FW TLV for NAN max channel switch time
Johannes Berg (6):
wifi: iwlwifi: fw: cut down NIC wakeups during dump
wifi: iwlwifi: mvm: rename iwl_mvm_mac80211_idx_to_hwrate()
wifi: iwlwifi: move iwl_fw_rate_idx_to_plcp() to mvm
wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o netdetect
wifi: iwlwifi: mvm: fix P2P-Device binding handling
wifi: iwlwifi: pcie: fix write pointer move detection
Miri Korenblit (7):
wifi: iwlwifi: remove stale comment
wifi: iwlwifi: remove mvm prefix from marker command
wifi: iwlwifi: mld: fix smatch warning
wifi: iwlwifi: mld: always allow mimo in NAN
wifi: iwlwifi: fix a typo
wifi: iwlwifi: trans: export the maximum supported hcmd size
wifi: iwlwifi: mvm: remove __must_check annotation from command sending
Moriya Itzchaki (1):
wifi: iwlwifi: fix STEP_URM register address for SC devices
Pagadala Yesu Anjaneyulu (1):
wifi: iwlwifi: mld: set fast-balance scan for active EMLSR
Shahar Tzarfati (4):
wifi: iwlwifi: cfg: Revert "wifi: iwlwifi: cfg: move the MODULE_FIRMWARE to the per-rf file"
wifi: iwlwifi: remove orphaned DC2DC config enum
wifi: iwlwifi: stop supporting core101
wifi: iwlwifi: mld: drop TLC config cmd v4/v5 compat code
drivers/net/wireless/intel/iwlwifi/cfg/bz.c | 16 +-
drivers/net/wireless/intel/iwlwifi/cfg/dr.c | 4 +-
drivers/net/wireless/intel/iwlwifi/cfg/rf-fm.c | 12 -
drivers/net/wireless/intel/iwlwifi/cfg/rf-gf.c | 3 +-
drivers/net/wireless/intel/iwlwifi/cfg/sc.c | 4 +-
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 4 +-
drivers/net/wireless/intel/iwlwifi/fw/api/config.h | 11 +-
.../net/wireless/intel/iwlwifi/fw/api/datapath.h | 2 +-
drivers/net/wireless/intel/iwlwifi/fw/api/debug.h | 16 +-
drivers/net/wireless/intel/iwlwifi/fw/api/rs.h | 34 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 96 ++---
drivers/net/wireless/intel/iwlwifi/fw/file.h | 1 +
drivers/net/wireless/intel/iwlwifi/fw/img.h | 1 +
drivers/net/wireless/intel/iwlwifi/fw/rs.c | 27 --
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 6 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 6 +
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 3 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 5 +
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 15 +
drivers/net/wireless/intel/iwlwifi/mld/d3.c | 7 +-
drivers/net/wireless/intel/iwlwifi/mld/link.c | 15 +-
drivers/net/wireless/intel/iwlwifi/mld/link.h | 6 +
drivers/net/wireless/intel/iwlwifi/mld/mac80211.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mld/nan.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mld/scan.c | 8 +-
drivers/net/wireless/intel/iwlwifi/mld/sta.c | 6 +
.../intel/iwlwifi/mld/tests/link-selection.c | 280 ++++++++++--
.../net/wireless/intel/iwlwifi/mld/tests/link.c | 474 ++++++++++++++++++++-
.../net/wireless/intel/iwlwifi/mld/tests/utils.c | 60 +++
.../net/wireless/intel/iwlwifi/mld/tests/utils.h | 9 +-
drivers/net/wireless/intel/iwlwifi/mld/tlc.c | 74 ----
drivers/net/wireless/intel/iwlwifi/mld/tx.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/binding.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 26 +-
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 32 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 3 +-
.../wireless/intel/iwlwifi/pcie/gen1_2/internal.h | 1 +
.../intel/iwlwifi/pcie/gen1_2/trans-gen2.c | 12 +-
.../net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c | 7 +-
43 files changed, 1031 insertions(+), 306 deletions(-)
^ permalink raw reply
* Re: [PATCH] wifi: brcmfmac: add DPP support and fix fw-supplicant/P2P interop
From: kernel test robot @ 2026-06-03 13:20 UTC (permalink / raw)
To: Jason Huang, linux-wireless
Cc: oe-kbuild-all, wlan-kernel-dev-list, Johannes Berg, Kurt Lee,
Jason Huang
In-Reply-To: <20260603035722.145894-1-Jason.Huang2@infineon.com>
Hi Jason,
kernel test robot noticed the following build warnings:
[auto build test WARNING on wireless-next/main]
[also build test WARNING on wireless/main linus/master v7.1-rc6 next-20260602]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Jason-Huang/wifi-brcmfmac-add-DPP-support-and-fix-fw-supplicant-P2P-interop/20260603-115824
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260603035722.145894-1-Jason.Huang2%40infineon.com
patch subject: [PATCH] wifi: brcmfmac: add DPP support and fix fw-supplicant/P2P interop
config: x86_64-rhel-9.4-ltp (https://download.01.org/0day-ci/archive/20260603/202606031541.hOnf0Qnq-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260603/202606031541.hOnf0Qnq-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606031541.hOnf0Qnq-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function 'brcmf_p2p_tx_action_frame':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:1593:13: warning: variable 'action_frame_len' set but not used [-Wunused-but-set-variable]
1593 | u16 action_frame_len;
| ^~~~~~~~~~~~~~~~
vim +/action_frame_len +1593 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
1570
1571
1572 /**
1573 * brcmf_p2p_tx_action_frame() - send action frame over fil.
1574 *
1575 * @ifp: interface to transmit on.
1576 * @p2p: p2p info struct for vif.
1577 * @af_params: action frame data/info.
1578 * @vif: vif to send
1579 *
1580 * Send an action frame immediately without doing channel synchronization.
1581 *
1582 * This function waits for a completion event before returning.
1583 * The WLC_E_ACTION_FRAME_COMPLETE event will be received when the action
1584 * frame is transmitted.
1585 */
1586 static s32 brcmf_p2p_tx_action_frame(struct brcmf_if *ifp,
1587 struct brcmf_p2p_info *p2p,
1588 struct brcmf_fil_af_params_le *af_params)
1589 {
1590 struct brcmf_pub *drvr = p2p->cfg->pub;
1591 s32 err = 0;
1592 struct brcmf_fil_action_frame_le *action_frame;
> 1593 u16 action_frame_len;
1594
1595 action_frame = &af_params->action_frame;
1596 action_frame_len = le16_to_cpu(action_frame->len);
1597
1598 brcmf_dbg(TRACE, "Enter\n");
1599
1600 reinit_completion(&p2p->send_af_done);
1601 clear_bit(BRCMF_P2P_STATUS_ACTION_TX_COMPLETED, &p2p->status);
1602 clear_bit(BRCMF_P2P_STATUS_ACTION_TX_NOACK, &p2p->status);
1603
1604 err = brcmf_fil_bsscfg_data_set(ifp, "actframe", af_params,
1605 sizeof(*af_params));
1606 if (err) {
1607 bphy_err(drvr, " sending action frame has failed\n");
1608 goto exit;
1609 }
1610
1611 p2p->af_sent_channel = le32_to_cpu(af_params->channel);
1612 p2p->af_tx_sent_jiffies = jiffies;
1613
1614 if (test_bit(BRCMF_P2P_STATUS_DISCOVER_LISTEN, &p2p->status) &&
1615 p2p->af_sent_channel ==
1616 ieee80211_frequency_to_channel(p2p->remain_on_channel.center_freq))
1617 p2p->wait_for_offchan_complete = false;
1618 else
1619 p2p->wait_for_offchan_complete = true;
1620
1621 brcmf_dbg(TRACE, "Waiting for %s tx completion event\n",
1622 (p2p->wait_for_offchan_complete) ?
1623 "off-channel" : "on-channel");
1624
1625 wait_for_completion_timeout(&p2p->send_af_done, P2P_AF_MAX_WAIT_TIME);
1626
1627 if (test_bit(BRCMF_P2P_STATUS_ACTION_TX_COMPLETED, &p2p->status)) {
1628 brcmf_dbg(TRACE, "TX action frame operation is success\n");
1629 } else {
1630 err = -EIO;
1631 brcmf_dbg(TRACE, "TX action frame operation has failed\n");
1632 }
1633 /* clear status bit for action tx */
1634 clear_bit(BRCMF_P2P_STATUS_ACTION_TX_COMPLETED, &p2p->status);
1635 clear_bit(BRCMF_P2P_STATUS_ACTION_TX_NOACK, &p2p->status);
1636
1637 exit:
1638 return err;
1639 }
1640
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: Rasmus Villemoes @ 2026-06-03 13:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andy Shevchenko, Arnd Bergmann, Steven Rostedt, Masami Hiramatsu,
Andrew Morton, Petr Mladek, Nathan Chancellor, Dennis Dalessandro,
Jason Gunthorpe, Leon Romanovsky, Arend van Spriel,
Miri Korenblit, Mathieu Desnoyers, Sergey Senozhatsky,
Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka (SUSE), linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
In-Reply-To: <87zf1bhjqp.fsf@prevas.dk>
On Wed, Jun 03 2026, Rasmus Villemoes <ravi@prevas.dk> wrote:
> On Wed, Jun 03 2026, "Arnd Bergmann" <arnd@arndb.de> wrote:
>
>> On Wed, Jun 3, 2026, at 09:15, Rasmus Villemoes wrote:
>>> On Tue, Jun 02 2026, "Arnd Bergmann" <arnd@arndb.de> wrote:
>>>> On Tue, Jun 2, 2026, at 20:59, Andy Shevchenko wrote:
>>>>> On Tue, Jun 02, 2026 at 05:07:05PM +0200, Arnd Bergmann wrote:
>>>
>>> May I suggest a different approach, that avoids having that extra
>>> function emitted (which presumably compiles to a single jump
>>> instruction, but still, with retpoline and CFI and all that it all adds
>>> up): Keep the declaration of __vsnprintf() in the header without the
>>> __print() attribute, but then do
>>>
>>> int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
>>> __alias(vsnprintf);
>>>
>>> in vsprintf.c. Aside from reusing the same entry point, I could well
>>> imagine a compiler some day complaining about seeing the printf
>>> attribute applied in a local extra declaration but not having it in the
>>> header file.
>>>
>>> Presumably it will need its own EXPORT_SYMBOL if any of the intended
>>> users are modular, and it certainly still needs a comment.
>>
>> I had tried that earlier but given up because the attributes have to
>> match exactly.
>>
>> This definition works with all currently supported versions of gcc,
>> but may have to change when the there is a new version that adds
>> even more attributes:
>>
>> int
>> __printf(3, 0)
>> __attribute__((nothrow))
>> __attribute__((nonnull(1)))
>> __vsnprintf(char *__restrict buf, size_t size,
>> const char * __restrict fmt_str, va_list args)
>> __alias(vsnprintf);
>>
>
> Ah, I see. The documentation for the alias attribute does say that the
> types have to match, but I didn't know that the nothrow and nonnull
> attributes were considered part of the type identity. Oddly enough, if
> one does
>
> typeof(vsnprintf) __vsnprintf __alias(vsnprintf);
>
> that still fails, but only complains about nothrow, not nonnull.
>
> I don't remember what minimum gcc we currently require, but gcc 9
> introduced another attribute that is apperently meant for cases like
> this: 'copy'. This seems to build:
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 9f359b31c8d1..c1402d375429 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2988,6 +2988,9 @@ int vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
> }
> EXPORT_SYMBOL(vsnprintf);
>
> +int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
> + __alias(vsnprintf) __attribute__((__copy__(vsnprintf)));
> +
> /**
> * vscnprintf - Format a string and place it in a buffer
> * @buf: The buffer to place the result into
>
> That at least should handle any future "gcc knows this-or-that about the
> vsnprintf function". But I don't know if clang supports that copy
> mechanism or if the minimum supported gcc is too old.
Ah, so we already have __copy in compiler-attributes.h, stating that
it's not supported by clang. Our current minimum gcc version is 8. But
judging from the commit message for c0d9782f5, perhaps it's not actually
a problem that it just expands to nothing for gcc 8, as the "less
restrictive attribute" warning was also introduced with gcc 9, and the
__copy macro is already used for module init/exit functions. Which also
suggests that it might not be a problem that clang doesn't support it.
Rasmus
^ permalink raw reply
* Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: Arnd Bergmann @ 2026-06-03 13:10 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Andy Shevchenko, Arnd Bergmann, Steven Rostedt, Masami Hiramatsu,
Andrew Morton, Petr Mladek, Nathan Chancellor, Dennis Dalessandro,
Jason Gunthorpe, Leon Romanovsky, Arend van Spriel,
Miri Korenblit, Mathieu Desnoyers, Sergey Senozhatsky,
Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka (SUSE), linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
In-Reply-To: <87zf1bhjqp.fsf@prevas.dk>
On Wed, Jun 3, 2026, at 14:49, Rasmus Villemoes wrote:
> On Wed, Jun 03 2026, "Arnd Bergmann" <arnd@arndb.de> wrote:
>> On Wed, Jun 3, 2026, at 09:15, Rasmus Villemoes wrote:
> I don't remember what minimum gcc we currently require, but gcc 9
> introduced another attribute that is apperently meant for cases like
> this: 'copy'.
The minimum version is gcc-8.
> This seems to build:
>...
> +int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
> + __alias(vsnprintf) __attribute__((__copy__(vsnprintf)));
> +
>
> That at least should handle any future "gcc knows this-or-that about the
> vsnprintf function". But I don't know if clang supports that copy
> mechanism or if the minimum supported gcc is too old.
clang-22 and gcc-8 don't like the attribute, but also don't complain
about the other mismatched attributes, so simply using the __copy()
macro we already have will work on all currently supported
compilers and likely all future ones as well.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: David Laight @ 2026-06-03 13:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rasmus Villemoes, Andy Shevchenko, Arnd Bergmann, Steven Rostedt,
Masami Hiramatsu, Andrew Morton, Petr Mladek, Nathan Chancellor,
Dennis Dalessandro, Jason Gunthorpe, Leon Romanovsky,
Arend van Spriel, Miri Korenblit, Mathieu Desnoyers,
Sergey Senozhatsky, Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka (SUSE), linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
In-Reply-To: <aafe201a-64a6-438f-89a3-d1cd10a357a7@app.fastmail.com>
On Wed, 03 Jun 2026 10:41:18 +0200
"Arnd Bergmann" <arnd@arndb.de> wrote:
> On Wed, Jun 3, 2026, at 09:15, Rasmus Villemoes wrote:
> > On Tue, Jun 02 2026, "Arnd Bergmann" <arnd@arndb.de> wrote:
> >> On Tue, Jun 2, 2026, at 20:59, Andy Shevchenko wrote:
> >>> On Tue, Jun 02, 2026 at 05:07:05PM +0200, Arnd Bergmann wrote:
> >
> > May I suggest a different approach, that avoids having that extra
> > function emitted (which presumably compiles to a single jump
> > instruction, but still, with retpoline and CFI and all that it all adds
> > up): Keep the declaration of __vsnprintf() in the header without the
> > __print() attribute, but then do
> >
> > int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
> > __alias(vsnprintf);
> >
> > in vsprintf.c. Aside from reusing the same entry point, I could well
> > imagine a compiler some day complaining about seeing the printf
> > attribute applied in a local extra declaration but not having it in the
> > header file.
> >
> > Presumably it will need its own EXPORT_SYMBOL if any of the intended
> > users are modular, and it certainly still needs a comment.
>
> I had tried that earlier but given up because the attributes have to
> match exactly.
>
> This definition works with all currently supported versions of gcc,
> but may have to change when the there is a new version that adds
> even more attributes:
>
> int
> __printf(3, 0)
> __attribute__((nothrow))
> __attribute__((nonnull(1)))
> __vsnprintf(char *__restrict buf, size_t size,
> const char * __restrict fmt_str, va_list args)
> __alias(vsnprintf);
>
> We'd probably want to also add __nothrow and __nonnull macros
> in linux/compiler-attributes.h if we do this.
>
> For reference, see below for the alternative idea I had
> that avoids adding the __vsnprintf() alias altogether by
> passing down the va_format using "%pV".
>
> I don't think I actually got this one right in the end
> since I only build-tested it, but I expect it could be done
> if someone is able to test and fix all the corner cases
> properly.
>
> Arnd
>
> diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
> index 4715330c7b6b..8e44fc3e60b0 100644
> --- a/include/linux/trace_events.h
> +++ b/include/linux/trace_events.h
> @@ -956,14 +956,11 @@ perf_trace_buf_submit(void *raw_data, int size, int rctx, u16 type,
> * gcc warns that you can not use a va_list in an inlined
> * function. But lets me make it into a macro :-/
> */
> -#define __trace_event_vstr_len(fmt, va) \
> +#define __trace_event_vstr_len(vf) \
> ({ \
> - va_list __ap; \
> int __ret; \
> \
> - va_copy(__ap, *(va)); \
> - __ret = __vsnprintf(NULL, 0, fmt, __ap) + 1; \
> - va_end(__ap); \
> + __ret = snprintf(NULL, 0, "%pV", vf) + 1; \
This adds an extra snprintf call - non-trivial and more stack.
Can't you just use the old code with vf->fmt and vf->ap ?
And does the %pV" include the va_copy()?
It isn't normally needed.
Any scheme for avoiding doing the printf processing twice
is likely to be a gain.
-- David
^ permalink raw reply
* [PATCH] b43legacy: remove redundant mask bit set
From: Jeeva Anandh @ 2026-06-03 12:53 UTC (permalink / raw)
To: linux-wireless; +Cc: b43-dev, linux-kernel, Jeeva Anandh
mask is initialized to 0x0000001F, which already contains
the 0x0010 bit. Therefore the conditional OR operation is
redundant and can be removed.
Signed-off-by: Jeeva Anandh <anandhjeeva215@gmail.com>
---
drivers/net/wireless/broadcom/b43legacy/main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c b/drivers/net/wireless/broadcom/b43legacy/main.c
index 6b3e0b2bbca7..d32bffa6f009 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -1904,8 +1904,6 @@ static int b43legacy_gpio_init(struct b43legacy_wldev *dev)
mask |= 0x0200;
set |= 0x0200;
}
- if (dev->dev->id.revision >= 2)
- mask |= 0x0010; /* FIXME: This is redundant. */
#ifdef CONFIG_SSB_DRIVER_PCICORE
pcidev = bus->pcicore.dev;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning
From: Rasmus Villemoes @ 2026-06-03 12:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andy Shevchenko, Arnd Bergmann, Steven Rostedt, Masami Hiramatsu,
Andrew Morton, Petr Mladek, Nathan Chancellor, Dennis Dalessandro,
Jason Gunthorpe, Leon Romanovsky, Arend van Spriel,
Miri Korenblit, Mathieu Desnoyers, Sergey Senozhatsky,
Nick Desaulniers, Bill Wendling, Justin Stitt,
Vlastimil Babka (SUSE), linux-rdma, linux-kernel, linux-wireless,
brcm80211, brcm80211-dev-list.pdl, linux-trace-kernel, llvm
In-Reply-To: <aafe201a-64a6-438f-89a3-d1cd10a357a7@app.fastmail.com>
On Wed, Jun 03 2026, "Arnd Bergmann" <arnd@arndb.de> wrote:
> On Wed, Jun 3, 2026, at 09:15, Rasmus Villemoes wrote:
>> On Tue, Jun 02 2026, "Arnd Bergmann" <arnd@arndb.de> wrote:
>>> On Tue, Jun 2, 2026, at 20:59, Andy Shevchenko wrote:
>>>> On Tue, Jun 02, 2026 at 05:07:05PM +0200, Arnd Bergmann wrote:
>>
>> May I suggest a different approach, that avoids having that extra
>> function emitted (which presumably compiles to a single jump
>> instruction, but still, with retpoline and CFI and all that it all adds
>> up): Keep the declaration of __vsnprintf() in the header without the
>> __print() attribute, but then do
>>
>> int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
>> __alias(vsnprintf);
>>
>> in vsprintf.c. Aside from reusing the same entry point, I could well
>> imagine a compiler some day complaining about seeing the printf
>> attribute applied in a local extra declaration but not having it in the
>> header file.
>>
>> Presumably it will need its own EXPORT_SYMBOL if any of the intended
>> users are modular, and it certainly still needs a comment.
>
> I had tried that earlier but given up because the attributes have to
> match exactly.
>
> This definition works with all currently supported versions of gcc,
> but may have to change when the there is a new version that adds
> even more attributes:
>
> int
> __printf(3, 0)
> __attribute__((nothrow))
> __attribute__((nonnull(1)))
> __vsnprintf(char *__restrict buf, size_t size,
> const char * __restrict fmt_str, va_list args)
> __alias(vsnprintf);
>
Ah, I see. The documentation for the alias attribute does say that the
types have to match, but I didn't know that the nothrow and nonnull
attributes were considered part of the type identity. Oddly enough, if
one does
typeof(vsnprintf) __vsnprintf __alias(vsnprintf);
that still fails, but only complains about nothrow, not nonnull.
I don't remember what minimum gcc we currently require, but gcc 9
introduced another attribute that is apperently meant for cases like
this: 'copy'. This seems to build:
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 9f359b31c8d1..c1402d375429 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2988,6 +2988,9 @@ int vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
}
EXPORT_SYMBOL(vsnprintf);
+int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args)
+ __alias(vsnprintf) __attribute__((__copy__(vsnprintf)));
+
/**
* vscnprintf - Format a string and place it in a buffer
* @buf: The buffer to place the result into
That at least should handle any future "gcc knows this-or-that about the
vsnprintf function". But I don't know if clang supports that copy
mechanism or if the minimum supported gcc is too old.
Rasmus
^ permalink raw reply related
* [PATCH wireless-next] wifi: mac80211: Free keys associated with NAN Device
From: Johannes Berg @ 2026-06-03 12:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Ilan Peer
From: Ilan Peer <ilan.peer@intel.com>
A NAN Device interface can have keys associated with it, e.g.,
IGTK and BIGTK used for Tx. When a NAN Device interface is stopped,
we need to clear these keys.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/iface.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 56400c22d8bc..086272c3ec08 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -648,6 +648,12 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata, bool going_do
spin_unlock_bh(&sdata->u.nan.de.func_lock);
}
+
+ /*
+ * Free the remaining keys that might be associated with the
+ * NAN interface, e.g., IGTK and BIGTK used for Tx.
+ */
+ ieee80211_free_keys(sdata, true);
break;
case NL80211_IFTYPE_NAN_DATA:
RCU_INIT_POINTER(sdata->u.nan_data.nmi, NULL);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Johannes Berg @ 2026-06-03 12:10 UTC (permalink / raw)
To: Devin Wittmayer, linux-wireless
Cc: Felix Fietkau, Lorenzo Bianconi, linux-kernel, stable,
Oscar Alfonso Diaz, fjhhz1997
In-Reply-To: <20260519235713.49109-2-lucid_duck@justthetip.ca>
On Tue, 2026-05-19 at 16:57 -0700, Devin Wittmayer wrote:
>
> Cc: stable@vger.kernel.org # 6.9+
No. It's known to crash drivers on some versions, so it should
explicitly opt out of stable by
Cc: <stable+noautosel@kernel.org> # causes some older drivers to crash
> - if (chanctx_conf)
> + if (chanctx_conf) {
> chandef = &chanctx_conf->def;
> - else if (local->emulate_chanctx)
> - chandef = &local->hw.conf.chandef;
> - else
> - goto fail_rcu;
> + } else {
> + struct ieee80211_chanctx *ctx;
> +
> + ctx = list_first_or_null_rcu(&local->chanctx_list,
> + struct ieee80211_chanctx, list);
> + if (!ctx ||
> + rcu_access_pointer(ctx->list.next) != &local->chanctx_list)
> + goto fail_rcu;
This results in a sparse warning, maybe my loop approach was better
after all.
johannes
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Johannes Berg @ 2026-06-03 12:09 UTC (permalink / raw)
To: Óscar Alfonso Díaz
Cc: Devin Wittmayer, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
linux-kernel, stable, fjhhz1997, Brite
In-Reply-To: <CA+bbHrUqv=4y7OUQuaheLuoBjp9hnaxw_8WwFOY0o8J4xm-K0Q@mail.gmail.com>
On Wed, 2026-06-03 at 13:54 +0200, Óscar Alfonso Díaz wrote:
> Hi, after my yesterday's email with the tests results. As you can see,
> all the cases are working but the 5ghz+VIF+DoS. Will this patch be
> added anyway while looking for a fix for this specific case? if so,
> from what kernel version will it be available? 7.0 I guess, just to
> confirm and update airgeddon wiki-docs.
>
Thanks for testing. I really don't want to have stable for this since
it's known to crash on some versions, so it'll be 7.2.
That's assuming I get a new version soon, because this one doesn't build
cleanly.
johannes
^ permalink raw reply
* Open source social media project from Salzburg
From: Dogan Karaarslan @ 2026-06-03 12:00 UTC (permalink / raw)
To: linux-wireless
Hello,
I found your contact through GitHub.
I’m a developer based in Salzburg, and I’ve created an open source social media project focused on communities and meaningful connections.
I’d love to share it with you. If you like the idea of an open source social media project, I would really appreciate it if you could take a look and maybe star the repository.
I’ve put a lot of heart into this project, so any kind of support, feedback, contribution, or simply sharing it would mean a lot to me.
Here is the project:
https://github.com/dogankaraarslan1/ciaorelated
Thank you for your time.
Best regards,
Dogan Karaarslan
^ permalink raw reply
* Re: pull-request: wifi: iwlwifi-next - 2026-05-31
From: Johannes Berg @ 2026-06-03 11:57 UTC (permalink / raw)
To: Korenblit, Miriam Rachel, linux-wireless
In-Reply-To: <DS0PR11MB78809C3AE2C2F3348D39581AA3142@DS0PR11MB7880.namprd11.prod.outlook.com>
On Sun, 2026-05-31 at 14:27 +0000, Korenblit, Miriam Rachel wrote:
> The following changes since commit 6f5dc19f46f4bd0e104c9a4da2f0a912cdf3bd86:
>
> Merge tag 'ath-next-20260526' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath (2026-05-28 10:23:15 +0200)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git/ tags/iwlwifi-next-2026-05-31
>
> for you to fetch changes up to 933c7e591e4112dc3d664374c6a62d7153df1d16:
>
> wifi: iwlwifi: bump maximum core version for BZ/SC/DR to 106 (2026-05-31 17:22:55 +0300)
>
> ----------------------------------------------------------------
> wifi: iwlwifi-next - 2026-05-31
>
> This contains features, cleanups and fixes.
I don't think that between the ~26 patches there's absolutely nothing
worth mentioning. Please resend with some explanations.
johannes
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Óscar Alfonso Díaz @ 2026-06-03 11:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Devin Wittmayer, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
linux-kernel, stable, fjhhz1997, Brite
In-Reply-To: <CA+bbHrVbDBwmQnDyEa-Mw1yH8vMSEQa0ZP5CyL+8oaT2rpqpOg@mail.gmail.com>
Hi, after my yesterday's email with the tests results. As you can see,
all the cases are working but the 5ghz+VIF+DoS. Will this patch be
added anyway while looking for a fix for this specific case? if so,
from what kernel version will it be available? 7.0 I guess, just to
confirm and update airgeddon wiki-docs.
Thanks and Regards.
--
Oscar
OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El mar, 2 jun 2026 a las 10:29, Óscar Alfonso Díaz
(<oscar.alfonso.diaz@gmail.com>) escribió:
>
> Hello, sorry for the delay, but here are the tests that were carried out:
>
> -Compiled kernel 7.0.11 using the suggested patch:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
>
> *Tests with Ralink RT3572:
> Standard DoS 2.4ghz -> working
> VIF DoS 2.4ghz -> working
> Standard DoS 5ghz -> working
> VIF DoS 5ghz -> working
>
> *Tests with MediaTek MT7921U:
> Standard DoS 2.4ghz -> working
> VIF DoS 2.4ghz -> working
> Standard DoS 5ghz -> working
> VIF DoS 5ghz -> not working (no freeze or error)
>
> -Compiled kernel 7.1-rc6 using same patch:
> https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
>
> *Tests with Ralink RT3572:
> Standard DoS 2.4ghz -> working
> VIF DoS 2.4ghz -> working
> Standard DoS 5ghz -> working
> VIF DoS 5ghz -> working
>
> *Tests with MediaTek MT7921U:
> Standard DoS 2.4ghz -> working
> VIF DoS 2.4ghz -> working
> Standard DoS 5ghz -> working
> VIF DoS 5ghz -> not working (no freeze or error)
>
> So exactly the same behavior on both kernels.
>
> Hope it helps. Thanks and regards.
> --
> Oscar
>
> OpenPGP Key: DA9C60E9 ||
> https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> --
> El mié, 20 may 2026 a las 11:55, Óscar Alfonso Díaz
> (<oscar.alfonso.diaz@gmail.com>) escribió:
> >
> > Ok, I'll do the testing using this one you suggested:
> > https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
> >
> > Thanks.
> > --
> > Oscar
> >
> > OpenPGP Key: DA9C60E9 ||
> > https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
> > 4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
> > --
> >
> > El mié, 20 may 2026 a las 11:53, Johannes Berg
> > (<johannes@sipsolutions.net>) escribió:
> > >
> > > On Wed, 2026-05-20 at 11:51 +0200, Óscar Alfonso Díaz wrote:
> > > > Ok, let me do one final test using Johannes’ v2 patch. The expected
> > > > behavior is as follows:
> > > >
> > > > 6.18 or lower: no need to test, it will not work. It’s clear now that
> > > > this does not matter, since the goal is only to fix newer kernel
> > > > versions.
> > > >
> > > > 6.19: some versions of the 6.19 will crash and others will not. The
> > > > crash was fixed at some point between 6.18.12 and 6.19.12. No need to
> > > > test.
> > > >
> > > > 7.0, or 7.1: the expected result is that there will be no crash, and
> > > > VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
> > > > (I'll test both, normal DoS and VIF+DoS). There should be no crash,
> > > > but it will not work.
> > > >
> > > > So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
> > > > the results. I'll be testing this patch (v2):
> > > > https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@sipsolutions.net/
> > > >
> > >
> > > Thanks. For testing that one you'd have to revert the other first, I
> > > think, you could also just test this one:
> > >
> > > https://patchwork.kernel.org/project/linux-wireless/patch/20260519235713.49109-2-lucid_duck@justthetip.ca/
> > >
> > > But I think they're basically all equivalent.
> > >
> > > Since we eventually need a patch to apply w/o reverting, Devin's is
> > > probably better than my old one.
> > >
> > > johannes
^ permalink raw reply
* Re: [PATCH wireless v2 2/4] wifi: mac80211: estimate expected throughput if not provided by driver/rc
From: Johannes Berg @ 2026-06-03 11:51 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless
In-Reply-To: <20260528111756.848243-2-nbd@nbd.name>
On Thu, 2026-05-28 at 11:17 +0000, Felix Fietkau wrote:
>
> +static u32 sta_estimate_expected_throughput(struct sta_info *sta,
> + struct rate_info *ri,
> + struct ieee80211_bss_conf *bss_conf)
> +{
> + struct ieee80211_hw *hw = &sta->sdata->local->hw;
> + struct ieee80211_chanctx_conf *conf;
> + u32 duration;
> + u8 band = 0;
> +
> + conf = rcu_dereference(bss_conf->chanctx_conf);
> + if (conf)
> + band = conf->def.chan->band;
That doesn't seem right, just return 0 if there's no chanctx.
> for_each_valid_link(sinfo, link_id) {
> + struct link_station_info *lsi = sinfo->links[link_id];
better call this "link_sinfo" as elsewhere, even if lines get a little
longer.
Anyway, I had already, but the whole series doesn't build :-(
johannes
^ permalink raw reply
* [GIT PULL] wireless-2026-06-03
From: Johannes Berg @ 2026-06-03 11:31 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
Hi,
And yet more things ... I'm going to defer a number of driver
things to wireless-next though, e.g. a PCIe device IRQ race.
Please pull and let us know if there's any problem.
Thanks,
johannes
The following changes since commit f3be0c984ecbcb82b0bec408022c4ef738cb3843:
Merge tag 'net-7.1-rc6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2026-05-29 15:46:40 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git tags/wireless-2026-06-03
for you to fetch changes up to cb9959ab5f99611d27a06586add84811fe8102dc:
wifi: cfg80211: enforce HE/EHT cap/oper consistency (2026-06-03 13:25:19 +0200)
----------------------------------------------------------------
Things are finally quieting down:
- iwlwifi:
- FW reset handshake removal for older devices
- NIC access fix in fast resume
- avoid too large command for some BIOSes
- fix TX power constraints in AP mode
- cfg80211:
- fix netlink parse overflow
- fix potential 6 GHz scan memory leak
- enforce HE/EHT consistency to avoid mac80211 crash
- mac80211: guard radiotap antenna parsing
----------------------------------------------------------------
Deepanshu Kartikey (1):
wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap
Emmanuel Grumbach (3):
wifi: iwlwifi: mvm: don't support the reset handshake for old firmwares
wifi: iwlwifi: mvm: avoid oversized UATS command copy
wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used
Fedor Pchelkin (1):
wifi: fix leak if split 6 GHz scanning fails
Johannes Berg (2):
Merge tag 'iwlwifi-fixes-2026-05-31' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
wifi: cfg80211: enforce HE/EHT cap/oper consistency
Pagadala Yesu Anjaneyulu (1):
wifi: iwlwifi: mld: send tx power constraints before link activation
Yuqi Xu (1):
wifi: nl80211: reject oversized EMA RNR lists
drivers/net/wireless/intel/iwlwifi/mld/ap.c | 4 --
drivers/net/wireless/intel/iwlwifi/mld/mac80211.c | 7 +++
drivers/net/wireless/intel/iwlwifi/mld/power.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 28 +++++++++---
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 6 +++
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 56 +++++++++++++----------
net/mac80211/tx.c | 4 +-
net/wireless/nl80211.c | 9 ++++
net/wireless/scan.c | 9 +++-
9 files changed, 88 insertions(+), 37 deletions(-)
^ permalink raw reply
* [PATCH v7 3/3] PCI: Disable broken bus reset on Qualcomm devices
From: Jose Ignacio Tornos Martinez @ 2026-06-03 10:58 UTC (permalink / raw)
To: bhelgaas, alex
Cc: jjohnson, mani, linux-pci, linux-wireless, ath11k, ath12k, mhi,
linux-kernel, Jose Ignacio Tornos Martinez
In-Reply-To: <20260603105853.326290-1-jtornosm@redhat.com>
Some Qualcomm PCIe devices (WCN6855/WCN7850 WiFi cards, SDX62/SDX65 modems)
do not properly support Secondary Bus Reset (SBR).
Testing confirms this is device-specific, not deployment-specific:
MediaTek MT7925e successfully uses bus reset through the same passive
M.2-to-PCIe adapters where Qualcomm devices fail, proving PERST# is
properly wired through the adapters.
This quirk acts as a safety net, preventing the broken bus reset from being
attempted if users override reset methods (device_specific or d3cold when
available) via sysfs.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v7: Address the comments from Jeff Johnson: the problem was detected for
the specific devices WCN6855 and WCN7850, use the name of the devices
instead of the related drivers ath11k and ath12k, which support a large
number of devices
v6: https://lore.kernel.org/all/20260602160024.1171949-4-jtornosm@redhat.com/
drivers/pci/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 000000000000..111111111111 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3789,6 +3789,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0030, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0032, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003c, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0033, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0034, quirk_no_bus_reset);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003e, quirk_no_bus_reset);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x1103, quirk_no_bus_reset); /* WCN6855 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x1107, quirk_no_bus_reset); /* WCN7850 */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_QCOM, 0x0308, quirk_no_bus_reset); /* SDX62/SDX65 */
/*
* Root port on some Cavium CN8xxx chips do not successfully complete a bus
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox