linux-kernel - Re: [PATCH] drm: omapdrm: displays: fix port

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] [day] [month] [year] [list]

Date:   Wed, 22 Aug 2018 09:46:30 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Tomi Valkeinen <tomi.valkeinen@...com>,
        David Airlie <airlied@...ux.ie>,
        Sebastian Reichel <sre@...nel.org>,
        "Andrew F. Davis" <afd@...com>, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        letux-kernel@...nphoenux.org
Subject: Re: [PATCH] drm: omapdrm: displays: fix port_num for opa362 output

Hi Laurent,

> Am 19.08.2018 um 16:07 schrieb Laurent Pinchart <laurent.pinchart@...asonboard.com>:
> 
> Hi Nikolaus,
> 
> Thank you for the patch.
> 
> On Friday, 27 July 2018 17:24:32 EEST H. Nikolaus Schaller wrote:
>> The opa362 amplifier has two ports, an input (usually connected
>> to the OMAP3 VENC) and an output port connected to the external
>> connector.
>> 
>> These are usually defined as input port@0 and outpt port@1 in
>> the DT and really distinguished by the reg = <port_num> property
>> of these nodes.
>> 
>> But we are missing to define the output port as number 1 so
>> it does not match the DT entry.
>> 
>> Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
> 
> I think this patch is superseded by "[PATCH v3 36/61] drm/omap: dss: Replace 
> omap_dss_device port number with bitmask"

looks good and from cursory review it seems to resolve the opa362
bug as a side-effect. Maybe this can be noted in the commit description.

What I am not sure how this magically defines the output as
reg=<1> or if we have to swap reg number definitions in the DT.
But encoder-tfp410.c and encoder-tpd12s015.c seem to do it the
same way, so it is very likely that it works as defined.

> which should get merged in v4.20.

Well, I had hoped our bug fix makes it into v4.19 and can be
potentially backported to stable.

Do you plan to backport you patch? It seems to be quite independent
and should apply to older releases.

BR,
Nikolaus