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