Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> 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
