[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51A52A16.1040204@wwwdotorg.org>
Date: Tue, 28 May 2013 16:05:10 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Jon Hunter <jgchunter@...il.com>
CC: Afzal Mohammed <afzal@...com>,
Russell King <linux@....linux.org.uk>,
linux-doc@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
linux-kernel@...r.kernel.org,
Rob Herring <rob.herring@...xeda.com>,
Grant Likely <grant.likely@...aro.org>,
Benoit Cousson <benoit.cousson@...aro.org>,
linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
On 05/28/2013 03:25 PM, Jon Hunter wrote:
>
> On 27/05/13 15:37, Afzal Mohammed wrote:
>> AM43x timer bindings.
>>
>> Signed-off-by: Afzal Mohammed <afzal@...com>
>> ---
>> Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
>> index d02e27c..70cb398 100644
>> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
>> @@ -14,6 +14,8 @@ Required properties:
>> ti,omap5430-timer (applicable to OMAP543x devices)
>> ti,am335x-timer (applicable to AM335x devices)
>> ti,am335x-timer-1ms (applicable to AM335x devices)
>> + "ti,am4372-timer-1ms", "ti,am335x-timer-1ms" for AM43x 1ms timer
>> + "ti,am4372-timer", "ti,am335x-timer" for AM43x timers other than 1ms one
>>
>> - reg: Contains timer register address range (base address and
>> length).
>
> If you are adding more compatibility strings, then this implies that the
> AM43x timers are not 100% compatible with any other device listed (such
> as am335x or any omap device). That's fine but you should state that in
> the changelog. If the AM43x timer registers are 100% compatible with
> existing devices you should not add these.
I'm not sure that's true; .dts files should always include a compatible
value that describes the most specific model of the HW, plus any
baseline compatible value that the HW is compatible with. This allows
any required quirks/fixes/... to be applied for the specific HW model
later even if nobody knows right now they'll be needed. Hence, defining
new compatible values doesn't necessarily mean incompatible HW.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists