lkml.org 
[lkml]   [2014]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2014-07-18 12:01    [W:0.069 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site