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

[Marc Dietrich]

Hallo Chen-Yu,

On Sat, 14 Feb 2026, Chen-Yu Tsai wrote:

> On Sat, Feb 14, 2026 at 10:27 PM Marc Dietrich <marvin24@xxxxxx> 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@xxxxxxxxxx>
> > > >
> > > >
> > > > 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.

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