Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Tomas Winkler <tomasw@gmail.com>
Cc: linville@tuxdriver.com, yi.zhu@intel.com,
	linux-wireless@vger.kernel.org,
	Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Subject: Re: [PATCH 1/2 V2] mac80211: send action frame when toggling SM PS mode
Date: Thu, 02 Oct 2008 13:15:49 +0200	[thread overview]
Message-ID: <1222946149.24551.49.camel@johannes.berg> (raw)
In-Reply-To: <1ba2fa240810020403r56d02416k60f45e9e6fb95fd8@mail.gmail.com> (sfid-20081002_130345_325234_6F0CD7F5)

[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]

On Thu, 2008-10-02 at 14:03 +0300, Tomas Winkler wrote:

> >> +static void ieee80211_send_sm_ps(struct ieee80211_sub_if_data *sdata, u8 mode)
> >
> > Can we use an enum for 'mode'?
> 
> We use spec numbers here why to invent more numbers.

Well we can also just put the spec numbers into an enum and use that
enum here. enum doesn't mean that we don't fix the numbers :)

> >> +     /* Implemented for STA only */
> >> +     if (sdata->vif.type != NL80211_IFTYPE_STATION)
> >> +             return;
> >
> > What about mesh, ibss, wds, ...? I see this doesn't make much sense for
> > an AP, but...?
> 
> This is explicitly defined in spec for STA mode.

Ok. Maybe change the comment then so that it's more obvious.

> > It seems that for the second use case you're citing you've now done
> > something that might lead to bouncing back and forth because there is no
> > central instance deciding on the powersave mode. You seem to be trying
> > to avoid this by introducing the two new variables sm_ps_psp_mode and
> > sm_ps_cam_mode, but this seems very strange. Is the driver supposed to
> > modify them at runtime?
> 
> No it should be set on registration only
> 
> What sort of policy does the driver impose on
> > them? Why is this policy driver-specific?
> 
> Depends on radio ability rather then policy. The only policy that is
> set here is that we coupling SM PS and PS
> 
> Why doesn't the driver just
> > inform mac80211 of the antenna status and mac80211 then decides based on
> > the antenna status and the requested powersave mode which SM PS mode
> > should be activated, and then notifies the driver of that?
> 
> Correct that's the solution, just keep in mind that driver change rx
> chain configuration upon SM PS request as well.

Yeah but you were saying it's about detecting whether MIMO is effective
or not. So I think what makes more sense is to have the driver _only_
push that information to mac80211, and then wait for mac80211 to make a
decision about the SM PS mode, and not reconfigure its chains
immediately. Therefore, it wouldn't change chain configuration when it
detects MIMO doesn't work, it would only do that when mac80211 requests
it based on the information.

> > I'd much rather see you implement this in a different way:
> >  * a HW flag that determines whether the driver can wake up with or
> >   without an RTS frame (?)
> 
> Not enough there are 3 states you may request in SM_PS

Yes, but this is just a hardware capability which indirectly influences
the PS mode, no? So not having the wakeup-without-rts capability may
mean that SM_PS_XYZ cannot be used or whatever.

> >   - possibly interface modes (maybe no need for MIMO when in mesh etc.)
> 
> Out of scope, HT is not enabled at all in these modes.

currently.

I'll look at more details after lunch.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2008-10-02 11:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-30 20:07 [PATCH 1/2 V2] mac80211: send action frame when toggling SM PS mode Tomas Winkler
2008-09-30 20:07 ` [PATCH 2/2] mac80211: modify SM_PS state upon change in power save state Tomas Winkler
2008-10-02  8:37 ` [PATCH 1/2 V2] mac80211: send action frame when toggling SM PS mode Johannes Berg
2008-10-02 11:03   ` Tomas Winkler
2008-10-02 11:15     ` Johannes Berg [this message]

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=1222946149.24551.49.camel@johannes.berg \
    --to=johannes@sipsolutions.net \
    --cc=emmanuel.grumbach@intel.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=tomasw@gmail.com \
    --cc=yi.zhu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox