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

Reply via email to