From: Conor Dooley <conor@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: soc@kernel.org, Conor Dooley <conor.dooley@microchip.com>,
Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Olof Johansson <olof@lixom.net>,
Palmer Dabbelt <palmer@dabbelt.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH v1] Documentation/process: add soc maintainer handbook
Date: Mon, 22 May 2023 22:34:25 +0100 [thread overview]
Message-ID: <20230522-concrete-unpeeled-7e4718e61b46@spud> (raw)
In-Reply-To: <cf1c6b8c-8a3f-eca1-948f-e41946d4c34c@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 2202 bytes --]
On Tue, May 16, 2023 at 10:31:19AM +0200, Krzysztof Kozlowski wrote:
> On 15/05/2023 21:20, Conor Dooley wrote:
> > +devicetree ABI stability
> > +~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +Perhaps one of the most important things to highlight is that dt-bindings
> > +document the ABI between the devicetree and the kernel. Once dt-bindings have
> > +been merged (and appear in a release of the kernel) they are set in stone, and
> > +any changes made must be compatible with existing devicetrees. This means that,
> > +when changing properties, a "new" kernel must still be able to handle an old
> > +devicetree. For many systems the devicetree is provided by firmware, and
> > +upgrading to a newer kernel cannot cause regressions. Ideally, the inverse is
> > +also true, and a new devicetree will also be compatible with an old kernel,
> > +although this is often not possible.
>
> I would prefer to skip it and instead: enhance
> Documentation/devicetree/bindings/ABI.rst and then reference it here.
>
> > +
> > +If changes are being made to a devicetree that are incompatible with old
> > +kernels, the devicetree patch should not be applied until the driver is, or an
> > +appropriate time later. Most importantly, any incompatible changes should be
> > +clearly pointed out in the patch description and pull request, along with the
> > +expected impact on existing users.
I'm not really sure that I like this truncated section so much, but here
it is... I kept the last paragraph intact as it does not talk about the
ABI, but rather exceptions of submaintainers.
devicetree ABI stability
~~~~~~~~~~~~~~~~~~~~~~~~
Perhaps one of the most important things to highlight is that dt-bindings
document the ABI between the devicetree and the kernel. Please see
:ref:`devicetree-abi` for devicetree ABI rules.
If changes are being made to a devicetree that are incompatible with old
kernels, the devicetree patch should not be applied until the driver is, or an
appropriate time later. Most importantly, any incompatible changes should be
clearly pointed out in the patch description and pull request, along with the
expected impact on existing users.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-05-22 21:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 19:20 [PATCH v1] Documentation/process: add soc maintainer handbook Conor Dooley
2023-05-16 8:31 ` Krzysztof Kozlowski
2023-05-16 8:57 ` Conor Dooley
2023-05-16 9:06 ` Krzysztof Kozlowski
2023-05-16 9:15 ` Conor Dooley
2023-05-16 9:16 ` Arnd Bergmann
2023-05-16 10:08 ` Krzysztof Kozlowski
2023-05-22 21:34 ` Conor Dooley [this message]
2023-05-23 0:32 ` Jessica Clarke
2023-05-23 5:19 ` Conor Dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230522-concrete-unpeeled-7e4718e61b46@spud \
--to=conor@kernel.org \
--cc=arnd@arndb.de \
--cc=conor+dt@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=olof@lixom.net \
--cc=palmer@dabbelt.com \
--cc=robh+dt@kernel.org \
--cc=soc@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox