linux-kernel - Re: [PATCH 05/13] thermal: rcar: Document SoC-specific bindings

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:	Tue, 05 Aug 2014 17:30:05 -0700 (PDT)
From:	Kuninori Morimoto <kuninori.morimoto.gx@...il.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Zhang Rui <rui.zhang@...el.com>, Simon Horman <horms@...ge.net.au>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Magnus Damm <magnus.damm@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Eduardo Valentin <eduardo.valentin@...com>,
	Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 05/13] thermal: rcar: Document SoC-specific bindings


Hi Geert

> >> > >  Required properties:
> >> > > -- compatible             : "renesas,rcar-thermal"
> >> > > +- compatible             : "renesas,thermal-<soctype>", "renesas,rcar-thermal"
> >> > > +                   as fallback.
> >> > > +                   Examples with soctypes are:
> >> > > +                     - "renesas,thermal-r8a73a4" (R-Mobile AP6)
> >> > > +                     - "renesas,thermal-r8a7779" (R-Car H1)
> >> > > +                     - "renesas,thermal-r8a7790" (R-Car H2)
> >> > > +                     - "renesas,thermal-r8a7791" (R-Car M2)
> >> > >  - reg                    : Address range of the thermal registers.
> >> > >                     The 1st reg will be recognized as common register
> >> > >                     if it has "interrupts".
(snip)
> One important thing to note in my patch description is "some of which
> are already in use.".
> 
> $ git grep renesas,thermal -- arch/arm/boot/ | cat
> arch/arm/boot/dts/r8a7790.dtsi: compatible =
> "renesas,thermal-r8a7790", "renesas,rcar-thermal";
> arch/arm/boot/dts/r8a7791.dtsi: compatible =
> "renesas,thermal-r8a7791", "renesas,rcar-thermal";
> $
> 
> So these 2 should be added to the documentation for sure.
> Adding the 2 others, and adding them to the respective DTSes (cfr. the
> other patches in the series) doesn't hurt, and will help if an incompatibility
> ever arises.
> 
> (I assume the driver works with the other DTSes that already claim to have
> a device compatible with "renesas,rcar-thermal").

I reconsidered about this.
Actually, I'm still wondering about this approach
because driver side doesn't have SoC specific matching table.
Of course SoC-specific name in .compatible can be backup plan for us,
but, we don't know it is 100% true.
(we might have new driver for some specific SoC, like R-Car DMA driver ?)

Adding to SoC specific compatible name in SoC side DTSes are no problem,
it can be backup plan.
but, we can't say 100% true that <driver>.txt has SoC specific name list.
because, driver doesn't care about it today, and we don't know the future

But, on the other hand, this kind of update patch can indicate to
kernel users that "this driver is under maintenance".
# we have many drivers which are not updated.
# 50% it is complete driver, 50% it is just non-maintenanced driver

So, I can say,

   Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>

I can 100% agree if it is easy to understand
that listed specific SoC are just "working",
not "formally supported as SoC specific"


Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/