Pavel Machek <pavel@xxxxxx> 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? -- Kalle Valo
