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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 2 Dec 2016 09:24:11 +0530
From:   Archit Taneja <architt@...eaurora.org>
To:     zain wang <wzz@...k-chips.com>, Sean Paul <seanpaul@...omium.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Inki Dae <inki.dae@...sung.com>,
        David Airlie <airlied@...ux.ie>
Cc:     Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Mika Kahola <mika.kahola@...el.com>,
        Stéphane Marchesin <marcheu@...omium.org>,
        Tomasz Figa <tfiga@...omium.org>, dianders@...omium.org,
        Thierry Reding <treding@...dia.com>,
        Krzysztof Kozlowski <k.kozlowski@...sung.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Jingoo Han <jingoohan1@...il.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-samsung-soc@...r.kernel.org,
        linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not
 support PSR in PSR functions

Hi,

On 12/02/2016 08:02 AM, zain wang wrote:
> We will ignored PSR setting if panel not support it. So, in this case, we should
> return from analogix_dp_enable/disable_psr() without any error code.
> Let's retrun 0 instead of -EINVAL when panel not support PSR in
> analogix_dp_enable/disable_psr().
>
> Signed-off-by: zain wang <wzz@...k-chips.com>
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 6e0447f..0cb3695 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -112,7 +112,7 @@ int analogix_dp_enable_psr(struct device *dev)
>  	struct edp_vsc_psr psr_vsc;
>
>  	if (!dp->psr_support)
> -		return -EINVAL;
> +		return 0;

Looking at the rockchip analogix dp code, in analogix_dp_psr_set, the worker that calls
analogix_dp_enable/disable_psr isn't even if psr isn't enabled. So, the bridge funcs
shouldn't be called in the first place. I think the error handling is fine to have
here.

>
>  	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
>  	memset(&psr_vsc, 0, sizeof(psr_vsc));
> @@ -135,7 +135,7 @@ int analogix_dp_disable_psr(struct device *dev)
>  	struct edp_vsc_psr psr_vsc;
>
>  	if (!dp->psr_support)
> -		return -EINVAL;
> +		return 0;
>
>  	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
>  	memset(&psr_vsc, 0, sizeof(psr_vsc));
> @@ -878,6 +878,8 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
>  	dp->psr_support = analogix_dp_detect_sink_psr(dp);
>  	if (dp->psr_support)
>  		analogix_dp_enable_sink_psr(dp);
> +	else
> +		dev_warn(dp->dev, "Sink not support PSR\n");

This doesn't seem beneficial either. There seems to be a debug
print already in analogix_dp_detect_sink_psr which reports PSR
related info.

Archit

>  }
>
>  /*
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Powered by blists - more mailing lists