linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luciano Coelho <coelho@ti.com>
To: Eliad Peller <eliad@wizery.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 06/29] wl12xx: add vifs list
Date: Mon, 10 Oct 2011 22:40:02 +0300	[thread overview]
Message-ID: <1318275602.9690.409.camel@cumari> (raw)
In-Reply-To: <CAB3XZEfA2woetrXDycv3xcBYGBvyYJQoLz969Rp8k8WjaG3FFw@mail.gmail.com>

On Mon, 2011-10-10 at 21:29 +0200, Eliad Peller wrote: 
> On Mon, Oct 10, 2011 at 8:28 PM, Luciano Coelho <coelho@ti.com> wrote:
> > On Mon, 2011-10-10 at 10:12 +0200, Eliad Peller wrote:
> >> keep a list of all the vifs associated with our hw.
> >> it will be later used in order to iterate through vifs.
> >>
> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> ---
> >
> > [...]
> >
> >> diff --git a/drivers/net/wireless/wl12xx/wl12xx.h b/drivers/net/wireless/wl12xx/wl12xx.h
> >> index 33ccdf8..55561c5 100644
> >> --- a/drivers/net/wireless/wl12xx/wl12xx.h
> >> +++ b/drivers/net/wireless/wl12xx/wl12xx.h
> >> @@ -394,6 +394,8 @@ struct wl1271 {
> >>       unsigned long roles_map[BITS_TO_LONGS(WL12XX_MAX_ROLES)];
> >>       unsigned long roc_map[BITS_TO_LONGS(WL12XX_MAX_ROLES)];
> >>
> >> +     struct list_head wlvif_list;
> >> +
> >>       struct wl1271_acx_mem_map *target_mem_map;
> >>
> >>       /* Accounting for allocated / available TX blocks on HW */
> >> @@ -564,6 +566,7 @@ struct wl1271_station {
> >>
> >>  struct wl12xx_vif {
> >>       struct wl1271 *wl;
> >> +     struct list_head list;
> >
> > I know we alredy call this kind of thing "list" struct wl1271 for the
> > ARP stuff, but I prefer "node" so it's easier to follow when calling
> > list_add and friends.  Mind changing?
> >
> i think "list" is the standard convention (e.g. see sta_info,
> ieee80211_key, etc.) and more intuitive.

Yeah, it makes a bit of sense, because each node is actually a head of a
list.  Still, I don't like it because it's annoying to read it a
list_add() with two lists.  It's not intuitive to know which one is
which.  Anyway, it's fine to leave it like this.


> >> @@ -653,6 +656,9 @@ struct ieee80211_vif *wl12xx_wlvif_to_vif(struct wl12xx_vif *wlvif)
> >>       return container_of((void *)wlvif, struct ieee80211_vif, drv_priv);
> >>  }
> >>
> >> +#define wl12xx_for_each_wlvif(wl, wlvif) \
> >> +             list_for_each_entry(wlvif, &wl->wlvif_list, list)
> >> +
> >
> > This looks fine, but is it really necessary? I think the call to
> > list_for_each_entry is clear enough already, isn't it?
> >
> i find it easier to understand this way.
> also, future patches will add wl12xx_for_each_wlvif_sta and
> wl12xx_for_each_wlvif_ap, so it even makes more sense to use this
> macro.

Yeah, I now saw the other macros and it now makes a bit more sense for
the other ones.  But I dislike simple macros whose content are almost as
easy to understand as the macro name, because one needs to go dig the
macro out to figure out exactly what it is doing.  With no macro, it
would be much easier to figure out that this is a simple
list_for_each_entry(), because you would simply call that explicitly. ;)
It's as annoying as unnecessary typedefs.

But I'm in a temporary and unusual mood of accepting stuff easier than
usual right now, so it's fine to keep it like this. ;)

-- 
Cheers,
Luca.


  reply	other threads:[~2011-10-10 19:40 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-10  8:12 [PATCH 00/29] make the driver ready for multi-vif support Eliad Peller
2011-10-10  8:12 ` [PATCH 01/29] wl12xx: refactor fw init into a new function Eliad Peller
2011-10-10  8:12 ` [PATCH 02/29] wl12xx: move last_tx_hlid into wlvif Eliad Peller
2011-10-10 17:52   ` Luciano Coelho
2011-10-10 19:16     ` Eliad Peller
2011-10-10  8:12 ` [PATCH 03/29] wl12xx: unify STA and AP tx_queue mechanism Eliad Peller
2011-10-10  8:12 ` [PATCH 04/29] wl12xx: move some functions from remove_interface() to stop() Eliad Peller
2011-10-10  8:12 ` [PATCH 05/29] wl12xx: move bitrate_masks into wlvif Eliad Peller
2011-10-10 18:20   ` Luciano Coelho
2011-10-10 19:21     ` Eliad Peller
2011-10-10 19:25       ` Luciano Coelho
2011-10-10  8:12 ` [PATCH 06/29] wl12xx: add vifs list Eliad Peller
2011-10-10 18:28   ` Luciano Coelho
2011-10-10 19:29     ` Eliad Peller
2011-10-10 19:40       ` Luciano Coelho [this message]
2011-10-10 20:04   ` Johannes Berg
2011-10-10 20:07     ` Eliad Peller
2011-10-10  8:12 ` [PATCH 07/29] wl12xx: support multiple vifs in the tx path Eliad Peller
2011-10-10  8:12 ` [PATCH 08/29] wl12xx: configure sleep_policy according to active roles Eliad Peller
2011-10-10 18:51   ` Luciano Coelho
2011-10-10 19:32     ` Eliad Peller
2011-10-10 19:54       ` Luciano Coelho
2011-10-10  8:12 ` [PATCH 09/29] wl12xx: make event handling support multirole Eliad Peller
2011-10-10 18:58   ` Luciano Coelho
2011-10-10 19:36     ` Eliad Peller
2011-10-10 19:47       ` Luciano Coelho
2011-10-10  8:12 ` [PATCH 10/29] wl12xx: move tx_security_seq into wlvif Eliad Peller
2011-10-10 19:25   ` Luciano Coelho
2011-10-10  8:12 ` [PATCH 11/29] wl12xx: rearm rx streaming per vif Eliad Peller
2011-10-10  8:13 ` [PATCH 12/29] wl12xx: make WL1271_FLAG_STA_ASSOCIATED flag per-vif Eliad Peller
2011-10-10  8:13 ` [PATCH 13/29] wl12xx: make WL1271_FLAG_IBSS_JOINED " Eliad Peller
2011-10-10  8:13 ` [PATCH 14/29] wl12xx: make WL1271_FLAG_AP_STARTED " Eliad Peller
2011-10-10  8:13 ` [PATCH 15/29] wl12xx: make WL1271_FLAG_PSM " Eliad Peller
2011-10-10  8:13 ` [PATCH 16/29] wl12xx: make WL1271_FLAG_STA_STATE_SENT " Eliad Peller
2011-10-10  8:13 ` [PATCH 17/29] wl12xx: make WL1271_FLAG_RX_STREAMING_STARTED " Eliad Peller
2011-10-10  8:13 ` [PATCH 18/29] wl12xx: make WL1271_FLAG_IF_INITIALIZED per-vif Eliad Peller
2011-10-10  8:13 ` [PATCH 19/29] wl12xx: make WL1271_FLAG_PSPOLL_FAILURE flag per-vif Eliad Peller
2011-10-10  8:13 ` [PATCH 20/29] wl12xx: make WL1271_FLAG_CS_PROGRESS " Eliad Peller
2011-10-10  8:13 ` [PATCH 21/29] wl12xx: add band field to wlvif Eliad Peller
2011-10-10 20:38   ` Luciano Coelho
2011-10-10 20:47     ` Eliad Peller
2011-10-11  9:48       ` Victor Goldenshtein
2011-10-10  8:13 ` [PATCH 22/29] wl12xx: add channel " Eliad Peller
2011-10-10  8:13 ` [PATCH 23/29] wl12xx: add power_level " Eliad Peller
2011-10-10  8:13 ` [PATCH 24/29] wl12xx: make op_config configure all vifs Eliad Peller
2011-10-10  8:13 ` [PATCH 25/29] wl12xx: replace all remaining wl->vif references Eliad Peller
2011-10-10  8:13 ` [PATCH 26/29] wl12xx: call stop() on recovery Eliad Peller
2011-10-10  8:13 ` [PATCH 27/29] wl12xx: use dynamic rate policies Eliad Peller
2011-10-10  8:13 ` [PATCH 28/29] wl12xx: add elp wakeup/sleep calls to add_interface Eliad Peller
2011-10-10  8:13 ` [PATCH 29/29] wl12xx: use round-robin policy for tx Eliad Peller
2011-10-11 12:52 ` [PATCH 00/29] make the driver ready for multi-vif support Luciano Coelho

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=1318275602.9690.409.camel@cumari \
    --to=coelho@ti.com \
    --cc=eliad@wizery.com \
    --cc=linux-wireless@vger.kernel.org \
    /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).