linux-kernel - Re: [PATCH 1/6] wifi: ath9k: Obtain system GPIOS from descriptors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 01 Feb 2024 11:57:09 +0100
From: Toke Høiland-Jørgensen <toke@...e.dk>
To: Linus Walleij <linus.walleij@...aro.org>, Kalle Valo <kvalo@...nel.org>,
 Arend van Spriel <aspriel@...il.com>, Franky Lin
 <franky.lin@...adcom.com>, Hante Meuleman <hante.meuleman@...adcom.com>,
 Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Arnd Bergmann
 <arnd@...db.de>, Lee Jones <lee@...nel.org>, Brian Norris
 <briannorris@...omium.org>, Srinivasan Raju <srini.raju@...elifi.com>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
 brcm80211-dev-list.pdl@...adcom.com, Linus Walleij
 <linus.walleij@...aro.org>
Subject: Re: [PATCH 1/6] wifi: ath9k: Obtain system GPIOS from descriptors

Linus Walleij <linus.walleij@...aro.org> writes:

> 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.
>
> My best guess is that everyone actually using this driver has
> support for the local (custom) GPIO API and the bit in
> h->caps.gpio_mask is always set for any GPIO the driver may
> try to obtain, so this facility to use system-wide GPIOs is
> actually unused and could be deleted.
>
> Anyway: I cannot know if this is really the case, so implement
> a fallback handling using GPIO descriptors obtained from the
> ah->dev device indexed 0..31. These can for example be passed
> in the device tree, ACPI or through board files. I doubt that
> anyone will use them, but this makes it possible to obtain a
> system-wide GPIO for any of the 0..31 GPIOs potentially
> requested by the driver.
>
> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>

This seems reasonable, thanks!

Acked-by: Toke Høiland-Jørgensen <toke@...e.dk>