On Fri, Dec 03, 2021 at 02:52:43PM +0000, Srinivas Kandagatla wrote:
> On 03/12/2021 14:36, Stephan Gerhold wrote:
> > On Fri, Dec 03, 2021 at 10:35:08AM +0000, Srinivas Kandagatla wrote:
> > > I have tested DB410c this use case in the past using similar patch [1].
> > >
> >
> > Did you use a different modem DSP firmware? (An older one maybe?)
>
> It was very old which came with some Android release I guess.
>
Right, that should be similar to the ones used on MSM8916
smartphones/tablets. I was really glad that the qdsp6 drivers (q6asm,
q6afe, ...) worked without any changes on MSM8916 by the way, thanks a
lot for all your work on them!
> > > > @@ -148,11 +266,16 @@ static const struct snd_soc_dapm_widget apq8016_sbc_dapm_widgets[] = {
> > > > static int apq8016_sbc_platform_probe(struct platform_device *pdev)
> > > > {
> > > > + void (*add_ops)(struct snd_soc_card *card);
> > > > struct device *dev = &pdev->dev;
> > > > struct snd_soc_card *card;
> > > > struct apq8016_sbc_data *data;
> > > > int ret;
> > > > + add_ops = device_get_match_data(&pdev->dev);
> > > > + if (!add_ops)
> > > > + return -EINVAL;
> > >
> > > We will never hit the error case here because without a match we can not
> > > even enter the probe function.
> > >
> >
> > Theoretically it's possible to create platform devices through other
> > ways than the device tree (think of old board C files for example).
> > I agree that nobody should do that, but having this check here
> > at least avoids a NULL pointer dereference in this unlikely scenario.
> >
> > Please let me know if I should remove it anyway, that's fine for me!
>
> TBH, I don't have very strong opinion on this.
>
Great, can I assume your Reviewed-by: applies without any changes then?
Thanks,
Stephan
