From: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
To: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>,
Nicolas Escande <nico.escande@gmail.com>,
ath12k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH ath-next v4] wifi: ath12k: avoid dynamic alloc when parsing wmi tb
Date: Tue, 24 Mar 2026 09:55:12 -0700 [thread overview]
Message-ID: <edf86c6a-fb09-4524-9b47-3061c3d6e68f@oss.qualcomm.com> (raw)
In-Reply-To: <ec266bec-c371-4ec8-a60f-21ebb810d38e@oss.qualcomm.com>
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.
next prev parent reply other threads:[~2026-03-24 16:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 8:47 [PATCH ath-next v4] wifi: ath12k: avoid dynamic alloc when parsing wmi tb Nicolas Escande
2026-03-17 8:57 ` Baochen Qiang
2026-03-19 11:08 ` Rameshkumar Sundaram
2026-03-19 14:35 ` Nicolas Escande
2026-03-19 15:59 ` Jeff Johnson
2026-03-23 12:40 ` Rameshkumar Sundaram
2026-03-24 16:55 ` Jeff Johnson [this message]
2026-03-26 8:37 ` Nicolas Escande
2026-03-26 16:29 ` Jeff Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edf86c6a-fb09-4524-9b47-3061c3d6e68f@oss.qualcomm.com \
--to=jeff.johnson@oss.qualcomm.com \
--cc=ath12k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nico.escande@gmail.com \
--cc=rameshkumar.sundaram@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox