ARM: tegra: paz00: use software nodes to describe GPIOs for WiFi rfkill

PATCH Applied Dmitry Torokhov 4 participants 7 messages Jun 27, 2024 – Feb 23

Subsystems (3)

Arm (32-bit) Arm sub-architectures Tegra architecture support

lore

Share & tools

lore

Dmitry Torokhov

author

2024-06-27 04:46 UTC #0 lore raw

PATCH 1/1 ARM: tegra: paz00: use software nodes to describe GPIOs for WiFi rfkill

Complete conversion of the WiFi rfkill device to use device properties/software nodes by utilizing PROPERTY_ENTRY_GPIO() instead of a lookup table.

Signed-off-by Dmitry Torokhov <[email protected]>

---

Compiled only, no real hardware to test.

 arch/arm/mach-tegra/board-paz00.c | 50 ++++++++++++++++++++-----------
 1 file changed, 32 insertions(+), 18 deletions(-)

arch/arm/mach-tegra/board-paz00.c +32 ~~-18~~

index 18d37f90cdfe..3ec810b6f1a7 100644
@@ -8,35 +8,49 @@
  * Copyright (C) 2010 Google, Inc.
  */
 
-#include <linux/property.h>
+#include <linux/err.h>
 #include <linux/gpio/machine.h>
+#include <linux/gpio/property.h>
 #include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/property.h>
 
 #include "board.h"
 
-static struct property_entry wifi_rfkill_prop[] __initdata = {
-	PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
-	PROPERTY_ENTRY_STRING("type", "wlan"),
-	{ },
+static const struct software_node tegra_gpiochip_node = {
+	.name	= "tegra-gpio",
 };
 
-static struct platform_device wifi_rfkill_device = {
-	.name	= "rfkill_gpio",
-	.id	= -1,
+static const struct property_entry wifi_rfkill_prop[] __initconst = {
+	PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
+	PROPERTY_ENTRY_STRING("type", "wlan"),
+	PROPERTY_ENTRY_GPIO("reset-gpios",
+			    &tegra_gpiochip_node, 25, GPIO_ACTIVE_HIGH),
+	PROPERTY_ENTRY_GPIO("shutdown-gpios",
+			    &tegra_gpiochip_node, 85, GPIO_ACTIVE_HIGH),
+	{ }
 };
 
-static struct gpiod_lookup_table wifi_gpio_lookup = {
-	.dev_id = "rfkill_gpio",
-	.table = {
-		GPIO_LOOKUP("tegra-gpio", 25, "reset", 0),
-		GPIO_LOOKUP("tegra-gpio", 85, "shutdown", 0),
-		{ },
-	},
+static const struct platform_device_info wifi_rfkill_info __initconst = {
+	.name		= "rfkill_gpio",
+	.id		= PLATFORM_DEVID_NONE,
+	.properties	= wifi_rfkill_prop,
 };
 
 void __init tegra_paz00_wifikill_init(void)
 {
-	device_create_managed_software_node(&wifi_rfkill_device.dev, wifi_rfkill_prop, NULL);
-	gpiod_add_lookup_table(&wifi_gpio_lookup);
-	platform_device_register(&wifi_rfkill_device);
+	struct platform_device *pd;
+	int err;
+
+	err = software_node_register(&tegra_gpiochip_node);
+	if (err) {
+		pr_err("failed to register %s node: %d\n",
+		       tegra_gpiochip_node.name, err);
+		return;
+	}
+
+	pd = platform_device_register_full(&wifi_rfkill_info);
+	err = PTR_ERR_OR_ZERO(pd);
+	if (err)
+		pr_err("failed to register WiFi rfkill device: %d\n", err);
 }

Signature · 5 lines

2.45.2.741.gdbec12cfda-goog


-- 
Dmitry

Thierry Reding

Applied

2024-06-28 15:35 UTC #1 lore raw

From: Thierry Reding <[email protected]>

Quoted 5 lines · Dmitry Torokhov

Complete conversion of the WiFi rfkill device to use device properties/software nodes by utilizing PROPERTY_ENTRY_GPIO() instead of a lookup table.

Applied, thanks!

[1/1] ARM: tegra: paz00: use software nodes to describe GPIOs for WiFi rfkill

      commit: 47ac458bb229f8c4864081d173adbcfc55c34880

Best regards,

Signature · 1 line

Thierry Reding <[email protected]>

Dmitry Torokhov

author

2026-02-12 03:22 UTC #2 lore raw

Hi Thierry,

Quoted 10 lines · Thierry Reding

From: Thierry Reding <[email protected]>
Quoted 5 lines · Dmitry Torokhov
Complete conversion of the WiFi rfkill device to use device properties/software nodes by utilizing PROPERTY_ENTRY_GPIO() instead of a lookup table.

Quoted 4 lines

Applied, thanks!
[1/1] ARM: tegra: paz00: use software nodes to describe GPIOs for WiFi rfkill
      commit: 47ac458bb229f8c4864081d173adbcfc55c34880

Do you know by any chance why paz00 does not simply configure rfkill switch via device tree? The driver (rfkill-gpio) seem to support device tree...

Thanks.

Signature · 1 line

Dmitry

Marc Dietrich

2026-02-14 14:27 UTC #3 lore raw

Hi Dimitry,

Quoted 13 lines · Dmitry Torokhov

Hi Thierry,
Quoted 10 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Quoted 5 lines · Dmitry Torokhov
Complete conversion of the WiFi rfkill device to use device properties/software nodes by utilizing PROPERTY_ENTRY_GPIO() instead of a lookup table.

Quoted 8 lines

Quoted 4 lines
Applied, thanks!
[1/1] ARM: tegra: paz00: use software nodes to describe GPIOs for WiFi rfkill
      commit: 47ac458bb229f8c4864081d173adbcfc55c34880
Do you know by any chance why paz00 does not simply configure rfkill switch via device tree? The driver (rfkill-gpio) seem to support device tree...

last time I tried this was rejected because the wifi chip is on the usb bus and "rfkill" should be a sub-function of this chip [1], but that was some time ago...

Looking hard the schematics, the wifi chip does not have a gpio input as first thought. Rather it seems that the first gpio toggles a regulator which supplies the wifi module (m2 card) with power and the second gpio is just connected to the wifi LED.

Not sure how to transfer this into dt, but I guess this would be the better solution.

Marc

[1]
https://linux-tegra.vger.kernel.narkive.com/hRFke8jh/patch-1-3-net-rfkill-gpio-add-device-tree-support

Chen-Yu Tsai

2026-02-14 14:49 UTC #4 lore raw

Quoted 31 lines · Marc Dietrich

Hi Dimitry,
Quoted 13 lines · Dmitry Torokhov
Hi Thierry,
Quoted 10 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Quoted 5 lines · Dmitry Torokhov
Complete conversion of the WiFi rfkill device to use device properties/software nodes by utilizing PROPERTY_ENTRY_GPIO() instead of a lookup table.
Quoted 8 lines
Quoted 4 lines
Applied, thanks!
[1/1] ARM: tegra: paz00: use software nodes to describe GPIOs for WiFi rfkill
      commit: 47ac458bb229f8c4864081d173adbcfc55c34880
Do you know by any chance why paz00 does not simply configure rfkill switch via device tree? The driver (rfkill-gpio) seem to support device tree...
last time I tried this was rejected because the wifi chip is on the usb bus and "rfkill" should be a sub-function of this chip [1], but that was some time ago...

Quoted 7 lines

Looking hard the schematics, the wifi chip does not have a gpio input as first thought. Rather it seems that the first gpio toggles a regulator which supplies the wifi module (m2 card) with power and the second gpio is just connected to the wifi LED.
Not sure how to transfer this into dt, but I guess this would be the better solution.

Then the first GPIO should probably just be described as a fixed regulator feeding the USB controller that the M.2 module is connected to.

There's also a WIP M.2 E-key binding and driver, but AFAIK that doesn't actually implement USB support.

The second one could be just a GPIO-driver LED with a netdev trigger?

ChenYu

Quoted 5 lines

Marc
[1]
https://linux-tegra.vger.kernel.narkive.com/hRFke8jh/patch-1-3-net-rfkill-gpio-add-device-tree-support

Marc Dietrich

2026-02-14 20:40 UTC #5 lore raw

Hallo Chen-Yu,

Quoted 37 lines · Chen-Yu Tsai

Quoted 36 lines · Marc Dietrich
Hi Dimitry,
Quoted 13 lines · Dmitry Torokhov
Hi Thierry,
Quoted 10 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Quoted 5 lines · Dmitry Torokhov
Complete conversion of the WiFi rfkill device to use device properties/software nodes by utilizing PROPERTY_ENTRY_GPIO() instead of a lookup table.
Quoted 8 lines
Quoted 4 lines
Applied, thanks!
[1/1] ARM: tegra: paz00: use software nodes to describe GPIOs for WiFi rfkill
      commit: 47ac458bb229f8c4864081d173adbcfc55c34880
Do you know by any chance why paz00 does not simply configure rfkill switch via device tree? The driver (rfkill-gpio) seem to support device tree...
last time I tried this was rejected because the wifi chip is on the usb bus and "rfkill" should be a sub-function of this chip [1], but that was some time ago...
Looking hard the schematics, the wifi chip does not have a gpio input as first thought. Rather it seems that the first gpio toggles a regulator which supplies the wifi module (m2 card) with power and the second gpio is just connected to the wifi LED.

Quoted 5 lines

Quoted 2 lines
Not sure how to transfer this into dt, but I guess this would be the better solution.
Then the first GPIO should probably just be described as a fixed regulator feeding the USB controller that the M.2 module is connected to.

I think that is what rfkill-gpio is for, so the proposal of Dimitry looks fine, execpt for the reset-gpio, aka LED which is already included in the dt (but maybe with the wrong gpio).

I will give it a try on real HW and report back.

Thanks!

Marc

Chen-Yu Tsai

2026-02-23 09:27 UTC #6 lore raw

Quoted 45 lines · Marc Dietrich

Hallo Chen-Yu,
Quoted 40 lines · Chen-Yu Tsai
Quoted 38 lines · Marc Dietrich
Hi Dimitry,
Quoted 13 lines · Dmitry Torokhov
Hi Thierry,
Quoted 10 lines · Thierry Reding
From: Thierry Reding <[email protected]>
Quoted 5 lines · Dmitry Torokhov
Complete conversion of the WiFi rfkill device to use device properties/software nodes by utilizing PROPERTY_ENTRY_GPIO() instead of a lookup table.
Quoted 8 lines
Quoted 4 lines
Applied, thanks!
[1/1] ARM: tegra: paz00: use software nodes to describe GPIOs for WiFi rfkill
      commit: 47ac458bb229f8c4864081d173adbcfc55c34880
Do you know by any chance why paz00 does not simply configure rfkill switch via device tree? The driver (rfkill-gpio) seem to support device tree...
last time I tried this was rejected because the wifi chip is on the usb bus and "rfkill" should be a sub-function of this chip [1], but that was some time ago...
Looking hard the schematics, the wifi chip does not have a gpio input as first thought. Rather it seems that the first gpio toggles a regulator which supplies the wifi module (m2 card) with power and the second gpio is just connected to the wifi LED.
Not sure how to transfer this into dt, but I guess this would be the better solution.

Quoted 6 lines

Quoted 2 lines
Then the first GPIO should probably just be described as a fixed regulator feeding the USB controller that the M.2 module is connected to.
I think that is what rfkill-gpio is for, so the proposal of Dimitry looks fine, execpt for the reset-gpio, aka LED which is already included in the dt (but maybe with the wrong gpio).

I did that some years ago and was rejected. It was for SDIO, not USB though.

Note that if the wireless driver also registers an rfkill device, you would end up with two rfkill devices in the system, and with slightly different behavior.

One would just disable the radio portion of the WiFi device, while the other would cause the WiFi device to disappear.

ChenYu

Quoted 5 lines

I will give it a try on real HW and report back.
Thanks!
Marc