ARM: dts: Drop unused ti,am4372-timer compatible

Drop unused (and undocumented) ti,am4372-timer related compatible
properties to avoid dtb warnings when updating the binding to yaml.

The dual-mode timer instances on am43 are compatible with the am3
timers.

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/am437x-l4.dtsi | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

* Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> [220408 08:22]:
> On 08/04/2022 10:12, Tony Lindgren wrote:
> > Drop unused (and undocumented) ti,am4372-timer related compatible
> > properties to avoid dtb warnings when updating the binding to yaml.
> > 
> > The dual-mode timer instances on am43 are compatible with the am3
> > timers.
> 
> Are you sure this is correct approach? Maybe some other user of DTS
> references the am43 compatible, so instead it should be documented in
> the bindings?

No users. The driver does not parse these. The am4 SoCs boot using
the am3 related compatible properties.

> See also recommendation "DO use fallback compatibles...":
> Documentation/devicetree/bindings/writing-bindings.rst
> which maybe applies here?

Yes I'd agree if there were users for this, or if this was already
documented :) But I don't see a need to keep these am4 specific
properties.

Regards,

Tony

On 08/04/2022 10:29, Tony Lindgren wrote:
> * Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> [220408 08:22]:
>> On 08/04/2022 10:12, Tony Lindgren wrote:
>>> Drop unused (and undocumented) ti,am4372-timer related compatible
>>> properties to avoid dtb warnings when updating the binding to yaml.
>>>
>>> The dual-mode timer instances on am43 are compatible with the am3
>>> timers.
>>
>> Are you sure this is correct approach? Maybe some other user of DTS
>> references the am43 compatible, so instead it should be documented in
>> the bindings?
> 
> No users. 

You sure you check all operating systems and all out-of-tree users? I
did not talk about in-kernel DTS...

> The driver does not parse these. The am4 SoCs boot using
> the am3 related compatible properties.
> 
>> See also recommendation "DO use fallback compatibles...":
>> Documentation/devicetree/bindings/writing-bindings.rst
>> which maybe applies here?
> 
> Yes I'd agree if there were users for this, or if this was already
> documented :) But I don't see a need to keep these am4 specific
> properties.


Best regards,
Krzysztof

* Grygorii Strashko <grygorii.strashko@ti.com> [220408 09:31]:
> 
> 
> On 08/04/2022 11:33, Krzysztof Kozlowski wrote:
> > On 08/04/2022 10:29, Tony Lindgren wrote:
> > > * Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> [220408 08:22]:
> > > > On 08/04/2022 10:12, Tony Lindgren wrote:
> > > > > Drop unused (and undocumented) ti,am4372-timer related compatible
> > > > > properties to avoid dtb warnings when updating the binding to yaml.
> > > > > 
> > > > > The dual-mode timer instances on am43 are compatible with the am3
> > > > > timers.
> > > > 
> > > > Are you sure this is correct approach? Maybe some other user of DTS
> > > > references the am43 compatible, so instead it should be documented in
> > > > the bindings?
> > > 
> > > No users.
> > 
> > You sure you check all operating systems and all out-of-tree users? I
> > did not talk about in-kernel DTS...

Yeah you can never be quite sure :)

> > > The driver does not parse these. The am4 SoCs boot using
> > > the am3 related compatible properties.
> > > 
> > > > See also recommendation "DO use fallback compatibles...":
> > > > Documentation/devicetree/bindings/writing-bindings.rst
> > > > which maybe applies here?
> > > 
> > > Yes I'd agree if there were users for this, or if this was already
> > > documented :) But I don't see a need to keep these am4 specific
> > > properties.
> > 
> 
> I'd prefer to drop it if not used and not documented.
> conversation to yaml is good time for clean up.
> if somebody complains - can always return back and document it.

Well this will produce warnings for Krzysztof for the dt bindings branch
until it's dropped for the dts files. And since it's possible to discuss
this with arguments both ways.. Let's just keep it and document it. I just
noticed we already have few redundant compatibles with dm814 and dm816 that
are probably compatible with omap4 if rememember correctly.

Regards,

Tony