gmane.linux.kernel.wireless.general

[PATCH] mac80211: Add routine for retrieving qosnull frame

Soumik Das — 2012-05-26T10:06:21

From: Soumik Das <soumik.das-0IS4wlFg1OjSUeElwK9/Pw< at >public.gmane.org>

Add routine for retrieving qos null template frame.
Driver may need that for uploading it in the device.

Signed-off-by: Soumik Das <soumik.das-0IS4wlFg1OjSUeElwK9/Pw< at >public.gmane.org>
Signed-off-by: Prakhar Vig <prakhar.vig-0IS4wlFg1OjSUeElwK9/Pw< at >public.gmane.org>
---
 include/net/mac80211.h |   16 ++++++++++++++++
 net/mac80211/tx.c      |   38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 1937c7d..10a0529 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
< at >< at > -2876,6 +2876,22 < at >< at > struct sk_buff *ieee80211_nullfunc_get(struct ieee80211_hw *hw,
        struct ieee80211_vif *vif);
 
 /**
+ * ieee80211_qosnullfunc_get - retrieve a qos nullfunc template
+ * < at >hw: pointer obtained from ieee80211_alloc_hw().
+ * < at >vif: &struct ieee80211_vif pointer from the add_interface callback.
+ *
+ * Creates a QOS Nullfunc templat

Re: [ath9k-devel] Anyone doing WiFi throughput tests?

Sujith Manoharan — 2012-05-26T07:43:42

Yes, those numbers are with ath9k, with latest wireless-testing.

Sujith
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/8] brcm80211: smac: rework regulatory support

Luis R. Rodriguez — 2012-05-26T07:19:20

Atheros had similar poo. When I reviewed the architecture behind it,
it was simply a design consideration, it had nothing to with
regulatory. Nothing at all. In fact, all it did was add an overhead of
data.


Same thing here, turns out you can dynamically figure this out based
on the regulatory rules.


It is taken into account. In fact 802.11ac and 802.11ad are thing I've
already have considered as well.


Great!


Thanks,

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/8] brcm80211: smac: rework regulatory support

Arend van Spriel — 2012-05-26T06:38:31

Thanks, Luis. I mainly focused on the crda database and it has a
relation freqs<->pwr_limit. In our regulatory code we make a distinction
between 11n and abg as we believe that is necessary. Another example
would be 20MHz transmission in 40MHz channel. Maybe that is taken into
account in crda code, but I did not have a close look at it yet.

I will have a look at the regsim repository and follow up on that.


Will do.

Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ath9k-devel] Anyone doing WiFi throughput tests?

Joe Semler — 2012-05-26T05:48:20




Am 26.05.2012 um 05:24 schrieb Sujith Manoharan <c_manoha-A+ZNKFmMK5xy9aJCnZT0Uw< at >public.gmane.org>:


Do you use ath9k for that purpouse? I was thinking our driver is not able to operate MIMO.
Some changes that i missed?

JoeSemler
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Anyone doing WiFi throughput tests?

Ben Greear — 2012-05-26T03:17:46

We've been doing some tests using Atheros stations and various APs.  The max throughput
we've seen so far is about 237Mbps (received UDP payload on the stations).
(Open-Air, AP about 5 feet away, 3x3 MIMO, HT40, 5Ghz, etc).

We are still running lots of different permutations, but I am interested if
anyone else has any numbers to share (official or otherwise).

Thanks,
Ben

(unknown)

robothroli company — 2012-05-25T13:45:54

 i am robothroli, Purchase manager from roli Merchant Ltd. We are
Import/export Company based in taiwan. We are interested in purchasing
your product and I would like to make an inquiry. Please inform me on:

Sample availability and price
Minimum order quantity
FOB Prices

Sincerely
Purchase Manager
robothroli



--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/8] brcm80211: smac: rework regulatory support

Luis R. Rodriguez — 2012-05-25T22:51:38

BTW if you would like to address anything please let me know. If you'd like
to review things in private too that's fine, just let me know. I
should say that the staging area for the next generation regulatory
code is being done through the regulatory simulator:

git://github.com/mcgrof/regsim.git

If you have any early stage idea / changes this is where we should be
reviewing / strategizing on them. I should note that this does let you
use the code for regulatory anywhere, the kernel, firmware, whatever.
Due to synch issues with host / firmware database though my
recommendation is obviously to trust the host with the reg data,
unless you resolve the synch issues.

I suppose one way to deal with synch issues as a temporary stage
(before removing firmware reg stuff) is to send the data structure of
the regdomain to firmware so it can base prepare itself / not have any
issues.


Arend, in the future please trim all hunks that are not relevant to
your replies, that makes review easier.

  Luis
--
To unsubscribe

Re: [RFC PATCH 8/8] brcm80211: smac: use current regulatory domain when checking whether OFDM is allowed

Arend van Spriel — 2012-05-25T22:34:34

Reviewed-by: Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>

No comments here.

Gr. AvS


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 6/8] brcm80211: smac: use mac80211 channel data for tx power limits

Arend van Spriel — 2012-05-25T22:33:50

Reviewed-by: Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>

I still have the question on the mimo power limits pending. We can
address it later.

Gr. AvS


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 7/8] brcm80211: smac: don't validate channels against internal regulatory data

Arend van Spriel — 2012-05-25T22:33:58

Reviewed-by: Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>

No comments.

Gr. AvS


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 5/8] brcm80211: smac: enable/disable radio on regulatory updates

Arend van Spriel — 2012-05-25T22:33:31

Reviewed-by: Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>

I think we need to validate the channels against our phy as well. See
brcms_c_channels_init().


could break here when a valid channel is found.


Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 4/8] brcm80211: smac: inform mac80211 of the X2 regulatory domain

Arend van Spriel — 2012-05-25T22:33:15

Reviewed-by: Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>

If channels 12 and 13 are 20MHz only, shouldn't channel 14 above
(2484MHz) be 20MHz as well?


The X2 domain did not support channel 14 so this is cheating ;-)


Row is abbreviation for Rest of World, hence RoW. Come to think of it,
this actually makes the term Worldwide a bit redundant.


You can avoid this code if you/we do not add the channels to
wiphy->bands[IEEE80211_BAND_5GHZ]. The driver does not support DFS so we
better stay away from these channels, which was your original issue to
start this work if I recall correct :-( Sorry.


can save one indent when using else if () immediately here.


can this be moved in brcms_c_channel_mgr_attach()?


Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vg

Re: [RFC PATCH 3/8] brcm80211: smac: clean up channel.c

Arend van Spriel — 2012-05-25T22:33:05

Reviewed-by: Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Brett Rudley <brudley-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>

We are not supporting 40MHz right now, but it is on our roadmap. I would
prefer to keep it, but git can recover it for me when that roadmap item
is due.

Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/8] brcm80211: smac: always set channel specified by mac80211

Arend van Spriel — 2012-05-25T22:32:34

Reviewed-by: Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>

No comments here.

Gr. AvS


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/8] brcm80211: smac: don't set up tx power limits during initialization

Arend van Spriel — 2012-05-25T22:32:17

Reviewed-by: Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>
Reviewed-by: Brett Rudley <brudley-dY08KVG/lbpWk0Htik3J/w< at >public.gmane.org>

No comments on this patch.

Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/8] brcm80211: smac: rework regulatory support

Arend van Spriel — 2012-05-25T22:31:36

You missed an 'e' ;-)


It took a while. There were some discussions and we agreed that your
changes establish a better integration with the regulatory framework.
There are some concerns about the content of the crda database, but that
is another thing outside the scope of your patches.


Appreciated. We can add/change in subsequent patches. I collected review
comments internally including mine. I will provide them in response to
each individual patch.

General comment: you should run 'checkpatch.pl --strict' script over the
patches. I came across several issues that will probably be flagged by it.

Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BCM4331 tx failures after S3

Arend van Spriel — 2012-05-25T20:59:37

Ok. I dived into b43 and it does disable the wireless core in the
.stop() callback. So I believe it does reinitialize the device when
.start() callback is being called after resume. So I think you should
check the chipctl register at the end of the .start() callback.


I assume you mean bcma instead of b43, right? I admit it is a bit shady,
because bcma is more than just a bus driver. It also contains drivers
for the chipcommon and pcie cores on the device.

Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BCM4331 tx failures after S3

Seth Forshee — 2012-05-25T20:44:59

I don't think your missing it. There doesn't seem to be a resume handler
in b43.


Before. I printed the value from bcma_host_pci_resume().

I can easily make a patch that fixes the chipctl register up as needed
during resume to fix my problem. But based on the fact that other fields
in the register are also changing value, I'm wondering if more thorough
handling is needed for the register. And I'm also a little fuzzy on
exactly who should be responsible for what in the relationship between
b43 and the wireless drivers.

Thanks,
Seth

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcmsmac and BCM47186 (BCM5357) + brcmfmac and BCM43236 V2

Arend van Spriel — 2012-05-25T20:32:44

Sorry for the late response. Found it ready and waiting in my Drafts
folder :-S


We are planning to add support for bcm43227/228. This requires an update
in the n-phy code.


I expect you changed some brcmsmac code allow it to handle your device.
Correct?


I had to dive into the firmware repo myself and the answer is yes. The
published firmware for brcmsmac only supports the corerev of the chips
it currently supports.


There is no fullmac firmware for Rev 1 and 2 as these simply lack
on-chip memory to do so. These devices use a different driver model.
This model has a different split of functionality between device and
host. Neither brcmsmac nor brcmfmac can support devices using that model.

Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BCM4331 tx failures after S3

Arend van Spriel — 2012-05-25T20:19:43

Yes, that is my suggestion. I dived into the b43 driver, but I do not
see a .resume callback for bcma:

static struct bcma_driver b43_bcma_driver = {
.name= KBUILD_MODNAME,
.id_table= b43_bcma_tbl,
.probe= b43_bcma_probe,
.remove= b43_bcma_remove,
};

So upon suspend/resume b43 seems to take no extra steps, but I may be
missing it as I am not a b43 specialist (let me CC the b43 developer
list :-) ).

In brcmsmac the brcms_b_hw_up() is called in brcms_c_up() when the flag
hw_up is false:

int brcms_c_up(struct brcms_c_info *wlc)
{
if (!wlc->pub->hw_up) {
brcms_b_hw_up(wlc->hw);
wlc->pub->hw_up = true;
}

/* Initialize just the hardware when coming out of POR or S3/S5 system
states */
static void brcms_b_hw_up(struct brcms_hardware *wlc_hw)

You are right that this particular code does not fiddle with
BCMA_CC_CHIPCTL. Where in the code did you print the value of this
register? Before or after the mac80211 .start() callback has been called?

Gr. AvS

--
To unsubscribe from this list: send the