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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJKOXPdZ2iP3-BUk+p5A=UnbGia7s2GAOh84htcEjwB1wNAJrQ@mail.gmail.com>
Date:   Tue, 7 Sep 2021 08:59:18 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Andreas Färber <afaerber@...e.de>
Cc:     Chester Lin <clin@...e.com>, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-serial@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Oleksij Rempel <linux@...pel-privat.de>,
        Stefan Riedmueller <s.riedmueller@...tec.de>,
        Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        Li Yang <leoyang.li@....com>,
        Fabio Estevam <festevam@...il.com>,
        Matteo Lisi <matteo.lisi@...icam.com>,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        Tim Harvey <tharvey@...eworks.com>,
        Jagan Teki <jagan@...rulasolutions.com>, s32@....com,
        catalin-dan.udma@....com, bogdan.hamciuc@....com,
        bogdan.folea@....com, ciprianmarian.costea@....com,
        radu-nicolae.pirea@....com, ghennadi.procopciuc@....com,
        Matthias Brugger <matthias.bgg@...il.com>,
        "Ivan T . Ivanov" <iivanov@...e.de>,
        "Lee, Chun-Yi" <jlee@...e.com>, Rob Herring <robh@...nel.org>
Subject: Re: [PATCH 1/8] dt-bindings: arm: fsl: add NXP S32G2 boards

On Mon, 6 Sept 2021 at 22:38, Andreas Färber <afaerber@...e.de> wrote:
>
> 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@...e.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.

This is a new platform/SoC therefore there is no ABI. There is no
requirement in the kernel that a new ABI (which you define in this
patchset in the bindings) should be compatible with something
somewhere. It's some misunderstanding of stable ABI. Therefore all new
compatibles are allowed to be nxp, not fsl.

No one here proposed renaming existing compatibles from fsl tro nxp.
We talk about new ones.

Different question of course whether you want to be nice to some
existing out-of-tree users... but then have in mind that we don't care
about out of tree. :) Anyway being nice to out-of-tree is not part of
ABI. It's just being nice and useful.

Best regards,
Krzysztof