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

[Kuninori Morimoto]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/