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:   Thu, 12 Sep 2019 11:26:35 +0100
From:   Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
To:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        linux-renesas-soc@...r.kernel.org,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Cc:     David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>,
        "open list:DRM DRIVERS FOR RENESAS" <dri-devel@...ts.freedesktop.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm: rcar-du: Add r8a77980 support

Hi Sergei,

(pulling in +Geert for his opinion on compatible string usages)

On 12/09/2019 11:00, Sergei Shtylyov wrote:> Hello!
> 
> On 11.09.2019 22:25, Kieran Bingham wrote:
> 
>> Add direct support for the r8a77980 (V3H).
>>
>> The V3H shares a common, compatible configuration with the r8a77970
>> (V3M) so that device info structure is reused.
> 
>    Do we really need to add yet another compatible in this case?
> I just added r8a77970 to the compatible prop in the r8a77980 DT. That's why
> a patch like this one didn't get posted by me.

It's not just about the compatible string for me here,

There is no indication in the driver that it supports the r8a77980, and
no comment in the driver to explain that the r8a77980 is shared by the
r8a77970.

This patch makes that explicit at the driver.

Also - I am considering sending a patch (that I've already created
anyway) to remove the r8a77970 reference from the

  arch/arm64/boot/dts/renesas/r8a77980.dtsi file.

This is the *only* non r8a77980 reference in this file, so it seems very
out of place.

In fact more so than that - except for a seemingly glaring typo, that
I'll investigate and send a patch for next, this is the *only* cross-soc
compatible reference:



#!/bin/sh

files=r8a77*.dtsi

for f in $files;
do
	soc=`basename $f .dtsi | sed 's/-.*//'`
	echo "F: $f soc: $soc";

	# Find all references to all socs, then hide 'this' soc
	grep r8a77 $f | grep -v $soc
done;

Finds :

> F: r8a774a1.dtsi soc: r8a774a1
> F: r8a774c0.dtsi soc: r8a774c0
> F: r8a7795-es1.dtsi soc: r8a7795
> F: r8a7795.dtsi soc: r8a7795
> F: r8a7796.dtsi soc: r8a7796
> F: r8a77965.dtsi soc: r8a77965
>  * Based on r8a7796.dtsi
> F: r8a77970.dtsi soc: r8a77970
> 			compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar";
> F: r8a77980.dtsi soc: r8a77980
> 				     "renesas,du-r8a77970";
> F: r8a77990.dtsi soc: r8a77990
> F: r8a77995.dtsi soc: r8a77995

--
KB

> 
>> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
> [...]
> 
> MBR, Sergei

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ