[RESEND PATCH ath-current 0/3] wifi: ath11k: fix QRTR readiness related WLAN initialization failures

[RESEND PATCH ath-current 0/3] wifi: ath11k: fix QRTR readiness related WLAN initialization failures

[Miaoqing Pan]

On WCN6750 platforms, QRTR SMD may not be available when ath11k starts
during boot. If QMI messages never arrive, WLAN initialization can stall,
leaving firmware running but no wireless interface created.

It also hardens the cleanup path to avoid crashes when deinitializing
partially initialized devices after QMI setup failures.

---
Miaoqing Pan (3):
  wifi: ath11k: fix sporadic WLAN initialization failures
  wifi: ath11k: fix NULL dereference in ahb remove when QMI init
    incomplete
  wifi: ath11k: unregister PM notifier on QMI init failure path

 drivers/net/wireless/ath/ath11k/Kconfig | 3 +++
 drivers/net/wireless/ath/ath11k/ahb.c   | 8 ++++++--
 2 files changed, 9 insertions(+), 2 deletions(-)


base-commit: 6776197cc88d0d397084bc47bca7e983017cecc2
-- 
2.34.1

[RESEND PATCH ath-current 1/3] wifi: ath11k: fix sporadic WLAN initialization failures

[Miaoqing Pan]

On WCN6750 platforms, reboot stress testing occasionally results in WLAN
initialization failures after boot. The WPSS firmware reaches the running
state successfully, but no WLAN interface is created.

Analysis shows that ath11k_ahb depends on the QRTR SMD transport for QMI
communication with WPSS firmware. However, this dependency is not
currently expressed in Kconfig, allowing qrtr_smd and ath11k_ahb to load
in either order when built as modules.

If ath11k_ahb is loaded before qrtr_smd becomes available, WLAN
initialization may not complete successfully.

Make the QRTR and QRTR_SMD dependencies explicit and add a soft
dependency to ensure qrtr_smd is loaded before ath11k_ahb.

Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1

Fixes: 00402f49d26f ("ath11k: Add support for WCN6750 device")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
---
 drivers/net/wireless/ath/ath11k/Kconfig | 3 +++
 drivers/net/wireless/ath/ath11k/ahb.c   | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath11k/Kconfig b/drivers/net/wireless/ath/ath11k/Kconfig
index 122726f84492..44b520d2e66e 100644
--- a/drivers/net/wireless/ath/ath11k/Kconfig
+++ b/drivers/net/wireless/ath/ath11k/Kconfig
@@ -14,6 +14,9 @@ config ATH11K_AHB
 	tristate "Atheros ath11k AHB support"
 	depends on ATH11K
 	depends on REMOTEPROC
+	select RPMSG
+	select QRTR
+	select QRTR_SMD
 	help
 	  This module adds support for AHB bus
 
diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
index 1e1dea485760..fb5640882b98 100644
--- a/drivers/net/wireless/ath/ath11k/ahb.c
+++ b/drivers/net/wireless/ath/ath11k/ahb.c
@@ -1312,5 +1312,6 @@ static struct platform_driver ath11k_ahb_driver = {
 
 module_platform_driver(ath11k_ahb_driver);
 
+MODULE_SOFTDEP("pre: qrtr_smd");
 MODULE_DESCRIPTION("Driver support for Qualcomm Technologies 802.11ax WLAN AHB devices");
 MODULE_LICENSE("Dual BSD/GPL");
-- 
2.34.1

[RESEND PATCH ath-current 2/3] wifi: ath11k: fix NULL dereference in ahb remove when QMI init incomplete

[Miaoqing Pan]

On WCN6750, if QMI messages never arrive (for example when qrtr_smd
is not ready), WLAN initialization stops before the device is fully
registered. In this case ATH11K_FLAG_QMI_FAIL is not set because no
QMI event handler is executed.

When the driver is removed, ath11k_ahb_remove() still calls
ath11k_core_deinit(), which eventually triggers
ath11k_ce_cleanup_pipes() on uninitialized CE pipes and results in a
NULL pointer dereference in ath11k_hal_srng_access_begin():

  ath11k_hal_srng_access_begin+0x14/0x68 [ath11k]
  ath11k_ce_cleanup_pipes+0x184/0x190 [ath11k]
  ath11k_pcic_stop+0x24/0x38 [ath11k]
  ath11k_core_deinit+0xfc/0x1c0 [ath11k]
  ath11k_ahb_remove+0x38/0xa0 [ath11k_ahb]

Fix this by invoking ath11k_ahb_remove_prepare() before the state
check and skipping ath11k_core_deinit() when either QMI initialization
failed or the device was never registered. If ATH11K_FLAG_REGISTERED
is not set, core initialization did not complete and CE pipes may
remain uninitialized, making ath11k_core_deinit() unsafe.

Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1

Fixes: 00402f49d26f ("ath11k: Add support for WCN6750 device")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
---
 drivers/net/wireless/ath/ath11k/ahb.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
index fb5640882b98..7f5f5c8d7c56 100644
--- a/drivers/net/wireless/ath/ath11k/ahb.c
+++ b/drivers/net/wireless/ath/ath11k/ahb.c
@@ -1265,14 +1265,16 @@ static void ath11k_ahb_remove(struct platform_device *pdev)
 {
 	struct ath11k_base *ab = platform_get_drvdata(pdev);
 
-	if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags)) {
+	ath11k_ahb_remove_prepare(ab);
+
+	if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags) ||
+	    !test_bit(ATH11K_FLAG_REGISTERED, &ab->dev_flags)) {
 		ath11k_ahb_power_down(ab, false);
 		ath11k_debugfs_soc_destroy(ab);
 		ath11k_qmi_deinit_service(ab);
 		goto qmi_fail;
 	}
 
-	ath11k_ahb_remove_prepare(ab);
 	ath11k_core_deinit(ab);
 
 qmi_fail:
-- 
2.34.1

Re: [RESEND PATCH ath-current 2/3] wifi: ath11k: fix NULL dereference in ahb remove when QMI init incomplete

[Rameshkumar Sundaram]

On 7/30/2026 8:39 AM, Miaoqing Pan wrote:
> On WCN6750, if QMI messages never arrive (for example when qrtr_smd
> is not ready), WLAN initialization stops before the device is fully
> registered. In this case ATH11K_FLAG_QMI_FAIL is not set because no
> QMI event handler is executed.
> 
> When the driver is removed, ath11k_ahb_remove() still calls
> ath11k_core_deinit(), which eventually triggers
> ath11k_ce_cleanup_pipes() on uninitialized CE pipes and results in a
> NULL pointer dereference in ath11k_hal_srng_access_begin():
> 
>    ath11k_hal_srng_access_begin+0x14/0x68 [ath11k]
>    ath11k_ce_cleanup_pipes+0x184/0x190 [ath11k]
>    ath11k_pcic_stop+0x24/0x38 [ath11k]
>    ath11k_core_deinit+0xfc/0x1c0 [ath11k]
>    ath11k_ahb_remove+0x38/0xa0 [ath11k_ahb]
> 
> Fix this by invoking ath11k_ahb_remove_prepare() before the state
> check and skipping ath11k_core_deinit() when either QMI initialization
> failed or the device was never registered. If ATH11K_FLAG_REGISTERED
> is not set, core initialization did not complete and CE pipes may
> remain uninitialized, making ath11k_core_deinit() unsafe.
> 
> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1
> 
> Fixes: 00402f49d26f ("ath11k: Add support for WCN6750 device")
> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath11k/ahb.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
> index fb5640882b98..7f5f5c8d7c56 100644
> --- a/drivers/net/wireless/ath/ath11k/ahb.c
> +++ b/drivers/net/wireless/ath/ath11k/ahb.c
> @@ -1265,14 +1265,16 @@ static void ath11k_ahb_remove(struct platform_device *pdev)
>   {
>   	struct ath11k_base *ab = platform_get_drvdata(pdev);
>   
> -	if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags)) {
> +	ath11k_ahb_remove_prepare(ab);
> +
> +	if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags) ||
> +	    !test_bit(ATH11K_FLAG_REGISTERED, &ab->dev_flags)) {

Can we use ATH11K_FLAG_REGISTERED alone to decide the cleanup path? If 
REGISTERED is set, ath11k_core_qmi_firmware_ready() completed at least 
once and the normal ath11k_core_deinit() path should run. If QMI failed 
on recovery (say before FW_READY or INIT_DONE) this should still do 
core_deinit() isn't ?


>   		ath11k_ahb_power_down(ab, false);
>   		ath11k_debugfs_soc_destroy(ab);
>   		ath11k_qmi_deinit_service(ab);
>   		goto qmi_fail;
>   	}
>   
> -	ath11k_ahb_remove_prepare(ab);
>   	ath11k_core_deinit(ab);
>   
>   qmi_fail:



--
Ramesh

Re: [RESEND PATCH ath-current 2/3] wifi: ath11k: fix NULL dereference in ahb remove when QMI init incomplete

[Miaoqing Pan]

On 7/31/2026 5:24 PM, Rameshkumar Sundaram wrote:
> On 7/30/2026 8:39 AM, Miaoqing Pan wrote:
>> On WCN6750, if QMI messages never arrive (for example when qrtr_smd
>> is not ready), WLAN initialization stops before the device is fully
>> registered. In this case ATH11K_FLAG_QMI_FAIL is not set because no
>> QMI event handler is executed.
>>
>> When the driver is removed, ath11k_ahb_remove() still calls
>> ath11k_core_deinit(), which eventually triggers
>> ath11k_ce_cleanup_pipes() on uninitialized CE pipes and results in a
>> NULL pointer dereference in ath11k_hal_srng_access_begin():
>>
>>    ath11k_hal_srng_access_begin+0x14/0x68 [ath11k]
>>    ath11k_ce_cleanup_pipes+0x184/0x190 [ath11k]
>>    ath11k_pcic_stop+0x24/0x38 [ath11k]
>>    ath11k_core_deinit+0xfc/0x1c0 [ath11k]
>>    ath11k_ahb_remove+0x38/0xa0 [ath11k_ahb]
>>
>> Fix this by invoking ath11k_ahb_remove_prepare() before the state
>> check and skipping ath11k_core_deinit() when either QMI initialization
>> failed or the device was never registered. If ATH11K_FLAG_REGISTERED
>> is not set, core initialization did not complete and CE pipes may
>> remain uninitialized, making ath11k_core_deinit() unsafe.
>>
>> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1
>>
>> Fixes: 00402f49d26f ("ath11k: Add support for WCN6750 device")
>> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
>> ---
>>   drivers/net/wireless/ath/ath11k/ahb.c | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/ 
>> wireless/ath/ath11k/ahb.c
>> index fb5640882b98..7f5f5c8d7c56 100644
>> --- a/drivers/net/wireless/ath/ath11k/ahb.c
>> +++ b/drivers/net/wireless/ath/ath11k/ahb.c
>> @@ -1265,14 +1265,16 @@ static void ath11k_ahb_remove(struct 
>> platform_device *pdev)
>>   {
>>       struct ath11k_base *ab = platform_get_drvdata(pdev);
>> -    if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags)) {
>> +    ath11k_ahb_remove_prepare(ab);
>> +
>> +    if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags) ||
>> +        !test_bit(ATH11K_FLAG_REGISTERED, &ab->dev_flags)) {
> 
> Can we use ATH11K_FLAG_REGISTERED alone to decide the cleanup path? If 
> REGISTERED is set, ath11k_core_qmi_firmware_ready() completed at least 
> once and the normal ath11k_core_deinit() path should run. If QMI failed 
> on recovery (say before FW_READY or INIT_DONE) this should still do 
> core_deinit() isn't ?
> 
> 
During SSR recovery, it is possible for a QMI failure to occur after the 
device has already been registered, which could result in both 
ATH11K_FLAG_REGISTERED and ATH11K_FLAG_QMI_FAIL being set at the same time.
>>           ath11k_ahb_power_down(ab, false);
>>           ath11k_debugfs_soc_destroy(ab);
>>           ath11k_qmi_deinit_service(ab);
>>           goto qmi_fail;
>>       }
>> -    ath11k_ahb_remove_prepare(ab);
>>       ath11k_core_deinit(ab);
>>   qmi_fail:
> 
> 
> 
> -- 
> Ramesh

Re: [RESEND PATCH ath-current 2/3] wifi: ath11k: fix NULL dereference in ahb remove when QMI init incomplete

[Rameshkumar Sundaram]

On 8/3/2026 12:17 PM, Miaoqing Pan wrote:
> 
> 
> On 7/31/2026 5:24 PM, Rameshkumar Sundaram wrote:
>> On 7/30/2026 8:39 AM, Miaoqing Pan wrote:
>>> On WCN6750, if QMI messages never arrive (for example when qrtr_smd
>>> is not ready), WLAN initialization stops before the device is fully
>>> registered. In this case ATH11K_FLAG_QMI_FAIL is not set because no
>>> QMI event handler is executed.
>>>
>>> When the driver is removed, ath11k_ahb_remove() still calls
>>> ath11k_core_deinit(), which eventually triggers
>>> ath11k_ce_cleanup_pipes() on uninitialized CE pipes and results in a
>>> NULL pointer dereference in ath11k_hal_srng_access_begin():
>>>
>>>    ath11k_hal_srng_access_begin+0x14/0x68 [ath11k]
>>>    ath11k_ce_cleanup_pipes+0x184/0x190 [ath11k]
>>>    ath11k_pcic_stop+0x24/0x38 [ath11k]
>>>    ath11k_core_deinit+0xfc/0x1c0 [ath11k]
>>>    ath11k_ahb_remove+0x38/0xa0 [ath11k_ahb]
>>>
>>> Fix this by invoking ath11k_ahb_remove_prepare() before the state
>>> check and skipping ath11k_core_deinit() when either QMI initialization
>>> failed or the device was never registered. If ATH11K_FLAG_REGISTERED
>>> is not set, core initialization did not complete and CE pipes may
>>> remain uninitialized, making ath11k_core_deinit() unsafe.
>>>
>>> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1
>>>
>>> Fixes: 00402f49d26f ("ath11k: Add support for WCN6750 device")
>>> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
>>> ---
>>>   drivers/net/wireless/ath/ath11k/ahb.c | 6 ++++--
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/ 
>>> wireless/ath/ath11k/ahb.c
>>> index fb5640882b98..7f5f5c8d7c56 100644
>>> --- a/drivers/net/wireless/ath/ath11k/ahb.c
>>> +++ b/drivers/net/wireless/ath/ath11k/ahb.c
>>> @@ -1265,14 +1265,16 @@ static void ath11k_ahb_remove(struct 
>>> platform_device *pdev)
>>>   {
>>>       struct ath11k_base *ab = platform_get_drvdata(pdev);
>>> -    if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags)) {
>>> +    ath11k_ahb_remove_prepare(ab);
>>> +
>>> +    if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags) ||
>>> +        !test_bit(ATH11K_FLAG_REGISTERED, &ab->dev_flags)) {
>>
>> Can we use ATH11K_FLAG_REGISTERED alone to decide the cleanup path? If 
>> REGISTERED is set, ath11k_core_qmi_firmware_ready() completed at least 
>> once and the normal ath11k_core_deinit() path should run. If QMI 
>> failed on recovery (say before FW_READY or INIT_DONE) this should 
>> still do core_deinit() isn't ?
>>
>>
> During SSR recovery, it is possible for a QMI failure to occur after the 
> device has already been registered, which could result in both 
> ATH11K_FLAG_REGISTERED and ATH11K_FLAG_QMI_FAIL being set at the same time.

Yeah so in that case current code will skip core_deinit() which should 
actually run isn't ? Though the QMI has failed on recovery the core was 
already initialized and should be torn down.

>>>           ath11k_ahb_power_down(ab, false);
>>>           ath11k_debugfs_soc_destroy(ab);
>>>           ath11k_qmi_deinit_service(ab);
>>>           goto qmi_fail;
>>>       }
>>> -    ath11k_ahb_remove_prepare(ab);
>>>       ath11k_core_deinit(ab);
>>>   qmi_fail:
>>

--
Ramesh

Re: [RESEND PATCH ath-current 2/3] wifi: ath11k: fix NULL dereference in ahb remove when QMI init incomplete

[Miaoqing Pan]

On 8/5/2026 6:07 PM, Rameshkumar Sundaram wrote:
> On 8/3/2026 12:17 PM, Miaoqing Pan wrote:
>>
>>
>> On 7/31/2026 5:24 PM, Rameshkumar Sundaram wrote:
>>> On 7/30/2026 8:39 AM, Miaoqing Pan wrote:
>>>> On WCN6750, if QMI messages never arrive (for example when qrtr_smd
>>>> is not ready), WLAN initialization stops before the device is fully
>>>> registered. In this case ATH11K_FLAG_QMI_FAIL is not set because no
>>>> QMI event handler is executed.
>>>>
>>>> When the driver is removed, ath11k_ahb_remove() still calls
>>>> ath11k_core_deinit(), which eventually triggers
>>>> ath11k_ce_cleanup_pipes() on uninitialized CE pipes and results in a
>>>> NULL pointer dereference in ath11k_hal_srng_access_begin():
>>>>
>>>>    ath11k_hal_srng_access_begin+0x14/0x68 [ath11k]
>>>>    ath11k_ce_cleanup_pipes+0x184/0x190 [ath11k]
>>>>    ath11k_pcic_stop+0x24/0x38 [ath11k]
>>>>    ath11k_core_deinit+0xfc/0x1c0 [ath11k]
>>>>    ath11k_ahb_remove+0x38/0xa0 [ath11k_ahb]
>>>>
>>>> Fix this by invoking ath11k_ahb_remove_prepare() before the state
>>>> check and skipping ath11k_core_deinit() when either QMI initialization
>>>> failed or the device was never registered. If ATH11K_FLAG_REGISTERED
>>>> is not set, core initialization did not complete and CE pipes may
>>>> remain uninitialized, making ath11k_core_deinit() unsafe.
>>>>
>>>> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1
>>>>
>>>> Fixes: 00402f49d26f ("ath11k: Add support for WCN6750 device")
>>>> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
>>>> ---
>>>>   drivers/net/wireless/ath/ath11k/ahb.c | 6 ++++--
>>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/ 
>>>> wireless/ath/ath11k/ahb.c
>>>> index fb5640882b98..7f5f5c8d7c56 100644
>>>> --- a/drivers/net/wireless/ath/ath11k/ahb.c
>>>> +++ b/drivers/net/wireless/ath/ath11k/ahb.c
>>>> @@ -1265,14 +1265,16 @@ static void ath11k_ahb_remove(struct 
>>>> platform_device *pdev)
>>>>   {
>>>>       struct ath11k_base *ab = platform_get_drvdata(pdev);
>>>> -    if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags)) {
>>>> +    ath11k_ahb_remove_prepare(ab);
>>>> +
>>>> +    if (test_bit(ATH11K_FLAG_QMI_FAIL, &ab->dev_flags) ||
>>>> +        !test_bit(ATH11K_FLAG_REGISTERED, &ab->dev_flags)) {
>>>
>>> Can we use ATH11K_FLAG_REGISTERED alone to decide the cleanup path? 
>>> If REGISTERED is set, ath11k_core_qmi_firmware_ready() completed at 
>>> least once and the normal ath11k_core_deinit() path should run. If 
>>> QMI failed on recovery (say before FW_READY or INIT_DONE) this should 
>>> still do core_deinit() isn't ?
>>>
>>>
>> During SSR recovery, it is possible for a QMI failure to occur after 
>> the device has already been registered, which could result in both 
>> ATH11K_FLAG_REGISTERED and ATH11K_FLAG_QMI_FAIL being set at the same 
>> time.
> 
> Yeah so in that case current code will skip core_deinit() which should 
> actually run isn't ? Though the QMI has failed on recovery the core was 
> already initialized and should be torn down.
> 

Thanks for the review.

You are right. During SSR, if QMI fails after the device is already 
registered, core_deinit() should still run for proper cleanup. Will send v2.

>>>>           ath11k_ahb_power_down(ab, false);
>>>>           ath11k_debugfs_soc_destroy(ab);
>>>>           ath11k_qmi_deinit_service(ab);
>>>>           goto qmi_fail;
>>>>       }
>>>> -    ath11k_ahb_remove_prepare(ab);
>>>>       ath11k_core_deinit(ab);
>>>>   qmi_fail:
>>>
> 
> -- 
> Ramesh

[RESEND PATCH ath-current 3/3] wifi: ath11k: unregister PM notifier on QMI init failure path

[Miaoqing Pan]

ath11k_core_init() registers a PM notifier before the QMI server
becomes available. If the QMI server never arrives, the device remove()
path can take the early-exit path introduced for QMI initialization
failures, skipping ath11k_core_deinit().

As a result, the PM notifier remains registered after the ath11k base
object has been freed. A subsequent suspend or resume event may invoke
the stale notifier and trigger a use-after-free.

Fix this by explicitly unregistering the PM notifier in the QMI failure
cleanup path before releasing ath11k resources.

Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1

Fixes: 32d93b51bc7e ("wifi: ath11k: choose default PM policy for hibernation")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
---
 drivers/net/wireless/ath/ath11k/ahb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
index 7f5f5c8d7c56..bdb8c99f10fa 100644
--- a/drivers/net/wireless/ath/ath11k/ahb.c
+++ b/drivers/net/wireless/ath/ath11k/ahb.c
@@ -1272,6 +1272,7 @@ static void ath11k_ahb_remove(struct platform_device *pdev)
 		ath11k_ahb_power_down(ab, false);
 		ath11k_debugfs_soc_destroy(ab);
 		ath11k_qmi_deinit_service(ab);
+		ath11k_core_pm_notifier_unregister(ab);
 		goto qmi_fail;
 	}
 
-- 
2.34.1

Re: [RESEND PATCH ath-current 3/3] wifi: ath11k: unregister PM notifier on QMI init failure path

[Jeff Johnson]

On 7/29/2026 8:09 PM, Miaoqing Pan wrote:
> ath11k_core_init() registers a PM notifier before the QMI server
> becomes available. If the QMI server never arrives, the device remove()
> path can take the early-exit path introduced for QMI initialization
> failures, skipping ath11k_core_deinit().

This patch felt wrong to me, so I spent some time with my buddy Claude.

I asked Claude: in the last patch the commit text says "If the QMI server
never arrives, the device remove() path can take the early-exit path
introduced for QMI initialization failures". where is this device remove()
path code? I'm trying to understand why there needs to be a call to
ath11k_core_pm_notifier_unregister() in ath11k_ahb_remove() as well as in
ath11k_core_deinit(). since ath11k_core_pm_notifier_register() is only called
from one place it is logical that ath11k_core_pm_notifier_unregister() should
also be called in one place that is symmetrical. the proposed patch breaks the
init/deinit symmetry.

Claude said:
The symmetry argument is well-founded. Here's the actual structure:

ath11k_core_init() registers the notifier. ath11k_core_deinit() is its
symmetric counterpart and unregisters it. That is the intended 1:1 pairing.

The problem is that both ath11k_ahb_remove() and ath11k_pci_remove() have an
early-exit path for QMI_FAIL that bypasses ath11k_core_deinit() — but still
need to undo what ath11k_core_init() did. So they replicate the unregister
call directly. This is an existing pattern: pci.c:1188 already had
ath11k_core_pm_notifier_unregister() in its QMI_FAIL early-exit before this
patch series.

Patch 3 simply extends that same pattern to ahb.c's early-exit path, which was
missing it.

The symmetry break isn't introduced by this patch — it was already present for
PCI. The fix for the symmetry issue would be to restructure so the early-exit
paths all go through ath11k_core_deinit() (or a new partial-deinit function),
but that's a larger refactor. This patch's approach matches the existing
convention in the tree.

The commit message claim about "the early-exit path introduced for QMI
initialization failures" refers to the QMI_FAIL branch at ahb.c:1301 — the
goto qmi_fail block that skips ath11k_core_deinit().

Thank you, Claude.

So I guess this patch is OK since it is replicating the PCI pattern, but is
there any way to have ath11k_core_deinit() called in those early exit paths so
that we can keep the init/deinit symmetry? It just seems wrong that if
ath11k_core_init() did not return an error that we would have deinit logic
that would skip calling ath11k_core_deinit()

> 
> As a result, the PM notifier remains registered after the ath11k base
> object has been freed. A subsequent suspend or resume event may invoke
> the stale notifier and trigger a use-after-free.
> 
> Fix this by explicitly unregistering the PM notifier in the QMI failure
> cleanup path before releasing ath11k resources.
> 
> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1
> 
> Fixes: 32d93b51bc7e ("wifi: ath11k: choose default PM policy for hibernation")
> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
> ---
>  drivers/net/wireless/ath/ath11k/ahb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
> index 7f5f5c8d7c56..bdb8c99f10fa 100644
> --- a/drivers/net/wireless/ath/ath11k/ahb.c
> +++ b/drivers/net/wireless/ath/ath11k/ahb.c
> @@ -1272,6 +1272,7 @@ static void ath11k_ahb_remove(struct platform_device *pdev)
>  		ath11k_ahb_power_down(ab, false);
>  		ath11k_debugfs_soc_destroy(ab);
>  		ath11k_qmi_deinit_service(ab);
> +		ath11k_core_pm_notifier_unregister(ab);
>  		goto qmi_fail;
>  	}
>  

Re: [RESEND PATCH ath-current 3/3] wifi: ath11k: unregister PM notifier on QMI init failure path

[Miaoqing Pan]

On 8/1/2026 7:06 AM, Jeff Johnson wrote:
> On 7/29/2026 8:09 PM, Miaoqing Pan wrote:
>> ath11k_core_init() registers a PM notifier before the QMI server
>> becomes available. If the QMI server never arrives, the device remove()
>> path can take the early-exit path introduced for QMI initialization
>> failures, skipping ath11k_core_deinit().
> 
> This patch felt wrong to me, so I spent some time with my buddy Claude.
> 
> I asked Claude: in the last patch the commit text says "If the QMI server
> never arrives, the device remove() path can take the early-exit path
> introduced for QMI initialization failures". where is this device remove()
> path code? I'm trying to understand why there needs to be a call to
> ath11k_core_pm_notifier_unregister() in ath11k_ahb_remove() as well as in
> ath11k_core_deinit(). since ath11k_core_pm_notifier_register() is only called
> from one place it is logical that ath11k_core_pm_notifier_unregister() should
> also be called in one place that is symmetrical. the proposed patch breaks the
> init/deinit symmetry.
> 
> Claude said:
> The symmetry argument is well-founded. Here's the actual structure:
> 
> ath11k_core_init() registers the notifier. ath11k_core_deinit() is its
> symmetric counterpart and unregisters it. That is the intended 1:1 pairing.
> 
> The problem is that both ath11k_ahb_remove() and ath11k_pci_remove() have an
> early-exit path for QMI_FAIL that bypasses ath11k_core_deinit() — but still
> need to undo what ath11k_core_init() did. So they replicate the unregister
> call directly. This is an existing pattern: pci.c:1188 already had
> ath11k_core_pm_notifier_unregister() in its QMI_FAIL early-exit before this
> patch series.
> 
> Patch 3 simply extends that same pattern to ahb.c's early-exit path, which was
> missing it.
> 
> The symmetry break isn't introduced by this patch — it was already present for
> PCI. The fix for the symmetry issue would be to restructure so the early-exit
> paths all go through ath11k_core_deinit() (or a new partial-deinit function),
> but that's a larger refactor. This patch's approach matches the existing
> convention in the tree.
> 
> The commit message claim about "the early-exit path introduced for QMI
> initialization failures" refers to the QMI_FAIL branch at ahb.c:1301 — the
> goto qmi_fail block that skips ath11k_core_deinit().
> 
> Thank you, Claude.
> 
> So I guess this patch is OK since it is replicating the PCI pattern, but is
> there any way to have ath11k_core_deinit() called in those early exit paths so
> that we can keep the init/deinit symmetry? It just seems wrong that if
> ath11k_core_init() did not return an error that we would have deinit logic
> that would skip calling ath11k_core_deinit()
> 
The init/deinit symmetry issue is a pre-existing concern and not trivial 
to solve. We can address it separately in a future cleanup/refactoring 
patch.
>>
>> As a result, the PM notifier remains registered after the ath11k base
>> object has been freed. A subsequent suspend or resume event may invoke
>> the stale notifier and trigger a use-after-free.
>>
>> Fix this by explicitly unregistering the PM notifier in the QMI failure
>> cleanup path before releasing ath11k resources.
>>
>> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1
>>
>> Fixes: 32d93b51bc7e ("wifi: ath11k: choose default PM policy for hibernation")
>> Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
>> ---
>>   drivers/net/wireless/ath/ath11k/ahb.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
>> index 7f5f5c8d7c56..bdb8c99f10fa 100644
>> --- a/drivers/net/wireless/ath/ath11k/ahb.c
>> +++ b/drivers/net/wireless/ath/ath11k/ahb.c
>> @@ -1272,6 +1272,7 @@ static void ath11k_ahb_remove(struct platform_device *pdev)
>>   		ath11k_ahb_power_down(ab, false);
>>   		ath11k_debugfs_soc_destroy(ab);
>>   		ath11k_qmi_deinit_service(ab);
>> +		ath11k_core_pm_notifier_unregister(ab);
>>   		goto qmi_fail;
>>   	}
>>   
> 

Re: [RESEND PATCH ath-current 0/3] wifi: ath11k: fix QRTR readiness related WLAN initialization failures

[Baochen Qiang]

On 7/30/2026 11:09 AM, Miaoqing Pan wrote:
> On WCN6750 platforms, QRTR SMD may not be available when ath11k starts
> during boot. If QMI messages never arrive, WLAN initialization can stall,
> leaving firmware running but no wireless interface created.
> 
> It also hardens the cleanup path to avoid crashes when deinitializing
> partially initialized devices after QMI setup failures.
> 
> ---
> Miaoqing Pan (3):
>   wifi: ath11k: fix sporadic WLAN initialization failures
>   wifi: ath11k: fix NULL dereference in ahb remove when QMI init
>     incomplete
>   wifi: ath11k: unregister PM notifier on QMI init failure path
> 
>  drivers/net/wireless/ath/ath11k/Kconfig | 3 +++
>  drivers/net/wireless/ath/ath11k/ahb.c   | 8 ++++++--
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> 
> base-commit: 6776197cc88d0d397084bc47bca7e983017cecc2

Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>