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

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

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.