Skip to contentSkip to conversation

ASoC: dt-bindings: Correct interrupt flags in examples

PATCH In review Krzysztof Kozlowski 3 participants 3 messages Sep 8, 2020 – Sep 17, 2020

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ASoC: dt-bindings: Correct interrupt flags in examples

GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING

Correct the interrupt flags, assuming the author of the code wanted some logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_LEVEL_HIGH

---
 Documentation/devicetree/bindings/sound/max98090.txt | 2 +-
 Documentation/devicetree/bindings/sound/rt5640.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5659.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5665.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5668.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5677.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5682.txt   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)
Documentation/devicetree/bindings/sound/max98090.txt +1 -1
index 7e1bbd5c27fd..39d640294c62 100644
@@ -55,5 +55,5 @@ audio-codec@10 {
 	compatible = "maxim,max98090";
 	reg = <0x10>;
 	interrupt-parent = <&gpio>;
-	interrupts = <TEGRA_GPIO(H, 4) GPIO_ACTIVE_HIGH>;
+	interrupts = <TEGRA_GPIO(H, 4) IRQ_TYPE_LEVEL_HIGH>;
 };
Documentation/devicetree/bindings/sound/rt5640.txt +1 -1
index e40e4893eed8..ff1228713f7e 100644
@@ -88,7 +88,7 @@ rt5640 {
 	compatible = "realtek,rt5640";
 	reg = <0x1c>;
 	interrupt-parent = <&gpio>;
-	interrupts = <TEGRA_GPIO(W, 3) GPIO_ACTIVE_HIGH>;
+	interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_HIGH>;
 	realtek,ldo1-en-gpios =
 		<&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
 };
Documentation/devicetree/bindings/sound/rt5659.txt +1 -1
index 1766e0543fc5..56788f50b6cf 100644
@@ -72,7 +72,7 @@ rt5659 {
 	compatible = "realtek,rt5659";
 	reg = <0x1b>;
 	interrupt-parent = <&gpio>;
-	interrupts = <TEGRA_GPIO(W, 3) GPIO_ACTIVE_HIGH>;
+	interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_HIGH>;
 	realtek,ldo1-en-gpios =
 		<&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
 };
Documentation/devicetree/bindings/sound/rt5665.txt +1 -1
index 8df170506986..f6ca96b4ce98 100644
@@ -62,7 +62,7 @@ rt5659 {
 	compatible = "realtek,rt5665";
 	reg = <0x1b>;
 	interrupt-parent = <&gpio>;
-	interrupts = <TEGRA_GPIO(W, 3) GPIO_ACTIVE_HIGH>;
+	interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_HIGH>;
 	realtek,ldo1-en-gpios =
 		<&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
 };
Documentation/devicetree/bindings/sound/rt5668.txt +1 -1
index c88b96e7764b..a2b7e9a2f2f3 100644
@@ -41,7 +41,7 @@ rt5668 {
 	compatible = "realtek,rt5668b";
 	reg = <0x1a>;
 	interrupt-parent = <&gpio>;
-	interrupts = <TEGRA_GPIO(U, 6) GPIO_ACTIVE_HIGH>;
+	interrupts = <TEGRA_GPIO(U, 6) IRQ_TYPE_LEVEL_HIGH>;
 	realtek,ldo1-en-gpios =
 		<&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
 	realtek,dmic1-data-pin = <1>;
Documentation/devicetree/bindings/sound/rt5677.txt +1 -1
index 1b3c13d206ff..da2430099181 100644
@@ -64,7 +64,7 @@ rt5677 {
 	compatible = "realtek,rt5677";
 	reg = <0x2c>;
 	interrupt-parent = <&gpio>;
-	interrupts = <TEGRA_GPIO(W, 3) GPIO_ACTIVE_HIGH>;
+	interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_HIGH>;
 
 	gpio-controller;
 	#gpio-cells = <2>;
Documentation/devicetree/bindings/sound/rt5682.txt +1 -1
index ade1ece8b45f..707fa98d1310 100644
@@ -58,7 +58,7 @@ rt5682 {
 	compatible = "realtek,rt5682i";
 	reg = <0x1a>;
 	interrupt-parent = <&gpio>;
-	interrupts = <TEGRA_GPIO(U, 6) GPIO_ACTIVE_HIGH>;
+	interrupts = <TEGRA_GPIO(U, 6) IRQ_TYPE_LEVEL_HIGH>;
 	realtek,ldo1-en-gpios =
 		<&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
 	realtek,dmic1-data-pin = <1>;
Signature · 1 line
2.17.1
maintainer Acked-by on v1 1/1
#1 lore raw
Quoted 11 lines · Krzysztof Kozlowski

GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING

Correct the interrupt flags, assuming the author of the code wanted some logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_LEVEL_HIGH

Quoted 10 lines
---
 Documentation/devicetree/bindings/sound/max98090.txt | 2 +-
 Documentation/devicetree/bindings/sound/rt5640.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5659.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5665.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5668.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5677.txt   | 2 +-
 Documentation/devicetree/bindings/sound/rt5682.txt   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)
maintainer
#2 lore raw
In reply to Krzysztof Kozlowski
Quoted 9 lines · Krzysztof Kozlowski

GPIO_ACTIVE_x flags are not correct in the context of interrupt flags. These are simple defines so they could be used in DTS but they will not have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 = IRQ_TYPE_EDGE_RISING

Correct the interrupt flags, assuming the author of the code wanted some logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_LEVEL_HIGH

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: dt-bindings: Correct interrupt flags in examples

      commit: abe42b09118914f01246f880dd9029150fdc727c

All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying to this mail.

Thanks,
Mark