netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Dmytro Milinevskyy <milinevskyy@gmail.com>
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: Fri, 04 Jun 2010 12:22:15 -0400	[thread overview]
Message-ID: <1275668535.17251.20.camel@mj> (raw)
In-Reply-To: <4c0902ef.0a41df0a.6c86.2df0@mx.google.com>

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

  reply	other threads:[~2010-06-04 16:22 UTC|newest]

Thread overview: 13+ 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 [this message]
2010-06-07  7:39   ` Dmytro Milinevskyy
  -- strict thread matches above, loose matches on Subject: below --
2010-06-09  7:31 Dmytro Milinevskyy
2010-06-09 13:58 ` [ath5k-devel] " Bob Copeland
2010-06-09 14:43   ` Dmytro Milinevskyy
     [not found]     ` <AANLkTimXqdkQxv_Y1JaleTTWNsDIQHQaPn8HR7efOupb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-11 20:09       ` Johannes Berg
2010-06-11 20:26         ` [ath5k-devel] " Dmytro Milinevskyy
     [not found]           ` <AANLkTim90VBfWjp2YPYeYN6ImjIyZzcJ_XnpT5cdgCt4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-11 20:29             ` Johannes Berg
2010-06-03 19:39 Dmytro Milinevskyy
2010-06-04 14:09 ` John W. Linville
2010-04-07 18:58 Dmytro Milinevskyy
2010-04-07 18:58 Dmytro Milinevskyy
2010-06-01 20:34 ` Bob Copeland
2010-06-01 23:01   ` Dmytro Milinevskyy
2010-04-07 18:58 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=1275668535.17251.20.camel@mj \
    --to=proski@gnu.org \
    --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=milinevskyy@gmail.com \
    --cc=netdev@vger.kernel.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).