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


Hi Simon

> 1. That the (in this case thermal) IP on the SoC's listed is known
>    to work with the driver using the generic (in this case
>    renesas,rcar-thermal) compatibility string.
> 
> 2. That if some incompatibility is subsequently found such that the
>    IP on SoC does function correctly using the generic compatibility
>    string or some new feature is to be enabled which is not generic
>    then it the driver should be updated with code that is triggered
>    by the SoC-specific compat string.
> 3. That Soc dts(i) files should list the more specific SoC compat string
>    followed bu the generic compat string. In this way so long as the
>    driver only matches on the generic compat string it will be used. But
>    if the driver is updated match on the SoC-specific compat string
>    then it will be used instead. In this way dtbs should be forwards
>    compatible with driver updates.
> 
>    I believe that this series includes patches to update the relevant
>    dtsi files accordingly.
> 
> In relation to verification, I believe all the SoCs listed in this patch
> are known to work with the generic compat string. And they should continue
> to work with this change because its only an documentation change. In the
> future, if a SoC specific compat string is added to the driver code then
> verification would need to occur.
> 
> From my point of view the documentation in rcar-thermal.txt is consistent
> with the documentation for other drivers that use this binding scheme
> (at least the ones that are documented :). I would not have any problems
> examples but I don't think its entirely necessary.

>From my point of view,
I have no object to adding SoC-specific compatible
string on dts(i) file.
It can be insurance for future (above 1, 2, 3).

My concern is to add "known working SoC" to documentation.
I have no objection if this listed "known working SoC" 
was matched to "SoC-specific" compatible name.
Because driver cares it specially.
And, this case, documentation should list it.

But this case, listed SoC are matched to "generic name".

> +- 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)

>From my (general?) point of view,
it seems that these listed SoC doesn't match to "generic name".
I mean that driver will do something special for these SoC.
And, we will confuse if driver supports "SoC-specific" compatible name.
(which one is special ? which one is generic ?)

And, I don't want to keep updating
"generic name matched SoC" on document.

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/