linux-kernel - Re: [PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

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] [day] [month] [year] [list]

Message-ID: <CAOw6vbLv_q8XPj4_A7Yx1HaVVkdUTeq9=EHAjtJd7bOge2C21Q@mail.gmail.com>
Date:   Mon, 5 Dec 2016 12:28:01 -0500
From:   Sean Paul <seanpaul@...omium.org>
To:     Archit Taneja <architt@...eaurora.org>
Cc:     zain wang <wzz@...k-chips.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Inki Dae <inki.dae@...sung.com>,
        David Airlie <airlied@...ux.ie>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Mika Kahola <mika.kahola@...el.com>,
        Stéphane Marchesin <marcheu@...omium.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Doug Anderson <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 Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-samsung-soc <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

On Sun, Dec 4, 2016 at 10:13 PM, Archit Taneja <architt@...eaurora.org> wrote:
>
>
> On 12/02/2016 09:33 PM, Sean Paul wrote:
>>
>> On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja <architt@...eaurora.org>
>> wrote:
>>>
>>> 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.
>>>
>>
>> Hi Archit,
>>
>> This was my first impression, too, and the complexity of the various
>> psr abstraction layers don't help :)
>>
>> However, this code path will be hit if the source supports psr, but
>> the sink doesn't. The rockchip_drm_psr code doesn't know if the sink
>> supports psr, so it will end up calling this.
>
>
> Okay, thanks for the explanation. The dev_warn() below still seems
> unnecessary, right?
>

Yeah, one could make a case for dev_info (disclaimer: I have a high
tolerance for noisy logs), but a warning does seem excessive.

Sean

> Archit
>
>
>>
>> Sean
>>
>>
>>>>
>>>>         /* 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
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project