From: Juuso Oikarinen <[email protected]>
The .11h features are mandatory along with .11a items. These patches add some
of missing .11h stuff (major parts for DFS and TPC.)
However, some things are still to TODO after these:
- Quieting
- TPC Basic reporting - currently mac80211 is always responding with a
'refused' status, but that is not exactly in the spirit of the .11h spec
Juuso Oikarinen (2):
wl12xx: Enable the IEEE80211_HW_SPECTRUM_MGMT hw flag
wl12xx: Add a rule for WLAN_EID_PWR_CONSTRAINT in the beacon filter
drivers/net/wireless/wl12xx/main.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
From: Juuso Oikarinen <[email protected]>
It's mandatory to support this along with 11a.
Signed-off-by: Juuso Oikarinen <[email protected]>
---
drivers/net/wireless/wl12xx/main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index dfab21e..bc09812 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -3215,7 +3215,8 @@ int wl1271_init_ieee80211(struct wl1271 *wl)
IEEE80211_HW_SUPPORTS_UAPSD |
IEEE80211_HW_HAS_RATE_CONTROL |
IEEE80211_HW_CONNECTION_MONITOR |
- IEEE80211_HW_SUPPORTS_CQM_RSSI;
+ IEEE80211_HW_SUPPORTS_CQM_RSSI |
+ IEEE80211_HW_SPECTRUM_MGMT;
wl->hw->wiphy->cipher_suites = cipher_suites;
wl->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
--
1.7.1
On Wed, 2011-01-26 at 11:02 +0200, Juuso Oikarinen wrote:
> Well I guess I'm stating the obvious here. The effects of the flag are:
>
> - It causes mac80211 to add the spectrum mgmt capability bit, list of
> supported channels and TX power capability info into the assoc-req
> - It causes mac80211 to process channel switch actions
> - It causes mac80211 to process and react to TPC power constraint
> elements sent out in beacons
> - It causes mac80211 to respond to TPC report requests by the AP, albeit
> currently only by refusing them.
Right. But all of this is generic, no? Except maybe TPC?
> In addition to this, I plan to implement the TPC basic reporting,
> including mac80211 stuff if required (I still need to learn some more on
> the subject, specifically regarding the wl12xx chipset) and also I plan
> to implement quieting, though it's likely that wont need mac80211
> intervention with wl12xx at least.
>
> AFAIK all these items are mandatory on the 5GHz band, at least in
> Europe.
>
> So I don't see how this flag could be removed. Unless you wan't to make
> the above default behavior - but then adding for instance the spectrum
> mgmt bit into the capabilities assumes all chipset will be able handle
> all of the features?
Yeah, I was thinking those should be default, and the actual TPC
reporting would of course depend on hardware features? But then again
maybe TPC itself isn't necessarily implemented by drivers since not all
drivers implement setting the power correctly.
johannes
On Wed, 2011-01-26 at 10:04 +0100, ext Johannes Berg wrote:
> On Wed, 2011-01-26 at 11:02 +0200, Juuso Oikarinen wrote:
>
> > Well I guess I'm stating the obvious here. The effects of the flag are:
> >
> > - It causes mac80211 to add the spectrum mgmt capability bit, list of
> > supported channels and TX power capability info into the assoc-req
> > - It causes mac80211 to process channel switch actions
> > - It causes mac80211 to process and react to TPC power constraint
> > elements sent out in beacons
> > - It causes mac80211 to respond to TPC report requests by the AP, albeit
> > currently only by refusing them.
>
> Right. But all of this is generic, no? Except maybe TPC?
>
> > In addition to this, I plan to implement the TPC basic reporting,
> > including mac80211 stuff if required (I still need to learn some more on
> > the subject, specifically regarding the wl12xx chipset) and also I plan
> > to implement quieting, though it's likely that wont need mac80211
> > intervention with wl12xx at least.
> >
> > AFAIK all these items are mandatory on the 5GHz band, at least in
> > Europe.
> >
> > So I don't see how this flag could be removed. Unless you wan't to make
> > the above default behavior - but then adding for instance the spectrum
> > mgmt bit into the capabilities assumes all chipset will be able handle
> > all of the features?
>
> Yeah, I was thinking those should be default, and the actual TPC
> reporting would of course depend on hardware features? But then again
> maybe TPC itself isn't necessarily implemented by drivers since not all
> drivers implement setting the power correctly.
This *is* mandatory stuff, so in that perspective I guess it would make
sense to remove the flag and make all of this default behavior. Indeed
the mac80211 could be made to refuse the TCP basic reports unless the
driver provides a call-back for that or sth like that.
Also, I guess it would be a valid assumption all drivers supporting the
5GHz band would also support setting the TX power - otherwise they will
possibly violate regulations anyway - whether they say they state or not
they have the specturm mgmt capability makes little difference.
As I mentioned, I plan to implement basic reporting once I find out how
to do that - so I will be reviewing this functionality some more later.
Maybe, if you like, I can consider removing the flag at that point?
-Juuso
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2011-01-26 at 09:31 +0100, ext Johannes Berg wrote:
> On Wed, 2011-01-26 at 10:29 +0200, [email protected] wrote:
> > From: Juuso Oikarinen <[email protected]>
> >
> > + IEEE80211_HW_SPECTRUM_MGMT;
>
> I once had a patch to remove this flag completely since it has very
> little effect at all on mac80211. Can I convince you to review the flag
> use in mac80211 and tell me why you think it is, or not, present?
>
> johannes
Well I guess I'm stating the obvious here. The effects of the flag are:
- It causes mac80211 to add the spectrum mgmt capability bit, list of
supported channels and TX power capability info into the assoc-req
- It causes mac80211 to process channel switch actions
- It causes mac80211 to process and react to TPC power constraint
elements sent out in beacons
- It causes mac80211 to respond to TPC report requests by the AP, albeit
currently only by refusing them.
In addition to this, I plan to implement the TPC basic reporting,
including mac80211 stuff if required (I still need to learn some more on
the subject, specifically regarding the wl12xx chipset) and also I plan
to implement quieting, though it's likely that wont need mac80211
intervention with wl12xx at least.
AFAIK all these items are mandatory on the 5GHz band, at least in
Europe.
So I don't see how this flag could be removed. Unless you wan't to make
the above default behavior - but then adding for instance the spectrum
mgmt bit into the capabilities assumes all chipset will be able handle
all of the features?
-Juuso
-Juuso
On Wed, 2011-01-26 at 10:29 +0200, [email protected] wrote:
> From: Juuso Oikarinen <[email protected]>
>
> It's mandatory to support this along with 11a.
>
> Signed-off-by: Juuso Oikarinen <[email protected]>
> ---
> drivers/net/wireless/wl12xx/main.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
> index dfab21e..bc09812 100644
> --- a/drivers/net/wireless/wl12xx/main.c
> +++ b/drivers/net/wireless/wl12xx/main.c
> @@ -3215,7 +3215,8 @@ int wl1271_init_ieee80211(struct wl1271 *wl)
> IEEE80211_HW_SUPPORTS_UAPSD |
> IEEE80211_HW_HAS_RATE_CONTROL |
> IEEE80211_HW_CONNECTION_MONITOR |
> - IEEE80211_HW_SUPPORTS_CQM_RSSI;
> + IEEE80211_HW_SUPPORTS_CQM_RSSI |
> + IEEE80211_HW_SPECTRUM_MGMT;
I once had a patch to remove this flag completely since it has very
little effect at all on mac80211. Can I convince you to review the flag
use in mac80211 and tell me why you think it is, or not, present?
johannes
From: Juuso Oikarinen <[email protected]>
The WLAN_EID_PWR_CONSTRAINT is used in .11h to pass a local TX power
constraint value, and may change any time.
Add a rule to the beacon filter to pass any beacons with this value changed,
so that it may be properly handled.
Signed-off-by: Juuso Oikarinen <[email protected]>
---
drivers/net/wireless/wl12xx/main.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index bc09812..8996ce2 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -239,11 +239,15 @@ static struct conf_drv_settings default_conf = {
.wake_up_event = CONF_WAKE_UP_EVENT_DTIM,
.listen_interval = 1,
.bcn_filt_mode = CONF_BCN_FILT_MODE_ENABLED,
- .bcn_filt_ie_count = 1,
+ .bcn_filt_ie_count = 2,
.bcn_filt_ie = {
[0] = {
.ie = WLAN_EID_CHANNEL_SWITCH,
.rule = CONF_BCN_RULE_PASS_ON_APPEARANCE,
+ },
+ [1] = {
+ .ie = WLAN_EID_PWR_CONSTRAINT,
+ .rule = CONF_BCN_RULE_PASS_ON_CHANGE,
}
},
.synch_fail_thold = 10,
--
1.7.1
On Wed, 2011-01-26 at 11:17 +0200, Juuso Oikarinen wrote:
> On Wed, 2011-01-26 at 10:04 +0100, ext Johannes Berg wrote:
> > On Wed, 2011-01-26 at 11:02 +0200, Juuso Oikarinen wrote:
> >
> > > Well I guess I'm stating the obvious here. The effects of the flag are:
> > >
> > > - It causes mac80211 to add the spectrum mgmt capability bit, list of
> > > supported channels and TX power capability info into the assoc-req
> > > - It causes mac80211 to process channel switch actions
> > > - It causes mac80211 to process and react to TPC power constraint
> > > elements sent out in beacons
> > > - It causes mac80211 to respond to TPC report requests by the AP, albeit
> > > currently only by refusing them.
> >
> > Right. But all of this is generic, no? Except maybe TPC?
> >
> > > In addition to this, I plan to implement the TPC basic reporting,
> > > including mac80211 stuff if required (I still need to learn some more on
> > > the subject, specifically regarding the wl12xx chipset) and also I plan
> > > to implement quieting, though it's likely that wont need mac80211
> > > intervention with wl12xx at least.
> > >
> > > AFAIK all these items are mandatory on the 5GHz band, at least in
> > > Europe.
> > >
> > > So I don't see how this flag could be removed. Unless you wan't to make
> > > the above default behavior - but then adding for instance the spectrum
> > > mgmt bit into the capabilities assumes all chipset will be able handle
> > > all of the features?
> >
> > Yeah, I was thinking those should be default, and the actual TPC
> > reporting would of course depend on hardware features? But then again
> > maybe TPC itself isn't necessarily implemented by drivers since not all
> > drivers implement setting the power correctly.
>
> This *is* mandatory stuff, so in that perspective I guess it would make
> sense to remove the flag and make all of this default behavior. Indeed
> the mac80211 could be made to refuse the TCP basic reports unless the
> driver provides a call-back for that or sth like that.
>
> Also, I guess it would be a valid assumption all drivers supporting the
> 5GHz band would also support setting the TX power - otherwise they will
> possibly violate regulations anyway - whether they say they state or not
> they have the specturm mgmt capability makes little difference.
>
> As I mentioned, I plan to implement basic reporting once I find out how
> to do that - so I will be reviewing this functionality some more later.
> Maybe, if you like, I can consider removing the flag at that point?
Sure, makes sense, thanks for looking.
johannes