[PATCH ath-next] wifi: ath12k: change MAC buffer ring size to 4096

[Manivannan Sadhasivam]

+ Jeff

On Tue, Oct 20, 2026 at 04:53:03PM +0800, Shawn Guo wrote:
> + linux-arm-msm
> 
> On Tue, Jun 09, 2026 at 08:13:58PM -0700, Yingying Tang wrote:
> > For WCN7850, MAC buffer ring size is updated to 2048 in
> > 955df16f2a4c3 ("wifi: ath12k: change MAC buffer ring size to 2048")
> > to increase peak throughput.
> > 
> > But during the RX process, a phenomenon can still be observed where
> > the throughput drops by about 30% from its peak value and then recovers,
> > and this behavior repeats during RX.
> > 
> > After increasing MAC buffer ring size to 4096, the data rate drop has
> > gone.
> > 
> > Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> > 
> > Signed-off-by: Yingying Tang <yingying.tang at oss.qualcomm.com>
> 
> FYI, in case someone else runs into this: with this change (merged in
> v7.3), WiFi on my Lenovo Yoga Slim 7x (X1E80100, WCN7850 hw2.0) stopped
> working with the older firmware that Debian trixie still ships
> (firmware-atheros 20250410-2):
> 
>   WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
> 
> Probe and firmware download succeed, but every WMI command times out
> once the interface is brought up:
> 
>   ath12k_wifi7_pci 0004:01:00.0: wmi command 16387 timeout
>   ath12k_wifi7_pci 0004:01:00.0: failed to send WMI_PDEV_SET_PARAM cmd
>   ath12k_wifi7_pci 0004:01:00.0: failed to enable PMF QOS: -11
>   ath12k_wifi7_pci 0004:01:00.0: fail to start mac operations in pdev idx 0 ret -11
> 
> Bisecting ath12k between v7.2 and v7.3 lands on this commit, and
> reverting it on v7.3 brings WiFi back with the old firmware.
> 
> Unmodified v7.3 works fine after updating to the current linux-firmware
> image:
> 
>   WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
> 
> On Debian trixie that one is available from trixie-backports
> (firmware-atheros 20260916-1~bpo13+1).
> 
> So nothing needs fixing on the driver side. I'm just leaving this here
> so that anyone who sees "wmi command ... timeout" on WCN7850 after a
> kernel upgrade knows to update the firmware first.
> 

Thanks Shawn for reporting this regression!

Jeff, this is unacceptable in two grounds:

1. Driver change *must not* break userspace, in this case the old firmware. The
driver must maintain backwards compatibility even if the data rate drops with
the old firmware. This is the promise, kernel strives to keep up from the
start.

2. The offending patch didn't mention anything about the firmware
incompatibility, which is too bad. How does the users be notified of needing a
firmware update?

So I'd suggest reverting this commit and come up with a new change that
preserves the backwards compatibility with the old firmware while fixing the
throughput issue.

- Mani

-- 
மணிவண்ணன் சதாசிவம்