Re: [PATCH 0/7] ASoC: core: Create new components in sane state

[Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>]

Hi Cezary

Thank you for the patch

> 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.

I would like to review this patch, but unfortunately I'm busy this week.
Actually, I'm now posting cleanup snd_soc_component_xxx(),
which has many steps, and is now under progress.

I will review your patch next week, but I guess some of them (= not all)
are conflicts to mine...

Thank you for your help !!

Best regards
---
Kuninori Morimoto