arm64: dts: tegra: Fix boolean properties with values
Subsystems (2)
Rob Herring
maintainerPATCH RESEND 1/1 arm64: dts: tegra: Fix boolean properties with values
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter.
It may have been intended that 0 values are false, but there is no change in behavior with this patch.
---
Can someone apply this for 5.18.
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 8 ++++---- .../boot/dts/nvidia/tegra186-p3509-0000+p3636-0001.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 4 ++-- 8 files changed, 27 insertions(+), 27 deletions(-)
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi +4 -4
@@ -262,25 +262,25 @@ gpio3 { gpio4 { pins = "gpio4"; function = "32k-out1"; - drive-push-pull = <1>; + drive-push-pull; }; gpio5 { pins = "gpio5"; function = "gpio"; - drive-push-pull = <0>; + drive-push-pull; }; gpio6 { pins = "gpio6"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; gpio7 { pins = "gpio7"; function = "gpio"; - drive-push-pull = <0>; + drive-push-pull; }; };
arch/arm64/boot/dts/nvidia/tegra186-p3509-0000+p3636-0001.dts +4 -4
@@ -462,25 +462,25 @@ gpio3 { gpio4 { pins = "gpio4"; function = "32k-out1"; - drive-push-pull = <1>; + drive-push-pull; }; gpio5 { pins = "gpio5"; function = "gpio"; - drive-push-pull = <0>; + drive-push-pull; }; gpio6 { pins = "gpio6"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; gpio7 { pins = "gpio7"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; };
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi +3 -3
@@ -174,19 +174,19 @@ gpio3 { gpio4 { pins = "gpio4"; function = "32k-out1"; - drive-push-pull = <1>; + drive-push-pull; }; gpio6 { pins = "gpio6"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; gpio7 { pins = "gpio7"; function = "gpio"; - drive-push-pull = <0>; + drive-push-pull; }; };
arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi +3 -3
@@ -148,19 +148,19 @@ gpio3 { gpio4 { pins = "gpio4"; function = "32k-out1"; - drive-push-pull = <1>; + drive-push-pull; }; gpio6 { pins = "gpio6"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; gpio7 { pins = "gpio7"; function = "gpio"; - drive-push-pull = <0>; + drive-push-pull; }; };
arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi +3 -3
@@ -59,7 +59,7 @@ gpio0 { gpio1 { pins = "gpio1"; function = "fps-out"; - drive-push-pull = <1>; + drive-push-pull; maxim,active-fps-source = <MAX77620_FPS_SRC_0>; maxim,active-fps-power-up-slot = <7>; maxim,active-fps-power-down-slot = <0>;
@@ -68,7 +68,7 @@ gpio1 { gpio2_3 { pins = "gpio2", "gpio3"; function = "fps-out"; - drive-open-drain = <1>; + drive-open-drain; maxim,active-fps-source = <MAX77620_FPS_SRC_0>; };
@@ -80,7 +80,7 @@ gpio4 { gpio5_6_7 { pins = "gpio5", "gpio6", "gpio7"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; };
arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi +4 -4
@@ -1351,7 +1351,7 @@ gpio0 { gpio1 { pins = "gpio1"; function = "fps-out"; - drive-push-pull = <1>; + drive-push-pull; maxim,active-fps-source = <MAX77620_FPS_SRC_0>; maxim,active-fps-power-up-slot = <7>; maxim,active-fps-power-down-slot = <0>;
@@ -1360,14 +1360,14 @@ gpio1 { gpio2 { pins = "gpio2"; function = "fps-out"; - drive-open-drain = <1>; + drive-open-drain; maxim,active-fps-source = <MAX77620_FPS_SRC_0>; }; gpio3 { pins = "gpio3"; function = "fps-out"; - drive-open-drain = <1>; + drive-open-drain; maxim,active-fps-source = <MAX77620_FPS_SRC_0>; };
@@ -1379,7 +1379,7 @@ gpio4 { gpio5_6_7 { pins = "gpio5", "gpio6", "gpio7"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; };
arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts +4 -4
@@ -195,7 +195,7 @@ gpio0 { gpio1 { pins = "gpio1"; function = "fps-out"; - drive-push-pull = <1>; + drive-push-pull; maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; maxim,active-fps-power-up-slot = <0>; maxim,active-fps-power-down-slot = <7>;
@@ -204,7 +204,7 @@ gpio1 { gpio2 { pins = "gpio2"; function = "fps-out"; - drive-open-drain = <1>; + drive-open-drain; maxim,active-fps-source = <MAX77620_FPS_SRC_0>; maxim,active-fps-power-up-slot = <0>; maxim,active-fps-power-down-slot = <7>;
@@ -213,7 +213,7 @@ gpio2 { gpio3 { pins = "gpio3"; function = "fps-out"; - drive-open-drain = <1>; + drive-open-drain; maxim,active-fps-source = <MAX77620_FPS_SRC_0>; maxim,active-fps-power-up-slot = <4>; maxim,active-fps-power-down-slot = <3>;
@@ -227,7 +227,7 @@ gpio4 { gpio5_6_7 { pins = "gpio5", "gpio6", "gpio7"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; };
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts +2 -2
@@ -1386,7 +1386,7 @@ gpio0_1_2_7 { gpio3 { pins = "gpio3"; function = "fps-out"; - drive-open-drain = <1>; + drive-open-drain; maxim,active-fps-source = <MAX77620_FPS_SRC_0>; maxim,active-fps-power-up-slot = <4>; maxim,active-fps-power-down-slot = <2>;
@@ -1395,7 +1395,7 @@ gpio3 { gpio5_6 { pins = "gpio5", "gpio6"; function = "gpio"; - drive-push-pull = <1>; + drive-push-pull; }; gpio4 {
Signature · 1 line
2.32.0
This patch was applied to soc/soc.git (arm/fixes) by Arnd Bergmann <[email protected]>:
Hello:
This patch was applied to soc/soc.git (arm/fixes)
by Arnd Bergmann <[email protected]>:
Quoted 8 lines · On Wed, 6 Apr 2022 14:17:30 -0500 you wrote:
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter.
It may have been intended that 0 values are false, but there is no change in behavior with this patch.
[...]
Here is the summary with links:
- [RESEND] arm64: dts: tegra: Fix boolean properties with values
https://git.kernel.org/soc/soc/c/1a67653de0dd
You are awesome, thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Quoted 11 lines · Rob Herring
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter.
It may have been intended that 0 values are false, but there is no change in behavior with this patch.
Signed-off-by Rob Herring <[email protected]>---
Can someone apply this for 5.18.
Quoted 9 lines
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 8 ++++---- .../boot/dts/nvidia/tegra186-p3509-0000+p3636-0001.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 4 ++-- 8 files changed, 27 insertions(+), 27 deletions(-)
This causes multiple regressions on Tegra boards. The reason for this is that these properties are not in fact boolean, despite what the DT bindings say. If you look at the code that handles these, you'll notice that they are single-cell properties, typically with <0> and <1> values. What may have led to the conclusion that these are boolean is that there is also a special case where these can be left out, but the meaning of that is not the "false" (<0>) value. Instead, leaving these out means that the values should be left at whatever is currently in the register.
See pinconf_generic_parse_dt_config() and parse_dt_cfg() specifically in drivers/pinctrl/pinconf-generic.c.
Arnd, can you please revert this so that these boards can be unbroken?
It's a bit unfortunate because there seem to be other platforms that also employ these in the boolean form that Rob mentioned, but I think it is those that probably need fixing instead. Not sure what the intentions were for those.
Adding Bjorn for MSM, the Nuvoton and STM32 folks.
Thierry
Jon Hunter
maintainerQuoted 31 lines · Thierry Reding
Quoted 11 lines · Rob Herring
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter.
It may have been intended that 0 values are false, but there is no change in behavior with this patch.
Signed-off-by Rob Herring <[email protected]>---
Can someone apply this for 5.18.Quoted 9 lines
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 8 ++++---- .../boot/dts/nvidia/tegra186-p3509-0000+p3636-0001.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 4 ++-- 8 files changed, 27 insertions(+), 27 deletions(-)This causes multiple regressions on Tegra boards. The reason for this is that these properties are not in fact boolean, despite what the DT bindings say. If you look at the code that handles these, you'll notice that they are single-cell properties, typically with <0> and <1> values. What may have led to the conclusion that these are boolean is that there is also a special case where these can be left out, but the meaning of that is not the "false" (<0>) value. Instead, leaving these out means that the values should be left at whatever is currently in the register.
Quoted 4 lines
See
pinconf_generic_parse_dt_config()andparse_dt_cfg()specifically indrivers/pinctrl/pinconf-generic.c.Arnd, can you please revert this so that these boards can be unbroken?
Arnd, any feedback on this? A lot of Tegra boards are still not booting with v5.18-rc4.
Jon
Signature · 1 line
nvpublic
Quoted 32 lines · Jon Hunter
Quoted 31 lines · Thierry Reding
Quoted 11 lines · Rob Herring
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter.
It may have been intended that 0 values are false, but there is no change in behavior with this patch.
Signed-off-by Rob Herring <[email protected]>---
Can someone apply this for 5.18.Quoted 9 lines
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 8 ++++---- .../boot/dts/nvidia/tegra186-p3509-0000+p3636-0001.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 4 ++-- 8 files changed, 27 insertions(+), 27 deletions(-)This causes multiple regressions on Tegra boards. The reason for this is that these properties are not in fact boolean, despite what the DT bindings say. If you look at the code that handles these, you'll notice that they are single-cell properties, typically with <0> and <1> values. What may have led to the conclusion that these are boolean is that there is also a special case where these can be left out, but the meaning of that is not the "false" (<0>) value. Instead, leaving these out means that the values should be left at whatever is currently in the register.
Quoted 8 lines
Quoted 4 lines
See
pinconf_generic_parse_dt_config()andparse_dt_cfg()specifically indrivers/pinctrl/pinconf-generic.c.Arnd, can you please revert this so that these boards can be unbroken?
Arnd, any feedback on this? A lot of Tegra boards are still not booting with v5.18-rc4.
I have reverted this commit now, sorry for missing the earlier report.
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=arm/fixes
Quoted 1 line
Quoted 1 line
Adding Bjorn for MSM, the Nuvoton and STM32 folks.
I'll wait for the others to reply, but I do agree that these are likely broken as well. Could one of you propose a patch to make the binding describe what the kernel code actually expects here?
Arnd
Rob Herring
maintainerQuoted 22 lines · Thierry Reding
Quoted 11 lines · Rob Herring
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter.
It may have been intended that 0 values are false, but there is no change in behavior with this patch.
Signed-off-by Rob Herring <[email protected]>---
Can someone apply this for 5.18.Quoted 9 lines
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 8 ++++---- .../boot/dts/nvidia/tegra186-p3509-0000+p3636-0001.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 6 +++--- arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 8 ++++---- arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 4 ++-- 8 files changed, 27 insertions(+), 27 deletions(-)
Quoted 8 lines
This causes multiple regressions on Tegra boards. The reason for this is that these properties are not in fact boolean, despite what the DT bindings say. If you look at the code that handles these, you'll notice that they are single-cell properties, typically with <0> and <1> values. What may have led to the conclusion that these are boolean is that there is also a special case where these can be left out, but the meaning of that is not the "false" (<0>) value. Instead, leaving these out means that the values should be left at whatever is currently in the register.
The majority of users do use boolean in their DT.
Treating these as tri-state doesn't make much sense because what does setting the pin to !push-pull mean? Isn't that just open-drain or open-source for which also have boolean values? Allowing these to have values is unnecessary and enables more invalid combinations.
Quoted 2 lines
See
pinconf_generic_parse_dt_config()andparse_dt_cfg()specifically indrivers/pinctrl/pinconf-generic.c.
of_property_read_u32() will return -EOVERFLOW on a boolean value and then the default value (0) is used. However, at least for QCom the value is ignored.
Looking at max77620, the value is used. However, it is clear that push-pull and open-drain operate on the same register bit.
Quoted 1 line
Arnd, can you please revert this so that these boards can be unbroken?
That's fine for now...
Quoted 4 lines
It's a bit unfortunate because there seem to be other platforms that also employ these in the boolean form that Rob mentioned, but I think it is those that probably need fixing instead. Not sure what the intentions were for those.
I still think it's Tegra that needs fixing. The question is to what extent forwards and backwards compatibity is needed on these platforms? I'm not sure if we can fix new dtb with old kernel. A new dtb with a stable kernel update would be plausible. It may work just replacing 'drive-push-pull = <0>' cases with 'drive-open-drain'.
Rob