Re: [PATCH ath-next v4] wifi: ath12k: avoid dynamic alloc when parsing wmi tb

["Nicolas Escande" <nico.escande@gmail.com>]

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 ?