linux-kernel - Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

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: <20190517094708.GA16858@lst.de>
Date:   Fri, 17 May 2019 11:47:08 +0200
From:   Torsten Duwe <duwe@....de>
To:     Maxime Ripard <maxime.ripard@...tlin.com>
Cc:     Vasily Khoruzhick <anarsoul@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thierry Reding <thierry.reding@...il.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Icenowy Zheng <icenowy@...c.io>,
        Sean Paul <seanpaul@...omium.org>,
        Harald Geyer <harald@...ib.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree <devicetree@...r.kernel.org>,
        arm-linux <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge
 on Teres-I

On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> >
> > So for all current practical purposes, we can assume the Teres-I panel
> > to be powered properly and providing valid EDID; nothing to worry about
> > in software.
> 
> You're creating a generic binding for all the users of that bridge,
> while considering only the specific case of the Teres-I.

All I'm saying is that _this_ usage is also valid. Nothing keeps other
users from defining the output panel; on the contrary: the driver at hand
already considers an _optional_ panel and handles it, conditionally. So
driver and binding spec are 100% in sync here.

This is much more straightforward than requiring an output and making up
some dummy code and params because it cannot reasonably be handled.
(Remember, if there is an output, the driver will make calls to the
"attached device" driver.)

	Torsten