ASoC: core: Create new components in sane state

Cezary Rojewski <cezary.rojewski@intel.com> says:

There is a gap between snd_soc_component_alloc() and
snd_soc_register_component().  A driver that obtains a component object
through snd_soc_component_alloc() receives an object in uninitialized
state.  soc_component_initialize() is the function responsible for
bringing it into a sane one but it is not accessible by the framework
users.  Example of the uninitialized members are the lists e.g.:
comp->dai_list.

The framework shall prevent manipulation of uninitialized components.
Introduce snd_soc_component_new() which acts as a constructor: allocates
and initializes the component object before returning it to the caller.

Given the quite recent discussion related to all things
component-register [1], decided to stick to the "register" wording and
renamed soc_component_add() to snd_soc_component_register().  With that,
register/unregister pattern is kept.  At the same time, the update
brings a clear division between:

	1) snd_soc_component_register(component..)
	2) snd_soc_register_component(dev..)

A driver uses 1) when operating on pre-constructed component object
explicitly and 2) when they want the ASoC framework to do everything for
them.

Parameter "name" is added to the ctor parameter list as it is one of the
fields that is always initialized, see the 'if (!component->name)'
within soc_component_initialize().  Private data on the other hand is
not so opted out of including it.  And thus snd_soc_component_set_priv()
remains intact.

[1]: https://lore.kernel.org/all/87y0f2rz8l.wl-kuninori.morimoto.gx@renesas.com/

Link: https://patch.msgid.link/20261007133353.455185-1-cezary.rojewski@intel.com

0 files changed, 0 insertions, 0 deletions