Am 08.03.2018 um 15:29 schrieb Kalle Valo:
Pavel Machek <pa...@ucw.cz> writes:

ath10k_leds.gpio = ar->hw_params.led_pin;
gpio_led_register_device(0, &ath10k_leds);
the problem are other architectures which have already registered gpio_led
at system start like ar71xx
you cannot register a second one. so a independend led driver is a
requirement for direct control
If the limitation indeed exists, please fix the limitation rather than
working around it in each and every driver.
see ath9k. its exact the same implementation.
Ok, so one more driver to fix.

in addition my variant does also work without gpiolib support. so it
can be used even if the kernel is configured without gpio support.
and not to forget, using a own led driver is more ligthweight from
the call path for each led on / off event which is important for low
performance embedded devices
We are not going to copy&paste code because such code works without
libraries, and we are not going to copy&paste code because that uses
less cache during calls. Sorry.

NAK. Please fix your patch.
To me it's not that black and white, sometimes copying code is simpler
than trying to bring up complicated or restricting frameworks (talking
in general here).

I haven't been able to review this patch in detail yet but from a quick
look most of the code is about standard ath10k infrastructure code. How
many lines of code would using leds-gpio save?
nothing. the led driver code is already very small. (see gpio.c in the patch) i had a leds-gpio implementation but it will not work since a platform data with the name "leds-gpio" does already exist on various platforms (ath79 for instance) so a second leds-gpio can't be registered. so this solution does simply not work and asking me for fixing the kernel generic platform data handling like pavel did, is really out of mind and a own led driver has also better performance than using the leds-gpio->gpiolib->ath10k gpio driver callpath. if someone is still complaining that i added a gpio feature driver as well to my patch, i can simply remove that usefull feature and all would be happy. but i think having access to all gpios of the card instead of just the led gpio makes sense to. thats why i implemented a gpiolib driver as well

Sebastian


--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Reply via email to