Re: [PATCH ath-next] wifi: ath9k: release the LED GPIO after ath9k_stop()

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Rosen Penev <rosenp@gmail.com> writes:

> ath9k_deinit_device() frees the LED pin in ath_deinit_leds() before it
> unregisters the hw. ath9k_stop() then switches the LED pin back to an
> input with ath9k_hw_gpio_request_in(). For a SoC GPIO outside of the
> WMAC, ath9k_hw_gpio_request() takes a new descriptor through
> gpiod_get_index() at that point, and nothing releases it again. The
> next probe fails with "request GPIO12 failed:-16" and every LED update
> hits the WARN_ON() in ath9k_hw_set_gpio(). That request also runs
> under sc->sc_pcu_lock, while gpiod_get_index() and
> gpiod_set_consumer_name() may sleep.
>
> Free the LED pin after ieee80211_unregister_hw() instead. This also
> frees the pin when the LED class device could not be registered,
> which leaked it before.

Hmm, instead of reworking the deinit code, how about we just drop the
ath9k_hw_gpio_request_in() call from ath9k_stop()? It's an LED pin, why
would it ever need to be reset? The commit that introduced that call
says it was "for consistency", which seems entirely bogus in this case?

-Toke