linux-kernel - Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux

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:   Thu, 7 Apr 2022 17:20:34 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc:     Abhinav Kumar <quic_abhinavk@...cinc.com>,
        "Sankeerth Billakanti (QUIC)" <quic_sbillaka@...cinc.com>,
        quic_kalyant <quic_kalyant@...cinc.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        quic_vproddut <quic_vproddut@...cinc.com>,
        David Airlie <airlied@...ux.ie>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "Kuogee Hsieh (QUIC)" <quic_khsieh@...cinc.com>,
        freedreno <freedreno@...ts.freedesktop.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        Sean Paul <seanpaul@...omium.org>,
        "Aravind Venkateswaran (QUIC)" <quic_aravindh@...cinc.com>,
        Stephen Boyd <swboyd@...omium.org>,
        Sean Paul <sean@...rly.run>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus

Hi,

On Thu, Apr 7, 2022 at 4:36 PM Dmitry Baryshkov
<dmitry.baryshkov@...aro.org> wrote:
>
> The ps8640 driver looks 'working by coincidence'. It calls
> dp_aux_populate, then immediately after the function returns it checks
> for the panel. If panel-edp is built as a module, the probe might fail
> easily.
> The anx7625 driver has the same kind of issue. The DP AUX bus is
> populated from the probe() and after some additional work the panel is
> being checked.
> This design is fragile and from my quick glance it can break (or be
> broken) too easy. It reminds me of our drm msm 'probe' loops
> preventing the device to boot completely if the dsi bridge/panel could
> not be probed in time.

I did spend some time thinking about this, at least for ps8640. I
believe that as long as the panel's probe isn't asynchronous.
Basically if the panel isn't ready then ps8640 should return and we'll
retry later. I do remember the probe loops that we used to have with
msm and I don't _think_ this would trigger it.

That being said, if we need to separate out the AUX bus into a
sub-device like we did in sn65dsi86 we certainly could.

-Doug