From: Sebastian Gottschall <s.gottschall@dd-wrt.com> To: Pavel Machek <pavel@ucw.cz> Cc: "Rafał Miłecki" <zajec5@gmail.com>, "open list:LED SUBSYSTEM" <linux-leds@vger.kernel.org>, "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, "Kalle Valo" <kvalo@codeaurora.org>, ath10k@lists.infradead.org, "Sebastian Gottschall" <s.gottschall@newmedia-net.de> Subject: Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets Date: Thu, 8 Mar 2018 15:34:23 +0100 [thread overview] Message-ID: <c2d75791-5822-ac55-35ad-734947e22d45@dd-wrt.com> (raw) In-Reply-To: <20180308140515.GA4889@amd> Am 08.03.2018 um 15:05 schrieb Pavel Machek: > On Thu 2018-03-08 13:33:29, Sebastian Gottschall wrote: >> Am 08.03.2018 um 10:02 schrieb Pavel Machek: >>> On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote: >>>> Am 07.03.2018 um 17:22 schrieb Rafał Miłecki: >>>>> On 2 March 2018 at 10:22, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote: >>>>>>>> leds-gpio is crap and limited. you can just register one platform data at >>>>>>>> kernel runtime since its identified by its object name "led-gpio" but the >>>>>>>> kernel forbidds to register 2 platform datas with the same name >>>>>>>> consider the ar71xx devices with qca988x wifi chipsets. they all have >>>>>>>> already a led platform data registered >>>>>>>> at boottime. a second can't be registered anymore so gpio_led is useless >>>>>>>> at >>>>>>>> all for most developers on such platforms. its mainly used for early >>>>>>>> kernel >>>>>>>> platform data initialisation for system leds. >>>>>>> If leds-gpio has limitations, please fix those, rather then >>>>>>> introducing duplicated code. >>>>>> there is no duplicated code introduced and there is no solution for it. >>>>>> consider that all wifi drivers with softled support >>>>>> are going that way with registering a own led driver. see ath9k for >>>>>> instance. gpio-led cannot be used for it and there is no way to >>>>>> support multiple platform datas with the same name. its a kernel limitation >>>>> I just reviewed some mips arch patch adding support for more LEDs for >>>>> selected devices: >>>>> [PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs >>>>> https://patchwork.linux-mips.org/patch/18681/ >>>>> >>>>> It seems to be simply adding another call to the >>>>> gpio_led_register_device(). It seems to me you can call that function >>>>> multiple times and register multiple structs with LEDs. >>>>> >>>>> Isn't all you need something like this? >>>>> >>>>> static const struct gpio_led ath10k_leds[] = { >>>>> { >>>>> .name = "ath10k:color:function", >>>>> .active_low = 1, >>>>> .default_state = LEDS_GPIO_DEFSTATE_KEEP, >>>>> } >>>>> }; >>>>> >>>>> static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = { >>>>> leds = ath10k_leds; >>>>> num_leds = ARRAY_SIZE(ath10k_leds); >>>>> }; >>>>> >>>>> 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. show me a proof that its copy & paste. because its not > > Pavel -- 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.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Gottschall <s.gottschall@dd-wrt.com> To: Pavel Machek <pavel@ucw.cz> Cc: "Rafał Miłecki" <zajec5@gmail.com>, "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>, ath10k@lists.infradead.org, "open list:LED SUBSYSTEM" <linux-leds@vger.kernel.org>, "Sebastian Gottschall" <s.gottschall@newmedia-net.de>, "Kalle Valo" <kvalo@codeaurora.org> Subject: Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets Date: Thu, 8 Mar 2018 15:34:23 +0100 [thread overview] Message-ID: <c2d75791-5822-ac55-35ad-734947e22d45@dd-wrt.com> (raw) In-Reply-To: <20180308140515.GA4889@amd> Am 08.03.2018 um 15:05 schrieb Pavel Machek: > On Thu 2018-03-08 13:33:29, Sebastian Gottschall wrote: >> Am 08.03.2018 um 10:02 schrieb Pavel Machek: >>> On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote: >>>> Am 07.03.2018 um 17:22 schrieb Rafał Miłecki: >>>>> On 2 March 2018 at 10:22, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote: >>>>>>>> leds-gpio is crap and limited. you can just register one platform data at >>>>>>>> kernel runtime since its identified by its object name "led-gpio" but the >>>>>>>> kernel forbidds to register 2 platform datas with the same name >>>>>>>> consider the ar71xx devices with qca988x wifi chipsets. they all have >>>>>>>> already a led platform data registered >>>>>>>> at boottime. a second can't be registered anymore so gpio_led is useless >>>>>>>> at >>>>>>>> all for most developers on such platforms. its mainly used for early >>>>>>>> kernel >>>>>>>> platform data initialisation for system leds. >>>>>>> If leds-gpio has limitations, please fix those, rather then >>>>>>> introducing duplicated code. >>>>>> there is no duplicated code introduced and there is no solution for it. >>>>>> consider that all wifi drivers with softled support >>>>>> are going that way with registering a own led driver. see ath9k for >>>>>> instance. gpio-led cannot be used for it and there is no way to >>>>>> support multiple platform datas with the same name. its a kernel limitation >>>>> I just reviewed some mips arch patch adding support for more LEDs for >>>>> selected devices: >>>>> [PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs >>>>> https://patchwork.linux-mips.org/patch/18681/ >>>>> >>>>> It seems to be simply adding another call to the >>>>> gpio_led_register_device(). It seems to me you can call that function >>>>> multiple times and register multiple structs with LEDs. >>>>> >>>>> Isn't all you need something like this? >>>>> >>>>> static const struct gpio_led ath10k_leds[] = { >>>>> { >>>>> .name = "ath10k:color:function", >>>>> .active_low = 1, >>>>> .default_state = LEDS_GPIO_DEFSTATE_KEEP, >>>>> } >>>>> }; >>>>> >>>>> static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = { >>>>> leds = ath10k_leds; >>>>> num_leds = ARRAY_SIZE(ath10k_leds); >>>>> }; >>>>> >>>>> 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. show me a proof that its copy & paste. because its not > > Pavel -- 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.gottschall@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-03-08 14:34 UTC|newest] Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-26 8:44 [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets s.gottschall 2018-02-26 8:44 ` s.gottschall 2018-02-27 17:03 ` Steve deRosier 2018-02-27 17:03 ` Steve deRosier 2018-02-27 17:43 ` Sebastian Gottschall 2018-02-27 17:43 ` Sebastian Gottschall 2018-02-27 22:08 ` Rafał Miłecki 2018-02-27 22:08 ` Rafał Miłecki 2018-02-28 1:49 ` Sebastian Gottschall 2018-02-28 1:49 ` Sebastian Gottschall 2018-03-02 9:03 ` Pavel Machek 2018-03-02 9:03 ` Pavel Machek 2018-03-02 9:22 ` Sebastian Gottschall 2018-03-02 9:22 ` Sebastian Gottschall 2018-03-02 9:22 ` Sebastian Gottschall 2018-03-07 16:22 ` Rafał Miłecki 2018-03-07 16:22 ` Rafał Miłecki 2018-03-07 17:54 ` Sebastian Gottschall 2018-03-07 17:54 ` Sebastian Gottschall 2018-03-08 9:02 ` Pavel Machek 2018-03-08 9:02 ` Pavel Machek 2018-03-08 12:33 ` Sebastian Gottschall 2018-03-08 12:33 ` Sebastian Gottschall 2018-03-08 14:05 ` Pavel Machek 2018-03-08 14:05 ` Pavel Machek 2018-03-08 14:29 ` Kalle Valo 2018-03-08 14:29 ` Kalle Valo 2018-03-08 14:29 ` Kalle Valo 2018-03-08 14:43 ` Sebastian Gottschall 2018-03-08 14:43 ` Sebastian Gottschall 2018-03-08 14:34 ` Sebastian Gottschall [this message] 2018-03-08 14:34 ` Sebastian Gottschall 2018-03-08 15:04 ` Pavel Machek 2018-03-08 15:04 ` Pavel Machek 2018-03-08 15:04 ` Pavel Machek 2018-03-08 15:31 ` Sebastian Gottschall 2018-03-08 15:31 ` Sebastian Gottschall 2018-03-08 15:46 ` Felix Fietkau 2018-03-08 15:46 ` Felix Fietkau 2018-03-10 7:44 ` Julian Calaby 2018-03-10 7:44 ` Julian Calaby 2018-03-10 7:56 ` Sebastian Gottschall 2018-03-10 7:56 ` Sebastian Gottschall 2018-03-12 7:53 ` Mathias Kresin 2018-03-12 7:53 ` Mathias Kresin 2018-03-12 7:53 ` Mathias Kresin 2018-03-12 9:09 ` Sebastian Gottschall 2018-03-12 9:09 ` Sebastian Gottschall 2018-03-12 9:09 ` Sebastian Gottschall 2018-04-05 14:44 ` Kalle Valo 2018-04-05 14:44 ` Kalle Valo 2018-04-05 18:01 ` Sebastian Gottschall 2018-04-05 18:01 ` Sebastian Gottschall 2018-04-05 20:00 ` Sebastian Gottschall 2018-04-05 20:00 ` Sebastian Gottschall 2018-04-06 8:07 ` Kalle Valo 2018-04-06 8:07 ` Kalle Valo 2018-04-06 8:10 ` Sebastian Gottschall 2018-04-06 8:10 ` Sebastian Gottschall [not found] ` <1d917688-9f59-39ad-46a6-527d9e3dec03@dd-wrt.com> 2018-04-06 8:09 ` Kalle Valo 2018-04-06 8:09 ` Kalle Valo 2018-04-06 8:11 ` Sebastian Gottschall 2018-04-06 8:11 ` Sebastian Gottschall 2018-04-06 8:25 ` Kalle Valo 2018-04-06 8:25 ` Kalle Valo [not found] ` <f3617290-34d5-0cca-6442-4a37c06701b1@dd-wrt.com> 2018-04-06 9:17 ` Kalle Valo 2018-04-06 9:17 ` Kalle Valo 2018-04-06 8:05 ` Kalle Valo 2018-04-06 8:05 ` Kalle Valo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c2d75791-5822-ac55-35ad-734947e22d45@dd-wrt.com \ --to=s.gottschall@dd-wrt.com \ --cc=ath10k@lists.infradead.org \ --cc=kvalo@codeaurora.org \ --cc=linux-leds@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=pavel@ucw.cz \ --cc=s.gottschall@newmedia-net.de \ --cc=zajec5@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.