linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmytro Milinevskyy <milinevskyy@gmail.com>
To: Bob Copeland <me@bobcopeland.com>
Cc: ath5k-devel@lists.ath5k.org, Jiri Slaby <jirislaby@gmail.com>,
	Nick Kossifidis <mickflemm@gmail.com>,
	"Luis R. Rodriguez" <lrodriguez@atheros.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: Wed, 2 Jun 2010 02:01:32 +0300	[thread overview]
Message-ID: <AANLkTiklAs6MM-LkEzkiZbmLG78WednhDXm4oXRcdgMX@mail.gmail.com> (raw)
In-Reply-To: <AANLkTinFCuqgvnEGFmssL5R1J9-Yx7JB8mO9yKdXuYUj@mail.gmail.com>

Bob, thanks for the response.

I will rework the patch.

>> -/* GPIO-controlled software LED */
>> -#define AR5K_SOFTLED_PIN       0
>> -#define AR5K_SOFTLED_ON                0
>> -#define AR5K_SOFTLED_OFF       1
>> -
>
> Please drop this hunk, no problem keeping it around.

I suppose this should go away with another patch to keep current
clean. These dfinitions are not related to the subject.

Regards,

-- Dima

On Tue, Jun 1, 2010 at 11:34 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Wed, Apr 7, 2010 at 2:58 PM, Dmytro Milinevskyy
> <milinevskyy@gmail.com> wrote:
>> Hello!
>
> Thanks, comments inline.
>
>
>> +config ATH5K_LEDS
>> +       tristate "Atheros 5xxx wireless cards LEDs support"
>> +       depends on ATH5K
>> +       ---help---
>> +         Atheros 5xxx LED support.
>> +
>
> This can select the proper LED classes?  Then you can get rid of another
> ifdef check later.
>
>> -/* GPIO-controlled software LED */
>> -#define AR5K_SOFTLED_PIN       0
>> -#define AR5K_SOFTLED_ON                0
>> -#define AR5K_SOFTLED_OFF       1
>> -
>
> Please drop this hunk, no problem keeping it around.
>
>> +#ifdef CONFIG_ATH5K_LEDS
>>  /* LED functions */
>>  int ath5k_init_leds(struct ath5k_softc *sc);
>>  void ath5k_led_enable(struct ath5k_softc *sc);
>>  void ath5k_led_off(struct ath5k_softc *sc);
>>  void ath5k_unregister_leds(struct ath5k_softc *sc);
>> +#else
>> +#define ath5k_init_leds(sc) do {} while (0)
>> +#define ath5k_led_enable(sc) do {} while (0)
>> +#define ath5k_led_off(sc) do {} while (0)
>> +#define ath5k_unregister_leds(sc) do {} while (0)
>> +#endif
>
> I prefer:
>
> #ifdef
> ...
> #else
> static inline int ath5k_init_leds(struct ath5k_softc *sc)
> {
>    return 0;
> }
> ...
> #endif
>
> so you get type-checking.  Also this doesn't quite work in your version:
>
>    int foo = ath5k_init_leds(sc);
>
>> +#ifdef CONFIG_ATH5K_LEDS
>>  /*
>>  * State for LED triggers
>>  */
>>  struct ath5k_led
>>  {
>> -       char name[ATH5K_LED_MAX_NAME_LEN + 1];  /* name of the LED in sysfs */
>>        struct ath5k_softc *sc;                 /* driver state */
>> +#ifdef CONFIG_LEDS_CLASS
>> +       char name[ATH5K_LED_MAX_NAME_LEN + 1];  /* name of the LED in sysfs */
>>        struct led_classdev led_dev;            /* led classdev */
>> +#endif
>>  };
>> +#endif
>
> Why move name?
>
>>  /* Rfkill */
>>  struct ath5k_rfkill {
>> @@ -186,9 +190,6 @@ struct ath5k_softc {
>>
>>        u8                      bssidmask[ETH_ALEN];
>>
>> -       unsigned int            led_pin,        /* GPIO pin for driving LED */
>> -                               led_on;         /* pin setting for LED on */
>> -
>>        struct tasklet_struct   restq;          /* reset tasklet */
>>
>>        unsigned int            rxbufsize;      /* rx size based on mtu */
>> @@ -196,7 +197,6 @@ struct ath5k_softc {
>>        spinlock_t              rxbuflock;
>>        u32                     *rxlink;        /* link ptr in last RX desc */
>>        struct tasklet_struct   rxtq;           /* rx intr tasklet */
>> -       struct ath5k_led        rx_led;         /* rx led */
>>
>>        struct list_head        txbuf;          /* transmit buffer */
>>        spinlock_t              txbuflock;
>> @@ -204,7 +204,14 @@ struct ath5k_softc {
>>        struct ath5k_txq        txqs[AR5K_NUM_TX_QUEUES];       /* tx queues */
>>        struct ath5k_txq        *txq;           /* main tx queue */
>>        struct tasklet_struct   txtq;           /* tx intr tasklet */
>> +
>> +
>> +#ifdef CONFIG_ATH5K_LEDS
>> +       unsigned int            led_pin,        /* GPIO pin for driving LED */
>> +                               led_on;         /* pin setting for LED on */
>> +       struct ath5k_led        rx_led;         /* rx led */
>>        struct ath5k_led        tx_led;         /* tx led */
>> +#endif
>
> You might want to do this in two stages: move the led-dependent things
> together in the structure (or into a separate structure) and then only
> have one #ifdef section.
>
> Still too many ifdefs in general.
>
> --
> Bob Copeland %% www.bobcopeland.com
>

  reply	other threads:[~2010-06-01 23:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-07 18:58 [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection Dmytro Milinevskyy
2010-06-01 20:34 ` Bob Copeland
2010-06-01 23:01   ` Dmytro Milinevskyy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-06-03 19:39 Dmytro Milinevskyy
2010-06-04 14:09 ` John W. Linville
2010-06-04 13:43 Dmytro Milinevskyy
2010-06-04 16:22 ` Pavel Roskin
2010-06-07  7:39   ` Dmytro Milinevskyy
2010-06-09  7:31 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=AANLkTiklAs6MM-LkEzkiZbmLG78WednhDXm4oXRcdgMX@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=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).