10.03.2018 08:56, Sebastian Gottschall:
taken a look at the specific code, and from my point of view the code
that sets up the LED (including callback) is so trivial that it's simply
not worth dealing with adding the leds-gpio driver to the mix.
It adds extra complexity and an extra dependency for no reason at all.
There's no extra functionality to be gained by using it.
Stupid question: If the LED driver isn't using the GPIO subsystem
(when enabled), what happens if the user uses the GPIO subsystem to
fiddle with the pin the LED is connected to?
in our case here it can coexist and will not have a negative effect
since the led will still run. (except if you reconfigure the gpio to input)
for sure it makes no sense.
Well, it will have negative effects as I noticed in OpenWrt. If the same
GPIO is controlled by the internal LED function it can't be really used
via the GPIO controller as there will be "bogus" changes of the GPIO pin
state.
but however i can block the gpio for beeing reused if the led driver
took it. this has been made in ath9k for instance.
Most likely I'm not aware of the upstream code you are talking about.
But OpenWrt has a custom patch which registers the ath9k pins as GPIO
controller.
As soon as there are pins, manufactures will use them and the assumption
about a default led connected to a specific pin will fail.
I've seen (home)routers routers using the "default" ath9k LED pin as
button or for LEDs with a different purpose than "wireless". I never was
able to find any kind of information which explains why exactly this
specific pin is used for the ath9k-led. But that's another story.
My solution for OpenWrt was a patch which prevents the creation of the
ath9k-led if the "default" pin is used as GPIO.
If mach files are used, the ath9k led isn't created (ath9k led pin is
set to -1) in case the platform data have a button or led using the same
pin. If the device tree is used, the ath9k led isn't created (ath9k led
pin is set to -1) if the devicetree node for the ath9k device has the
gpio-controller property. I'm not really proud of the code and it can be
most likely done better, but it fixes the issue outlined above.
I've done it this way since the use of the GPIO controller should always
override any kind of default LEDs.
In the end ath[0|10]k-led is only required for hardware configurations
where the wireless isn't fixed like with miniPCIe, USB ... wireless
cards. If the configuration is fixed - like it is for most of the
(home)routers - the GPIO controller can be registered via the devicetree
and gpio-leds can be used. Something similar can be most likely done via
mach files (I barely touch mach files).
I'm aware of the issue since the first version of your patch. But since
I'm very interested in getting the ath10k pins exposed as gpio
controller, I planned to add a workaround similar to what we have for
ath9k to OpenWrt.
Mathias
