[<prev] [next>] [day] [month] [year] [list]
Message-ID: <66cff026-3e7d-f88b-e99f-8100233231bb@linaro.org>
Date: Mon, 17 Jul 2023 09:58:00 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Conor Dooley <conor@...nel.org>
Cc: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Alim Akhtar <alim.akhtar@...sung.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Nishanth Menon <nm@...com>, linux-riscv@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
Jonathan Corbet <corbet@....net>,
Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
soc@...nel.org, workflows@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/3] Documentation/process: maintainer-soc: add clean
platforms profile
On 14/07/2023 14:50, Conor Dooley wrote:
> 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@...aro.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?
OK, but maybe better then
SoC Platforms with DTS Compliance Requirements
?
>
>> +=============================
>> +
>> +Overview
>> +--------
>> +
>> +SoC platforms or subarchitectures follow all the rules from
>
> s/follow/should follow/?
Ack
>
>> +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?
Ack
> Also, to match the title case you used elsewhere, "Schema Compliance"?
Ack
>
>> +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."?
Ack
>
>> +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?
Makes sense, we could add such rule to Devicetree maintainer profile.
Anyway enforcing it relies on Rob's bot reporting the warnings, which
seems silent recently.
> 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@...rochip.com>
>
Best regards,
Krzysztof
Powered by blists - more mailing lists