From: "Mukunda,Vijendar" <vijendar.mukunda@amd.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: broonie@kernel.org, alsa-devel@alsa-project.org,
yung-chuan.liao@linux.intel.com, pierre-louis.bossart@linux.dev,
Basavaraj.Hiregoudar@amd.com, Sunil-kumar.Dommati@amd.com,
venkataprasad.potturu@amd.com, Syed.SabaKareem@amd.com,
Mario.Limonciello@amd.com, Richard.Gong@amd.com,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/9] soundwire: amd: allocate sdw_amd_ctx pdev array dynamically
Date: Mon, 5 Oct 2026 12:08:46 +0530 [thread overview]
Message-ID: <6e630839-4c20-4b77-9959-d4352314e3c6@amd.com> (raw)
In-Reply-To: <asC0VC--CaFMJ_ow@parshuram>
On 03/10/26 13:22, Vinod Koul wrote:
> On 17-09-26, 14:32, Vijendar Mukunda wrote:
>> Replace the fixed-size pdev[AMD_ACP63_SDW_MAX_MANAGER_COUNT] member of
>> struct sdw_amd_ctx with a dynamically allocated pointer array. The array
>> is sized by max_manager_count via kcalloc() in sdw_amd_probe_controller()
>> and freed on all error paths and in sdw_amd_cleanup().
>>
>> Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
>> ---
>> drivers/soundwire/amd_init.c | 12 ++++++++++++
>> include/linux/soundwire/sdw_amd.h | 2 +-
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/soundwire/amd_init.c b/drivers/soundwire/amd_init.c
>> index 15d117172bdb..94d766b3f8af 100644
>> --- a/drivers/soundwire/amd_init.c
>> +++ b/drivers/soundwire/amd_init.c
>> @@ -62,6 +62,7 @@ static int sdw_amd_cleanup(struct sdw_amd_ctx *ctx)
>> continue;
>> platform_device_unregister(ctx->pdev[i]);
>> }
>> + kfree(ctx->pdev);
>>
>> return 0;
>> }
>> @@ -116,8 +117,16 @@ static struct sdw_amd_ctx *sdw_amd_probe_controller(struct sdw_amd_res *res)
>>
>> ctx->count = count;
>> ctx->link_mask = res->link_mask;
>> +
>> + ctx->pdev = kcalloc(max_manager_count, sizeof(*ctx->pdev), GFP_KERNEL);
> why not use managed api for this?
The reason devm_kcalloc() cannot be used here is that
sdw_amd_cleanup() explicitly frees ctx->pdev using kfree().
If devm_kcalloc(res->parent, ...) were used, the allocation
would also be tracked by devres and freed automatically during
device unbind, resulting in a double-free.
Therefore, the existing manual alloc/free lifecycle is
intentional.
>> + if (!ctx->pdev) {
>> + kfree(ctx);
>> + return NULL;
>> + }
>> +
>> struct resource *sdw_res __free(kfree) = kzalloc_obj(*sdw_res);
>> if (!sdw_res) {
>> + kfree(ctx->pdev);
>> kfree(ctx);
>> return NULL;
>> }
>> @@ -127,6 +136,7 @@ static struct sdw_amd_ctx *sdw_amd_probe_controller(struct sdw_amd_res *res)
>>
>> sdw_pdata = kcalloc(max_manager_count, sizeof(*sdw_pdata), GFP_KERNEL);
>> if (!sdw_pdata) {
>> + kfree(ctx->pdev);
>> kfree(ctx);
>> return NULL;
>> }
>> @@ -134,6 +144,7 @@ static struct sdw_amd_ctx *sdw_amd_probe_controller(struct sdw_amd_res *res)
>> pdevinfo = kcalloc(max_manager_count, sizeof(*pdevinfo), GFP_KERNEL);
>> if (!pdevinfo) {
>> kfree(sdw_pdata);
>> + kfree(ctx->pdev);
>> kfree(ctx);
>> return NULL;
>> }
>> @@ -171,6 +182,7 @@ static struct sdw_amd_ctx *sdw_amd_probe_controller(struct sdw_amd_res *res)
>>
>> kfree(pdevinfo);
>> kfree(sdw_pdata);
>> + kfree(ctx->pdev);
>> kfree(ctx);
>> return NULL;
>> }
>> diff --git a/include/linux/soundwire/sdw_amd.h b/include/linux/soundwire/sdw_amd.h
>> index 40ba84c3b2cc..476de2c30389 100644
>> --- a/include/linux/soundwire/sdw_amd.h
>> +++ b/include/linux/soundwire/sdw_amd.h
>> @@ -139,7 +139,7 @@ struct sdw_amd_acpi_info {
>> struct sdw_amd_ctx {
>> int count;
>> u32 link_mask;
>> - struct platform_device *pdev[AMD_ACP63_SDW_MAX_MANAGER_COUNT];
>> + struct platform_device **pdev;
>> struct sdw_peripherals *peripherals;
>> };
>>
>> --
>> 2.48.1
next prev parent reply other threads:[~2026-10-05 6:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 9:02 [PATCH 0/9] soundwire: amd: introduce hw_ops dispatch and consolidate probe setup Vijendar Mukunda
2026-09-17 9:02 ` [PATCH 1/9] soundwire: amd: rename AMD_SDW_MAX_MANAGER_COUNT macro Vijendar Mukunda
2026-09-17 9:02 ` [PATCH 2/9] soundwire: amd: allocate pdevinfo and sdw_pdata by ACP revision in probe Vijendar Mukunda
2026-09-17 9:02 ` [PATCH 3/9] soundwire: amd: allocate sdw_amd_ctx pdev array dynamically Vijendar Mukunda
2026-10-03 7:52 ` Vinod Koul
2026-10-05 6:38 ` Mukunda,Vijendar [this message]
2026-09-17 9:02 ` [PATCH 4/9] soundwire: amd: rename hardware backend functions to amd_acp63_*() prefix Vijendar Mukunda
2026-09-17 9:02 ` [PATCH 5/9] soundwire: amd: remove unused AMD_SDW_MAX_FREQ_NUM define Vijendar Mukunda
2026-09-17 9:02 ` [PATCH 6/9] soundwire: amd: introduce struct amd_sdw_hw_ops dispatch framework Vijendar Mukunda
2026-10-03 7:56 ` Vinod Koul
2026-10-05 6:43 ` Mukunda,Vijendar
2026-09-17 9:02 ` [PATCH 7/9] soundwire: amd: convert irq/work handlers to hw_ops callbacks Vijendar Mukunda
2026-09-17 9:02 ` [PATCH 8/9] soundwire: amd: wire amd_acp63_*() call sites through acp_*() helpers Vijendar Mukunda
2026-09-17 9:02 ` [PATCH 9/9] soundwire: amd: consolidate revision-specific probe setup Vijendar Mukunda
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=6e630839-4c20-4b77-9959-d4352314e3c6@amd.com \
--to=vijendar.mukunda@amd.com \
--cc=Basavaraj.Hiregoudar@amd.com \
--cc=Mario.Limonciello@amd.com \
--cc=Richard.Gong@amd.com \
--cc=Sunil-kumar.Dommati@amd.com \
--cc=Syed.SabaKareem@amd.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=pierre-louis.bossart@linux.dev \
--cc=venkataprasad.potturu@amd.com \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.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
all inboxes | Powered by JetHome®