[PATCH 1/8] dt-bindings: arm: fsl: add NXP S32G2 boards

[Andreas Färber]

Hi Chester,

On 18.08.21 16:34, Chester Lin wrote:
> On Fri, Aug 13, 2021 at 12:53:59PM -0500, Rob Herring wrote:
>> On Thu, Aug 05, 2021 at 02:54:22PM +0800, Chester Lin wrote:
>>> Add bindings for S32G2's evaluation board (S32G-VNP-EVB) and reference
>>> design 2 board ( S32G-VNP-RDB2).
>>>
>>> Signed-off-by: Chester Lin <clin at suse.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
>>> index e2097011c4b0..3914aa09e503 100644
>>> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
>>> @@ -983,6 +983,13 @@ properties:
>>>            - const: solidrun,lx2160a-cex7
>>>            - const: fsl,lx2160a
>>>  
>>> +      - description: S32G2 based Boards
>>> +        items:
>>> +          - enum:
>>> +              - fsl,s32g274a-evb
>>> +              - fsl,s32g274a-rdb2
>>> +          - const: fsl,s32g2
>>
>> Given this is an entirely different family from i.MX and new?, shouldn't 
>> it use 'nxp' instead of 'fsl'? Either way,
> 
> It sounds good and Radu from NXP has mentioned a similar idea for the
> compatible string of linflexuart. To keep the naming consistency, should we
> change all 'fsl' to 'nxp' as well?

I assume that question was just unclearly phrased, so for the record:

ABI stability rules forbid us from changing "all 'fsl'" in compatible
strings or property names.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/ABI.rst

Deployed firmware providing mainline-merged platforms with DTBs using
fsl prefix (e.g., the quoted LX2160A) needs to continue working with
newer drivers, and deployed mainline Linux should continue working after
firmware updates that modify the DTB provided to Linux.

So, if NXP wants to use nxp prefix for new S32G bindings, you can do
that for your additions only, but for LINFlexD UART (3/8) you will still
need to use fsl for the "historical" S32V binding used as fallback.

Please keep S32G consistent with itself - so if we decide on nxp here,
we should apply it to SoC, boards, LINFlexD and any future peripherals.

> For example, we could rename the fsl.yaml
> to nxp.yaml.

Since other people might be contributing i.MX boards etc. to that file,
better not make your patch series conflict with other people's patches,
so that it can get merged and we can move on to the next patchsets.

The schema filename is not ABI, so it can be renamed later.

The .dtb path may become ABI (e.g., U-Boot $fdtfile), thus my comment
about consciously deciding between freescale/ vs. nxp/ subdirectory.

> However, changing all of them would cause some impacts, which will
> need more verifications on new strings. Otherwise we would have to tolerate the
> naming differences only used by s32g2.

I fear tolerating the mess one way or another is the only viable way.
Otherwise both bindings and drivers would need duplication for backwards
compatibility, for no good reason - Freescale was acquired back in 2015.

Cheers,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)