[PATCH ath-next v4] wifi: ath12k: avoid dynamic alloc when parsing wmi tb
Nicolas Escande
nico.escande at gmail.com
Thu Mar 26 01:37:23 PDT 2026
On Tue Mar 24, 2026 at 5:55 PM CET, Jeff Johnson wrote:
> On 3/23/2026 5:40 AM, Rameshkumar Sundaram wrote:
>> On 3/19/2026 9:29 PM, Jeff Johnson wrote:
>>> On 3/19/2026 7:35 AM, Nicolas Escande wrote:
>>>> On Thu Mar 19, 2026 at 12:08 PM CET, Rameshkumar Sundaram wrote:
>>>>> Or may be have this allocated on first device probe and free it on last
>>>>> device deinit ?
>>>>
>>>> That seems even more involved. It would be easier to go back to the previous
>>>> version and simply, alloc it once per ath12k_base
>>>>
>>>> What do you guys think ?
>>>>
>>>
>>> Going back to that may be the better solution. It isn't nice that this current
>>> solution may allocate memory when the driver isn't actually used. But I'll let
>>> others on the team weigh in as well.
>>>
>>
>> Yeah, allocating once per ath12k_base is definitely the simpler
>> ownership model.
>> I was only wondering whether sharing it across devices might be worth a
>> look, since this is per-CPU scratch space and the table itself is fairly
>> large.
>
> The other alternative is to still have a single global allocation, but also
> keep a reference count that starts at 0. when each ar starts it calls a single
> api to alloc the memory and when it stops it calls another api to dealloc the
> memory
>
> when the first ar starts and calls the alloc api, the refcount will be 0 so it
> will allocate the memory and increment the refcount to 1. when any subsequent
> ars start and call the alloc api, it will just increment the ref count. on
> deinit each ar will call the dealloc api. this api will just decrement the
> refcount until it reaches 0 at which time the memory is freed.
We can do that, but we'll need a lock to protect this shared ressource:
- The clean way would mean adding yet another lock to protect this, but it
feels like there are already enough locks in ath12k.
- The other way would be to piggy back another existing one.
ath12k_hw_group_mutex would be a good candidate to be honest
What do you prefer ?
More information about the ath12k
mailing list