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

[Jeff Johnson]

On 3/26/2026 1:37 AM, Nicolas Escande wrote:
> 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 ?

i prefer a separate lock for this use case.

leveraging one thing for a completely different use case leads to confusion.

/jeff