[alsa-devel] [PATCH][RFC] ASoC: soc-core: WARN() is not related to component->driver->probe

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Tue May 21 16:22:47 CEST 2019


On 5/20/19 7:42 PM, Kuninori Morimoto wrote:
> 
> Hi Pierre-Louis
> 
>>>>> 	if (component->driver->probe) {
>>>>> 		ret = component->driver->probe(component);
>>>>> 		...
>>>>> (A)		WARN(...)
>>>>> 	}
>>>>> (B)	WARN(...)
> (snip)
>>>> My take is that unless we can prove this is incorrect we leave it as is.
>>>
>>> I think this commit is correct, thanks.
>>> But, then, it sounds we need to check it even though without .prove ?
>>
>> Sorry, I am not getting your question.
>> I don't have a trace of which codecs need this check, and I don't know
>> either if this check needs to be done in other cases than the
>> .probe(). Given all this, why would we try to move this WARN statement
>> outside of the .probe case? It seems like asking for trouble.
> 
> Sorry for bother you.
> Actually, I'm planning to post soc-pcm.c / soc-core.c cleanup patch
> because, it is not readable/understandable/balanceable,
> thus, it is difficult to support multi CPU / multi Platform, etc, etc, etc...
> 
> Then, I can see below cade too many places.
> 
> 		if (component->driver->xxx)
> 			ret = component->driver->xxx()
> 
> this kind of code is very verbose for me.
> As one of this cleanup, I want to create very simple new_func like below.
> Then, this WARN() here is not good match for this purpose.
> In my understanding, this WARN() is effective
> even though it doesn't have .probe
> If so, code will be more simple.
> 
> 	int xxx_probe(component) {
> 		if (component->driver->probe)
> 			return component->driver->probe()
> 		return 0;
> 	}
> 
> 	...
> 	ret = xxx_probe(component);
> =>	WARN();
> 	...

I don't know how to help further. Doing this change will result in the 
warning being thrown in cases where it wasn't before. and since no one 
knows what this warning means in the first place, either we leave it or 
we remove it, changing its location would be very odd.


More information about the Alsa-devel mailing list