netdev - Re: [PATCH can-next 1/2] CAN: rcar: add gen[12] fallback compatibility strings

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:	Tue, 23 Feb 2016 09:08:22 +0900
From:	Simon Horman <horms@...ge.net.au>
To:	Marc Kleine-Budde <mkl@...gutronix.de>
Cc:	Rob Herring <robh@...nel.org>,
	Wolfgang Grandegger <wg@...ndegger.com>,
	Magnus Damm <magnus.damm@...il.com>, linux-can@...r.kernel.org,
	netdev@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH can-next 1/2] CAN: rcar: add gen[12] fallback
 compatibility strings

On Mon, Feb 22, 2016 at 10:40:37AM +0100, Marc Kleine-Budde wrote:
> On 02/22/2016 04:37 AM, Rob Herring wrote:
> > On Mon, Feb 22, 2016 at 11:15:49AM +0900, Simon Horman wrote:
> >> Add fallback compatibility string for R-Car Gen 1 and Gen2 families.
> >> This is in keeping with the fallback scheme being adopted wherever
> >> appropriate for drivers for Renesas SoCs.
> >>
> >> Signed-off-by: Simon Horman <horms+renesas@...ge.net.au>
> >> ---
> >>  Documentation/devicetree/bindings/net/can/rcar_can.txt | 4 +++-
> >>  drivers/net/can/rcar_can.c                             | 2 ++
> >>  2 files changed, 5 insertions(+), 1 deletion(-)
> > 
> > Acked-by: Rob Herring <robh@...nel.org>
> 
> I'm not following the latest DT discussions, is there a (new) decision
> to add such "generic" compatibles? AFAIK you add the oldest device
> that's compatible with your driver to your SoC dtsi at rightmost
> compatible. You can add one that identifies your SoC's IP core in front
> of it. So there's no need to modify the driver until an IP core needs
> different handling.
> 
> In your case you'd identify the oldest SoC that implements the Gen1 IP
> core and use this instead of "renesas,can-gen1. Same for Gen2 IP core.

In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 1 and Gen 2, but beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7779 is older than r8a7778 but that doesn't imply that the
latter is a descendant of the former or vice versa.