[PATCH] dt-bindings: mailbox: Convert omap-mailbox.txt binding to YAML

Suman Anna s-anna at ti.com
Thu May 20 09:45:28 PDT 2021


On 5/19/21 7:08 PM, Rob Herring wrote:
> On Wed, May 19, 2021 at 10:14:14AM -0500, Suman Anna wrote:
>> On 5/18/21 12:20 PM, Suman Anna wrote:
>>> Convert the current OMAP Mailbox binding from text format to YAML
>>> format/DT schema, and delete the legacy text binding file.
>>>
>>> The new YAML binding conversion is an updated version compared to
>>> the original. The descriptions for certain properties have been
>>> improved to provide more clarity. Constraints are added to the
>>> properties 'ti,mbox-num-users', 'ti,mbox-num-fifos' and 'interrupts'.
>>> The 'ti,hwmods' is a legacy property and is retained only to reflect
>>> the existing usage on some older OMAP2 and OMAP3 platforms.
>>>
>>> All the existing examples have also been updated to reflect the
>>> latest dts nodes (ti,hwmods removed from OMAP4 and AM33xx examples,
>>> and interrupts value updated for AM65x SoCs).
>>>
>>> Signed-off-by: Suman Anna <s-anna at ti.com>
>>> ---
>>> Hi,
>>>
>>> This patch does fix a number of dtbs_check warnings seen around OMAP Mailbox
>>> nodes with the latest kernel. There are few left-over warnings when just
>>> this patch is used on v5.13-rc1 or next-20210518. I have posted a separate
>>> fix for a warning on TI K3 SoCs [1], and will be posting a separate cleanup
>>> series for OMAP2+ SoCs. The dts patches can be picked up independently
>>> of this patch.
>>
>> FYI, All the dtbs_check warnings will be gone with [1] and the OMAP2+ cleanup
>> series [2].
> 
> Nice, though it is a moving target. :) Is that still true with the 
> undocumented compatible checks that's been added? 

[1] is acked, so will definitely get picked up for the next merge window. Should
hit next sometime in the next couple of days.

I didn't exactly understand your second comment, but no new compatibles were
added. The existing nodes are already in compliance with the constraints I added
(so that's strictly binding enforcements). These constraints are almost all on
legacy SoCs, so these do not pose any issues.

Most of the generated warnings stem from me adding a pattern for the child nodes
in the binding, and [2] is mostly just renaming these node names.

Tony,
Do you have/foresee any concerns with the patches in [2]?

regards
Suman

[1]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210514212016.3153-1-s-anna@ti.com/
[2] https://patchwork.kernel.org/project/linux-omap/list/?series=484489




More information about the linux-arm-kernel mailing list