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

[Cezary Rojewski <cezary.rojewski@intel.com>]

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