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

[Chen-Yu Tsai]

On Sat, Feb 14, 2026 at 10:27 PM Marc Dietrich <marvin24 at gmx.de> wrote:
>
> Hi Dimitry,
>
> On Wed, 11 Feb 2026, Dmitry Torokhov wrote:
>
> > Hi Thierry,
> >
> > On Fri, Jun 28, 2024 at 05:35:08PM +0200, Thierry Reding wrote:
> >> From: Thierry Reding <treding at nvidia.com>
> >>
> >>
> >> On Wed, 26 Jun 2024 21:46:13 -0700, Dmitry Torokhov wrote:
> >>> 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
> >
> > 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.

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

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