linux-kernel - Re: [PATCH v5 0/3] drm/panel: Support Rocktech jh057n00900 DSI panel

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:   Wed, 03 Apr 2019 10:11:00 -0700
From:   Joe Perches <joe@...ches.com>
To:     Thierry Reding <thierry.reding@...il.com>,
        Guido Günther <agx@...xcpu.org>
Cc:     David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Kevin Hilman <khilman@...libre.com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Johan Hovold <johan@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH v5 0/3] drm/panel: Support Rocktech jh057n00900 DSI panel

On Wed, 2019-04-03 at 18:17 +0200, Thierry Reding wrote:
> On Mon, Apr 01, 2019 at 12:35:32PM +0200, Guido Günther wrote:
> > v4 fixes up the DT binding example and uses a wider cc list since I
> > failed to extend that when touching more files.
[]
> Applied, thanks.
> 
> checkpatch does complain about the dsi_generic_write_seq() macro
> definition, because it uses flow control statements, but there are
> already similar macros in other drivers, so I let this slide. We may
> want to eventually come up with something better and then replace these
> macros for the other drivers as well.

Dunno about the other drivers, but the mechanism isn't
particularly nice as it separates the init identifier
from the data being written.

It might be better to use something like a struct for
each command and a for loop for each block of commands.

Also the 0xBF value used in one of the init sequence
writes does not have an identifier #define in the
'Manufacturer specific Commands send via DSI' block
which is odd.