Linux-GPIO Archive mirror
 help / color / mirror / Atom feed
From: "Michał Kępień" <kernel@kempniu.pl>
To: Linus Walleij <linusw@kernel.org>
Cc: "Jeff Johnson" <jeff.johnson@oss.qualcomm.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Arnd Bergmann" <arnd@arndb.de>, "Alban Bedel" <albeu@free.fr>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	linux-wireless@vger.kernel.org,
	brcm80211-dev-list.pdl@broadcom.com, linux-gpio@vger.kernel.org,
	"Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Subject: Re: [PATCH v6] wifi: ath9k: Obtain system GPIOS from descriptors
Date: Tue, 7 Apr 2026 17:13:16 +0200	[thread overview]
Message-ID: <adUfDB4y-xt5QorX@larwa.hq.kempniu.pl> (raw)
In-Reply-To: <20260317-descriptors-wireless-v6-1-b19ecff9cd2b@kernel.org>

Linus,

> The ath9k has an odd use of system-wide GPIOs: if the chip
> does not have internal GPIO capability, it will try to obtain a
> GPIO line from the system GPIO controller:
> 
>   if (BIT(gpio) & ah->caps.gpio_mask)
>         ath9k_hw_gpio_cfg_wmac(...);
>   else if (AR_SREV_SOC(ah))
>         ath9k_hw_gpio_cfg_soc(ah, gpio, out, label);
> 
> Where ath9k_hw_gpio_cfg_soc() will attempt to issue
> gpio_request_one() passing the local GPIO number of the controller
> (0..31) to gpio_request_one().
> 
> This is somewhat peculiar and possibly even dangerous: there is
> nowadays no guarantee of the numbering of these system-wide
> GPIOs, and assuming that GPIO 0..31 as used by ath9k would
> correspond to GPIOs 0..31 on the system as a whole seems a bit
> wild.
> 
> Register all 32 GPIOs at index 0..31 directly in the ATH79K
> GPIO driver and associate with the NULL device (making them
> widely available) if and only if we are probing ATH79K wifi
> from the AHB bus (used for SoCs). We obtain these offsets from
> the NULL device if necessary.
> 
> These GPIOs should ideally be defined in the device tree
> instead, but we have no control over that for the legacy
> code path.
> 
> Testcompiled with the ath79 defconfig.

I could only test a 6.12 backport of v6 on real hardware as that is the
kernel version that OpenWRT's current main branch uses for my router.
That being said, the only conflict I had to resolve was the one caused
by commit 551a097118391018ddc4079cbcec6fe4e7d64bc5 ("gpio: ath79: use
new generic GPIO chip API") in ath79_gpio_probe(), i.e. no functional
changes were necessary.

After replacing the "tweaked" version of v2 with a 6.12 backport of v6
in OpenWRT's source tree, the WiFi LED still works fine on my router.

For the above:

Tested-by: Michał Kępień <kernel@kempniu.pl>

-- 
Best regards,
Michał Kępień

  reply	other threads:[~2026-04-07 15:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17  8:45 [PATCH v6] wifi: ath9k: Obtain system GPIOS from descriptors Linus Walleij
2026-04-07 15:13 ` Michał Kępień [this message]
2026-04-22 13:59 ` Jeff Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adUfDB4y-xt5QorX@larwa.hq.kempniu.pl \
    --to=kernel@kempniu.pl \
    --cc=albeu@free.fr \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=brgl@bgdev.pl \
    --cc=jeff.johnson@oss.qualcomm.com \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).