All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
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,
	"Sebastian Gottschall" <s.gottschall@dd-wrt.com>,
	"Sebastian Gottschall" <s.gottschall@newmedia-net.de>,
	"open list:LED SUBSYSTEM" <linux-leds@vger.kernel.org>
Subject: Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Date: Thu, 08 Mar 2018 16:29:36 +0200	[thread overview]
Message-ID: <87371ahc8f.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20180308140515.GA4889@amd> (Pavel Machek's message of "Thu, 8 Mar 2018 15:05:16 +0100")

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

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
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,
	"Sebastian Gottschall" <s.gottschall@dd-wrt.com>,
	"Sebastian Gottschall" <s.gottschall@newmedia-net.de>,
	"open list:LED SUBSYSTEM" <linux-leds@vger.kernel.org>
Subject: Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Date: Thu, 08 Mar 2018 16:29:36 +0200	[thread overview]
Message-ID: <87371ahc8f.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20180308140515.GA4889@amd> (Pavel Machek's message of "Thu, 8 Mar 2018 15:05:16 +0100")

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

-- 
Kalle Valo

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Sebastian Gottschall" <s.gottschall@dd-wrt.com>,
	"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>,
	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, 08 Mar 2018 16:29:36 +0200	[thread overview]
Message-ID: <87371ahc8f.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20180308140515.GA4889@amd> (Pavel Machek's message of "Thu, 8 Mar 2018 15:05:16 +0100")

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

-- 
Kalle Valo

  reply	other threads:[~2018-03-08 14:29 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 [this message]
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
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=87371ahc8f.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=s.gottschall@dd-wrt.com \
    --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: link
Be 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.