linux-kernel - Re: [PATCH v1] drm/msm/dp: use dp_hpd_plug_handle() and dp_hpd_unplug

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]

Message-ID: <27cadd17-10a3-3b8c-2b29-6698ccdce531@quicinc.com>
Date: Thu, 28 Mar 2024 16:41:57 -0700
From: Abhinav Kumar <quic_abhinavk@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Stephen Boyd <swboyd@...omium.org>,
        Bjorn Andersson
	<andersson@...nel.org>,
        Johan Hovold <johan@...nel.org>,
        Kuogee Hsieh
	<quic_khsieh@...cinc.com>, <abel.vesa@...aro.org>,
        <agross@...nel.org>, <airlied@...il.com>, <daniel@...ll.ch>,
        <dianders@...omium.org>, <dri-devel@...ts.freedesktop.org>,
        <robdclark@...il.com>, <sean@...rly.run>, <vkoul@...nel.org>,
        <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 v1] drm/msm/dp: use dp_hpd_plug_handle() and
 dp_hpd_unplug_handle() directly



On 3/28/2024 3:50 PM, Dmitry Baryshkov wrote:
> On Thu, 28 Mar 2024 at 23:21, Abhinav Kumar <quic_abhinavk@...cinc.com> wrote:
>>
>>
>>
>> On 3/28/2024 1:58 PM, Stephen Boyd wrote:
>>> Quoting Abhinav Kumar (2024-03-28 13:24:34)
>>>> + Johan and Bjorn for FYI
>>>>
>>>> On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
>>>>> For internal HPD case, hpd_event_thread is created to handle HPD
>>>>> interrupts generated by HPD block of DP controller. It converts
>>>>> HPD interrupts into events and executed them under hpd_event_thread
>>>>> context. For external HPD case, HPD events is delivered by way of
>>>>> dp_bridge_hpd_notify() under thread context. Since they are executed
>>>>> under thread context already, there is no reason to hand over those
>>>>> events to hpd_event_thread. Hence dp_hpd_plug_handle() and
>>>>> dp_hpd_unplug_hanlde() are called directly at dp_bridge_hpd_notify().
>>>>>
>>>>> Signed-off-by: Kuogee Hsieh <quic_khsieh@...cinc.com>
>>>>> ---
>>>>>     drivers/gpu/drm/msm/dp/dp_display.c | 5 +++--
>>>>>     1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>
>>>> Fixes: 542b37efc20e ("drm/msm/dp: Implement hpd_notify()")
>>>
>>> Is this a bug fix or an optimization? The commit text doesn't tell me.
>>>
>>
>> I would say both.
>>
>> optimization as it avoids the need to go through the hpd_event thread
>> processing.
>>
>> bug fix because once you go through the hpd event thread processing it
>> exposes and often breaks the already fragile hpd handling state machine
>> which can be avoided in this case.
> 
> Please add a description for the particular issue that was observed
> and how it is fixed by the patch.
> 
> Otherwise consider there to be an implicit NAK for all HPD-related
> patches unless it is a series that moves link training to the enable
> path and drops the HPD state machine completely.
> 
> I really mean it. We should stop beating a dead horse unless there is
> a grave bug that must be fixed.
> 

I think the commit message is explaining the issue well enough.

This was not fixing any issue we saw to explain you the exact scenario 
of things which happened but this is just from code walkthrough.

Like kuogee wrote, hpd event thread was there so handle events coming 
out of the hpd_isr for internal hpd cases. For the hpd_notify coming 
from pmic_glink or any other extnernal hpd cases, there is no need to 
put this through the hpd event thread because this will only make things 
worse of exposing the race conditions of the state machine.

Moving link training to enable and removal of hpd event thread will be 
worked on but delaying obvious things we can fix does not make sense.

>>
>>>>
>>>> Looks right to me,
>>>>
>>>> Reviewed-by: Abhinav Kumar <quic_abhinavk@...cinc.com>
> 
> 
>