From: Kalle Valo <kvalo@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
"Toke Høiland-Jørgensen" <toke@toke.dk>,
"Arend van Spriel" <aspriel@gmail.com>,
"Franky Lin" <franky.lin@broadcom.com>,
"Hante Meuleman" <hante.meuleman@broadcom.com>,
"Arnd Bergmann" <arnd@arndb.de>, "Lee Jones" <lee@kernel.org>,
"Brian Norris" <briannorris@chromium.org>,
"Srinivasan Raju" <srini.raju@purelifi.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
Subject: Re: [PATCH 1/6] wifi: ath9k: Obtain system GPIOS from descriptors
Date: Thu, 01 Feb 2024 14:51:23 +0200 [thread overview]
Message-ID: <878r44uz3o.fsf@kernel.org> (raw)
In-Reply-To: <ZbuDF2-m8oJofpyl@smile.fi.intel.com> (Andy Shevchenko's message of "Thu, 1 Feb 2024 13:40:07 +0200")
Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> On Wed, Jan 31, 2024 at 11:37:20PM +0100, Linus Walleij wrote:
>
>> 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.
>
> ...
>
>> + /* Obtains a system specific GPIO descriptor from another GPIO controller */
>> + gpiod = devm_gpiod_get_index(ah->dev, NULL, gpio, flags);
>
>> +
>
> Unnecessary blank line, please don't add it.
I can fix that in the pending branch, no need to resend because of this.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2024-02-01 12:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 22:37 [PATCH 0/6] Convert some wireless drivers to use GPIO descriptors Linus Walleij
2024-01-31 22:37 ` [PATCH 1/6] wifi: ath9k: Obtain system GPIOS from descriptors Linus Walleij
2024-02-01 10:57 ` Toke Høiland-Jørgensen
2024-02-01 11:40 ` Andy Shevchenko
2024-02-01 12:51 ` Kalle Valo [this message]
2024-02-01 12:20 ` Arnd Bergmann
2024-02-01 13:17 ` Andy Shevchenko
2024-02-01 14:00 ` Arnd Bergmann
2024-02-01 14:18 ` Toke Høiland-Jørgensen
2024-02-02 7:31 ` Arnd Bergmann
2024-02-02 10:23 ` Toke Høiland-Jørgensen
2024-02-05 18:13 ` Kalle Valo
2024-01-31 22:37 ` [PATCH 2/6] wifi: ti: wlcore: sdio: Drop unused include Linus Walleij
2024-02-05 18:17 ` Kalle Valo
2024-01-31 22:37 ` [PATCH 3/6] brcm80211: brcmsmac: Drop legacy header Linus Walleij
2024-01-31 22:37 ` [PATCH 4/6] wifi: mwifiex: Drop unused headers Linus Walleij
2024-01-31 22:37 ` [PATCH 5/6] wifi: plfxlc: Drop unused include Linus Walleij
2024-01-31 22:37 ` [PATCH 6/6] wifi: cw1200: Convert to GPIO descriptors Linus Walleij
2024-02-01 10:02 ` Kalle Valo
2024-02-01 11:42 ` [PATCH 0/6] Convert some wireless drivers to use " Andy Shevchenko
2024-02-01 12:53 ` Kalle Valo
2024-02-01 17:13 ` Linus Walleij
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=878r44uz3o.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=aspriel@gmail.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=briannorris@chromium.org \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=srini.raju@purelifi.com \
--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 NNTP newsgroup(s).