f1b518b45d
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. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230723131924.78190-2-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
26 lines
977 B
ReStructuredText
26 lines
977 B
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
==============================================
|
|
SoC Platforms with DTS Compliance Requirements
|
|
==============================================
|
|
|
|
Overview
|
|
--------
|
|
|
|
SoC platforms or subarchitectures should follow all the rules from
|
|
Documentation/process/maintainer-soc.rst. This document referenced in
|
|
MAINTAINERS impose additional requirements listed below.
|
|
|
|
Strict DTS DT Schema and dtc Compliance
|
|
---------------------------------------
|
|
|
|
No changes to the SoC platform Devicetree sources (DTS files) should introduce
|
|
new ``make dtbs_check W=1`` warnings. Warnings in a new board DTS, which are
|
|
results of issues in an included DTSI file, are considered existing, not new
|
|
warnings. The platform maintainers have automation in place which should point
|
|
out any new warnings.
|
|
|
|
If a commit introducing new warnings gets accepted somehow, the resulting
|
|
issues shall be fixed in reasonable time (e.g. within one release) or the
|
|
commit reverted.
|