linux-kernel - Re: [PATCH v3 09/12] drm/msm/dp: HPD handling relates to next

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: <20221027015846.5gsmlinx4iwyjvui@builder.lan>
Date:   Wed, 26 Oct 2022 20:58:46 -0500
From:   Bjorn Andersson <andersson@...nel.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Bjorn Andersson <quic_bjorande@...cinc.com>,
        Rob Clark <robdclark@...il.com>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Kuogee Hsieh <quic_khsieh@...cinc.com>,
        Sankeerth Billakanti <quic_sbillaka@...cinc.com>,
        Johan Hovold <johan@...nel.org>, linux-arm-msm@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 09/12] drm/msm/dp: HPD handling relates to next_bridge

On Wed, Oct 26, 2022 at 09:08:49AM +0300, Dmitry Baryshkov wrote:
> 
> 
> On 26 October 2022 06:26:21 EEST, Bjorn Andersson <quic_bjorande@...cinc.com> wrote:
> >From: Bjorn Andersson <bjorn.andersson@...aro.org>
> >
> >The DisplayPort controller's internal HPD interrupt handling is used for
> >cases where the HPD signal is connected to a GPIO which is pinmuxed into
> >the DisplayPort controller.
> >
> >Most of the logic for enabling and disabling the HPD-related interrupts
> >is conditioned on the presence of an EDP panel, but more generically
> >designs that has a downstream drm_bridge (next_bridge) could use this to
> >handle the HPD interrupts, instead of the internal mechanism.
> >
> >So replace the current is_edp-based guards with a check for the presence
> >of next_bridge.
> 
> This does not sound correct. The next bridge might be a dummy bridge,
> not supporting the hpd.

I only considered checking for the Chrome case, where the output isn't
modelled and we have to rely on the internal HPD logic. Checking that
next_bridge is present and will deliver us hpd events sounds somewhat
reasonable.

But if I understand the code correctly, panel-edp isn't handing us hpd
events - and we still don't want the internal HPD logic to trigger. So I
presume I would need to check that this isn't a EDP controller and that
we're going to get external HPD events?

If so, clean you please give me some pointer on how to check if
next_bridge will provide us with hpd signaling or not?


PS. Which dummy bridge do you have in mind?

> Please change this to use the enable_hpd()/disable_hpd() callbacks.
> This way the drm_bridge_connector framework will make sure to enable
> hpd handling for the bridge that is actually supposed to generate hpd
> events.
> 

The drm_bridge_connector_init() call in dp_drm_connector_init() does
this for us already.

Regards,
Bjorn

> 
> >
> >Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> >Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
> >---
> >
> >Changes since v2:
> >- None
> 
> 
> -- 
> With best wishes
> Dmitry