[PATCH 0/5] ASoC: intel: use component_name for Component name

[PATCH 0/5] ASoC: intel: use component_name for Component name

[Kuninori Morimoto]

Hi Mark, Intel developer

Current component has component->name, but we can't setup it via
component_driver today, so the user need to use
snd_soc_component_initialize() / snd_soc_add_component() directly
instead of using snd_soc_register_component().

This patch-set try to solve root cause of this issue

Kuninori Morimoto (5):
  ASoC: soc-component: add driver_name
  ASoC: soc-component: add component_name
  ASoC: intel: avs: pcm: use component_name for Component name
  ASoC: intel: avs: probes: use component_name for Component name
  ASoC: intel: catpt: pcm: use component_name for Component name

 include/sound/soc-component.h |  6 +++++-
 sound/soc/intel/avs/pcm.c     |  4 ++--
 sound/soc/intel/avs/probes.c  | 27 ++++++++++-----------------
 sound/soc/intel/catpt/pcm.c   | 20 ++++----------------
 sound/soc/soc-core.c          | 11 ++++++-----
 5 files changed, 27 insertions(+), 41 deletions(-)

-- 
2.53.0

[PATCH 1/5] ASoC: soc-component: add driver_name

[Kuninori Morimoto]

Current component has component->name, but we can't setup it via
component_driver today, so the user need to use
snd_soc_component_initialize() / snd_soc_add_component() directly
instead of using snd_soc_register_component().

We can solve root cause of this irregular to add support it in driver.

But, in the same time, current component driver already has .name which
is used as driver_name.
Add .driver_name and use it instead. Existing .name will remain for the
time being, but will be removed if all drivers switched to use new
.driver_name.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 include/sound/soc-component.h |  5 ++++-
 sound/soc/soc-core.c          | 10 +++++-----
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/include/sound/soc-component.h b/include/sound/soc-component.h
index aa423865dbe7c..b2a362f3effa4 100644
--- a/include/sound/soc-component.h
+++ b/include/sound/soc-component.h
@@ -67,7 +67,10 @@ struct snd_compress_ops {
 };
 
 struct snd_soc_component_driver {
-	const char *name;
+	union {
+		const char *name;		/* REMOVE ME */
+		const char *driver_name;
+	};
 
 	/* Default control and setup, added after probe() is run */
 	const struct snd_kcontrol_new *controls;
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 7817beea5b3bc..e5860a2cc90d3 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -344,7 +344,7 @@ struct snd_soc_component *snd_soc_rtdcom_lookup(struct snd_soc_pcm_runtime *rtd,
 	 * to 1 rtd, this function will return 1st found component.
 	 */
 	for_each_rtd_components(rtd, i, component) {
-		const char *component_name = component->driver->name;
+		const char *component_name = component->driver->driver_name;
 
 		if (!component_name)
 			continue;
@@ -370,13 +370,13 @@ struct snd_soc_component
 		if (!driver_name)
 			return component;
 
-		if (!component->driver->name)
+		if (!component->driver->driver_name)
 			continue;
 
-		if (component->driver->name == driver_name)
+		if (component->driver->driver_name == driver_name)
 			return component;
 
-		if (strcmp(component->driver->name, driver_name) == 0)
+		if (strcmp(component->driver->driver_name, driver_name) == 0)
 			return component;
 	}
 
@@ -2808,7 +2808,7 @@ void snd_soc_unregister_component_by_driver(struct device *dev,
 	const char *driver_name = NULL;
 
 	if (component_driver)
-		driver_name = component_driver->name;
+		driver_name = component_driver->driver_name;
 
 	guard(mutex)(&client_mutex);
 
-- 
2.53.0

[PATCH 2/5] ASoC: soc-component: add component_name

[Kuninori Morimoto]

Current component has component->name, but we can't setup it via
component_driver today, so the user need to use
snd_soc_component_initialize() / snd_soc_add_component() directly
instead of using snd_soc_register_component().

We can solve root cause of this irregular to add support it in driver.

Adds component_name in Component driver.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 include/sound/soc-component.h | 1 +
 sound/soc/soc-core.c          | 1 +
 2 files changed, 2 insertions(+)

diff --git a/include/sound/soc-component.h b/include/sound/soc-component.h
index b2a362f3effa4..4ec6c8c52ff92 100644
--- a/include/sound/soc-component.h
+++ b/include/sound/soc-component.h
@@ -71,6 +71,7 @@ struct snd_soc_component_driver {
 		const char *name;		/* REMOVE ME */
 		const char *driver_name;
 	};
+	const char *component_name;
 
 	/* Default control and setup, added after probe() is run */
 	const struct snd_kcontrol_new *controls;
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index e5860a2cc90d3..24ba5b1817293 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2717,6 +2717,7 @@ int snd_soc_component_initialize(struct snd_soc_component *component,
 	INIT_LIST_HEAD(&component->card_aux_list);
 	mutex_init(&component->io_mutex);
 
+	component->name = driver->component_name;
 	if (!component->name) {
 		component->name = fmt_single_name(dev, NULL);
 		if (!component->name) {
-- 
2.53.0

[PATCH 3/5] ASoC: intel: avs: pcm: use component_name for Component name

[Kuninori Morimoto]

We can set component->name via component_driver->component_name.
Use it

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 sound/soc/intel/avs/pcm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/intel/avs/pcm.c b/sound/soc/intel/avs/pcm.c
index 797b9c9163b49..1a0b7cd26d9f1 100644
--- a/sound/soc/intel/avs/pcm.c
+++ b/sound/soc/intel/avs/pcm.c
@@ -1393,8 +1393,8 @@ int avs_register_component(struct device *dev, const char *name,
 	if (!acomp)
 		return -ENOMEM;
 
-	acomp->base.name = devm_kstrdup(dev, name, GFP_KERNEL);
-	if (!acomp->base.name)
+	drv->component_name = devm_kstrdup(dev, name, GFP_KERNEL);
+	if (!drv->component_name)
 		return -ENOMEM;
 
 	INIT_LIST_HEAD(&acomp->node);
-- 
2.53.0

[PATCH 4/5] ASoC: intel: avs: probes: use component_name for Component name

[Kuninori Morimoto]

We can set component->name via component_driver->component_name.
Use it

Now it no longer need to use snd_soc_component_initialize() /
snd_soc_component_add(). Use snd_soc_component_register() instead.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 sound/soc/intel/avs/probes.c | 27 ++++++++++-----------------
 1 file changed, 10 insertions(+), 17 deletions(-)

diff --git a/sound/soc/intel/avs/probes.c b/sound/soc/intel/avs/probes.c
index 099119ad28b3c..322e4d79e0ac9 100644
--- a/sound/soc/intel/avs/probes.c
+++ b/sound/soc/intel/avs/probes.c
@@ -287,28 +287,21 @@ static struct snd_soc_dai_driver probe_cpu_dais[] = {
 },
 };
 
-static const struct snd_soc_component_driver avs_probe_component_driver = {
-	.name			= "avs-probe-compr",
-	.compress_ops		= &avs_probe_compress_ops,
-	.module_get_upon_open	= 1, /* increment refcount when a stream is opened */
-};
-
 int avs_register_probe_component(struct avs_dev *adev, const char *name)
 {
-	struct snd_soc_component *component;
-	int ret;
+	struct snd_soc_component_driver *component_driver;
 
-	component = devm_kzalloc(adev->dev, sizeof(*component), GFP_KERNEL);
-	if (!component)
+	component_driver = devm_kzalloc(adev->dev, sizeof(*component_driver), GFP_KERNEL);
+	if (!component_driver)
 		return -ENOMEM;
 
-	component->name = devm_kstrdup(adev->dev, name, GFP_KERNEL);
-	if (!component->name)
+	component_driver->compress_ops		= &avs_probe_compress_ops;
+	component_driver->module_get_upon_open	= 1; /* increment refcount when a stream is opened */
+	component_driver->driver_name		= "avs-probe-compr";
+	component_driver->component_name	= devm_kstrdup(adev->dev, name, GFP_KERNEL);
+	if (!component_driver->component_name)
 		return -ENOMEM;
 
-	ret = snd_soc_component_initialize(component, &avs_probe_component_driver, adev->dev);
-	if (ret)
-		return ret;
-
-	return snd_soc_add_component(component, probe_cpu_dais, ARRAY_SIZE(probe_cpu_dais));
+	return snd_soc_register_component(adev->dev, component_driver,
+					  probe_cpu_dais, ARRAY_SIZE(probe_cpu_dais));
 }
-- 
2.53.0

[PATCH 5/5] ASoC: intel: catpt: pcm: use component_name for Component name

[Kuninori Morimoto]

We can set component->name via component_driver->component_name.
Use it

Now it no longer need to use snd_soc_component_initialize() /
snd_soc_component_add(). Use snd_soc_component_register() instead.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 sound/soc/intel/catpt/pcm.c | 20 ++++----------------
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/sound/soc/intel/catpt/pcm.c b/sound/soc/intel/catpt/pcm.c
index 8fb0efb67eb1d..dba7ad00f8649 100644
--- a/sound/soc/intel/catpt/pcm.c
+++ b/sound/soc/intel/catpt/pcm.c
@@ -1017,7 +1017,8 @@ static const struct snd_soc_dapm_route component_routes[] = {
 };
 
 static const struct snd_soc_component_driver catpt_comp_driver = {
-	.name = "catpt-platform",
+	.driver_name = "catpt-platform",
+	.component_name = "catpt-platform",
 
 	.pcm_new = catpt_component_pcm_new,
 	.open = catpt_component_open,
@@ -1072,19 +1073,6 @@ int catpt_arm_stream_templates(struct catpt_dev *cdev)
 
 int catpt_register_plat_component(struct catpt_dev *cdev)
 {
-	struct snd_soc_component *component;
-	int ret;
-
-	component = devm_kzalloc(cdev->dev, sizeof(*component), GFP_KERNEL);
-	if (!component)
-		return -ENOMEM;
-
-	ret = snd_soc_component_initialize(component, &catpt_comp_driver,
-					   cdev->dev);
-	if (ret)
-		return ret;
-
-	component->name = catpt_comp_driver.name;
-	return snd_soc_add_component(component, dai_drivers,
-				     ARRAY_SIZE(dai_drivers));
+	return snd_soc_register_component(cdev->dev, &catpt_comp_driver,
+					  dai_drivers, ARRAY_SIZE(dai_drivers));
 }
-- 
2.53.0

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Cezary Rojewski]

On 6/26/2026 8:09 AM, Kuninori Morimoto wrote:
> Hi Mark, Intel developer
> 
> Current component has component->name, but we can't setup it via
> component_driver today, so the user need to use
> snd_soc_component_initialize() / snd_soc_add_component() directly
> instead of using snd_soc_register_component().
> 
> This patch-set try to solve root cause of this issue

Hi Kuninori,

Does this mean you have a patchset or two that follow this one up? 
Looking at this one alone, I'm not seeing why both ->driver_name and 
->component_name are added.

The driver is supposed to define _behavior_ of the entity it _drives_. 
Component's name is (typically) a static part of its description, not 
its runtime behavior.  To keep the design nice and clean shouldn't we 
leave driver->name and component->name alone?


Kind regards,
Czarek


> Kuninori Morimoto (5):
>    ASoC: soc-component: add driver_name
>    ASoC: soc-component: add component_name
>    ASoC: intel: avs: pcm: use component_name for Component name
>    ASoC: intel: avs: probes: use component_name for Component name
>    ASoC: intel: catpt: pcm: use component_name for Component name
> 
>   include/sound/soc-component.h |  6 +++++-
>   sound/soc/intel/avs/pcm.c     |  4 ++--
>   sound/soc/intel/avs/probes.c  | 27 ++++++++++-----------------
>   sound/soc/intel/catpt/pcm.c   | 20 ++++----------------
>   sound/soc/soc-core.c          | 11 ++++++-----
>   5 files changed, 27 insertions(+), 41 deletions(-)
> 

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Kuninori Morimoto]

Hi Cezary

Thank you for review, and sorry for un-clear explanation.

> Does this mean you have a patchset or two that follow this one up? 
> Looking at this one alone, I'm not seeing why both ->driver_name and 
> ->component_name are added.
> 
> The driver is supposed to define _behavior_ of the entity it _drives_. 
> Component's name is (typically) a static part of its description, not 
> its runtime behavior.  To keep the design nice and clean shouldn't we 
> leave driver->name and component->name alone?

It is difficult to clearly define what does "driver" means.
But basically, I would like to capsuling DAI/Component/Card into each
soc-dai/component/card.c. Because current ASoC is not capsuled,
each driver can directly access to each members randomly.

Here, We need to separate the member which set via each driver and
set via ASoC framework.
The behavior and its name are set via driver, the others, like lock / link,
and other necessary members which is needef for controlling ASoC are set
via ASoC framework.

About component->name, in current implementation, it is set in
snd_soc_component_initialize() (X) if default component->name was not set (A).
But, if we capsuled the Component, people can't access to
component->xxx because it will be capsuled.

(X)	int snd_soc_component_initialize(...)
	{
		...
(A)		if (!component->name) {
			component->name = fmt_single_name(...);
			...
		}
		...
	}

And more, many drivers are basically using snd_soc_register_component()
to register component. The component is alloced in this function (B).
So, there is zero chance to set default component name for this
function user. So this patch-set try to set it via driver.

	int snd_soc_register_component(...)
	{
		...
(B)		component = devm_kzalloc(...);
		if (!component)
			return -ENOMEM;

(X)		ret = snd_soc_component_initialize(...);
		...
	}

I hope this explanation makes it clear for you.


Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH 2/5] ASoC: soc-component: add component_name

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On Fri, Jun 26, 2026 at 06:09:56AM +0000, Kuninori Morimoto wrote:
> Current component has component->name, but we can't setup it via
> component_driver today, so the user need to use
> snd_soc_component_initialize() / snd_soc_add_component() directly
> instead of using snd_soc_register_component().

> @@ -2717,6 +2717,7 @@ int snd_soc_component_initialize(struct snd_soc_component *component,
>  	INIT_LIST_HEAD(&component->card_aux_list);
>  	mutex_init(&component->io_mutex);
>  
> +	component->name = driver->component_name;

Should we handle the case where there's a name somehow already, this is
user visible.  Preserve the existing value and/or warn.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Cezary Rojewski]

On 6/29/2026 1:35 AM, Kuninori Morimoto wrote:

>> Does this mean you have a patchset or two that follow this one up?
>> Looking at this one alone, I'm not seeing why both ->driver_name and
>> ->component_name are added.
>>
>> The driver is supposed to define _behavior_ of the entity it _drives_.
>> Component's name is (typically) a static part of its description, not
>> its runtime behavior.  To keep the design nice and clean shouldn't we
>> leave driver->name and component->name alone?
> 
> It is difficult to clearly define what does "driver" means.
> But basically, I would like to capsuling DAI/Component/Card into each
> soc-dai/component/card.c. Because current ASoC is not capsuled,
> each driver can directly access to each members randomly.

What do you mean by "access each members randomly" ?

> Here, We need to separate the member which set via each driver and
> set via ASoC framework.
> The behavior and its name are set via driver, the others, like lock / link,
> and other necessary members which is needef for controlling ASoC are set
> via ASoC framework.
> 
> About component->name, in current implementation, it is set in
> snd_soc_component_initialize() (X) if default component->name was not set (A).
> But, if we capsuled the Component, people can't access to
> component->xxx because it will be capsuled.
> 
> (X)	int snd_soc_component_initialize(...)
> 	{
> 		...
> (A)		if (!component->name) {
> 			component->name = fmt_single_name(...);
> 			...
> 		}
> 		...
> 	}
> 
> And more, many drivers are basically using snd_soc_register_component()
> to register component. The component is alloced in this function (B).
> So, there is zero chance to set default component name for this
> function user. So this patch-set try to set it via driver.
> 
> 	int snd_soc_register_component(...)
> 	{
> 		...
> (B)		component = devm_kzalloc(...);
> 		if (!component)
> 			return -ENOMEM;
> 
> (X)		ret = snd_soc_component_initialize(...);
> 		...
> 	}
I hope you do not mean to privatize/drop the 
snd_soc_component_initialize() and snd_soc_component_add().  These give 
us a) flexibility and b) dd-alike API (the device-driver API).

It's easier to move between subsystems if their API patterns are 
similar.  At the same time, it's hard to predict "what comes next".  By 
splitting the registration into two steps (with all 3 functions being 
public symbols) the framework is more robust.

Moving on, does this mean we are getting dev_name()/dev_set_name() for 
the component?

	snd_soc_component_name(comp)
	snd_soc_component_set_name(comp, str)

Though the "snd_soc_" prefix we have everywhere in sound/soc/ scales 
poorly with 3+ arguments in the list.  But that's a tale for another 
patchset..


Kind regards,
Czarek

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Kuninori Morimoto]

Hi Cezary

Thank you for your feedback

> > But basically, I would like to capsuling DAI/Component/Card into each
> > soc-dai/component/card.c. Because current ASoC is not capsuled,
> > each driver can directly access to each members randomly.
> 
> What do you mean by "access each members randomly" ?

We can access each members without restriction, like below.
Because of this, there was a driver which is using the member a
way other than intended.

	component->aaa = aaa;
	component->bbb = bbb;
	component->ccc = ccc;


> > 	int snd_soc_register_component(...)
> > 	{
> > 		...
> > (B)		component = devm_kzalloc(...);
> > 		if (!component)
> > 			return -ENOMEM;
> > 
> > (X)		ret = snd_soc_component_initialize(...);
> > 		...
> > 	}
> I hope you do not mean to privatize/drop the 
> snd_soc_component_initialize() and snd_soc_component_add().  These give 
> us a) flexibility and b) dd-alike API (the device-driver API).

Yes, my plan is makes them local function.

We have snd_soc_register_{dai/component/card}(), but only component
has such style. The biggest reason is regsiter_component() allocs
component inside, but initialize() assues component already had some
member (->name, ->debugfs_prefix).

So, if user want to set own driver name, he need to
	- alloc component
	- call initialize()
	- call add()
This flexibility is simply needed to set the name.
But, I don't think it is strange that the *component_driver gives its
name.

And more, if component capsuling has done, you can't directly alloc
component.

> Moving on, does this mean we are getting dev_name()/dev_set_name() for 
> the component?
> 
> 	snd_soc_component_name(comp)
> 	snd_soc_component_set_name(comp, str)

?
You can set name via component_driver->name;

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH 2/5] ASoC: soc-component: add component_name

[Kuninori Morimoto]

Hi Mark

> > Current component has component->name, but we can't setup it via
> > component_driver today, so the user need to use
> > snd_soc_component_initialize() / snd_soc_add_component() directly
> > instead of using snd_soc_register_component().
> 
> > @@ -2717,6 +2717,7 @@ int snd_soc_component_initialize(struct snd_soc_component *component,
> >  	INIT_LIST_HEAD(&component->card_aux_list);
> >  	mutex_init(&component->io_mutex);
> >  
> > +	component->name = driver->component_name;
> 
> Should we handle the case where there's a name somehow already, this is
> user visible.  Preserve the existing value and/or warn.

Yes, indeed.
Thank you for your review.
Will fix in v2

Best regards
---
Kuninori Morimoto

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Cezary Rojewski]

On 7/1/2026 12:49 AM, Kuninori Morimoto wrote:

>>> But basically, I would like to capsuling DAI/Component/Card into each
>>> soc-dai/component/card.c. Because current ASoC is not capsuled,
>>> each driver can directly access to each members randomly.
>>
>> What do you mean by "access each members randomly" ?
> 
> We can access each members without restriction, like below.
> Because of this, there was a driver which is using the member a
> way other than intended.
> 
> 	component->aaa = aaa;
> 	component->bbb = bbb;
> 	component->ccc = ccc;

I see your point but that's very close to over-defensive programming. 
If a developer wants to break their driver/configuration, we can't stop 
them anyway, no matter how tight the API is.

Why over-defend?

>>> 	int snd_soc_register_component(...)
>>> 	{
>>> 		...
>>> (B)		component = devm_kzalloc(...);
>>> 		if (!component)
>>> 			return -ENOMEM;
>>>
>>> (X)		ret = snd_soc_component_initialize(...);
>>> 		...
>>> 	}
>> I hope you do not mean to privatize/drop the
>> snd_soc_component_initialize() and snd_soc_component_add().  These give
>> us a) flexibility and b) dd-alike API (the device-driver API).
> 
> Yes, my plan is makes them local function.
> 
> We have snd_soc_register_{dai/component/card}(), but only component
> has such style. The biggest reason is regsiter_component() allocs
> component inside, but initialize() assues component already had some
> member (->name, ->debugfs_prefix).
> 
> So, if user want to set own driver name, he need to
> 	- alloc component
> 	- call initialize()
> 	- call add()
> This flexibility is simply needed to set the name.
> But, I don't think it is strange that the *component_driver gives its
> name.
> 
> And more, if component capsuling has done, you can't directly alloc
> component.

Meaning with this you break a) flexibility b) alignment with dd API.

The flexibility is needed only for the name, _currently_.
It's not _only_ the soc-component which has such style, device-driver 
does too.


>> Moving on, does this mean we are getting dev_name()/dev_set_name() for
>> the component?
>>
>> 	snd_soc_component_name(comp)
>> 	snd_soc_component_set_name(comp, str)
> 
> ?
> You can set name via component_driver->name;
Asking about the getter part too.  How, after privatizing component 
_and_ component->name, one accesses the component's name?  Let's say 
from snd_soc_dai_hw_params() context.

Re: [PATCH 3/5] ASoC: intel: avs: pcm: use component_name for Component name

[Cezary Rojewski]

On 6/26/2026 8:10 AM, Kuninori Morimoto wrote:
> We can set component->name via component_driver->component_name.
> Use it
> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>   sound/soc/intel/avs/pcm.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/intel/avs/pcm.c b/sound/soc/intel/avs/pcm.c
> index 797b9c9163b49..1a0b7cd26d9f1 100644
> --- a/sound/soc/intel/avs/pcm.c
> +++ b/sound/soc/intel/avs/pcm.c
> @@ -1393,8 +1393,8 @@ int avs_register_component(struct device *dev, const char *name,
>   	if (!acomp)
>   		return -ENOMEM;
>   
> -	acomp->base.name = devm_kstrdup(dev, name, GFP_KERNEL);
> -	if (!acomp->base.name)
> +	drv->component_name = devm_kstrdup(dev, name, GFP_KERNEL);
> +	if (!drv->component_name)

Unfortunately, things are not that easy.  You're modifying member of a 
staticly-declared component driver.
That's a no.

After taking look at it again, I'm even further away from agreeing to 
the idea:

- components should be populated dynamically as their description may or 
may not differ between instances
- component-drivers can be left static as they describe behavior and the 
behavior operates on (component) pointers

With the proposed changes, instead of assigning memory for the driver 
once (for avs, once per interface type), we are going to do that each 
and every time new component pops up?  1:1 relation between components 
and component-drivers heralds bad design.  Plus a waste of memory.

>   		return -ENOMEM;
>   
>   	INIT_LIST_HEAD(&acomp->node);

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Kuninori Morimoto]

Hi Cezary

Thank you for your review

> > 	component->aaa = aaa;
> > 	component->bbb = bbb;
> > 	component->ccc = ccc;
> 
> I see your point but that's very close to over-defensive programming. 
> If a developer wants to break their driver/configuration, we can't stop 
> them anyway, no matter how tight the API is.
> 
> Why over-defend?

The goal is not to increase inconvenience, but to prevent unintended
actions. I think it is called as "capsuling", not "over-defend"

> Meaning with this you break a) flexibility b) alignment with dd API.
> 
> The flexibility is needed only for the name, _currently_.
> It's not _only_ the soc-component which has such style, device-driver 
> does too.

I can agree that flexibility is important.
But current flexibility is used only for adding component->name,
and it makes difficult to read code. I don't think this is "flexibility".

This patch trying is not removing flexibility, but removing waste.
There are no drivers lose flexibility by this patch, for now I think.

I don't 100% understand what you are worry about.
Could you please tell me more specifically, what kind of "flexibility"
is lost by this patch ? And what it makes impossible to ever get back ?

> >> 	snd_soc_component_name(comp)
> >> 	snd_soc_component_set_name(comp, str)
> > 
> > ?
> > You can set name via component_driver->name;
> Asking about the getter part too.  How, after privatizing component 
> _and_ component->name, one accesses the component's name?  Let's say 
> from snd_soc_dai_hw_params() context.

To get name,
before capsuling, you can use component->name directly,
after  capsuling, you can use snd_soc_component_name() I will add later.

To add name, you can use component_driver->name when probe().


Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH 3/5] ASoC: intel: avs: pcm: use component_name for Component name

[Kuninori Morimoto]

Hi Cezary

> Unfortunately, things are not that easy.  You're modifying member of a 
> staticly-declared component driver.
> That's a no.
> 
> After taking look at it again, I'm even further away from agreeing to 
> the idea:
> 
> - components should be populated dynamically as their description may or 
> may not differ between instances
> - component-drivers can be left static as they describe behavior and the 
> behavior operates on (component) pointers
> 
> With the proposed changes, instead of assigning memory for the driver 
> once (for avs, once per interface type), we are going to do that each 
> and every time new component pops up?  1:1 relation between components 
> and component-drivers heralds bad design.  Plus a waste of memory.

Yes, actually it is one of my concern.
So, maybe remove name from driver, but add it as parameter on register() ?
like this

	ret = snd_soc_register_component(..., driver, ..., "myname");

The driver which needs own component name is not so many, it is easy to
adjust to it.

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Kuninori Morimoto]

Hi Cezary, again

> I can agree that flexibility is important.
> But current flexibility is used only for adding component->name,
> and it makes difficult to read code. I don't think this is "flexibility".
> 
> This patch trying is not removing flexibility, but removing waste.
> There are no drivers lose flexibility by this patch, for now I think.
> 
> I don't 100% understand what you are worry about.
> Could you please tell me more specifically, what kind of "flexibility"
> is lost by this patch ? And what it makes impossible to ever get back ?

I reconsidered about your opinion (= flexibility), and is your concern that
we might have new component->xxx in the future which is Component specific
(= not Component driver specific) ?

If so, can you agree to add many _set() function, like below ?

	component = snd_soc_component_alloc(...);

	snd_soc_component_set_aaa(component, xxx);
	snd_soc_component_set_bbb(component, xxx);
	snd_soc_component_set_ccc(component, xxx);

	snd_soc_component_initialize(component, ...);	(A)
	snd_soc_component_add(component, ...);		(B)

Here I think we can merge (A) and (B) into one ?
I would like to have like this

	component = snd_soc_component_alloc(...);

	snd_soc_component_set_aaa(component, xxx);
	snd_soc_component_set_bbb(component, xxx);
	snd_soc_component_set_ccc(component, xxx);

	snd_soc_register_component(component, ...); // = (A) + (B)

And more, I want to use _Generic() for register()

	snd_soc_register_component(dev, ...);		// exist
	snd_soc_register_component(component, ...);	// new

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Cezary Rojewski]

On 7/2/2026 7:41 AM, Kuninori Morimoto wrote:
> 
> Hi Cezary, again
> 
>> I can agree that flexibility is important.
>> But current flexibility is used only for adding component->name,
>> and it makes difficult to read code. I don't think this is "flexibility".
>>
>> This patch trying is not removing flexibility, but removing waste.
>> There are no drivers lose flexibility by this patch, for now I think.
>>
>> I don't 100% understand what you are worry about.
>> Could you please tell me more specifically, what kind of "flexibility"
>> is lost by this patch ? And what it makes impossible to ever get back ?
> 
> I reconsidered about your opinion (= flexibility), and is your concern that
> we might have new component->xxx in the future which is Component specific
> (= not Component driver specific) ?

Precisely!

> If so, can you agree to add many _set() function, like below ?
> 
> 	component = snd_soc_component_alloc(...);
> 
> 	snd_soc_component_set_aaa(component, xxx);
> 	snd_soc_component_set_bbb(component, xxx);
> 	snd_soc_component_set_ccc(component, xxx);
> 
> 	snd_soc_component_initialize(component, ...);	(A)
> 	snd_soc_component_add(component, ...);		(B)
> 
> Here I think we can merge (A) and (B) into one ?
> I would like to have like this
> 
> 	component = snd_soc_component_alloc(...);
> 
> 	snd_soc_component_set_aaa(component, xxx);
> 	snd_soc_component_set_bbb(component, xxx);
> 	snd_soc_component_set_ccc(component, xxx);
> 
> 	snd_soc_register_component(component, ...); // = (A) + (B)
> 
> And more, I want to use _Generic() for register()
> 
> 	snd_soc_register_component(dev, ...);		// exist
> 	snd_soc_register_component(component, ...);	// new
Yes, that's why I've explicitly provided an example for component->name 
earlier:

	snd_soc_component_name()
	snd_soc_component_set_name()

Without getters/setters, soon I won't be the only one complaining about 
the lack of flexibility.  Anyhow, I'm going to continue in the follow up 
thread you've posted.

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Kuninori Morimoto]

Hi Cezary

Thank you for your feedback

> > I reconsidered about your opinion (= flexibility), and is your concern that
> > we might have new component->xxx in the future which is Component specific
> > (= not Component driver specific) ?
> 
> Precisely!

OK, Now I could understand your opinion !
And yes I 100% agree.

> Yes, that's why I've explicitly provided an example for component->name 
> earlier:
> 
> 	snd_soc_component_name()
> 	snd_soc_component_set_name()

OK.
But 1 concern here is that if we use "set", we want to have "get".
But I prefer to use snd_soc_component_name() (= not get).

This is just a naming balance. I want to use...

	snd_soc_component_name()
	snd_soc_component_attach_name()

>	snd_soc_component_initialize(component, ...);	(A)
>	snd_soc_component_add(component, ...);		(B)
(snip)
>	snd_soc_register_component(component, ...); // = (A) + (B)

Actually, my 1st motivation to do create this patch-set was this
unbalance. basically people use

	snd_soc_register_component();
	snd_soc_unregister_component();

It is easy to understand.
But, the code which want to set component->name, it is

	snd_soc_component_initialize(component, ...);	(A)
	snd_soc_component_add(component, ...);		(B)
	snd_soc_unregister_component();

It is a really minor thing, but this kind of unbalance really
bothers me... I'm happy if we can have register func = (A) + (B).

> Without getters/setters, soon I won't be the only one complaining about 
> the lack of flexibility.  Anyhow, I'm going to continue in the follow up 
> thread you've posted.

Thank you for your help/review !!

Best regards
---
Kuninori Morimoto

Re: [PATCH 0/5] ASoC: intel: use component_name for Component name

[Cezary Rojewski]

On 7/3/2026 1:54 AM, Kuninori Morimoto wrote:

>> Yes, that's why I've explicitly provided an example for component->name
>> earlier:
>>
>> 	snd_soc_component_name()
>> 	snd_soc_component_set_name()
> 
> OK.
> But 1 concern here is that if we use "set", we want to have "get".
> But I prefer to use snd_soc_component_name() (= not get).
> 
> This is just a naming balance. I want to use...
> 
> 	snd_soc_component_name()
> 	snd_soc_component_attach_name()
> 
Why? There 'get' is typically matched with 'put' in the Linux kernel 
whereas 'set' is often paired with '' (nothing) when talking about 
getter/setter context. One of the most widely used examples: dev_name(), 
dev_set_name().

I'd prefer to keep close to other, widely known headers.