[PATCH] wifi: ath11k: pci: Fix msi_irq crash on driver unload with QCN9074 PCIe WiFi 6 modules

Balsam Chihi balsam.chihi at moment.tech
Thu Apr 24 05:08:39 PDT 2025


Yes I of course I can help, i'm trying to reproduce the bug, by
rebuilding a clean distro without the patch.
and i will enable the debug_mask=0x1020 at boot via u-boot to kernel arguments.
please let me know if is there anything else you would like to test.
just FYI, i'm using the official openwrt-v24.10.1 (with kernel 6.6.86
and mac80211 backported from kernel 6.12.6) on a Layerscape LS1088A.


On Thu, Apr 24, 2025 at 12:45 PM Baochen Qiang <quic_bqiang at quicinc.com> wrote:
>
>
>
> On 4/24/2025 6:36 PM, Vasanthakumar Thiagarajan wrote:
> >
> >
> > On 4/24/2025 3:19 PM, Baochen Qiang wrote:
> >>
> >>
> >> On 4/24/2025 5:25 PM, Balsam Chihi wrote:
> >>> Hello,
> >>>
> >>> @Baochen Qiang,
> >>> Thank you for your feedback.
> >>> I tested unloading and reloading the driver and it is enumerated,
> >>> detected and operating correctly.
> >>
> >> Different hardware platforms may have different behaviors ...
> >>
> >>> And I understand your concern about other chips, and certainly it is
> >>> not the best way to implement such a fix.
> >>> I will continue debugging to determine the root cause of the
> >>> synchronous external abort.
> >>> So this patch is now just a workaround to fix the kernel crash when
> >>> rmmod the driver and reboot the system,
> >>> that i wanted to share with you to attract your attention to the
> >>> problem, and seek for help.
> >>>
> >>> @Vasanthakumar Thiagarajan,
> >>> Thank you too for your feedback.
> >>> Yes, I understand.
> >>> I will enable the debug_mask and check the logs, like you said.
> >>>
> >>> I'm wondering if anyone else has the same problem with ath11k_pci.a
> >>
> >> There is another issue report with the soc_global_reset register, although it is reported
> >> on another hardware.
> >>
> >> Vasanth, could you check if the register address is correctly defined for QCN9074?
> >>
> >> #define PCIE_SOC_GLOBAL_RESET            0x3008
> >
> > That offset for global_reset is correct.
>
> Okay, then it should not be global_reset causing this.
>
> Balsam, could you help debug further to check which specific register access is causing
> this issue? We can then check if the register is defined correctly or not.
>


-- 


Balsam CHIHI

Embedded Systems Engineer

06 42 90 57 24
3 Boulevard Richard Lenoir - 75011 Paris
Maximize profits with our latest guide to ancillary revenue strategies 📊



More information about the ath11k mailing list