Mention the usage of YAML coding style. Describe explicitly that
four-space indentation in DTS examples is preferred, because:
1. The YAML's default two-space indentation for DTS code makes it
significantly less readable.
2. Linux coding style tabs would introduce inconsistency (entire file is
indented with spaces).
3. On the other hand, eight spaces would not align with example's
opening ' - |' part. Four spaces makes the code nicely aligned with
it.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220403081849.8051-2-krzysztof.kozlowski@linaro.org
Switch the DT validation to use DTB files directly instead of a DTS to
YAML conversion.
The original motivation for supporting validation on DTB files was to
enable running validation on a running system (e.g. 'dt-validate
/sys/firmware/fdt') or other cases where the original source DTS is not
available.
The YAML format was not without issues. Using DTBs with the schema type
information solves some of those problems. The YAML format relies on the
DTS source level information including bracketing of properties, size
directives, and phandle tags all of which are lost in a DTB file. While
standardizing the bracketing is a good thing, it does cause a lot of
extra warnings and churn to fix them.
Another issue has been signed types are not validated correctly as sign
information is not propagated to YAML. Using the schema type information
allows for proper handling of signed types. YAML also can't represent
the full range of 64-bit integers as numbers are stored as floats by
most/all parsers.
The DTB validation works by decoding property values using the type
information in the schemas themselves. The main corner case this does
not work for is matrix types where neither dimension is fixed. For
now, checking the dimensions in these cases are skipped.
Signed-off-by: Rob Herring <robh@kernel.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20220310160513.1708182-3-robh@kernel.org
DT_SCHEMA_FILES is currently restricted to a list of exact files with
the full source tree path (i.e. Documentation/devicetree/bindings/...).
Loosen this requirement and let DT_SCHEMA_FILES be a partial match.
With this, checking all schema files in a directory is possible:
$ make DT_SCHEMA_FILES=/gpio/ dt_binding_check
Or all schema files with 'qcom' in the path or filename:
$ make DT_SCHEMA_FILES=qcom dt_binding_check
Cc: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20220228201006.1484903-1-robh@kernel.org
Installing dtschema from github.com/devicetree-org is not needed anymore
because dtschema is now part of regular PyPI repository. In certain
cases it might cause some troubles as it brings latest master version,
not the stable release:
$ pip3 show dtschema
Version: 2020.8.2.dev4+g341f3e3
$ make dt_binding_check
dtschema minimum version is v2020.8.1
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220223073547.8746-1-krzysztof.kozlowski@canonical.com
The DT docs are currently all just lumped together in the doc build.
Let's organize the documents by kernel specifics, overlays and bindings.
As writing-schema.rst is about bindings, let's move it to the bindings
directory.
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210325164713.1296407-6-robh@kernel.org
