* [PATCH 1/4] b43, b43legacy: debugfs: use kzalloc() to allocate formatting buffers
From: Mike Rapoport (Microsoft) @ 2026-07-01 13:59 UTC (permalink / raw)
To: Johannes Berg
Cc: Brian Norris, Francesco Dolcini, Jakub Kicinski, Mike Rapoport,
b43-dev, libertas-dev, linux-kernel, linux-mm, linux-wireless,
netdev
In-Reply-To: <20260701-b4-drivers-wireless-v1-0-60264cdf2efe@kernel.org>
b43* debugfs functions allocate 16 KiB buffers for formatting debug output
text using __get_free_pages().
kzalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object and for 16 Kib
allocation kzalloc() will anyway delegate it to buddy.
Replace use of __get_free_pages() with kzalloc().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
drivers/net/wireless/broadcom/b43/debugfs.c | 12 +++++-------
drivers/net/wireless/broadcom/b43legacy/debugfs.c | 12 +++++-------
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/debugfs.c b/drivers/net/wireless/broadcom/b43/debugfs.c
index acddae68947a..31a1ff00c1a4 100644
--- a/drivers/net/wireless/broadcom/b43/debugfs.c
+++ b/drivers/net/wireless/broadcom/b43/debugfs.c
@@ -495,7 +495,6 @@ static ssize_t b43_debugfs_read(struct file *file, char __user *userbuf,
ssize_t ret;
char *buf;
const size_t bufsize = 1024 * 16; /* 16 kiB buffer */
- const size_t buforder = get_order(bufsize);
int err = 0;
if (!count)
@@ -518,15 +517,14 @@ static ssize_t b43_debugfs_read(struct file *file, char __user *userbuf,
dfile = fops_to_dfs_file(dev, dfops);
if (!dfile->buffer) {
- buf = (char *)__get_free_pages(GFP_KERNEL, buforder);
+ buf = kzalloc(bufsize, GFP_KERNEL);
if (!buf) {
err = -ENOMEM;
goto out_unlock;
}
- memset(buf, 0, bufsize);
ret = dfops->read(dev, buf, bufsize);
if (ret <= 0) {
- free_pages((unsigned long)buf, buforder);
+ kfree(buf);
err = ret;
goto out_unlock;
}
@@ -538,7 +536,7 @@ static ssize_t b43_debugfs_read(struct file *file, char __user *userbuf,
dfile->buffer,
dfile->data_len);
if (*ppos >= dfile->data_len) {
- free_pages((unsigned long)dfile->buffer, buforder);
+ kfree(dfile->buffer);
dfile->buffer = NULL;
dfile->data_len = 0;
}
@@ -577,7 +575,7 @@ static ssize_t b43_debugfs_write(struct file *file,
goto out_unlock;
}
- buf = (char *)get_zeroed_page(GFP_KERNEL);
+ buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!buf) {
err = -ENOMEM;
goto out_unlock;
@@ -591,7 +589,7 @@ static ssize_t b43_debugfs_write(struct file *file,
goto out_freepage;
out_freepage:
- free_page((unsigned long)buf);
+ kfree(buf);
out_unlock:
mutex_unlock(&dev->wl->mutex);
diff --git a/drivers/net/wireless/broadcom/b43legacy/debugfs.c b/drivers/net/wireless/broadcom/b43legacy/debugfs.c
index 3ad99124d522..a04d90d7307c 100644
--- a/drivers/net/wireless/broadcom/b43legacy/debugfs.c
+++ b/drivers/net/wireless/broadcom/b43legacy/debugfs.c
@@ -192,7 +192,6 @@ static ssize_t b43legacy_debugfs_read(struct file *file, char __user *userbuf,
ssize_t ret;
char *buf;
const size_t bufsize = 1024 * 16; /* 16 KiB buffer */
- const size_t buforder = get_order(bufsize);
int err = 0;
if (!count)
@@ -215,12 +214,11 @@ static ssize_t b43legacy_debugfs_read(struct file *file, char __user *userbuf,
dfile = fops_to_dfs_file(dev, dfops);
if (!dfile->buffer) {
- buf = (char *)__get_free_pages(GFP_KERNEL, buforder);
+ buf = kzalloc(bufsize, GFP_KERNEL);
if (!buf) {
err = -ENOMEM;
goto out_unlock;
}
- memset(buf, 0, bufsize);
if (dfops->take_irqlock) {
spin_lock_irq(&dev->wl->irq_lock);
ret = dfops->read(dev, buf, bufsize);
@@ -228,7 +226,7 @@ static ssize_t b43legacy_debugfs_read(struct file *file, char __user *userbuf,
} else
ret = dfops->read(dev, buf, bufsize);
if (ret <= 0) {
- free_pages((unsigned long)buf, buforder);
+ kfree(buf);
err = ret;
goto out_unlock;
}
@@ -240,7 +238,7 @@ static ssize_t b43legacy_debugfs_read(struct file *file, char __user *userbuf,
dfile->buffer,
dfile->data_len);
if (*ppos >= dfile->data_len) {
- free_pages((unsigned long)dfile->buffer, buforder);
+ kfree(dfile->buffer);
dfile->buffer = NULL;
dfile->data_len = 0;
}
@@ -279,7 +277,7 @@ static ssize_t b43legacy_debugfs_write(struct file *file,
goto out_unlock;
}
- buf = (char *)get_zeroed_page(GFP_KERNEL);
+ buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!buf) {
err = -ENOMEM;
goto out_unlock;
@@ -298,7 +296,7 @@ static ssize_t b43legacy_debugfs_write(struct file *file,
goto out_freepage;
out_freepage:
- free_page((unsigned long)buf);
+ kfree(buf);
out_unlock:
mutex_unlock(&dev->wl->mutex);
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] drivers/net: replace __get_free_pages() with kmalloc()
From: Mike Rapoport (Microsoft) @ 2026-07-01 13:59 UTC (permalink / raw)
To: Johannes Berg
Cc: Brian Norris, Francesco Dolcini, Jakub Kicinski, Mike Rapoport,
b43-dev, libertas-dev, linux-kernel, linux-mm, linux-wireless,
netdev
This is a (small) part of larger work of replacing page allocator calls
with kmalloc.
My initial intention a few month ago was to remove ugly casts [1], but then
willy pointed out that Linus objected to something like this [2] and it
looks like more than a decade old technical debt.
Largely, anything that doesn't need struct page (or a memdesc in the
future) should just use kmalloc() or kvmalloc() to allocate memory.
kmalloc() guarantees alignment, physical contiguity and working
virt_to_phys() and beside nicer API that returns void * on alloc and
doesn't require to know the allocation size on free, kmalloc() provides
better debugging capabilities than page allocator.
Another thing is that touching these allocation sites gives the reviewers
opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
another size is appropriate.
For larger allocations that don't need physically contiguous memory
kvmalloc() can be a better option that __get_free_pages() because under
memory pressure it's is easier to allocate several order-0 pages than a
physically contiguous chunk with the same number of pages.
And last, but not least, removing needless calls to page allocator should
help with memdesc (aka project folio) conversion. There will be way less
places to audit to see if the user was actually using struct page.
Also in git:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git gfp-to-kmalloc/drivers-net-wireless
[1] https://lore.kernel.org/all/20251018093002.3660549-1-rppt@kernel.org/
[2] https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/
---
Changes in v2:
- split out wireless drivers from a larger set
- use kzalloc() instead of kmalloc() + memset in b43legacy
v1: https://patch.msgid.link/20260630-b4-drivers-net-v1-0-672162a91f37@kernel.org
---
Mike Rapoport (Microsoft) (4):
b43, b43legacy: debugfs: use kzalloc() to allocate formatting buffers
libertas: debugfs: use kzalloc() to allocate formatting buffers
mwifiex: debugfs: use kzalloc() to allocate formatting buffers
wlcore: allocate aggregation and firmware log buffers with kzalloc()
drivers/net/wireless/broadcom/b43/debugfs.c | 12 ++---
drivers/net/wireless/broadcom/b43legacy/debugfs.c | 12 ++---
drivers/net/wireless/marvell/libertas/debugfs.c | 39 ++++++--------
drivers/net/wireless/marvell/mwifiex/debugfs.c | 62 ++++++++++-------------
drivers/net/wireless/ti/wlcore/main.c | 14 +++--
5 files changed, 59 insertions(+), 80 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260630-b4-drivers-wireless-5294524fab46
Best regards,
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Greg KH @ 2026-07-01 13:48 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: stable@vger.kernel.org, Sasha Levin, Felix Fietkau,
Lorenzo Bianconi, Jiajia Liu, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, Ming Yen Hsieh,
Leon Yen, linux-wireless, linux-kernel, linux-arm-kernel,
linux-mediatek, Linux kernel regressions list
In-Reply-To: <dc7657b2-e3d5-4777-af52-1169fe743761@leemhuis.info>
On Wed, Jul 01, 2026 at 08:16:07AM +0200, Thorsten Leemhuis wrote:
> On 7/1/26 07:39, Jiajia Liu wrote:
> > On Tue, Jun 30, 2026 at 01:29:51PM +0200, Thorsten Leemhuis wrote:
> >> On 5/28/26 05:38, Jiajia Liu wrote:
> >>> Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
> >>> to avoid reinitializing the wcid->poll_list.
> >>>
> >>> Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
> >>
> >> Jiajia Liu, Felox:
>
> BTW: @Felix, sorry for the typo!
>
> >> given that the problem seems to be in 7.1, should we
> >> ask the stable team to pick this regression fix up, as this change was
> >> mainlined (as 20b126920a259d ("wifi: mt76: add wcid publish check in
> >> mt76_sta_add") [v7.2-rc1]), but lacks both a Fixes and a Stable tag?
> >
> > Yes. It seems to be related to cbf5e61da660 ("wifi: mt76: initialize
> > more wcid fields mt76_wcid_init") [v6.14-rc1]. But I didn't reproduce
> > when I checked it out and tested. So Fixes was not added.
>
> In that case:
>
> @Stable team, you you please pick up 20b126920a259d ("wifi: mt76: add
> wcid publish check in mt76_sta_add") [v7.2-rc1] for 7.1? It lacks a
> fixes tag and the problem might be older, but I saw two reports about
> this with 7.1-rc -- so it seems some recent change made that problem
> more likely to occur, so it might be good to fix it at least in 7.1.y.
Now queued up for 6.18.y and 7.1.y, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property
From: Loic Poulain @ 2026-07-01 13:35 UTC (permalink / raw)
To: Rob Herring
Cc: Ulf Hansson, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Jens Axboe, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Srinivas Kandagatla,
Andrew Lunn, Heiner Kallweit, Russell King, Saravana Kannan,
Christian Marangi, linux-mmc, devicetree, linux-kernel,
linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, stable, Bartosz Golaszewski
In-Reply-To: <CAL_JsqKFjk-mdaAAOzNB6rFiJbw5gd4eDpRBLQL-4q+uJKnp3g@mail.gmail.com>
On Tue, Jun 30, 2026 at 11:46 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jun 30, 2026 at 2:59 PM Loic Poulain
> <loic.poulain@oss.qualcomm.com> wrote:
> >
> > Hi Rob,
> >
> > On Tue, Jun 30, 2026 at 8:02 PM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Mon, Jun 29, 2026 at 10:55:20AM +0200, Loic Poulain wrote:
> > > > Child nodes of a fixed-partitions node are not necessarily partition
> > > > entries, for example an nvmem-layout node has no reg property. The
> > > > current code passes a NULL reg pointer and uninitialized len to the
> > > > length check, which can result in a kernel panic or silent failure to
> > > > register any partitions.
> > >
> > > That does not sound right to me. A fixed-partitions node should only be
> > > defining partitions with address ranges. I would expect a partition node
> > > could be nvmem-layout, but not the whole address range. If you wanted
> > > the latter, then just do:
> > >
> > > partitions {
> > > ...
> > > };
> > >
> > > nvmem-layout {
> > > ...
> > > };
> >
> > In our case, the nvmem-layout needs to be associated with a specific
> > eMMC hardware partition, nvmem cells can be a simple sub-range within
> > the global eMMC, each hardware partition (boot0, boot1, user...)
> > having its own address spaces.
> >
> > That said, your point about not abusing fixed-partitions is valid. I
> > initially dropped the compatible = "fixed-partitions" from the
> > partitions-boot1 node when it only carries an nvmem-layout and no
> > actual partition entries, making it a plain named container node. But
> > it's a bit fragile if we want to support both nvmem-layout and
> > fixed-partitions.
> >
> > Regarding your expectation of a partition node being a nvmem-layout,
> > do you mean that the nvmem-layout should live under a fixed-partitions
> > node? Something along these lines:
> >
> > partitions-boot1 {
> > compatible = "fixed-partitions";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > nvmem@4400 {
>
> partition@4400
>
> > reg = <0x4400 0x1000>;
> >
> > nvmem-layout {
> > compatible = "fixed-layout";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > wifi_mac_addr: mac-addr@0 {
> > compatible = "mac-base";
> > reg = <0x0 0x6>;
> > #nvmem-cell-cells = <1>;
> > };
> > [...]
>
> Either this or replacing "fixed-partitions" with "fixed-layout" if you
> want to make the whole boot1 partition nvmem-layout looks like the
> right way to me.
Well, now I think both approaches make sense. We should support a
fixed-layout on the entire hw-part/block, while also allowing it
within individual logical partitions.
Support for the former would only require a small rework/addition in
this series (to have the hw boot partition a fixed-layout) . The
latter could come in a follow-up series, as it would require some
additional fwnode logic.
>
> > That makes some sense, this would require extra work for the
> > emmc/block layer to also associate fwnodes with logical partitions,
> > not just the whole disk/hw (hw part), Is that the direction you'd like
> > us to go?
>
> Yes.
>
> > Also, Note that regardless of which approach we settle on, this
> > specific fix/patch remains necessary to validate the partition node
> > and prevent NULL-deref.
>
> Fair enough, though the reasoning for it would be different and
> perhaps should give a warning.
Sure.
Thanks,
Loic
^ permalink raw reply
* Re: [PATCH v2 3/6] firmware: qcom: scm: Add support for setting Bluetooth power modes
From: Konrad Dybcio @ 2026-07-01 13:31 UTC (permalink / raw)
To: George Moussalem, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <SN7PR19MB6736B784D6A16CBA531DBD5C9DF62@SN7PR19MB6736.namprd19.prod.outlook.com>
On 7/1/26 3:15 PM, George Moussalem wrote:
> On 7/1/26 14:40, Konrad Dybcio wrote:
>> On 6/29/26 3:01 PM, George Moussalem via B4 Relay wrote:
>>> From: George Moussalem <george.moussalem@outlook.com>
>>>
>>> The Bluetooth subsystem (BTSS) on the IPQ5018 SoC supports setting power
>>> modes which are required to be configured through a Secure Channel
>>> Manager (SCM) call to TrustZone. However, not all Trusted Execution
>>> Environment (QSEE) images support this call, so first check if the call
>>> is available.
>>>
>>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>>> ---
>>
>> I'm amazed changing this setting is a secure operation
>>
>> [...]
>>
>>> +/**
>>> + * qcom_scm_pas_set_bluetooth_power_mode() - Configure power optimization mode
>>> + * for the Bluetooth subsystem (BTSS)
>>> + * @pas_id: peripheral authentication service id
>>> + * @val: 0x0 for normal operation, 0x4 for ECO mode
>>
>> If there's just two values, maybe we should make this take a `bool eco_mode`?
>
> that was the direction I was going in initially but then thought that
> there may be more (undocumented) power modes I'm unaware off so changed
> it to u32. I'll change it back to bool.
We can always change back if needed
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/6] firmware: qcom: scm: Add support for setting Bluetooth power modes
From: George Moussalem @ 2026-07-01 13:15 UTC (permalink / raw)
To: Konrad Dybcio, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <175f7835-df18-4bc6-8267-ceef35696af8@oss.qualcomm.com>
On 7/1/26 14:40, Konrad Dybcio wrote:
> On 6/29/26 3:01 PM, George Moussalem via B4 Relay wrote:
>> From: George Moussalem <george.moussalem@outlook.com>
>>
>> The Bluetooth subsystem (BTSS) on the IPQ5018 SoC supports setting power
>> modes which are required to be configured through a Secure Channel
>> Manager (SCM) call to TrustZone. However, not all Trusted Execution
>> Environment (QSEE) images support this call, so first check if the call
>> is available.
>>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>> ---
>
> I'm amazed changing this setting is a secure operation
>
> [...]
>
>> +/**
>> + * qcom_scm_pas_set_bluetooth_power_mode() - Configure power optimization mode
>> + * for the Bluetooth subsystem (BTSS)
>> + * @pas_id: peripheral authentication service id
>> + * @val: 0x0 for normal operation, 0x4 for ECO mode
>
> If there's just two values, maybe we should make this take a `bool eco_mode`?
that was the direction I was going in initially but then thought that
there may be more (undocumented) power modes I'm unaware off so changed
it to u32. I'll change it back to bool.
>
>> + *
>> + * Return: 0 on success, negative errno on failure.
>> + * Returns -EOPNOTSUPP if the firmware configuration call is unavailable.
>> + */
>> +int qcom_scm_pas_set_bluetooth_power_mode(u32 pas_id, u32 val)
>> +{
>> + if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_PIL,
>> + QCOM_SCM_PIL_PAS_BT_PWR_MODE))
>> + return -EOPNOTSUPP;
>> +
>> + return __qcom_scm_pas_set_bluetooth_power_mode(pas_id, val);
>
> Let's just inline the whole definition here - it's single-use anyway
will update, thanks.
>
> Konrad
Cheers,
George
^ permalink raw reply
* Re: [PATCH v8 10/14] media: qcom: Pass proper PAS ID to set_remote_state API
From: Sumit Garg @ 2026-07-01 12:19 UTC (permalink / raw)
To: Konrad Dybcio
Cc: andersson, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <c93b47af-e291-4a6a-ae4b-cc46f25c422b@oss.qualcomm.com>
On Wed, Jul 01, 2026 at 01:01:52PM +0200, Konrad Dybcio wrote:
> On 7/1/26 9:44 AM, Sumit Garg wrote:
> > On Tue, Jun 30, 2026 at 02:42:25PM +0200, Konrad Dybcio wrote:
> >> On 6/26/26 3:34 PM, Sumit Garg wrote:
> >>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>>
> >>> As per testing the SCM backend just ignores it while OP-TEE makes
> >>> use of it to for proper book keeping purpose.
> >>>
> >>> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> >>> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
> >>> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> >>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>> ---
> >>> drivers/media/platform/qcom/iris/iris_firmware.c | 2 +-
> >>> drivers/media/platform/qcom/venus/firmware.c | 2 +-
> >>> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
> >>> index ea9654dd679e..d2e7ba4f37e3 100644
> >>> --- a/drivers/media/platform/qcom/iris/iris_firmware.c
> >>> +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
> >>> @@ -110,5 +110,5 @@ int iris_fw_unload(struct iris_core *core)
> >>>
> >>> int iris_set_hw_state(struct iris_core *core, bool resume)
> >>> {
> >>> - return qcom_pas_set_remote_state(resume, 0);
> >>> + return qcom_pas_set_remote_state(resume, IRIS_PAS_ID);
> >>> }
> >>> diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
> >>> index 3a38ff985822..3c0727ea137d 100644
> >>> --- a/drivers/media/platform/qcom/venus/firmware.c
> >>> +++ b/drivers/media/platform/qcom/venus/firmware.c
> >>> @@ -59,7 +59,7 @@ int venus_set_hw_state(struct venus_core *core, bool resume)
> >>> int ret;
> >>>
> >>> if (core->use_tz) {
> >>> - ret = qcom_pas_set_remote_state(resume, 0);
> >>> + ret = qcom_pas_set_remote_state(resume, VENUS_PAS_ID);
> >>
> >> This should not be in the middle of a mildly related series..
> >> The PAS IDs should be centralized into a single header. And the
> >> name of the driver shouldn't be part of the define. I would guesstimate
> >> that on the secure side it's probably called VPU or VIDEO
> >
> > I agree with your comments, this is something I would also like to
> > consolidate on OP-TEE side as well: see discussion here [1].
> >
> > However, the patch itself was needed to do book keeping on OP-TEE side
> > but I can drop it since anyhow the video isn't functional yet in
> > upstream dependent on the proper IOMMU support.
>
> For this patch.. I think QCTZ may be ignoring the argument so it
> may not matter.. on a second thought you already have it reviewed
> and it's already a cross-subsys merge so might as well pull it in,
> worst case scenario it'll revert cleanly
Thanks, I will keep it then.
>
> Once this lands, please move all PAS defines to.. hmm.. qcom_pas.h
> sounds like a good candidate?
Sure, I will propose that as a follow-up change. We have to agree on
common naming there.
-Sumit
^ permalink raw reply
* Re: [PATCH v2 4/6] Bluetooth: Introduce Qualcomm IPQ5018 IPC based HCI driver
From: Konrad Dybcio @ 2026-07-01 11:19 UTC (permalink / raw)
To: george.moussalem, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260629-ipq5018-bluetooth-v2-4-02770f03b6bb@outlook.com>
On 6/29/26 3:01 PM, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
>
> Add support for the Bluetooth controller found in the IPQ5018 SoC.
> This driver implements firmware loading and the transport layer between
> the HCI core and the Bluetooth controller.
>
> The firmware is loaded by the host into the dedicated reserved memory
> carveout and authenticated by TrustZone. A Secure Channel Manager (SCM)
> call safely brings the peripheral core out of reset.
>
> A shared memory ring buffer topology handles runtime data frame
> transport between the host APSS and the controller.
>
> An outgoing APCS IPC bit and an incoming GIC interrupt handle host/guest
> signaling.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
[...]
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/elf.h>
> +#include <linux/firmware.h>
> +#include <linux/firmware/qcom/qcom_scm.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <linux/skbuff.h>
> +#include <linux/slab.h>
> +#include <linux/soc/qcom/mdt_loader.h>
> +#include <linux/types.h>
> +#include <linux/workqueue.h>
I don't know for sure, but the amount of the includes suggests some may
be unnecessary
[...]
> +static void btqcomipc_update_stats(struct hci_dev *hdev, struct sk_buff *skb);
I don't think the forward-declaration is necessary
> +static struct ring_buffer_info *btss_get_tx_rbuf(struct qcom_btss *desc,
> + bool *is_sbuf_full)
> +{
> + u8 idx;
> + struct ring_buffer_info *rinfo;
> +
> + for (rinfo = &(desc->tx_ctxt->sring_buf_info); rinfo != NULL;
> + rinfo = (struct ring_buffer_info *)(uintptr_t)(rinfo->next)) {
> + idx = (rinfo->widx + 1) % (desc->tx_ctxt->smsg_buf_cnt);
That's one complex for-loop! Maybe move the assignments into the loop body
[...]
> + /* Account for HCI packet type as it's not included in the skb payload */
> + len = (skb) ? skb->len + 1 : 0;
Unnecessary parentheses, also in some other places
> + memset(&aux_ptr, 0, sizeof(struct ipc_aux_ptr));
You can do aux_ptr = { } at declaration
Konrad
^ permalink raw reply
* Re: [PATCH] firmware: qcom: scm: add missing IRQ_DOMAIN select to QCOM_SCM
From: Konrad Dybcio @ 2026-07-01 11:10 UTC (permalink / raw)
To: Julian Braha, andersson
Cc: sumit.garg, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, sumit.garg,
harshal.dev
In-Reply-To: <20260701110344.1999068-1-julianbraha@gmail.com>
On 7/1/26 1:03 PM, Julian Braha wrote:
> 'drivers/firmware/qcom/qcom_scm.c' calls 'irq_create_fwspec_mapping'
> so it will fail to compile if IRQ_DOMAIN is disabled:
>
> drivers/firmware/qcom/qcom_scm.c: In function ‘qcom_scm_get_waitq_irq’:
> drivers/firmware/qcom/qcom_scm.c:2512:16: error: implicit declaration
> of function ‘irq_create_fwspec_mapping’; did you mean
> ‘irq_create_of_mapping’? [-Wimplicit-function-declaration]
> 2512 | return irq_create_fwspec_mapping(&fwspec);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> | irq_create_of_mapping
>
> A patch-set in review proposes making QCOM_SCM visible in the kconfig
> frontend, so let's ensure that it's safe for users to enable:
> https://lore.kernel.org/lkml/akS_6izxrhgK-I22@sumit-xelite/
>
> Signed-off-by: Julian Braha <julianbraha@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH] firmware: qcom: scm: add missing IRQ_DOMAIN select to QCOM_SCM
From: Julian Braha @ 2026-07-01 11:03 UTC (permalink / raw)
To: andersson
Cc: sumit.garg, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, sumit.garg,
harshal.dev, Julian Braha
'drivers/firmware/qcom/qcom_scm.c' calls 'irq_create_fwspec_mapping'
so it will fail to compile if IRQ_DOMAIN is disabled:
drivers/firmware/qcom/qcom_scm.c: In function ‘qcom_scm_get_waitq_irq’:
drivers/firmware/qcom/qcom_scm.c:2512:16: error: implicit declaration
of function ‘irq_create_fwspec_mapping’; did you mean
‘irq_create_of_mapping’? [-Wimplicit-function-declaration]
2512 | return irq_create_fwspec_mapping(&fwspec);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| irq_create_of_mapping
A patch-set in review proposes making QCOM_SCM visible in the kconfig
frontend, so let's ensure that it's safe for users to enable:
https://lore.kernel.org/lkml/akS_6izxrhgK-I22@sumit-xelite/
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
drivers/firmware/qcom/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
index b477d54b495a..9d137fa2aa23 100644
--- a/drivers/firmware/qcom/Kconfig
+++ b/drivers/firmware/qcom/Kconfig
@@ -7,6 +7,7 @@
menu "Qualcomm firmware drivers"
config QCOM_SCM
+ select IRQ_DOMAIN
select QCOM_TZMEM
tristate
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v8 10/14] media: qcom: Pass proper PAS ID to set_remote_state API
From: Konrad Dybcio @ 2026-07-01 11:01 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <akTFZgKBQYQUYxx4@sumit-xelite>
On 7/1/26 9:44 AM, Sumit Garg wrote:
> On Tue, Jun 30, 2026 at 02:42:25PM +0200, Konrad Dybcio wrote:
>> On 6/26/26 3:34 PM, Sumit Garg wrote:
>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>
>>> As per testing the SCM backend just ignores it while OP-TEE makes
>>> use of it to for proper book keeping purpose.
>>>
>>> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>>> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
>>> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>> ---
>>> drivers/media/platform/qcom/iris/iris_firmware.c | 2 +-
>>> drivers/media/platform/qcom/venus/firmware.c | 2 +-
>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
>>> index ea9654dd679e..d2e7ba4f37e3 100644
>>> --- a/drivers/media/platform/qcom/iris/iris_firmware.c
>>> +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
>>> @@ -110,5 +110,5 @@ int iris_fw_unload(struct iris_core *core)
>>>
>>> int iris_set_hw_state(struct iris_core *core, bool resume)
>>> {
>>> - return qcom_pas_set_remote_state(resume, 0);
>>> + return qcom_pas_set_remote_state(resume, IRIS_PAS_ID);
>>> }
>>> diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
>>> index 3a38ff985822..3c0727ea137d 100644
>>> --- a/drivers/media/platform/qcom/venus/firmware.c
>>> +++ b/drivers/media/platform/qcom/venus/firmware.c
>>> @@ -59,7 +59,7 @@ int venus_set_hw_state(struct venus_core *core, bool resume)
>>> int ret;
>>>
>>> if (core->use_tz) {
>>> - ret = qcom_pas_set_remote_state(resume, 0);
>>> + ret = qcom_pas_set_remote_state(resume, VENUS_PAS_ID);
>>
>> This should not be in the middle of a mildly related series..
>> The PAS IDs should be centralized into a single header. And the
>> name of the driver shouldn't be part of the define. I would guesstimate
>> that on the secure side it's probably called VPU or VIDEO
>
> I agree with your comments, this is something I would also like to
> consolidate on OP-TEE side as well: see discussion here [1].
>
> However, the patch itself was needed to do book keeping on OP-TEE side
> but I can drop it since anyhow the video isn't functional yet in
> upstream dependent on the proper IOMMU support.
For this patch.. I think QCTZ may be ignoring the argument so it
may not matter.. on a second thought you already have it reviewed
and it's already a cross-subsys merge so might as well pull it in,
worst case scenario it'll revert cleanly
Once this lands, please move all PAS defines to.. hmm.. qcom_pas.h
sounds like a good candidate?
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/6] firmware: qcom: scm: Add support for setting Bluetooth power modes
From: Konrad Dybcio @ 2026-07-01 10:40 UTC (permalink / raw)
To: george.moussalem, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260629-ipq5018-bluetooth-v2-3-02770f03b6bb@outlook.com>
On 6/29/26 3:01 PM, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
>
> The Bluetooth subsystem (BTSS) on the IPQ5018 SoC supports setting power
> modes which are required to be configured through a Secure Channel
> Manager (SCM) call to TrustZone. However, not all Trusted Execution
> Environment (QSEE) images support this call, so first check if the call
> is available.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
I'm amazed changing this setting is a secure operation
[...]
> +/**
> + * qcom_scm_pas_set_bluetooth_power_mode() - Configure power optimization mode
> + * for the Bluetooth subsystem (BTSS)
> + * @pas_id: peripheral authentication service id
> + * @val: 0x0 for normal operation, 0x4 for ECO mode
If there's just two values, maybe we should make this take a `bool eco_mode`?
> + *
> + * Return: 0 on success, negative errno on failure.
> + * Returns -EOPNOTSUPP if the firmware configuration call is unavailable.
> + */
> +int qcom_scm_pas_set_bluetooth_power_mode(u32 pas_id, u32 val)
> +{
> + if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_PIL,
> + QCOM_SCM_PIL_PAS_BT_PWR_MODE))
> + return -EOPNOTSUPP;
> +
> + return __qcom_scm_pas_set_bluetooth_power_mode(pas_id, val);
Let's just inline the whole definition here - it's single-use anyway
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/6] Bluetooth: btqca: Add IPQ5018 support
From: Bartosz Golaszewski @ 2026-07-01 9:59 UTC (permalink / raw)
To: george.moussalem
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, George Moussalem via B4 Relay,
linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260629-ipq5018-bluetooth-v2-2-02770f03b6bb@outlook.com>
On Mon, 29 Jun 2026 15:01:45 +0200, George Moussalem via B4 Relay
<devnull+george.moussalem.outlook.com@kernel.org> said:
> From: George Moussalem <george.moussalem@outlook.com>
>
> Add the IPQ5018 SoC type and support for loading its firmware.
>
> The firmware tested has been taken from GPL sources of various router
> boards. Firmware files needed are:
> - qca/bt_fw_patch.mbn
> - qca/mpnv10.bin
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 3/6] firmware: qcom: scm: Add support for setting Bluetooth power modes
From: Bartosz Golaszewski @ 2026-07-01 9:58 UTC (permalink / raw)
To: george.moussalem
Cc: George Moussalem via B4 Relay, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc, Jens Axboe,
Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Johannes Berg, Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
Saravana Kannan, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Bjorn Andersson, Konrad Dybcio, Mathieu Poirier,
Philipp Zabel
In-Reply-To: <20260629-ipq5018-bluetooth-v2-3-02770f03b6bb@outlook.com>
On Mon, 29 Jun 2026 15:01:46 +0200, George Moussalem via B4 Relay
<devnull+george.moussalem.outlook.com@kernel.org> said:
> From: George Moussalem <george.moussalem@outlook.com>
>
> The Bluetooth subsystem (BTSS) on the IPQ5018 SoC supports setting power
> modes which are required to be configured through a Secure Channel
> Manager (SCM) call to TrustZone. However, not all Trusted Execution
> Environment (QSEE) images support this call, so first check if the call
> is available.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] wifi: cfg80211: validate EHT MLE before MLD ID read
From: Haofeng Li @ 2026-07-01 9:33 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: linux-kernel, Haofeng Li, Haofeng Li
cfg80211_gen_new_ie() copies ML probe response elements from
the parent frame when the parent EHT multi-link element has an
MLD ID matching the nontransmitted BSSID index.
The code only checked that the extension element had more than
one byte before calling ieee80211_mle_get_mld_id(). That helper
assumes a BASIC MLE with enough common info and documents that
callers must first use ieee80211_mle_type_ok().
Attack chain:
malicious AP sends a short EHT MLE in an MBSSID beacon.
cfg80211_inform_bss_frame_data() stores the copied IE buffer.
cfg80211_parse_mbssid_data() builds the nontransmitted BSS IE.
cfg80211_gen_new_ie() sees the EHT MLE in the parent frame.
ieee80211_mle_get_mld_id() then reads past the IE boundary.
Validate the MLE type and size before reading the MLD ID. This
matches the contract required by the MLE helper and rejects the
short element before any internal MLE fields are accessed.
Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn>
---
net/wireless/scan.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 05b7dc6b766c..d93629802b09 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -326,8 +326,11 @@ cfg80211_gen_new_ie(const u8 *ie, size_t ielen,
/* For ML probe response, match the MLE in the frame body with
* MLD id being 'bssid_index'
*/
- if (parent->id == WLAN_EID_EXTENSION && parent->datalen > 1 &&
+ if (parent->id == WLAN_EID_EXTENSION &&
parent->data[0] == WLAN_EID_EXT_EHT_MULTI_LINK &&
+ ieee80211_mle_type_ok(parent->data + 1,
+ IEEE80211_ML_CONTROL_TYPE_BASIC,
+ parent->datalen - 1) &&
bssid_index == ieee80211_mle_get_mld_id(parent->data + 1)) {
if (!cfg80211_copy_elem_with_frags(parent,
ie, ielen,
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v8 10/14] media: qcom: Pass proper PAS ID to set_remote_state API
From: Sumit Garg @ 2026-07-01 7:44 UTC (permalink / raw)
To: Konrad Dybcio
Cc: andersson, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <c251430d-2184-4ecc-8d05-9cb47533e5ec@oss.qualcomm.com>
On Tue, Jun 30, 2026 at 02:42:25PM +0200, Konrad Dybcio wrote:
> On 6/26/26 3:34 PM, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > As per testing the SCM backend just ignores it while OP-TEE makes
> > use of it to for proper book keeping purpose.
> >
> > Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
> > Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> > drivers/media/platform/qcom/iris/iris_firmware.c | 2 +-
> > drivers/media/platform/qcom/venus/firmware.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
> > index ea9654dd679e..d2e7ba4f37e3 100644
> > --- a/drivers/media/platform/qcom/iris/iris_firmware.c
> > +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
> > @@ -110,5 +110,5 @@ int iris_fw_unload(struct iris_core *core)
> >
> > int iris_set_hw_state(struct iris_core *core, bool resume)
> > {
> > - return qcom_pas_set_remote_state(resume, 0);
> > + return qcom_pas_set_remote_state(resume, IRIS_PAS_ID);
> > }
> > diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
> > index 3a38ff985822..3c0727ea137d 100644
> > --- a/drivers/media/platform/qcom/venus/firmware.c
> > +++ b/drivers/media/platform/qcom/venus/firmware.c
> > @@ -59,7 +59,7 @@ int venus_set_hw_state(struct venus_core *core, bool resume)
> > int ret;
> >
> > if (core->use_tz) {
> > - ret = qcom_pas_set_remote_state(resume, 0);
> > + ret = qcom_pas_set_remote_state(resume, VENUS_PAS_ID);
>
> This should not be in the middle of a mildly related series..
> The PAS IDs should be centralized into a single header. And the
> name of the driver shouldn't be part of the define. I would guesstimate
> that on the secure side it's probably called VPU or VIDEO
I agree with your comments, this is something I would also like to
consolidate on OP-TEE side as well: see discussion here [1].
However, the patch itself was needed to do book keeping on OP-TEE side
but I can drop it since anyhow the video isn't functional yet in
upstream dependent on the proper IOMMU support.
[1] https://github.com/OP-TEE/optee_os/pull/7845#discussion_r3434507317
-Sumit
^ permalink raw reply
* Re: [PATCH v8 04/14] remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
From: Sumit Garg @ 2026-07-01 7:35 UTC (permalink / raw)
To: Konrad Dybcio
Cc: andersson, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <594cf827-819e-4262-9dff-a35c7f69f86b@oss.qualcomm.com>
On Tue, Jun 30, 2026 at 02:34:59PM +0200, Konrad Dybcio wrote:
> On 6/26/26 3:34 PM, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Switch qcom_q6v5_pas client driver over to generic PAS TZ APIs. Generic PAS
> > TZ service allows to support multiple TZ implementation backends like QTEE
> > based SCM PAS service, OP-TEE based PAS service and any further future TZ
> > backend service.
> >
> > Since qcom_q6v5_pas depends on MDT loader for PAS firmware loading, it
> > has to be switched over to generic PAS APIs in this commit to avoid any
> > build issues.
> >
> > Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
> > Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
>
> I assume that the leftover qcom_scm_assign_mem() will be handled
> in a separate effort, presumably through something like FF-A lend
> on the backend
The qcom_scm_assign_mem() is already handled as a SiP call in TF-A.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
Thanks.
-Sumit
^ permalink raw reply
* Re: [PATCH v8 02/14] firmware: qcom_scm: Migrate to generic PAS service
From: Sumit Garg @ 2026-07-01 7:21 UTC (permalink / raw)
To: Julian Braha
Cc: andersson, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg,
Harshal Dev
In-Reply-To: <ac8c92cb-21f2-4274-8fe6-f771fe48eec7@gmail.com>
On Fri, Jun 26, 2026 at 06:05:54PM +0100, Julian Braha wrote:
> Hi Sumit,
>
> On 6/26/26 14:34, Sumit Garg wrote:
>
> > config QCOM_SCM
> > + tristate "Qualcomm PAS SCM interface driver"
> > + select QCOM_PAS
> > select QCOM_TZMEM
> > - tristate
> I think QCOM_SCM is missing a 'select IRQ_DOMAIN'. Right now I get a
> build error without it:
>
> drivers/firmware/qcom/qcom_scm.c: In function ‘qcom_scm_get_waitq_irq’:
> drivers/firmware/qcom/qcom_scm.c:2512:16: error: implicit declaration
> of function ‘irq_create_fwspec_mapping’; did you mean
> ‘irq_create_of_mapping’? [-Wimplicit-function-declaration]
> 2512 | return irq_create_fwspec_mapping(&fwspec);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> | irq_create_of_mapping
>
This issue should be independent of this patch-set. Please submit a
standalone fix for this.
-Sumit
^ permalink raw reply
* Re: [PATCH v8 01/14] firmware: qcom: Add a generic PAS service
From: Sumit Garg @ 2026-07-01 7:17 UTC (permalink / raw)
To: Konrad Dybcio
Cc: andersson, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg,
Harshal Dev
In-Reply-To: <dc7e58d3-4383-4d93-a38e-699888bff903@oss.qualcomm.com>
On Tue, Jun 30, 2026 at 02:14:30PM +0200, Konrad Dybcio wrote:
> On 6/26/26 3:34 PM, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Qcom platforms has the legacy of using non-standard SCM calls
> > splintered over the various kernel drivers. These SCM calls aren't
> > compliant with the standard SMC calling conventions which is a
> > prerequisite to enable migration to the FF-A specifications from Arm.
>
> [...]
>
> > +bool qcom_pas_is_available(void)
>
> This is the most important function, for which I would expect
> kerneldoc be present. I think it also wouldn't hurt to add a
> footnote in every other function's kerneldoc saying that this must
> be called first
Will add in the next spin.
-Sumit
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: wireless: ath12k: drop qcom,ath12k-calibration-variant
From: Krzysztof Kozlowski @ 2026-07-01 7:05 UTC (permalink / raw)
To: Andrew LaMarche
Cc: Johannes Berg, Jeff Johnson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-wireless, devicetree, ath12k, linux-kernel,
Ernest Van Hoecke
In-Reply-To: <20260630133001.1426824-2-andrewjlamarche@gmail.com>
On Tue, Jun 30, 2026 at 01:30:01PM +0000, Andrew LaMarche wrote:
> The ath12k-wsi binding documentation describes using the
> generation-specific qcom,ath12k-calibration-variant binding as well as
> the generation-agnostic qcom,calibration-variant binding to load
> board-specific calibration data from the device tree. However, the
> driver never implemented either of these.
>
> Given that no devices currently supported use
> qcom,ath12k-calibration-variant and the previous patch implements
> qcom,calibration-variant, drop the generation-specific version from the
> binding to prevent future confusion.
>
> Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
> ---
> .../devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml | 7 -------
> 1 file changed, 7 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: rtw89: RTL8852BE P2P-device iftype and STA+P2P interface combination
From: Doug Brewer @ 2026-07-01 6:40 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <02d3be993ed84cf983cf995e53c86f1f@realtek.com>
On Tue, Jun 30, 2026 at 8:51 AM Ping-Ke Shih wrote:
>
> Doug Brewer wrote:
> > On Mon, Jun 29, 2026 at 10:10 AM Ping-Ke Shih wrote:
> > >
> > > Doug Brewer wrote:
> > > > Hi,
> > > >
> > > > I'm experimenting with Wi-Fi Display (Miracast sink) concurrent with an
> > > > STA connection on an RTL8852BE (PCIe) using the mainline rtw89 driver
> > > > (kernel 6.18.37).
> > > >
> > > > iw phy reports:
> > > > Supported interface modes:
> > > > * managed, AP, P2P-client, P2P-GO
> > > > (no P2P-device)
> > > > interface combinations are not supported
> > > >
> > > > In practice this blocks the standard P2P flow: there is no P2P-device
> > > > iftype for a dedicated discovery context, and no advertised interface
> > > > combination for managed + P2P-client coexistence.
> > > >
> > > > My questions:
> > > > 1. is P2P-device iftype support planned for rtw89 on RTL885x? Is there a
> > > > known technical blocker, or is it simply not yet implemented?
> > >
> > > We are planning to add P2P-device iftype. It needs to consider the cases of
> > > channel context, conditions of power save, and etc. It will take some time.
> > >
> > > I think it would be okay that you use STA interface to do P2P negotiation,
> > > and then create P2P-client or P2P-GO iftype then.
> > >
> > > > 2. would advertising a managed + P2P-client interface combination
> > > > (single channel) be feasible on the current rtw89?
> > >
> > > This is a SCC which is supported.
> > >
> > > > 3. is MCC (#channels > 1) on the roadmap, or considered out of scope?
> > >
> > > Current support MCC as well. However, we are cooking new firmware to support
> > > hw_scan with two operation channels -- which doesn't matter if you don't need
> > > to do scan when MCC is operating.
> >
> > Thanks for the suggestion. I tried using the STA interface for P2P
> > negotiation, and wanted to share what I found.
> >
> > With the STA connected (2.4GHz ch11) and an active p2p_connect, a
> > wpa_supplicant -dd trace shows GO negotiation getting fairly far:
> >
> > Peer's GO-NEG Request is received
> > send the GO-NEG Response on ch11, peer ACKs it (TX ack=1)
> > State goes GO_NEG -> CONNECT
> > then time out waiting for the GO-NEG Confirm, status=-1
> >
> > I select ch11 as the P2P operating channel (same as STA, SCC), while
> > the peer's operating preference is 5GHz ch149. It looks like after we TX
> > the Response, the radio doesn't stay on ch11 to listen for the Confirm,
> > so the frame is missed -- presumably because the single radio is serving
> > the STA connection.
>
> So, peer doesn't stay ch11 to complete he negotiation, right?
>
> What is the peer device you are using? Can you setup another RTL8852BE?
> I suggest running simple scenario first to dig cause.
>
> 1. two peers make P2P group without any STA connection
> 2. RTL8852BE with a STA connection, and peer without connection.
>
> >
> > Aalso tested with the STA on 5GHz (ch149); the result is the same
> > GO-NEG Confirm timeout.
> >
> > Is this the channel-context issue that P2P-device iftype will address?
> > And with the current driver, is there any way to keep the P2P listen
> > context on the operating channel during GO negotiation while STA is up?
>
> Before P2P negotiation completion, there is only one channel context.
> The second interface (GC or GO) is created when the P2P role is decided
> by P2P negotiation.
>
> You need to check supplicant log about channels on both peers. I think
> remain-on-channel is the method supplicant switch channel to send
> negotiation frames and to stay on listen channel.
>
> >
> > (FWIW, passing an explicit freq= to p2p_connect is rejected with FAIL,
> > whether or not it matches the STA channel.)
>
> Not sure why. In our side, it seems work.
>
>
> I'd share a pair of wpa_supplicant .conf and wpa_cli commands we are testing
> for reference.
Great progress using your test conf and a second RTL8852BE. Results:
Two RTL8852BE peers, no STA — P2P connects fine (GO/client, group formed,
4-way HS completed).
One RTL8852BE with STA on 5GHz ch149, the other RTL8852BE with no STA,
also succeeds. The GO comes up on ch153 while the STA stays on ch149 (so MCC),
group formed, client connected. Both sides confirmed via iw dev
(GO on ch153 + STA on ch149; peer client on ch153).
So STA + P2P coexistence, including MCC, works fine between two 8852BE peers.
p2p_no_group_iface=1 in your conf may have contributed, P2P runs on the main
interface instead of a separate group interface.
Thank you very much for the test conf and guidance.
> Peer 1:
> ctrl_interface=/var/run/wpa_supplicant
>
> network={
> ssid="ap_x"
> key_mgmt=NONE
>
> }
>
> update_config=1
> device_name=my_p2p
> manufacturer=Realtek
> model_name=RTW_STA
> model_number=WLAN_CU
> serial_number=12345
> device_type=1-0050F204-1
> os_version=01020300
> config_methods=virtual_display virtual_push_button keypad
> p2p_listen_reg_class=81
> p2p_listen_channel=1
> p2p_oper_reg_class=81
> p2p_oper_channel=1
> p2p_no_group_iface=1
>
>
> wpa_supplicant -i wlan0 -c p2p.conf
> wpa_cli
> > p2p_find
> > p2p_connect $SUT_MAC_ADDR pbc (freq=xxxx go_intent=15)
>
>
> Peer 2:
> ctrl_interface=/var/run/wpa_supplicant
> update_config=1
> device_name=my_p2p
> manufacturer=Realtek
> model_name=RTW_STA
> model_number=WLAN_CU
> serial_number=12345
> device_type=1-0050F204-1
> os_version=01020300
> config_methods=virtual_display virtual_push_button keypad
> p2p_listen_reg_class=81
> p2p_listen_channel=1
> p2p_oper_reg_class=81
> p2p_oper_channel=1
> p2p_no_group_iface=1
>
> wpa_supplicant -i wlan0 -c p2p.conf
> wpa_cli
> > p2p_find
> > p2p_connect $DUT_MAC_ADDR pbc (freq=xxxx go_intent=1)
>
> Regards
> Ping-Ke
Regards,
Doug
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Thorsten Leemhuis @ 2026-07-01 6:16 UTC (permalink / raw)
To: stable@vger.kernel.org, Greg KH, Sasha Levin
Cc: Felix Fietkau, Lorenzo Bianconi, Jiajia Liu, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Ming Yen Hsieh, Leon Yen,
linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Linux kernel regressions list
In-Reply-To: <akSoHk-BozrpWPmZ@nature>
On 7/1/26 07:39, Jiajia Liu wrote:
> On Tue, Jun 30, 2026 at 01:29:51PM +0200, Thorsten Leemhuis wrote:
>> On 5/28/26 05:38, Jiajia Liu wrote:
>>> Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
>>> to avoid reinitializing the wcid->poll_list.
>>>
>>> Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
>>
>> Jiajia Liu, Felox:
BTW: @Felix, sorry for the typo!
>> given that the problem seems to be in 7.1, should we
>> ask the stable team to pick this regression fix up, as this change was
>> mainlined (as 20b126920a259d ("wifi: mt76: add wcid publish check in
>> mt76_sta_add") [v7.2-rc1]), but lacks both a Fixes and a Stable tag?
>
> Yes. It seems to be related to cbf5e61da660 ("wifi: mt76: initialize
> more wcid fields mt76_wcid_init") [v6.14-rc1]. But I didn't reproduce
> when I checked it out and tested. So Fixes was not added.
In that case:
@Stable team, you you please pick up 20b126920a259d ("wifi: mt76: add
wcid publish check in mt76_sta_add") [v7.2-rc1] for 7.1? It lacks a
fixes tag and the problem might be older, but I saw two reports about
this with 7.1-rc -- so it seems some recent change made that problem
more likely to occur, so it might be good to fix it at least in 7.1.y.
Ciao, Thorsten
>>> According to the corruption information, prev->next was changed to itself.
>>>
>>> wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
>>> wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
>>> wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
>>> slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
>>> list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
>>>
>>> mt76_wcid_add_poll+0x95/0xd0 [mt76]
>>> mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
>>> mt7925_rx_check+0xa7/0xc0 [mt7925_common]
>>> mt76_dma_rx_poll+0x50d/0x790 [mt76]
>>> mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
>>>
>>> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
>>> ---
>>>
>>> Changes in v2:
>>> - use dev->wcid table instead of adding MT_WCID_FLAG_DRV_PUBLSH for
>>> wcid publish check suggested by Sean
>>> - subject and commit message update
>>>
>>> ---
>>> drivers/net/wireless/mediatek/mt76/mac80211.c | 15 ++++++++++++---
>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> index 4ae5e4715a9c..b78b4cd206e0 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> @@ -1576,6 +1576,7 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
>>> {
>>> struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
>>> struct mt76_dev *dev = phy->dev;
>>> + struct mt76_wcid *published;
>>> int ret;
>>> int i;
>>>
>>> @@ -1595,11 +1596,19 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
>>> mtxq->wcid = wcid->idx;
>>> }
>>>
>>> - ewma_signal_init(&wcid->rssi);
>>> - rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
>>> + published = rcu_dereference_protected(dev->wcid[wcid->idx],
>>> + lockdep_is_held(&dev->mutex));
>>> + if (published != wcid) {
>>> + WARN_ON_ONCE(published);
>>> + ewma_signal_init(&wcid->rssi);
>>> + rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
>>> + mt76_wcid_init(wcid, phy->band_idx);
>>> + } else {
>>> + wcid->phy_idx = phy->band_idx;
>>> + }
>>> +
>>> phy->num_sta++;
>>>
>>> - mt76_wcid_init(wcid, phy->band_idx);
>>> out:
>>> mutex_unlock(&dev->mutex);
>>>
^ permalink raw reply
* Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: synicalkid @ 2026-07-01 5:47 UTC (permalink / raw)
To: lucid_duck
Cc: linux-wireless, johannes, oscar.alfonso.diaz, fjhhz1997, stable
Tested v4 logic (applied as v3 diff, functionally identical for the
real-chanctx path) on bare metal — no VM, no hypervisor.
Setup:
- Host: MacBook Air (kali-rolling, kernel 6.19.14+kali-amd64)
- Adapter: Alfa AWUS036AXML — MT7921U USB (0e8d:7961), mt7921u driver
- phy1: wlan1 (monitor) + wlan2 (managed, connected to 2.4 GHz AP on same phy)
- mac80211.ko built from linux-source-6.19, v4 patch applied, loaded via insmod
Test:
Injected 802.11 beacon frames from wlan1 (monitor) while wlan2 held
the sole chanctx on phy1. Used scapy sendp() + concurrent sniff() on
the same interface.
Result: 3/3 injected frames received back on wlan1. No crash, no kernel
warning, dmesg clean throughout.
The managed+monitor coexistence case on bare-metal MT7921U USB is
stable with this patch.
Tested-by: Glitch <synicalkid@gmail.com>
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Jiajia Liu @ 2026-07-01 5:39 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Leon Yen, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, Linux kernel regressions list
In-Reply-To: <b143b62e-ca11-4f00-ad60-f71ae55213b9@leemhuis.info>
On Tue, Jun 30, 2026 at 01:29:51PM +0200, Thorsten Leemhuis wrote:
> On 5/28/26 05:38, Jiajia Liu wrote:
> > Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
> > to avoid reinitializing the wcid->poll_list.
> >
> > Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
>
> Jiajia Liu, Felox: given that the problem seems to be in 7.1, should we
> ask the stable team to pick this regression fix up, as this change was
> mainlined (as 20b126920a259d ("wifi: mt76: add wcid publish check in
> mt76_sta_add") [v7.2-rc1]), but lacks both a Fixes and a Stable tag?
Yes. It seems to be related to cbf5e61da660 ("wifi: mt76: initialize
more wcid fields mt76_wcid_init") [v6.14-rc1]. But I didn't reproduce
when I checked it out and tested. So Fixes was not added.
>
> Ciao, Thorsten
>
> > According to the corruption information, prev->next was changed to itself.
> >
> > wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
> > wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
> > wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
> > slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
> > list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
> >
> > mt76_wcid_add_poll+0x95/0xd0 [mt76]
> > mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
> > mt7925_rx_check+0xa7/0xc0 [mt7925_common]
> > mt76_dma_rx_poll+0x50d/0x790 [mt76]
> > mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
> >
> > Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> > ---
> >
> > Changes in v2:
> > - use dev->wcid table instead of adding MT_WCID_FLAG_DRV_PUBLSH for
> > wcid publish check suggested by Sean
> > - subject and commit message update
> >
> > ---
> > drivers/net/wireless/mediatek/mt76/mac80211.c | 15 ++++++++++++---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
> > index 4ae5e4715a9c..b78b4cd206e0 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
> > @@ -1576,6 +1576,7 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> > {
> > struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
> > struct mt76_dev *dev = phy->dev;
> > + struct mt76_wcid *published;
> > int ret;
> > int i;
> >
> > @@ -1595,11 +1596,19 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> > mtxq->wcid = wcid->idx;
> > }
> >
> > - ewma_signal_init(&wcid->rssi);
> > - rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> > + published = rcu_dereference_protected(dev->wcid[wcid->idx],
> > + lockdep_is_held(&dev->mutex));
> > + if (published != wcid) {
> > + WARN_ON_ONCE(published);
> > + ewma_signal_init(&wcid->rssi);
> > + rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> > + mt76_wcid_init(wcid, phy->band_idx);
> > + } else {
> > + wcid->phy_idx = phy->band_idx;
> > + }
> > +
> > phy->num_sta++;
> >
> > - mt76_wcid_init(wcid, phy->band_idx);
> > out:
> > mutex_unlock(&dev->mutex);
> >
^ permalink raw reply
* [PATCH] wifi: ath9k: validate RX stream lengths before copying
From: Pengpeng Hou @ 2026-07-01 5:38 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Pengpeng Hou, linux-wireless, linux-kernel
ath9k_hif_usb_rx_stream() reads RX stream headers and copies payload
bytes from the current skb into newly allocated skbs. It also completes
packets that span two URBs by copying the remaining bytes from the next
skb into hif_dev->remain_skb.
The parser checked the stream tag and an upper bound on pkt_len, but it
did not first prove that the fixed header, the non-fragmented payload,
or the bytes needed to complete a fragmented packet are present in the
current skb. Reject malformed RX stream data before reading or copying
beyond the received buffer.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 821909b8..f47b0ae0 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -571,6 +571,16 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
ptr = (u8 *) remain_skb->data;
index = rx_remain_len;
+ if (rx_remain_len < hif_dev->rx_pad_len ||
+ len < rx_remain_len - hif_dev->rx_pad_len) {
+ dev_kfree_skb_any(remain_skb);
+ hif_dev->remain_skb = NULL;
+ hif_dev->rx_remain_len = 0;
+ RX_STAT_INC(hif_dev, skb_dropped);
+ spin_unlock(&hif_dev->rx_lock);
+ return;
+ }
+
rx_remain_len -= hif_dev->rx_pad_len;
ptr += rx_pkt_len;
@@ -597,6 +607,11 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
ptr = (u8 *) skb->data;
+ if (len - index < 4) {
+ RX_STAT_INC(hif_dev, skb_dropped);
+ goto invalid_pkt;
+ }
+
pkt_len = get_unaligned_le16(ptr + index);
pkt_tag = get_unaligned_le16(ptr + index + 2);
@@ -625,6 +640,11 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
index = index + 4 + pkt_len + pad_len;
if (index > MAX_RX_BUF_SIZE) {
+ if (len < MAX_RX_BUF_SIZE) {
+ RX_STAT_INC(hif_dev, skb_dropped);
+ goto invalid_pkt;
+ }
+
spin_lock(&hif_dev->rx_lock);
nskb = __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC);
if (!nskb) {
@@ -649,6 +669,11 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
hif_dev->remain_skb = nskb;
spin_unlock(&hif_dev->rx_lock);
} else {
+ if (pkt_len > len - chk_idx - 4) {
+ RX_STAT_INC(hif_dev, skb_dropped);
+ goto invalid_pkt;
+ }
+
if (pool_index == MAX_PKT_NUM_IN_TRANSFER) {
dev_err(&hif_dev->udev->dev,
"ath9k_htc: over RX MAX_PKT_NUM\n");
^ 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