Re: [PATCH] ARM: tegra: paz00: configure WiFi rfkill switch through device tree

[Marc Dietrich <marvin24@gmx.de>]

Hi Dmitry,


On Sat, 28 Feb 2026, Marc Dietrich wrote:
> On Sun, 22 Feb 2026, Dmitry Torokhov wrote:
>> On Sat, Feb 21, 2026 at 03:24:35PM +0100, Marc Dietrich wrote:
>>> On Sat, 14 Feb 2026, Marc Dietrich wrote:
>>>> On Fri, 13 Feb 2026, Dmitry Torokhov wrote:
>>>> 
>>>>> 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 ....
>>>> 
>>>>> +		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.

thinking about all this a bit more, I guess your approach to just convert 
the driver to device-tree and not change any functionally beside it, is 
the best solution for now (and good pratice in general).
Maybe I can get access to a machine with bluetooth (or some other user 
steps up), so we can try to find a better solution, if required at all.

Thanks!
Marc