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: Tue, 21 May 2024 09:21:05 -0500
From: "Rob Herring (Arm)" <robh@...nel.org>
To: Douglas Anderson <dianders@...omium.org>
Cc: dri-devel@...ts.freedesktop.org,
	Thierry Reding <thierry.reding@...il.com>,
	Sam Ravnborg <sam@...nborg.org>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	devicetree@...r.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	Jeffrey Hugo <jeffrey.l.hugo@...il.com>,
	Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...il.com>,
	Jessica Zhang <quic_jesszhan@...cinc.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	linux-kernel@...r.kernel.org, Conor Dooley <conor+dt@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Maxime Ripard <mripard@...nel.org>
Subject: Re: [PATCH] dt-bindings: display: Reorganize legacy eDP panel
 bindings


On Mon, 20 May 2024 15:38:17 -0700, Douglas Anderson wrote:
> Back in the day, we used to need to list the exact panel in dts for
> eDP panels. This led to all sorts of problems including a large number
> of cases where people listed a bogus panel in their device tree
> because of the needs of second sourcing (and third sourcing, and
> fourth sourcing, ...). Back when we needed to add eDP panels to dts
> files we used to list them in "panel-simple.yaml".
> 
> These days we have the new way of doing things as documented in
> "panel-edp.yaml". We can just list the compatible "edp-panel", add
> some timing info to the source code, and we're good to go. There's not
> really good reasons not to use this new method.
> 
> To try to make it obvious that we shouldn't add new compatible strings
> for eDP panels, let's move them all out of the old "panel-simple.yaml"
> file to their own file: "panel-edp-legacy.yaml". This new file will
> have a description that makes it obvious that we shouldn't use it for
> new panels.
> 
> While we're doing this:
> - We can remove eDP-specific properties from panel-simple.yaml since
>   there are no more panels there.
> - We don't need to copy non-eDP properties to the
>   "panel-edp-legacy.yaml".
> - We'll fork off a separate yaml file for "samsung,atna33xc20.yaml".
>   This is an eDP panel which isn't _quite_ handled by the generic
>   "edp-panel" compatible since it's not allowed to have an external
>   backlight (it has one builtin) and it absolutely requires an
>   "enable" GPIO.
> - We'll un-fork the "sharp,ld-d5116z01b.yaml" and put it in
>   "panel-edp-legacy.yaml" since there doesn't appear to be any reason
>   for it to be separate.
> 
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---
> 
>  .../display/panel/panel-edp-legacy.yaml       | 127 ++++++++++++++++++
>  .../bindings/display/panel/panel-simple.yaml  |  58 --------
>  .../display/panel/samsung,atna33xc20.yaml     |  95 +++++++++++++
>  .../display/panel/sharp,ld-d5116z01b.yaml     |  30 -----
>  4 files changed, 222 insertions(+), 88 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/panel/sharp,ld-d5116z01b.yaml
> 

Reviewed-by: Rob Herring (Arm) <robh@...nel.org>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ