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

[Kang Yang]

On 10/21/2026 9:54 PM, Loic Poulain wrote:
> On Wed, Oct 21, 2026 at 11:10 AM Kang Yang <kang.yang@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>
> > ---
> >   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