[PATCH 2/3] Documentation/process: maintainer-soc: add clean platforms profile

[Conor Dooley]

Hey Krzysztof,

On Fri, Jul 14, 2023 at 10:47:24AM +0200, Krzysztof Kozlowski wrote:
> Some SoC platforms require that commits must not bring any new
> dtbs_check warnings.  Maintainers of such platforms usually have some
> automation set, so any new warning will be spotted sooner or later.
> Worst case: they run the tests themselves.  Document requirements for
> such platforms, so contributors can expect their patches being dropped
> or ignored, if they bring new warnings for existing boards.

Definitely a more scalable approach than your previous version!

> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> ---
>  .../process/maintainer-handbooks.rst          |  1 +
>  .../process/maintainer-soc-clean-dts.rst      | 22 +++++++++++++++++++
>  MAINTAINERS                                   |  2 +-
>  3 files changed, 24 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/process/maintainer-soc-clean-dts.rst
> 
> diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst
> index 9992bfd7eaa3..976391cec528 100644
> --- a/Documentation/process/maintainer-handbooks.rst
> +++ b/Documentation/process/maintainer-handbooks.rst
> @@ -17,5 +17,6 @@ Contents:
>  
>     maintainer-netdev
>     maintainer-soc
> +   maintainer-soc-clean-dts
>     maintainer-tip
>     maintainer-kvm-x86
> diff --git a/Documentation/process/maintainer-soc-clean-dts.rst b/Documentation/process/maintainer-soc-clean-dts.rst
> new file mode 100644
> index 000000000000..87feeb5543ff
> --- /dev/null
> +++ b/Documentation/process/maintainer-soc-clean-dts.rst
> @@ -0,0 +1,22 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=============================
> +SoC Platforms with Strict DTS

I don't think that this title makes much sense, it feels like it has
been truncated. Perhaps add "Requirements" to the end?

> +=============================
> +
> +Overview
> +--------
> +
> +SoC platforms or subarchitectures follow all the rules from

s/follow/should follow/?

> +Documentation/process/maintainer-soc.rst.  However platforms referencing this
> +document impose additional requirements listed below.
> +
> +Strict DTS DT schema compliance
> +-------------------------------
Should there be a blank line here to match the other section headings?
Also, to match the title case you used elsewhere, "Schema Compliance"?

> +None of the changes to the SoC platform Devicetree sources (DTS files) can
> +bring new ``make dtbs_check W=1`` warnings.  The platform maintainers have

Nitpickery again, but perhaps the first sentence here would read better as
"No changes to the SoC platform Devicetree sources (DTS files) should
introduce new ``make dtbs_check W=1`` warnings."?

> +automation in place which should point out any new warnings.
> +
> +If a commit introducing new warning gets accepted somehow, the resulting issues
> +shall be fixed in reasonable time (e.g. within one release) or the commit
> +reverted.

It is loosely related, but I was wondering if we should also try to push
people that change the platform's bindings to update the DTS also, so
that binding changes do not introduce W=1 complaints?
For many bindings the platform entry in MAINTAINERS does not cover them,
but things like the arm64 Apple stuff mention them specifically & others
will get coverage due to regexes.

Anyway, nitpickery aside I like this approach.
Reviewed-by: Conor Dooley <conor.dooley at microchip.com>

Thanks,
Conor.

> diff --git a/MAINTAINERS b/MAINTAINERS
> index b61289fa7891..7405fb6e38c3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1561,7 +1561,7 @@ S:	Maintained
>  P:	Documentation/process/maintainer-soc.rst
>  C:	irc://irc.libera.chat/armlinux
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
> -F:	Documentation/process/maintainer-soc.rst
> +F:	Documentation/process/maintainer-soc*.rst
>  F:	arch/arm/boot/dts/Makefile
>  F:	arch/arm64/boot/dts/Makefile
>  
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230714/9afc41e5/attachment.sig>