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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
