Re: [PATCH ath-next 1/3] wifi: ath12k: allocate the AFC memory region requested by firmware

[Goran Sustek]

On 11/2/2026 4:06 PM, Rameshkumar Sundaram wrote:
> In that case, shouldn't chunk->size be cleared when no memory is
> allocated, or should the response only contain the chunks that were
> actually allocated and assigned by host ? (see
> ath12k_qmi_assign_target_mem_chunk() which updates ab->qmi.mem_seg_count)
>
> Allocating AFC_REGION_TYPE while AFC itself is not supported by the host
> looks wrong to me.

Agreed, thanks. The comment above the switch already says that the host
does not allocate memory for regions it does not support, and v1 went
against that.

v2 will not allocate the region. It names the type, answers it with
address 0 and size 0, so the firmware no longer holds an AFC region at
bus address 0, and logs this at debug level instead of warning.

I prefer clearing the size over leaving the segment out, for three
reasons:

- The firmware already treats a region with size 0 as not provided, so
  the answer has a defined meaning. A response with fewer segments than
  requested is not something I could verify for the PCI firmware.
- It stays a local change in the existing switch case.
- Compacting target_mem[] in the PCI path would shift the indices that
  ath12k_qmi_alloc_chunk() uses to reuse memory after firmware recovery
  (prev_type/prev_size), and the free path walks mem_seg_count. That
  needs extra care to avoid stale or doubly freed entries.

Tested with WLAN.WBE.1.6-01243 on two QCN9274 boards: the firmware sends
the memory ready indication right after the response, reaches firmware
ready, and both radios come up and serve clients, with no firmware
crash. The AHB path already drops unknown types instead, so if you want
both paths to behave the same way, I can follow that in the PCI path.

v2 changes only type 10. The default branch for other unsupported types
stays as it is, because this firmware requests no other one.

Goran