On Tue, Jan 15, 2019 at 01:35:07PM -0600, Pierre-Louis Bossart wrote: > On 1/14/19 6:06 PM, Mark Brown wrote:
> > just pushing the breakage around rather than fixing it. Can someone
> > with an x86 system take a look and confirm exactly what's going on with
> > binding these cards please?
> Beyond the fact that the platform_name seems to be totally useless,
> additional tests show that the patch ('ASoC: soc-core: defer card probe
> until all component is added to list') adds a new restriction which
> contradicts existing error checks.
Yes... I'd been coming to the conclusion that it was a huge red herring
here.
> So if we want to be consistent, the new code should be something like:
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index b680c673c553..2791da9417f8 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -1154,7 +1154,7 @@ static int soc_init_dai_link(struct snd_soc_card
> *card,
> * Defer card registartion if cpu dai component is not added to
> * component list.
> */
> - if (!soc_find_component(link->cpu_of_node, link->cpu_name))
> + if (!link->cpu_dai_name && !soc_find_component(link->cpu_of_node,
> link->cpu_name))
> return -EPROBE_DEFER;
>
> /*
> or try to call soc_find_component with both cpu_name or cpu_dai_name, if
> this makes sense?
I think calling _find_component() makes more sense here as it will do
the check it's actually there thing no matter how the link is
identified. Assuming that does resolve the issue do you want to make a
patch given that you got there first?
signature.asc
Description: PGP signature
