lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Apr 2024 12:58:50 -0700
From: Abhinav Kumar <quic_abhinavk@...cinc.com>
To: Stephen Boyd <swboyd@...omium.org>,
        Kuogee Hsieh
	<quic_khsieh@...cinc.com>, <abel.vesa@...aro.org>,
        <agross@...nel.org>, <airlied@...il.com>, <andersson@...nel.org>,
        <daniel@...ll.ch>, <dianders@...omium.org>,
        <dmitry.baryshkov@...aro.org>, <dri-devel@...ts.freedesktop.org>,
        <robdclark@...il.com>, <sean@...rly.run>, <vkoul@...nel.org>
CC: <quic_jesszhan@...cinc.com>, <quic_sbillaka@...cinc.com>,
        <marijn.suijten@...ainline.org>, <freedreno@...ts.freedesktop.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] phy/qcom-qmp-combo: propagate correct return value at
 phy_power_on()



On 4/3/2024 12:51 PM, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2024-03-29 12:50:35)
>> Currently qmp_combo_dp_power_on() always return 0 in regardless of
>> return value of cfg->configure_dp_phy(). This patch propagate
>> return value of cfg->configure_dp_phy() all the way back to caller.
> 
> Is this found via code inspection or because the phy is failing to power
> on sometimes? I ask because I'm looking at a DP bug on Trogdor with
> chromeos' v6.6 based kernel and wondering if this is related.
> 

No, we actually hit an issue. This issue was originally reported as a 
link training issue while bringing up DP on x1e80100.

While debugging that we noticed that we should not have even proceeded 
to link training because the PLL was not getting locked and it was 
failing silently since there are no other error prints (and hence the 
second part of the patch to improve the error logs), and we do not 
return any error code from this driver, we could not catch the PLL 
unlocked issue.

> Also, is the call to phy_power_on() going to be checked in
> the DP driver?
> 
>   $ git grep -n phy_power_on -- drivers/gpu/drm/msm/dp/
>   drivers/gpu/drm/msm/dp/dp_ctrl.c:1453:  phy_power_on(phy);

Yes, this is a good point. We should also post the patch to add the 
error checking in DP driver to fail if phy_power_on fails.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ