- 20 Jan, 2022 5 commits
-
-
Michael Walle authored
We can get rid of all the empty stubs because all these functions call of_property_read_variable_u{8,16,32,64}_array() which already have an empty stub if CONFIG_OF is not defined. Signed-off-by:Michael Walle <michael@walle.cc> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220118173504.2867523-3-michael@walle.cc
-
Michael Walle authored
Make all the smaller variants of the of_parse_phandle() static inline. This also let us remove the empty function stubs if CONFIG_OF is not defined. Suggested-by:
-
Rob Herring authored
The 'interrupts' properties takes an irq number, not a phandle, and 'interrupt-parent' isn't needed in examples. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220119015611.2442819-1-robh@kernel.org
-
Rob Herring authored
The YAML DT encoding has leaked into some array properties. Properties which are defined as an array should have a schema that's just an array. That means there should only be a single level of 'minItems', 'maxItems', and/or 'items'. Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20220119015627.2443334-1-robh@kernel.org
-
Rob Herring authored
For a single pinctrl mode, it is not necessary to define pinctrl properties as the tools always allow pinctrl properties. Signed-off-by:
Mark Brown <broonie@kernel.org> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20220119015325.2438277-1-robh@kernel.org
-
- 19 Jan, 2022 3 commits
-
-
Rob Herring authored
Each independent example should be a separate entry. This allows for 'interrupts' to have different cell sizes. Signed-off-by:
-
Rob Herring authored
Each independent example should be a separate entry. This and dropping 'interrupt-parent' allows for 'interrupts' to have different cell sizes. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220106182518.1435497-6-robh@kernel.org
-
Rob Herring authored
With 'unevaluatedProperties' support enabled, several SPI based display binding examples have warnings: Documentation/devicetree/bindings/display/panel/samsung,ld9040.example.dt.yaml: lcd@0: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'spi-max-frequency', 'spi-cpol', 'spi-cpha' were unexpected) Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.example.dt.yaml: panel@0: Unevaluated properties are not allowed ('spi-max-frequency', 'spi-3wire' were unexpected) Documentation/devicetree/bindings/display/panel/ilitek,ili9322.example.dt.yaml: display@0: Unevaluated properties are not allowed ('reg' was unexpected) Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.example.dt.yaml: display@0: Unevaluated properties are not allowed ('spi-max-frequency' was unexpected) Documentation/devicetree/bindings/display/panel/abt,y030xx067a.example.dt.yaml: panel@0: Unevaluated properties are not allowed ('spi-max-frequency' was unexpected) Documentation/devicetree/bindings/display/panel/sony,acx565akm.example.dt.yaml: panel@2: Unevaluated properties are not allowed ('spi-max-frequency', 'reg' were unexpected) Documentation/devicetree/bindings/display/panel/tpo,td.example.dt.yaml: panel@0: Unevaluated properties are not allowed ('spi-max-frequency', 'spi-cpol', 'spi-cpha' were unexpected) Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.example.dt.yaml: panel@0: Unevaluated properties are not allowed ('reg', 'spi-max-frequency', 'spi-cpol', 'spi-cpha' were unexpected) Documentation/devicetree/bindings/display/panel/innolux,ej030na.example.dt.yaml: panel@0: Unevaluated properties are not allowed ('spi-max-frequency' was unexpected) Documentation/devicetree/bindings/display/panel/sitronix,st7789v.example.dt.yaml: panel@0: Unevaluated properties are not allowed ('spi-max-frequency', 'spi-cpol', 'spi-cpha' were unexpected) Fix all of these by adding a reference to spi-peripheral-props.yaml. With this, the description that the binding must follow spi-controller.yaml is both a bit out of date and redundant, so remove it. Signed-off-by:Paul Cercueil <paul@crapouillou.net> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://lore.kernel.org/r/20211221125209.1195932-1-robh@kernel.org
-
- 17 Jan, 2022 9 commits
-
-
Matthias Schiffer authored
dtx_diff suggests to use <(...) syntax to pipe two inputs into it, but this has never worked: The /proc/self/fds/... paths passed by the shell will fail the `[ -f "${dtx}" ] && [ -r "${dtx}" ]` check in compile_to_dts, but even with this check removed, the function cannot work: hexdump will eat up the DTB magic, making the subsequent dtc call fail, as a pipe cannot be rewound. Simply remove this broken example, as there is already an alternative one that works fine. Fixes: 10eadc25 ("dtc: create tool to diff device trees") Signed-off-by:Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by:
Frank Rowand <frank.rowand@sony.com> Signed-off-by:
-
Stanislav Jakubek authored
Cleanup double spaces in some of the comments. Signed-off-by:
Stanislav Jakubek <stano.jakubek@gmail.com> Signed-off-by:
-
Stanislav Jakubek authored
sparkfun,qwiic-joystick and st,24c256 had their comments incorrectly swapped. Swap them to make them correct. Signed-off-by:
-
Stanislav Jakubek authored
The vendor prefix for Wingtech [1] is used in device tree [2], but was not documented so far. Add it to the schema to document it. [1] http://www.wingtech.com/en [2] arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts Signed-off-by:
-
Stanislav Jakubek authored
The vendor prefix for Thundercomm [1] is used in device tree [2], but was not documented so far. Add it to the schema to document it. [1] https://www.thundercomm.com/ [2] arch/arm64/boot/dts/qcom/sdm845-db845c.dts Signed-off-by:
-
Stanislav Jakubek authored
The vendor prefix for Huawei [1] is used in device trees [2][3], but was not documented so far. Add it to the schema to document it. [1] https://www.huawei.com/en/ [2] arch/arm64/boot/dts/qcom/msm8916-huawei-g7.dts [3] arch/arm64/boot/dts/qcom/msm8994-angler-rev-101.dts Signed-off-by:
-
Stanislav Jakubek authored
The vendor prefix for F(x)tec [1] is used in device tree [2], but was not documented so far. Add it to the schema to document it. [1] https://www.fxtec.com/ [2] arch/arm64/boot/dts/qcom/msm8998-fxtec-pro1.dts Signed-off-by:
-
Stanislav Jakubek authored
The vendor prefix for 8devices [1] is used in device tree [2], but was not documented so far. Add it to the schema to document it. [1] https://www.8devices.com/ [2] arch/arm/boot/dts/qcom-ipq4018-jalapeno.dts Signed-off-by:
-
Sander Vanheule authored
Commit bcd56fe1 ("power: reset: gpio-restart: increase priority slightly") changed the default restart priority 129, but did not update the documentation. Correct this, so the driver and documentation have the same default value. Signed-off-by:
Sander Vanheule <sander@svanheule.net> Reviewed-by:
-
- 12 Jan, 2022 2 commits
-
-
Rob Herring authored
Pick a fix which didn't make it into v5.16.
-
Rob Herring authored
resets/reset-names are device specific and don't belong in the MDIO bus schema. For example, it doesn't match what is defined for the "qca,ar9331-switch" binding which defines "reset-names" to be "switch" rather than "phy". Neither name is that useful IMO. Other child properties are also device specific, but those won't conflict with device schemas. Signed-off-by:
-
- 11 Jan, 2022 19 commits
-
-
Krzysztof Kozlowski authored
Convert Samsung S5Pv210 SoC clock controller bindings to DT schema format. Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Convert Samsung Exynos5410 SoC clock controller bindings to DT schema format. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert Samsung Exynos5260 SoC clock controller bindings to DT schema format. Signed-off-by:
-
Krzysztof Kozlowski authored
The UFS for Exynos7 SoC clock controller requires additional input clocks for the FSYS1 clock controller. Update the bindings to reflect this, at least in theory. In practice, these input clocks are ignored, so it is rather adjusting of bindings to existing DTS, without affecting any real users. I understand that is not how it should be done, though... Signed-off-by:
-
Krzysztof Kozlowski authored
Convert Samsung Exynos7 SoC clock controller bindings to DT schema format. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert Samsung Exynos5433 SoC clock controller bindings to DT schema format. Signed-off-by:
-
Niklas Söderlund authored
Add bindings for Maxim Integrated MAX96712 deserializer. The MAX96712 deserializer converts GMSL2 or GMSL1 serial inputs into MIPI CSI-2 D-PHY or C-PHY formatted outputs. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Rob Herring authored
The '/bits/ 64' notation applies the next <> list of values. Another <> list is encoded as 32-bits by default. IOW, each <> list needs to be preceeded with '/bits/ 64'. While the dts format allows this, as a rule we don't mix sizes for DT properties since all size information is lost in the dtb file. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220107032026.2408196-1-robh@kernel.org
-
Rob Herring authored
The 'maxim,rcomp' is defined as a uint32, but the description and users all say it is uint8-array with 1 or 2 elements. The tools missed checking this case. Signed-off-by:
-
Rob Herring authored
The 2nd example has an interrupts cells size of 4, but the 'interrupts' property has 3 cells. The example should also be separate since the cell size differs in each example. Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220106182518.1435497-5-robh@kernel.org
-
Rob Herring authored
'interrupts' does not take a phandle, so remove it in the example. Signed-off-by:
-
Rob Herring authored
The example nodes have different sized interrupt cells which is not valid given no interrupt-parent is specified. As provider examples don't need to show the consumer side in the first place, just drop the consumer node. Signed-off-by:
-
Rob Herring authored
'interrupt-parent' is never required as it can be in a parent node or a parent node itself can be an interrupt provider. Where exactly it lives is outside the scope of a binding schema. Signed-off-by:
Lee Jones <lee.jones@linaro.org> Acked-by:
Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220107031905.2406176-1-robh@kernel.org
-
Rob Herring authored
DT booleans don't have a value and 'ti,max-output-impedance' is defined and used as a boolean. So drop the bogus value in the example. Signed-off-by:
-
Rob Herring authored
The '/bits/ 8' notation applies the next <> list of values. Another <> list is encoded as 32-bits by default. IOW, each <> list needs to be preceeded with '/bits/ 8'. While the dts format allows this, as a rule we don't mix sizes for DT properties since all size information is lost in the dtb file. Signed-off-by:
-
Rob Herring authored
'max-functions' is already defined in pci-ep.yaml schema as a uint8 and all users of it expect an uint8. Drop the conflicting schema. Signed-off-by:
-
Rob Herring authored
Each independent example should be a separate entry. This allows for 'interrupts' to have different cell sizes. Signed-off-by:
-
Rob Herring authored
Each independent example should be a separate entry. This allows for 'interrupts' to have different cell sizes. The first example also has a phandle in 'interrupts', so drop the phandle. Signed-off-by:
-
Rob Herring authored
The schemas for MDIO bus nodes range from missing to duplicating everything in mdio.yaml. The MDIO bus node schemas only need to reference mdio.yaml, define any binding specific properties, and define 'unevaluatedProperties: false'. This ensures that MDIO nodes only contain defined properties. With this, any duplicated properties can be removed. Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Vivien Didelot <vivien.didelot@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Vladimir Oltean <olteanv@gmail.com> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Cc: Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Cc: "Fernández Rojas" <noltari@gmail.com> Cc: John Crispin <john@phrozen.org> Cc: "G. Jaya Kumaran" <vineetha.g.jaya.kumaran@intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Joel Stanley <joel@jms.id.au> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Jose Abreu <joabreu@synopsys.com> Cc: netdev@vger.kernel.org Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220105151009.3093506-1-robh@kernel.org
-
- 10 Jan, 2022 2 commits
-
-
Rob Herring authored
With 'unevaluatedProperties' support implemented, the following warnings are generated in the net bindings: Documentation/devicetree/bindings/net/qca,ar71xx.example.dt.yaml: ethernet@19000000: Unevaluated properties are not allowed ('qca,ethcfg' was unexpected) Documentation/devicetree/bindings/net/stm32-dwmac.example.dt.yaml: ethernet@40028000: Unevaluated properties are not allowed ('reg-names', 'snps,pbl' were unexpected) Documentation/devicetree/bindings/net/ti,cpsw-switch.example.dt.yaml: mdio@1000: Unevaluated properties are not allowed ('clocks', 'clock-names' were unexpected) Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.example.dt.yaml: mdio@f00: Unevaluated properties are not allowed ('clocks', 'clock-names' were unexpected) Add the missing properties/nodes as necessary. Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: "Andreas Färber" <afaerber@suse.de> Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Cc: Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Cc: "G. Jaya Kumaran" <vineetha.g.jaya.kumaran@intel.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Christophe Roullier <christophe.roullier@foss.st.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: netdev@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-actions@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Signed-off-by: -
Rob Herring authored
With 'unevaluatedProperties' support implemented, the properties 'snps,pbl', 'snps,txpbl', and 'snps,rxpbl' are not allowed in the examples for some of the DWMAC versions: Documentation/devicetree/bindings/net/intel,dwmac-plat.example.dt.yaml: ethernet@3a000000: Unevaluated properties are not allowed ('snps,pbl', 'mdio0' were unexpected) Documentation/devicetree/bindings/net/stm32-dwmac.example.dt.yaml: ethernet@5800a000: Unevaluated properties are not allowed ('reg-names', 'snps,pbl' were unexpected) Documentation/devicetree/bindings/net/stm32-dwmac.example.dt.yaml: ethernet@40028000: Unevaluated properties are not allowed ('reg-names', 'snps,pbl' were unexpected) Documentation/devicetree/bindings/net/stm32-dwmac.example.dt.yaml: ethernet@40027000: Unevaluated properties are not allowed ('reg-names', 'snps,pbl' were unexpected) Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.example.dt.yaml: ethernet@28000000: Unevaluated properties are not allowed ('snps,txpbl', 'snps,rxpbl', 'mdio0' were unexpected) This appears to be an oversight, so fix it by allowing the properties on the v3.50a, v4.10a, and v4.20a versions of the DWMAC. Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Jose Abreu <joabreu@synopsys.com> Cc: netdev@vger.kernel.org Signed-off-by:Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20211206174147.2296770-1-robh@kernel.org
-
