linux-kernel - Re: [PATCH] drm/panel-edp: Allow querying the detected panel via sysfs

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: <CAD=FV=U8VGnRXv8MgofKzZF22_x0_X3M+AMfyPQ1u=yTXnFBQA@mail.gmail.com>
Date:   Tue, 25 Jan 2022 15:25:51 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     dri-devel <dri-devel@...ts.freedesktop.org>,
        David Airlie <airlied@...ux.ie>,
        Robert Foss <robert.foss@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>, jjsu@...omium.org,
        lschyi@...omium.org, Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH] drm/panel-edp: Allow querying the detected panel via sysfs

Hi,

On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas
<javierm@...hat.com> wrote:
>
> Hello Doug,
>
> On 1/25/22 22:54, Douglas Anderson wrote:
> > Recently we added generic "edp-panel"s probed by EDID. To support
> > panels in this way we look at the panel ID in the EDID and look up the
> > panel in a table that has power sequence timings. If we find a panel
> > that's not in the table we will still attempt to use it but we'll use
> > conservative timings. While it's likely that these conservative
> > timings will work for most nearly all panels, the performance of
> > turning the panel off and on suffers.
> >
> > We'd like to be able to reliably detect the case that we're using the
> > hardcoded timings without relying on parsing dmesg. This allows us to
> > implement tests that ensure that no devices get shipped that are
> > relying on the conservative timings.
> >
> > Let's add a new sysfs entry to panel devices. It will have one of:
> > * UNKNOWN - We tried to detect a panel but it wasn't in our table.
> > * HARDCODED - We're not using generic "edp-panel" probed by EDID.
> > * A panel name - This is the name of the panel from our table.
> >
> > Signed-off-by: Douglas Anderson <dianders@...omium.org>
> > ---
>
> Patch looks good to me.
>
> Reviewed-by: Javier Martinez Canillas <javierm@...hat.com>

Thanks!


> Should this new sysfs entry be documented in Documentation/ABI/ ?

I'm not sure what the policy is here. I actually don't know that I'm
too worried about this being an ABI. For the purposes of our tests
then if something about this file changed (path changed or something
like that) it wouldn't be a huge deal. Presumably the test itself
would just "fail" in this case and that would clue us in that the ABI
changed and we could adapt to whatever new way was needed to discover
this.

That being said, if the policy is that everything in sysfs is supposed
to be ABI then I can add documentation for this...

-Doug