From: Dmytro Milinevskyy <milinevskyy@gmail.com>
To: Pavel Roskin <proski@gnu.org>
Cc: ath5k-devel@lists.ath5k.org, Jiri Slaby <jirislaby@gmail.com>,
Nick Kossifidis <mickflemm@gmail.com>,
"Luis R. Rodriguez" <lrodriguez@atheros.com>,
Bob Copeland <me@bobcopeland.com>,
"John W. Linville" <linville@tuxdriver.com>,
GeunSik Lim <geunsik.lim@samsung.com>,
Greg Kroah-Hartman <gregkh@suse.de>,
Lukas Turek <8an@praha12.net>, Mark Hindley <mark@hindley.org.uk>,
Johannes Berg <johannes@sipsolutions.net>,
Jiri Kosina <jkosina@suse.cz>, Kalle Valo <kalle.valo@iki.fi>,
Keng-Yu Lin <keng-yu.lin@canonical.com>,
Luca Verdesca <magooz@salug.it>,
Shahar Or <shahar@shahar-or.co.il>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
Date: Mon, 7 Jun 2010 10:39:03 +0300 [thread overview]
Message-ID: <AANLkTilPVWvsgXkriz68lLl6e8Qslm_wMkHpkhEdWC3_@mail.gmail.com> (raw)
In-Reply-To: <1275668535.17251.20.camel@mj>
Pavel, thank you for the response here.
I agree with all your comments and will adjust the patch according to them.
I'm new to the submitting patches into the community and I appreciate
telling criticism so that in future I will not cause that much
troubles.
Regards,
-- Dima
On Fri, Jun 4, 2010 at 7:22 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2010-06-04 at 16:43 +0300, Dmytro Milinevskyy wrote:
>> Hi!
>>
>> Here is the patch to disable ath5k leds support on build stage.
>> However if the leds support was enabled do not force selection of 802.11 leds layer.
>> Depency on LEDS_CLASS is kept.
>>
>> Suggestion given by Pavel Roskin and Bob Copeland applied.
>
> It's great that you did it. The patch is much clearer now. That makes
> smaller issues visible. Please don't be discouraged by the criticism,
> you are on the right track.
>
> First of all, your patch doesn't apply cleanly to the current
> wireless-testing because of formatting changes in Makefile. Please
> update.
>
>> +config ATH5K_LEDS
>> + tristate "Atheros 5xxx wireless cards LEDs support"
>> + depends on ATH5K
>> + select NEW_LEDS
>> + select LEDS_CLASS
>> + ---help---
>> + Atheros 5xxx LED support.
>
> "tristate" is wrong here. "tristate" would allow users select "m",
> which is wrong, since LED support is not a separate module. I think you
> want "bool" here.
>
>> +#ifdef CONFIG_ATH5K_LEDS
>> /*
>> * State for LED triggers
>> */
>> @@ -95,6 +96,7 @@ struct ath5k_led
>> struct ath5k_softc *sc; /* driver state */
>> struct led_classdev led_dev; /* led classdev */
>> };
>> +#endif
>
> This shouldn't be needed. I'll rather see a structure that is not used
> in some cases than an extra pair of preprocessor conditionals.
>
>> diff --git a/drivers/net/wireless/ath/ath5k/gpio.c b/drivers/net/wireless/ath/ath5k/gpio.c
>> index 64a27e7..9e757b3 100644
>> --- a/drivers/net/wireless/ath/ath5k/gpio.c
>> +++ b/drivers/net/wireless/ath/ath5k/gpio.c
>> @@ -25,6 +25,7 @@
>> #include "debug.h"
>> #include "base.h"
>>
>> +#ifdef CONFIG_ATH5K_LEDS
>> /*
>> * Set led state
>> */
>> @@ -76,6 +77,7 @@ void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
>> else
>> AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led_5210);
>> }
>> +#endif
>
> I would just move that function to led.c (and don't forget to include
> reg.h). The Makefile should take care of the rest.
>
> --
> Regards,
> Pavel Roskin
>
next prev parent reply other threads:[~2010-06-07 7:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-04 13:43 [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection Dmytro Milinevskyy
2010-06-04 16:22 ` Pavel Roskin
2010-06-07 7:39 ` Dmytro Milinevskyy [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-06-09 7:31 Dmytro Milinevskyy
2010-06-03 19:39 Dmytro Milinevskyy
2010-06-04 14:09 ` John W. Linville
2010-04-07 18:58 Dmytro Milinevskyy
2010-06-01 20:34 ` Bob Copeland
2010-06-01 23:01 ` Dmytro Milinevskyy
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=AANLkTilPVWvsgXkriz68lLl6e8Qslm_wMkHpkhEdWC3_@mail.gmail.com \
--to=milinevskyy@gmail.com \
--cc=8an@praha12.net \
--cc=ath5k-devel@lists.ath5k.org \
--cc=geunsik.lim@samsung.com \
--cc=gregkh@suse.de \
--cc=jirislaby@gmail.com \
--cc=jkosina@suse.cz \
--cc=johannes@sipsolutions.net \
--cc=kalle.valo@iki.fi \
--cc=keng-yu.lin@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=lrodriguez@atheros.com \
--cc=magooz@salug.it \
--cc=mark@hindley.org.uk \
--cc=me@bobcopeland.com \
--cc=mickflemm@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=proski@gnu.org \
--cc=shahar@shahar-or.co.il \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).