[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71712242-ffc3-69d0-6abe-6ee61d3630bf@linaro.org>
Date: Thu, 8 Jun 2023 15:23:06 +0100
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: Johan Hovold <johan@...nel.org>
Cc: vkoul@...nel.org, andersson@...nel.org,
yung-chuan.liao@...ux.intel.com,
pierre-louis.bossart@...ux.intel.com, sanyog.r.kale@...el.com,
linux-arm-msm@...r.kernel.org, alsa-devel@...a-project.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] soundwire: qcom: stablity fixes
On 08/06/2023 14:05, Johan Hovold wrote:
> On Thu, Jun 08, 2023 at 01:45:22PM +0100, Srinivas Kandagatla wrote:
>> On 08/06/2023 13:40, Johan Hovold wrote:
>
>>> Looking at the above log it seems like we hit a probe deferral somewhere
>>> as some resource is not available yet, and this is eventually turned
>>> into a hard failure that breaks audio as the error is propagated up the
>>> stack.
>>
>> I was looking at this too, And I think this change should help..
>> Not tried it though
>
>> ret = snd_soc_tplg_component_load(component, &audioreach_tplg_ops, fw);
>> - if (ret < 0) {
>> + if (ret < 0)
>> dev_err(dev, "tplg component load failed%d\n", ret);
>> - ret = -EINVAL;
>> - }
>
> That in itself only seems to make the problem worse with new follow-on
> errors. Looks like a dereference of an error pointer in a codec driver:
Thanks Johan,
I will try to see if we can fix this properly.
--srini
Powered by blists - more mailing lists