From: Johannes Berg <johannes@sipsolutions.net>
To: Seth Forshee <seth.forshee@canonical.com>
Cc: linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org,
brcm80211-dev-list@broadcom.com,
"John W. Linville" <linville@tuxdriver.com>,
Stefano Brivio <stefano.brivio@polimi.it>,
Arend van Spriel <arend@broadcom.com>
Subject: Re: [RFC PATCH 2/8] mac80211: Add per-interface powersave states and parameters
Date: Tue, 17 Dec 2013 09:11:38 +0100 [thread overview]
Message-ID: <1387267898.4749.4.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <1387231260-2849-3-git-send-email-seth.forshee@canonical.com> (sfid-20131216_230108_711579_9783326A)
On Mon, 2013-12-16 at 16:00 -0600, Seth Forshee wrote:
> In preparation for managing powersave states on a per-interface
> basis, add powersave states and parameters to the interface-
> specific data structures. Also add a change_ps driver callback
> to notify drivers about changes to interface powersave states.
>
> The new members and callback are unused here but will be
> utilized by subsequent commits.
Can't say I like that part much, it just makes it harder to review.
> /**
> + * enum ieee80211_vif_ps_mode - virtual interface power save mode
> + *
> + * Ordered in terms of increasing wakefulness.
> + *
> + * @IEEE80211_VIF_PS_INACTIVE: the interface is not currently open
> + * @IEEE80211_VIF_PS_DOZE: the interface is in a low-power mode and may
> + * not be able to transmit or receive frames
> + * @IEEE80211_VIF_PS_AWAKE_PM: the interface is awake and able to transmit
> + * and receive frames but PM may be set in frame control
> + * @IEEE80211_VIF_PS_AWAKE: the interface is fully awake and able to
> + * transmit and receive frames
> + */
> +enum ieee80211_vif_ps_mode {
> + IEEE80211_VIF_PS_INACTIVE,
Does this INACTIVE thing really make sense? It should just be undefined
if it's not associated, no? Doing this might make people want to rely on
this to indicate associated-ness or something...
> + IEEE80211_VIF_PS_AWAKE_PM,
> + IEEE80211_VIF_PS_AWAKE,
The distinction between these seems somewhat unclear? "PM may be set"?
> + * @ps_mode: power save mode of this vif
> + * @dynamic_ps_active: indicates whether dynamic PS is active for this vif
> + * @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
> + * powersave documentation below. This variable is valid only when
> + * the interface is in the doze state.
> + * @max_sleep_period: the maximum number of beacon intervals to sleep for
> + * before checking the beacon for a TIM bit (managed mode only); this
> + * value will be only achievable between DTIM frames, the hardware
> + * needs to check for the multicast traffic bit in DTIM beacons.
> + * This variable is valid only when the interface is in the doze state.
> + * @ps_dtim_period: The DTIM period of the AP we're connected to, for use
> + * in power saving. Power saving will not be enabled until a beacon
> + * has been received and the DTIM period is known.
Should these really be in the vif struct? They still seem somewhat
internal to the implementation.
johannes
next prev parent reply other threads:[~2013-12-17 8:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 22:00 [RFC/RFT] mac80211 powersave rework Seth Forshee
2013-12-16 22:00 ` [RFC PATCH 1/8] mac80211: Move dynamic PS data out of common code Seth Forshee
2013-12-17 8:08 ` Johannes Berg
2013-12-17 12:37 ` Seth Forshee
2013-12-16 22:00 ` [RFC PATCH 2/8] mac80211: Add per-interface powersave states and parameters Seth Forshee
2013-12-17 8:11 ` Johannes Berg [this message]
2013-12-17 13:12 ` Seth Forshee
2013-12-16 22:00 ` [RFC PATCH 3/8] mac80211: Add powersave module Seth Forshee
2013-12-17 8:16 ` Johannes Berg
2013-12-17 13:31 ` Seth Forshee
2013-12-16 22:00 ` [RFC PATCH 4/8] mac80211: Use PS module for managed mode powersave Seth Forshee
2013-12-17 8:25 ` Johannes Berg
2013-12-17 14:09 ` Seth Forshee
2013-12-16 22:00 ` [RFC PATCH 5/8] mac80211: Don't start dynamic PS timer when leaving off-channel if still scanning Seth Forshee
2013-12-16 22:00 ` [RFC PATCH 6/8] brcmsmac: Set MCTL_HPS when PM should be set Seth Forshee
2013-12-16 22:00 ` [RFC PATCH 7/8] b43: Allow HWPS state to be changed Seth Forshee
2013-12-16 22:01 ` [RFC PATCH 8/8] b43: Set B43_MACCTL_HWPS when PM should be set Seth Forshee
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=1387267898.4749.4.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=arend@broadcom.com \
--cc=b43-dev@lists.infradead.org \
--cc=brcm80211-dev-list@broadcom.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=seth.forshee@canonical.com \
--cc=stefano.brivio@polimi.it \
/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).