Re: [PATCH ath-next v2 6/8] wifi: ath10k: hard-block the radio when entering WEDGED state

[Kang Yang <kang.yang@oss.qualcomm.com>]

On 10/21/2026 9:54 PM, Loic Poulain wrote:
> On Wed, Oct 21, 2026 at 11:10 AM Kang Yang <kang.yang@oss.qualcomm.com> wrote:
>>
>> Once ath10k reaches ATH10K_STATE_WEDGED, the device can no
>> longer recover and remains unusable until the driver is
>> reloaded.
>>
>> Userspace daemons may continue issuing scan and connect
>> requests, which the driver can only reject individually.
>>
>> Mark the radio as hardware-blocked through rfkill when
>> entering the WEDGED state so userspace stops retrying
>> operations against a device that can no longer operate.
>>
>> Both WEDGED transitions already route through
>> ath10k_core_enter_wedged(), so adding the call there is
>> enough to cover them consistently.
>>
>> Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
>> Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
>>
>> Signed-off-by: Kang Yang <kang.yang@oss.qualcomm.com>
>> ---
>>   drivers/net/wireless/ath/ath10k/core.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>> index 6b6b80242cd1..66585cfa6d96 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.c
>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>> @@ -2521,6 +2521,14 @@ static void ath10k_core_enter_wedged(struct ath10k *ar)
>>
>>          ieee80211_stop_queues(ar->hw);
>>          ath10k_core_wake_all_waiters(ar);
>> +
>> +       /*
>> +        * Signal the radio as hard-blocked so userspace (e.g.
>> +        * wpa_supplicant, NetworkManager) stops looping scan and connect
>> +        * requests at a device the driver has already given up on. The
>> +        * state is cleared only when the driver is reloaded.
>> +        */
>> +       wiphy_rfkill_set_hw_state(ar->hw->wiphy, true);
> 
> Using rfkill to signal the wedged state feels like an abuse of the
> interface. Have you seen similar handling in other wireless drivers?
> Wouldn't wiphy_unregister() be more appropriate here?

You can grep with 'wiphy_rfkill_set_hw_state' under 
'drivers/net/wireless' and you will see dozens of related calls.

We have tried wiphy_unregister() during internal review, which will 
generate a lot of call stacks(more than 20). wiphy_unregister() will 
call into ath10k to perform many operations, but at this point, the 
ath10k driver is no longer able to perform any behavior properly.



> 
>>   }
>>
>>   static void ath10k_core_recovery_check_work(struct work_struct *work)
>>
>> --
>> 2.34.1
>>