linux-kernel - Re: [PATCH v2] drm/panel: simple: Support reset GPIOs

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: <20200106101042.5bb5b742@xps13>
Date:   Mon, 6 Jan 2020 10:10:42 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Sam Ravnborg <sam@...nborg.org>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2] drm/panel: simple: Support reset GPIOs

Hi Sam,

Sam Ravnborg <sam@...nborg.org> wrote on Thu, 2 Jan 2020 18:27:00 +0100:

> Hi Miquel
> 
> On Tue, Dec 24, 2019 at 03:21:34PM +0100, Miquel Raynal wrote:
> > The panel common bindings provide a gpios-reset property. Let's
> > support it in the simple driver.
> > 
> > Two fields are added to the panel description structure: the time to
> > assert the reset and the time to wait right after before starting to
> > interact with it in any manner. In case these default values are not
> > filled but the GPIO is present in the DT, default values are applied.  
> 
> Wehn we discussed this the last time you wrote:
> 
> """
> my hardware is:
> 
> LVDS IP <----------> LVDS to RGB bridge <------------> Panel
> 
> While there is a simple "RGB to LVDS" bridge driver, there is none
> doing the work the other way around. In my case, the bridge has a reset
> pin.
> 
> As until now there is no way to represent the "LVDS to RGB" bridge and
> because the bindings already document such reset pin, I decided to add
> support for it in the simple panel driver.
> """
> 
> Based on the information provided it seems that the correct way is to
> add a "LVDS to RGB bridge" and then let the bridge handle the reset
> functionality.

This I agree, but we are talking about my current situation. 

> 
> It is obviously much more code to do it this way but then
> other panels using the same type of brigde have the
> same functionality without adding bridge functionality to the panel.

This, I do not fully agree as bindings for the panel reset already
exist and we could have a reset on both: the bridge and the panel.
I choose to use a wrong (private) DT representation because I am not
willing to add an LVDS->RGB bridge: as you say, it is much more work to
do. But, IMHO, this is not related to the patch. If you consider this
patch wrong because a panel cannot have a reset, then it should be
stated clearly and maybe removed from the bindings?

Anyway if you think this change can't be useful, let's put it aside.

Thanks for your time,
Miquèl