Hi Dmitry,

On Sun, 22 Feb 2026, Dmitry Torokhov wrote:

Hi Marc,

On Sat, Feb 21, 2026 at 03:24:35PM +0100, Marc Dietrich wrote:

quoted

Hi Dmitry,

On Sat, 14 Feb 2026, Marc Dietrich wrote:

quoted

Hi Dmitry,

On Fri, 13 Feb 2026, Dmitry Torokhov wrote:

quoted

As of d64c732dfc9e ("net: rfkill: gpio: add DT support") rfkill-gpio
device can be instantiated via device tree.

Add the declaration there and drop board-paz00.c file and relevant
Makefile fragments.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---

This is not tested on real hardware, compile tested only...

arch/arm/boot/dts/nvidia/tegra20-paz00.dts |  8 ++++
arch/arm/mach-tegra/Makefile               |  2 -
arch/arm/mach-tegra/board-paz00.c          | 56 ----------------------
arch/arm/mach-tegra/board.h                |  2 -
arch/arm/mach-tegra/tegra.c                |  4 --
5 files changed, 8 insertions(+), 64 deletions(-)

diff --git a/arch/arm/boot/dts/nvidia/tegra20-paz00.dts

b/arch/arm/boot/dts/nvidia/tegra20-paz00.dts
index 1408e1e00759..d1093ad569e6 100644

--- a/arch/arm/boot/dts/nvidia/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/nvidia/tegra20-paz00.dts

@@ -706,6 +706,14 @@ vdd_pnl_reg: regulator-3v0 {

		enable-active-high;
	};

+	rfkill {
+		compatible = "rfkill-gpio";
+		label = "wifi_rfkill";
+		radio-type = "wlan";
+		reset-gpios = <&gpio TEGRA_GPIO(D, 1) GPIO_ACTIVE_HIGH>;

I guess this can be removed, as it should trigger the LED, which is
already included elsewhere ....

quoted

+		shutdown-gpios = <&gpio TEGRA_GPIO(K, 5) GPIO_ACTIVE_HIGH>;
+	};
+
	sound {
		compatible = "nvidia,tegra-audio-alc5632-paz00",
			"nvidia,tegra-audio-alc5632";

I'll give it a try and report back.

rfkill (and LED) works as expected. With the reset-gpio line mentioned above
removed, you can add my Tested-By.

Thank you Marc.

I am still a bit confused about the reset gpio. As far as I understand
looking through old commits reset gpio (PD1) is distinct from the LED
gpio (PD0) that is currently being controlled by "gpio-leds".

well, the situation is a bit complicated. First, D1 gpio is eletrical ORed 
with the Wifi LED gpio (D0), which you can confirm by checking the schematic 
(google is your friend).
The said schematic contains two nearly identical devices (Toshiba 
Netbook AC100, aka Procyon and Toshiba tablet Folio 100, aka Sirius). 
GPIO D1 is also used on the tablet to rfkill the wifi/bt module on an M2 
card, while the Notebook has wifi on a separate usb port (JP2) (and G3 
modem on an M2 card), where D1 is not connected to at all. At least that's 
how I understand it.

I guess the rfkill driver needs at least one of "reset" or "shutdown"
gpios, and that is why it continues to work with only shutdown, but I am
trying to understand if PD1 was never connected to the WiFi chip reset
line and instead is used for something else, or if it is indeed a reset
line...

see above.

Was the patch not working with reset-gpios present? I am trying to
gather data to craft a proper commit message.

It also works with the reset-gpio, but just because it is not connected to 
anything beside the LED on this machine.

Maybe I should also add that there are also variants of the Netbook with 
integrated bluetooth (and without 3G), but I don't know where it is 
connected to (maybe also to the M2 socket). In order to support such 
machines, we could use a second rfkill device for bluetooth only I 
guess. The original code used a single rfkill device in order to control 
both gpios together for a common rfkill I guess. I just don't have such a 
variant, so I cannot test it.

Best wishes,

Marc