- 23 Oct, 2019 4 commits
-
-
Krzysztof Kozlowski authored
Array elements under 'items' should be indented. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Rob Herring <robh@kernel.org>
-
Fabrizio Castro authored
Add PCIe support for the RZ/G2N (a.k.a. R8A774B1). Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Andrew Murray <andrew.murray@arm.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Fabrizio Castro authored
RZ/G2N (a.k.a. R8A774B1) watchdog implementation is compatible with R-Car Gen3, therefore add the relevant documentation. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
-
Rob Herring authored
Convert the Arm SMMv3 binding to the DT schema format. Cc: Joerg Roedel <joro@8bytes.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Cc: iommu@lists.linux-foundation.org Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
- 16 Oct, 2019 1 commit
-
-
Rob Herring authored
Convert the Arm SMMU binding to DT schema. The existing binding doc doesn't cover the number of variations of compatible properties found in .dts files. "qcom,msm8998-smmu-v2" was also missing, so add it. SoCFPGA Stratix10 has a single clock defined which doesn't match the binding. This issue remains. Cc: Joerg Roedel <joro@8bytes.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Robin Murphy <Robin.Murphy@arm.com> Cc: iommu@lists.linux-foundation.org Signed-off-by:
-
- 15 Oct, 2019 12 commits
-
-
Jeffrey Hugo authored
Convert the sharp,ld-d5116z01b panel binding to DT schema. Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by:
-
Alexandre Torgue authored
"companion" entry is present in "generic.txt" usb binding file. This commit adds it also in generic-ehci yaml binding. Signed-off-by:
Alexandre Torgue <alexandre.torgue@st.com> [robh: restrict type to phandle instead of phandle-array] Signed-off-by:
-
Alexandre Torgue authored
As there is only one item "st,syscfg" this commit moves phandle description fields under "description" tag. It'll fix a validation issue seen during stm32 DT check. Signed-off-by:
-
Alexandre Torgue authored
This commit documents missing STM32 boards: -STM32MCU: F429 disco/eval, F469-disco, F746 disco/eval, F769 disco, H743 disco/eval. -STM32MPU: MP157 dk1/dk2/ed1/ev1. Signed-off-by:
-
Biju Das authored
Document SoC specific bindings for RZ/G2N (r8a774b1) SoC. Signed-off-by:
Biju Das <biju.das@bp.renesas.com> Reviewed-by:
-
Biju Das authored
Document RZ/G2N (R8A774B1) SoC bindings. Signed-off-by:
-
Krzysztof Kozlowski authored
Make the examples in Exynos ADC bindings more readable and bring them closer to real DTS by using defines for clocks. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Include the generic rtc.yaml bindings in Samsung S3C RTC bindings. This brings the requirement of proper node names and adds parsing of additional properties. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Make the examples in S3C RTC bindings more readable and bring them closer to real DTS by using defines for clocks. Signed-off-by:
-
Krzysztof Kozlowski authored
Change the indentation of examples used in json-schema bindings from two to four spaces as this makes the code easier to read and seems to be preferred in other files. Signed-off-by:
-
Maxime Ripard authored
The older Allwinner SoCs have a PS2 controller that is supported in Linux, with a matching Device Tree binding. Now that we have the DT validation in place, let's convert the device tree bindings for that controller over to a YAML schemas. Signed-off-by:
Maxime Ripard <mripard@kernel.org> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Benjamin Gaignard authored
Convert the STM32 display binding to DT schema format using json-schema. Split the original bindings in two yaml files: - one for display controller (ltdc) - one for DSI controller Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> [robh: drop maxItems from phy-dsi-supply] Signed-off-by:
-
- 14 Oct, 2019 6 commits
-
-
Benjamin Gaignard authored
Convert the STM32 timer binding to DT schema format using json-schema Signed-off-by:
-
Benjamin Gaignard authored
Convert the STM32 thermal binding to DT schema format using json-schema Signed-off-by:
-
Benjamin Gaignard authored
Convert the STM32 dcmi binding to DT schema format using json-schema Signed-off-by:
-
Benjamin Gaignard authored
Convert the STM32 cec binding to DT schema format using json-schema Signed-off-by:
-
Benjamin Gaignard authored
Convert the STM32 hwspinlock binding to DT schema format using json-schema Signed-off-by:
-
Rob Herring authored
Regulator '*-supply' properties are always a single phandle, so 'maxItems: 1' or a $ref is not necessary. All that's needed is either 'true' or an optional 'description'. Following this clean-up, the meta-schema will enforce this pattern. There's one case in tree with 'innolux,n156bge-l21' having 2 phandles. This appears to be a mistake or abuse of simple-panel as it's 2 different voltage rails connected to 'power-supply'. Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-iio@vger.kernel.org Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Signed-off-by:
-
- 11 Oct, 2019 4 commits
-
-
Rob Herring authored
DT bindings are moving to using a json-schema based schema format instead of freeform text. Add a checkpatch.pl check to encourage using the schema for new bindings. It's not yet a requirement, but is progressively being required by some maintainers. Cc: Andy Whitcroft <apw@canonical.com> Cc: Joe Perches <joe@perches.com> Signed-off-by: -
Rob Herring authored
Fix the errors in the RiscV CPU DT schema: Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: 'timebase-frequency' is a required property Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@1: 'timebase-frequency' is a required property Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: compatible:0: 'riscv' is not one of ['sifive,rocket0', 'sifive,e5', 'sifive,e51', 'sifive,u54-mc', 'sifive,u54', 'sifive,u5'] Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: compatible: ['riscv'] is too short Documentation/devicetree/bindings/riscv/cpus.example.dt.yaml: cpu@0: 'timebase-frequency' is a required property The DT spec allows for 'timebase-frequency' to be in 'cpu' or 'cpus' node and RiscV requires it in /cpus node, so make it disallowed in cpu nodes. Fixes: 4fd669a8 ("dt-bindings: riscv: convert cpu binding to json-schema") Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: linux-riscv@lists.infradead.org Acked-by:
Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by:
-
Martin Kaiser authored
Move the native-mode setting inside the display-timing node. Outside of display-timing, it is ignored. Signed-off-by:
Martin Kaiser <martin@kaiser.cx> Signed-off-by:
-
Martin Kaiser authored
Move the native-mode setting inside the display-timing node. Outside of display-timing, it is ignored. Signed-off-by:
-
- 10 Oct, 2019 5 commits
-
-
Maciej Falkowski authored
Document clocks macros with their description from 'Documentation/devicetree/bindings/sound/samsung-i2s.txt' Signed-off-by:
Maciej Falkowski <m.falkowski@samsung.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
-
Simon Horman authored
Convert Real Time Clock for Renesas SH and ARM SoCs bindings documentation to json-schema. Also name bindings documentation file according to the compat string being documented. Also correct syntax error in interrupts field in example. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Ulrich Hecht <uli+renesas@fpond.eu> Acked-by:
-
Krzysztof Kozlowski authored
Convert Samsung Exynos Security SubSystem (SSS) and SlimSSS hardware crypto accelerator bindings to DT schema format using json-schema. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert Samsung Exynos SROM controller bindings to DT schema format using json-schema. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert Samsung Exynos Pseudo Random Number Generator bindings to DT schema format using json-schema. Signed-off-by:
-
- 09 Oct, 2019 3 commits
-
-
Bartosz Golaszewski authored
arch/arm/boot/dts/at91-dvk_som60.dt.yaml uses the compatible string 'giantec,gt24c32a' for an at24 EEPROM with a fallback to 'atmel,24c32'. Add this model as a special case to the binding document. Reported-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
-
Bartosz Golaszewski authored
Convert the binding document for at24 EEPROMs from txt to yaml. The compatible property uses a regex pattern to address all the possible combinations of "vendor,model" strings. Signed-off-by:
-
Robin Murphy authored
Since the "dma-ranges" property is only valid for a node representing a bus, of_dma_get_range() currently assumes the node passed in is a leaf representing a device, and starts the walk from its parent. In cases like PCI host controllers on typical FDT systems, however, where the PCI endpoints are probed dynamically the initial leaf node represents the 'bus' itself, and this logic means we fail to consider any "dma-ranges" describing the host bridge itself. Rework the logic such that of_dma_get_range() also works correctly starting from a bus node containing "dma-ranges". While this does mean "dma-ranges" could incorrectly be in a device leaf node, there isn't really any way in this function to ensure that a leaf node is or isn't a bus node. Signed-off-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by:
-
- 08 Oct, 2019 5 commits
-
-
Rob Herring authored
of_pci_range_parser_one() has a bug when parsing dma-ranges. When it translates the parent address (aka cpu address in the code), 'ranges' is always being used. This happens to work because most users are just 1:1 translation. Cc: Robin Murphy <robin.murphy@arm.com> Tested-by:
-
Rob Herring authored
'dma-ranges' frequently exists without parent nodes having 'dma-ranges'. While this is an error for 'ranges', this is fine because DMA capable devices always have a translatable DMA address. Also, with no 'dma-ranges' at all, the assumption is that DMA addresses are 1:1 with no restrictions unless perhaps the device itself has implicit restrictions. Cc: Robin Murphy <robin.murphy@arm.com> Tested-by:
-
Rob Herring authored
The functions for parsing 'dma-ranges' ranges are buggy and fail to handle several conditions. Add new tests for of_dma_get_range() and for_each_of_pci_range(). With this test, we get 5 new failures which are fixed in subsequent commits: OF: translation of DMA address(0) to CPU address failed node(/testcase-data/address-tests/device@70000000) FAIL of_unittest_dma_ranges_one():798 of_dma_get_range failed on node /testcase-data/address-tests/device@70000000 rc=-22 OF: translation of DMA address(10000000) to CPU address failed node(/testcase-data/address-tests/bus@80000000/device@1000) FAIL of_unittest_dma_ranges_one():798 of_dma_get_range failed on node /testcase-data/address-tests/bus@80000000/device@1000 rc=-22 OF: translation of DMA address(0) to CPU address failed node(/testcase-data/address-tests/pci@90000000) FAIL of_unittest_dma_ranges_one():798 of_dma_get_range failed on node /testcase-data/address-tests/pci@90000000 rc=-22 FAIL of_unittest_pci_dma_ranges():851 for_each_of_pci_range wrong CPU addr (d0000000) on node /testcase-data/address-tests/pci@90000000 FAIL of_unittest_pci_dma_ranges():861 for_each_of_pci_range wrong CPU addr (ffffffffffffffff) on node /testcase-data/address-tests/pci@90000000 Cc: Robin Murphy <robin.murphy@arm.com> Tested-by:
-
Robin Murphy authored
In some cases such as PCI host controllers, we may have a "parent bus" which is an OF leaf node, but still need to correctly parse ranges from the point of view of that bus. For that, factor out variants of the "#addr-cells" and "#size-cells" parsers which do not assume they have a device node and thus immediately traverse upwards before reading the relevant property. Signed-off-by:
-
Robin Murphy authored
Much like for address translation, when checking for DMA coherence we should be sure to walk up the DMA hierarchy, rather than the MMIO one, now that we can accommodate them being different. Signed-off-by:
-
