Hi Geert, On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <magnus.d...@gmail.com> wrote: >> From: Magnus Damm <damm+rene...@opensource.se> >> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific >> features in the driver. The old compat strings will be deprecated in >> the not so distant future. >> >> Signed-off-by: Magnus Damm <damm+rene...@opensource.se> >> Acked-by: Geert Uytterhoeven <geert+rene...@glider.be> >> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> >> Acked-by: Rob Herring <r...@kernel.org> >> --- >> >> Changes since V2: >> - Added Acked-by from Rob >> - Removed Tested-by tag from DT binding patch - duh! >> >> Changes since V1: >> - Added Acked-by and Tested-by from Geert >> - Added Acked-by from Laurent >> >> Documentation/devicetree/bindings/timer/renesas,cmt.txt | 3 +++ >> 1 file changed, 3 insertions(+) >> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt >> 2015-09-17 17:26:57.440513000 +0900 >> @@ -36,6 +36,9 @@ Required Properties: >> (CMT1 on sh73a0 and r8a7740) >> This is a fallback for the above renesas,cmt-48-* entries. >> >> + - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car >> Gen2. >> + - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car >> Gen2. > > (advancing a few months always means more comments ;-)
Indeed! > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead? I have no strong feelings one way or the other, but I agree that aiming to make things more consistent must be good. Your proposal makes the fallback match with what we do for a bunch other devices on R-Car Gen2 like: "rcar-gen2-cpg-clocks" "rcar-gen2-scif" But we also seem to have: "pci-rcar-gen2" On R-Car Gen3 we seem to have the following per-SoC compat strings: "dmac-r8a7795" "etheravb-r8a7795" "gpio-r8a7795" "scif-r8a7795" But we also have: "r8a7795-cpg-mssr" My only feeling is that it looks a tad odd if we follow "<vendor>,<family-generation>-<device>" for fallback strings but "<vendor>,<device>-<part-number>" for the per-soc binding. Why not using the same order? Maybe this is specified in some document somewhere? I guess your take with "r8a7795-cpg-mssr" above is to follow the same order as for the fallback case? This seems sane to me, and if so then perhaps the per-soc compat strings for the CMT should also be updated? Same for other devices too then, like the recently added "dmac-r8a7795"? Cheers, / magnus
