public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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