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  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 <>
To:	Simon Horman <>
Cc:	Zhang Rui <>,
	Geert Uytterhoeven <>,
	Magnus Damm <>,,,,
	Eduardo Valentin <>,
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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists