* Re: [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Valo, Kalle @ 2016-10-12 4:59 UTC (permalink / raw)
To: Yeoh Chun-Yeow
Cc: Kolli, Anilkumar, akolli@codeaurora.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAEFj985tCc_4Q_zfwRtoT0fjfZv0u_c5E8SRSQVz=V4tiHh+GA@mail.gmail.com>
Yeoh Chun-Yeow <yeohchunyeow@gmail.com> writes:
> On Fri, Oct 7, 2016 at 10:58 PM, <akolli@qti.qualcomm.com> wrote:
>> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>>
>> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
>> event, Firmware sends one HTT event for every four PPDUs.
>> HTT payload has success pkts/bytes, failed pkts/bytes, retry
>> pkts/bytes and rate info per ppdu.
>> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
>> which are nowadays enabled by default.
>>
>> Parse peer stats and update the tx rate information per STA.
>>
>> tx rate, Peer stats are tested on QCA4019 with Firmware version
>> 10.4-3.2.1-00028.
>>
>
> Is QCA988X supported? I have tried to test with
> firmware-5.bin_10.2.4.70.56 but not working.
My understanding is that 10.2 branch does not have this feature,
unfortunately.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Chris Rorvick @ 2016-10-12 4:32 UTC (permalink / raw)
To: Paul Bolle
Cc: Luca Coelho, Intel Linux Wireless, Emmanuel Grumbach,
Johannes Berg, Kalle Valo, Oren Givon, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1476180668.17022.21.camel@tiscali.nl>
On Tue, Oct 11, 2016 at 5:11 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> For what it's worth, on my machine I have twenty (!) SPLX entries, all
> reading:
> Name (SPLX, Package (0x04)
> {
> Zero,
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> },
>
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> },
>
> Package (0x03)
> {
> 0x80000000,
> 0x80000000,
> 0x80000000
> }
> })
I actually see exactly the same on my Dell XPS 13 (9350) when I use
acpidump, etc. I typed the entry I included in the commit log by hand
based on what the driver gets back from the SPLC method (I added a
function to dump the returned object.)
Chris
^ permalink raw reply
* Re: [PATCH] docs-rst: sphinxify 802.11 documentation
From: Johannes Berg @ 2016-10-11 22:08 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-wireless
In-Reply-To: <20161011153911.6a0f778c@lwn.net>
> I could live with that, I guess, though I'm not thrilled with the
> idea.
>
> As an alternative, one or the other of us could just send it up in
> the next couple of days and be done with it. I'd say the chances of
> regressions are pretty small...:) If you want to do that, feel free
> to add my ack. If you'd rather I sent it, just say the word.
Ok, fair enough. Please go ahead, I'll ask davem to pull it back in
when I need it. You'll get it through to Linus quicker than me :)
johannes
^ permalink raw reply
* Re: [PATCH] docs-rst: sphinxify 802.11 documentation
From: Jonathan Corbet @ 2016-10-11 21:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1476192636.4118.8.camel@sipsolutions.net>
On Tue, 11 Oct 2016 15:30:36 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> Maybe I can just take the relevant header file change through my tree?
>
> It would cause the following warning to appear in your tree:
>
> include/net/cfg80211.h:3093: WARNING: Definition list ends without a blank line; unexpected unindent.
> include/net/cfg80211.h:3095: ERROR: Unexpected indentation.
> include/net/cfg80211.h:3099: WARNING: Block quote ends without a blank line; unexpected unindent.
> include/net/cfg80211.h:3107: WARNING: Definition list ends without a blank line; unexpected unindent.
> include/net/cfg80211.h:3109: ERROR: Unexpected indentation.
> include/net/cfg80211.h:3113: WARNING: Block quote ends without a blank line; unexpected unindent.
> include/net/cfg80211.h:3123: ERROR: Unexpected indentation.
> include/net/cfg80211.h:3124: WARNING: Definition list ends without a blank line; unexpected unindent.
> include/net/cfg80211.h:3126: ERROR: Unexpected indentation.
> include/net/cfg80211.h:3130: WARNING: Block quote ends without a blank line; unexpected unindent.
>
> for the time being - perhaps you can live with that, until my changes
> also propagate through to the tree?
I could live with that, I guess, though I'm not thrilled with the idea.
As an alternative, one or the other of us could just send it up in the
next couple of days and be done with it. I'd say the chances of
regressions are pretty small...:) If you want to do that, feel free to
add my ack. If you'd rather I sent it, just say the word.
jon
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Arend van Spriel @ 2016-10-11 19:12 UTC (permalink / raw)
To: Gucea Doru
Cc: Krishna Chaitanya, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <CANfLQra_Vh4cnHvpzU9yxv4_6SJEc1LN8Vqm4-11thOLvGxY2Q@mail.gmail.com>
On 07-10-16 16:33, Gucea Doru wrote:
> On Thu, Oct 6, 2016 at 10:25 AM, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 6-10-2016 10:07, Gucea Doru wrote:
>>> On Wed, Oct 5, 2016 at 11:12 AM, Arend Van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>> On 4-10-2016 13:39, Gucea Doru wrote:
>>>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>>>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>>>>> mode.
>>>>>>>>
>>>>>>>>
>>>>>>>> Any help would be highly appreciated :)
>>>>>>>
>>>>>>> Actually though I already sent you are reply, but alas here it is.
>>>>>>>
>>>>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>>>>> drivers. Regardless your question is more for firmware running on the
>>>>>>> device. So like the same behavior would be observed when using brcmfmac
>>>>>>> with same firmware.
>>>>>>>
>>>>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>>>>> exits the PS mode without waiting for a beacon.
>>>>>>>
>>>>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>>>>> should be in power-save at any other time. So it is difficult to say
>>>>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>>>>> is just some things I can come up with and I am sure there are more.
>>>>>
>>>>> I agree that there may be some events belonging to the regular STA
>>>>> interface that could trigger the Null Frame (which includes the exit
>>>>> from PS Mode). However, I would expect to see some management frames
>>>>> in the air before/after the Null Packet (e.g.: a Probe request in case
>>>>> of a scheduled scan). But in my case the trigger for the Null frame
>>>>> seems to be the ping request packet, the scenario is the same every
>>>>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>>>>> confirms this behavior).
>>>>>
>>>>> I thought that you had a power save optimization algorithm that keeps
>>>>> the card on a few milliseconds just to see if we can have a fast reply
>>>>> from the peer. Does this ring a bell? :)
>>>>
>>>> It does not. That would be implemented in firmware. As said I am working
>>>> on brcmfmac/brcmsmac. So bcmdhd and firmware are not my expertise.
>>>>
>>>
>>> Arend, could you please redirect me to a Broadcom firmware maintainer?
>>
>> Can you please elaborate on your platform, broadcom chipset, and what
>> version of bcmdhd you are using.
>>
>
> Platform: Nexus 5 running CM13 (Android 6.0.1)
> Broadcom chipset: BCM4339 Wi-Fi Chipset
> bcmdhd version:Dongle Host Driver, version 1.88.45 (r)
>
> Do you need more information?
So can you indicate the mac addresses of the two nexus devices and which
one is P2P-GO. I entered the wpa key you mentioned in your initial
email, but my wireshark does not seem to be able to decrypt the packets,
which makes it a bit harder to analyze.
Regards,
Arend
^ permalink raw reply
* [PATCH] Revert "ath9k_hw: implement temperature compensation support for AR9003+"
From: Felix Fietkau @ 2016-10-11 17:46 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
This reverts commit 171f6402e4aa5cd3b8407f82501f7ea21fa54ccc.
Some users report that this commit causes a regression in performance
under some conditions.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 25 +++----------------------
drivers/net/wireless/ath/ath9k/hw.h | 1 -
2 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index b6f064a..7e27a06 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -33,7 +33,6 @@ struct coeff {
enum ar9003_cal_types {
IQ_MISMATCH_CAL = BIT(0),
- TEMP_COMP_CAL = BIT(1),
};
static void ar9003_hw_setup_calibration(struct ath_hw *ah,
@@ -59,12 +58,6 @@ static void ar9003_hw_setup_calibration(struct ath_hw *ah,
/* Kick-off cal */
REG_SET_BIT(ah, AR_PHY_TIMING4, AR_PHY_TIMING4_DO_CAL);
break;
- case TEMP_COMP_CAL:
- ath_dbg(common, CALIBRATE,
- "starting Temperature Compensation Calibration\n");
- REG_SET_BIT(ah, AR_CH0_THERM, AR_CH0_THERM_LOCAL);
- REG_SET_BIT(ah, AR_CH0_THERM, AR_CH0_THERM_START);
- break;
default:
ath_err(common, "Invalid calibration type\n");
break;
@@ -93,8 +86,7 @@ static bool ar9003_hw_per_calibration(struct ath_hw *ah,
/*
* Accumulate cal measures for active chains
*/
- if (cur_caldata->calCollect)
- cur_caldata->calCollect(ah);
+ cur_caldata->calCollect(ah);
ah->cal_samples++;
if (ah->cal_samples >= cur_caldata->calNumSamples) {
@@ -107,8 +99,7 @@ static bool ar9003_hw_per_calibration(struct ath_hw *ah,
/*
* Process accumulated data
*/
- if (cur_caldata->calPostProc)
- cur_caldata->calPostProc(ah, numChains);
+ cur_caldata->calPostProc(ah, numChains);
/* Calibration has finished. */
caldata->CalValid |= cur_caldata->calType;
@@ -323,16 +314,9 @@ static const struct ath9k_percal_data iq_cal_single_sample = {
ar9003_hw_iqcalibrate
};
-static const struct ath9k_percal_data temp_cal_single_sample = {
- TEMP_COMP_CAL,
- MIN_CAL_SAMPLES,
- PER_MAX_LOG_COUNT,
-};
-
static void ar9003_hw_init_cal_settings(struct ath_hw *ah)
{
ah->iq_caldata.calData = &iq_cal_single_sample;
- ah->temp_caldata.calData = &temp_cal_single_sample;
if (AR_SREV_9300_20_OR_LATER(ah)) {
ah->enabled_cals |= TX_IQ_CAL;
@@ -340,7 +324,7 @@ static void ar9003_hw_init_cal_settings(struct ath_hw *ah)
ah->enabled_cals |= TX_IQ_ON_AGC_CAL;
}
- ah->supp_cals = IQ_MISMATCH_CAL | TEMP_COMP_CAL;
+ ah->supp_cals = IQ_MISMATCH_CAL;
}
#define OFF_UPPER_LT 24
@@ -1399,9 +1383,6 @@ static void ar9003_hw_init_cal_common(struct ath_hw *ah)
INIT_CAL(&ah->iq_caldata);
INSERT_CAL(ah, &ah->iq_caldata);
- INIT_CAL(&ah->temp_caldata);
- INSERT_CAL(ah, &ah->temp_caldata);
-
/* Initialize current pointer to first element in list */
ah->cal_list_curr = ah->cal_list;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 2a5d3ad..9cbca12 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -830,7 +830,6 @@ struct ath_hw {
/* Calibration */
u32 supp_cals;
struct ath9k_cal_list iq_caldata;
- struct ath9k_cal_list temp_caldata;
struct ath9k_cal_list adcgain_caldata;
struct ath9k_cal_list adcdc_caldata;
struct ath9k_cal_list *cal_list;
--
2.10.1
^ permalink raw reply related
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Chris Rorvick @ 2016-10-11 14:27 UTC (permalink / raw)
To: Paul Bolle
Cc: Luca Coelho, Intel Linux Wireless, Emmanuel Grumbach,
Johannes Berg, Kalle Valo, Oren Givon, linux-wireless, netdev,
linux-kernel
In-Reply-To: <CAEUsAPYDPCP0NBaTmy4xqFJhAS4xFQYinoNTknxFT23ef0dk4w@mail.gmail.com>
On Tue, Oct 11, 2016 at 9:09 AM, Chris Rorvick <chris@rorvick.com> wrote:
> I didn't receive your email so I'll try to respond via Paul's.
>>> If this is really bothering you, I guess I could apply this patch for
>>> now. But as I said, this is not solving the actual problem.
>>
>> Bikeshedding: I think IWL_INFO() is more appropriate, as info doesn't
>> imply one needs to act on this message, while warn does imply that
>> action is needed.
>
> Agreed. I still think making this a warning is appropriate, but it
> seems pretty clear this is not an error. This has nothing to do with
> how much it bothers me. An error tells the user something needs to be
> fixed, but in this case the interface is working fine. Making it a
> warning with an improved message will result in fewer people wasting
> their time.
I found your original email on lkml.org... should have looked there in
the first place! Yes, if there is a fix for the underlying issue then
that is obviously preferred. When I investigated this I saw several
reports spanning at least a few distros and kernel versions with at
least some concluding "this is normal".
Again, thanks!
Chris
^ permalink raw reply
* Re: [PATCH] docs-rst: sphinxify 802.11 documentation
From: Johannes Berg @ 2016-10-11 13:30 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-wireless
In-Reply-To: <20161011072119.7ad4e3a3@lwn.net>
> > Jon, unless you have strong objections, I'd like to take this
> > through my tree due to the header file changes.
>
> Is there any chance of splitting those two things up? In particular,
> index.rst has become a real conflict point, and I'm getting tired of
> explaining those to Linus...so I'd prefer to carry that part if
> possible.
Hmm. It may be easier then to take this through your tree entirely.
I could split it, and ask you to add only the index.rst change.
However, if this is a contention point, then the DocBook/Makefile will
also be the same contention point at least as far as conversions are
concerned, and if I don't have *that* in my tree either then the
(documentation) build will be broken by the removal of the template.
So ultimately then it'll be better for you to just take almost all of
the conversion through your tree.
The header file changes normally wouldn't be a big deal, they're in
comments only, but in this case I know that we have a work-in-progress
patch submission that will change things here, and I'd like that to
already use the new format.
Maybe I can just take the relevant header file change through my tree?
It would cause the following warning to appear in your tree:
include/net/cfg80211.h:3093: WARNING: Definition list ends without a blank line; unexpected unindent.
include/net/cfg80211.h:3095: ERROR: Unexpected indentation.
include/net/cfg80211.h:3099: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/cfg80211.h:3107: WARNING: Definition list ends without a blank line; unexpected unindent.
include/net/cfg80211.h:3109: ERROR: Unexpected indentation.
include/net/cfg80211.h:3113: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/cfg80211.h:3123: ERROR: Unexpected indentation.
include/net/cfg80211.h:3124: WARNING: Definition list ends without a blank line; unexpected unindent.
include/net/cfg80211.h:3126: ERROR: Unexpected indentation.
include/net/cfg80211.h:3130: WARNING: Block quote ends without a blank line; unexpected unindent.
for the time being - perhaps you can live with that, until my changes
also propagate through to the tree?
Alternatively, I could merge the header file change, and hold this
patch until my changes hit the tree, but that will be a long time
coming, presumably, since I'll have missed the merge window with both
of the changes.
johannes
^ permalink raw reply
* Re: [PATCH] docs-rst: sphinxify 802.11 documentation
From: Johannes Berg @ 2016-10-11 13:53 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-wireless
In-Reply-To: <1476193466.4118.10.camel@sipsolutions.net>
>
> Related question: I have some sequence diagrams, and just found the
> seqdiag sphinx plugin. How should we manage adding extensions? Or
> would you prefer not to add any at all?
Example here:
https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow
johannes
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Chris Rorvick @ 2016-10-11 14:09 UTC (permalink / raw)
To: Paul Bolle
Cc: Luca Coelho, Intel Linux Wireless, Emmanuel Grumbach,
Johannes Berg, Kalle Valo, Oren Givon, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1476180668.17022.21.camel@tiscali.nl>
Hi Luca,
I didn't receive your email so I'll try to respond via Paul's.
On Tue, Oct 11, 2016 at 5:11 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
>> This is not coming from the NIC itself, but from the platform's ACPI
>> tables. Can you tell us which platform you are using?
Interesting. I'm running a Dell XPS 13 9350. I replaced the
factory-provided Broadcom card with an AC 8260. I can update the
commit log to reflect this.
>> There are other things that look a bit inconsistent in this code...
>> I'll try to find the official ACPI table definitions for this entries
>> to make sure it's correct.
>
> When I looked into this error, some time ago, I searched around a bit
> for documentation on this splx stuff. Sadly, commit bcb079a14d75
> ("iwlwifi: pcie: retrieve and parse ACPI power limitations") provides
> very few clues and my searches turned up nothing useful. So a pointer
> or two would be really appreciated.
Ditto.
>> If this is really bothering you, I guess I could apply this patch for
>> now. But as I said, this is not solving the actual problem.
>
> Bikeshedding: I think IWL_INFO() is more appropriate, as info doesn't
> imply one needs to act on this message, while warn does imply that
> action is needed.
Agreed. I still think making this a warning is appropriate, but it
seems pretty clear this is not an error. This has nothing to do with
how much it bothers me. An error tells the user something needs to be
fixed, but in this case the interface is working fine. Making it a
warning with an improved message will result in fewer people wasting
their time.
Thanks!
Chris
^ permalink raw reply
* Re: [PATCH] docs-rst: sphinxify 802.11 documentation
From: Jonathan Corbet @ 2016-10-11 13:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1476190613-2403-1-git-send-email-johannes@sipsolutions.net>
On Tue, 11 Oct 2016 14:56:53 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> This is just a very basic conversion, I've split up the original
> multi-book template, and also split up the multi-part mac80211
> part in the original book; neither of those were handled by the
> automatic pandoc conversion.
>
> Fix errors that showed up, resulting in a much nicer rendering,
> at least for the interface combinations documentation.
Great, this is just what I want to see - another DocBook template gone!
> Jon, unless you have strong objections, I'd like to take this
> through my tree due to the header file changes.
Is there any chance of splitting those two things up? In particular,
index.rst has become a real conflict point, and I'm getting tired of
explaining those to Linus...so I'd prefer to carry that part if possible.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] docs-rst: sphinxify 802.11 documentation
From: Johannes Berg @ 2016-10-11 13:44 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-wireless
In-Reply-To: <20161011072119.7ad4e3a3@lwn.net>
> Great, this is just what I want to see - another DocBook template
> gone!
:)
Related question: I have some sequence diagrams, and just found the
seqdiag sphinx plugin. How should we manage adding extensions? Or would
you prefer not to add any at all?
johannes
^ permalink raw reply
* [PATCH] docs-rst: sphinxify 802.11 documentation
From: Johannes Berg @ 2016-10-11 12:56 UTC (permalink / raw)
To: linux-wireless; +Cc: Jonathan Corbet, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
This is just a very basic conversion, I've split up the original
multi-book template, and also split up the multi-part mac80211
part in the original book; neither of those were handled by the
automatic pandoc conversion.
Fix errors that showed up, resulting in a much nicer rendering,
at least for the interface combinations documentation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Jon, unless you have strong objections, I'd like to take this
through my tree due to the header file changes.
---
Documentation/80211/cfg80211.rst | 345 ++++++++++++++++++
Documentation/80211/conf.py | 5 +
Documentation/80211/index.rst | 17 +
Documentation/80211/introduction.rst | 17 +
Documentation/80211/mac80211-advanced.rst | 295 +++++++++++++++
Documentation/80211/mac80211.rst | 216 +++++++++++
Documentation/DocBook/80211.tmpl | 584 ------------------------------
Documentation/DocBook/Makefile | 2 +-
Documentation/index.rst | 1 +
include/net/cfg80211.h | 77 ++--
10 files changed, 939 insertions(+), 620 deletions(-)
create mode 100644 Documentation/80211/cfg80211.rst
create mode 100644 Documentation/80211/conf.py
create mode 100644 Documentation/80211/index.rst
create mode 100644 Documentation/80211/introduction.rst
create mode 100644 Documentation/80211/mac80211-advanced.rst
create mode 100644 Documentation/80211/mac80211.rst
delete mode 100644 Documentation/DocBook/80211.tmpl
diff --git a/Documentation/80211/cfg80211.rst b/Documentation/80211/cfg80211.rst
new file mode 100644
index 000000000000..b1e149ea6fee
--- /dev/null
+++ b/Documentation/80211/cfg80211.rst
@@ -0,0 +1,345 @@
+==================
+cfg80211 subsystem
+==================
+
+Device registration
+===================
+
+.. kernel-doc:: include/net/cfg80211.h
+ :doc: Device registration
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_channel_flags
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_channel
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_rate_flags
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_rate
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_sta_ht_cap
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_supported_band
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_signal_type
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_params_flags
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_flags
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wireless_dev
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_new
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_register
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_unregister
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_free
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_name
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_dev
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_priv
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: priv_to_wiphy
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: set_wiphy_dev
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wdev_priv
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_iface_limit
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_iface_combination
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_check_combinations
+
+Actions and configuration
+=========================
+
+.. kernel-doc:: include/net/cfg80211.h
+ :doc: Actions and configuration
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_ops
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: vif_params
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: key_params
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: survey_info_flags
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: survey_info
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_beacon_data
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_ap_settings
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: station_parameters
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: rate_info_flags
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: rate_info
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: station_info
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: monitor_flags
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: mpath_info_flags
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: mpath_info
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: bss_parameters
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_txq_params
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_crypto_settings
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_auth_request
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_assoc_request
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_deauth_request
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_disassoc_request
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_ibss_params
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_connect_params
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_pmksa
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_rx_mlme_mgmt
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_auth_timeout
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_rx_assoc_resp
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_assoc_timeout
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_tx_mlme_mgmt
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_ibss_joined
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_connect_result
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_connect_bss
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_connect_timeout
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_roamed
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_disconnected
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_ready_on_channel
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_remain_on_channel_expired
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_new_sta
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_rx_mgmt
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_mgmt_tx_status
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_cqm_rssi_notify
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_cqm_pktloss_notify
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_michael_mic_failure
+
+Scanning and BSS list handling
+==============================
+
+.. kernel-doc:: include/net/cfg80211.h
+ :doc: Scanning and BSS list handling
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_ssid
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_scan_request
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_scan_done
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_bss
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_inform_bss
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_inform_bss_frame_data
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_inform_bss_data
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_unlink_bss
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_find_ie
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_bss_get_ie
+
+Utility functions
+=================
+
+.. kernel-doc:: include/net/cfg80211.h
+ :doc: Utility functions
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_channel_to_frequency
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_frequency_to_channel
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_get_channel
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_get_response_rate
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_hdrlen
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_get_hdrlen_from_skb
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_radiotap_iterator
+
+Data path helpers
+=================
+
+.. kernel-doc:: include/net/cfg80211.h
+ :doc: Data path helpers
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_data_to_8023
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_data_from_8023
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: ieee80211_amsdu_to_8023s
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_classify8021d
+
+Regulatory enforcement infrastructure
+=====================================
+
+.. kernel-doc:: include/net/cfg80211.h
+ :doc: Regulatory enforcement infrastructure
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: regulatory_hint
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_apply_custom_regulatory
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: freq_reg_info
+
+RFkill integration
+==================
+
+.. kernel-doc:: include/net/cfg80211.h
+ :doc: RFkill integration
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_rfkill_set_hw_state
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_rfkill_start_polling
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: wiphy_rfkill_stop_polling
+
+Test mode
+=========
+
+.. kernel-doc:: include/net/cfg80211.h
+ :doc: Test mode
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_testmode_alloc_reply_skb
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_testmode_reply
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_testmode_alloc_event_skb
+
+.. kernel-doc:: include/net/cfg80211.h
+ :functions: cfg80211_testmode_event
diff --git a/Documentation/80211/conf.py b/Documentation/80211/conf.py
new file mode 100644
index 000000000000..20c7c275ef4a
--- /dev/null
+++ b/Documentation/80211/conf.py
@@ -0,0 +1,5 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "Linux 802.11 Driver Developer's Guide"
+
+tags.add("subproject")
diff --git a/Documentation/80211/index.rst b/Documentation/80211/index.rst
new file mode 100644
index 000000000000..90bba476f442
--- /dev/null
+++ b/Documentation/80211/index.rst
@@ -0,0 +1,17 @@
+=====================================
+Linux 802.11 Driver Developer's Guide
+=====================================
+
+.. toctree::
+
+ introduction
+ cfg80211
+ mac80211
+ mac80211-advanced
+
+.. only:: subproject
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/80211/introduction.rst b/Documentation/80211/introduction.rst
new file mode 100644
index 000000000000..4938fa87691c
--- /dev/null
+++ b/Documentation/80211/introduction.rst
@@ -0,0 +1,17 @@
+============
+Introduction
+============
+
+Explaining wireless 802.11 networking in the Linux kernel
+
+Copyright 2007-2009 Johannes Berg
+
+These books attempt to give a description of the various subsystems
+that play a role in 802.11 wireless networking in Linux. Since these
+books are for kernel developers they attempts to document the
+structures and functions used in the kernel as well as giving a
+higher-level overview.
+
+The reader is expected to be familiar with the 802.11 standard as
+published by the IEEE in 802.11-2007 (or possibly later versions).
+References to this standard will be given as "802.11-2007 8.1.5".
diff --git a/Documentation/80211/mac80211-advanced.rst b/Documentation/80211/mac80211-advanced.rst
new file mode 100644
index 000000000000..70a89b2163c2
--- /dev/null
+++ b/Documentation/80211/mac80211-advanced.rst
@@ -0,0 +1,295 @@
+=============================
+mac80211 subsystem (advanced)
+=============================
+
+Information contained within this part of the book is of interest only
+for advanced interaction of mac80211 with drivers to exploit more
+hardware capabilities and improve performance.
+
+LED support
+===========
+
+Mac80211 supports various ways of blinking LEDs. Wherever possible,
+device LEDs should be exposed as LED class devices and hooked up to the
+appropriate trigger, which will then be triggered appropriately by
+mac80211.
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_get_tx_led_name
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_get_rx_led_name
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_get_assoc_led_name
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_get_radio_led_name
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tpt_blink
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tpt_led_trigger_flags
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_create_tpt_led_trigger
+
+Hardware crypto acceleration
+============================
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: Hardware crypto acceleration
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: set_key_cmd
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_key_conf
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_key_flags
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_get_tkip_p1k
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_get_tkip_p1k_iv
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_get_tkip_p2k
+
+Powersave support
+=================
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: Powersave support
+
+Beacon filter support
+=====================
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: Beacon filter support
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_beacon_loss
+
+Multiple queues and QoS support
+===============================
+
+TBD
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tx_queue_params
+
+Access point mode support
+=========================
+
+TBD
+
+Some parts of the if_conf should be discussed here instead
+
+Insert notes about VLAN interfaces with hw crypto here or in the hw
+crypto chapter.
+
+support for powersaving clients
+-------------------------------
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: AP support for powersaving clients
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_get_buffered_bc
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_beacon_get
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_sta_eosp
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_frame_release_type
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_sta_ps_transition
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_sta_ps_transition_ni
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_sta_set_buffered
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_sta_block_awake
+
+Supporting multiple virtual interfaces
+======================================
+
+TBD
+
+Note: WDS with identical MAC address should almost always be OK
+
+Insert notes about having multiple virtual interfaces with different MAC
+addresses here, note which configurations are supported by mac80211, add
+notes about supporting hw crypto with it.
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_iterate_active_interfaces
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_iterate_active_interfaces_atomic
+
+Station handling
+================
+
+TODO
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_sta
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: sta_notify_cmd
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_find_sta
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_find_sta_by_ifaddr
+
+Hardware scan offload
+=====================
+
+TBD
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_scan_completed
+
+Aggregation
+===========
+
+TX A-MPDU aggregation
+---------------------
+
+.. kernel-doc:: net/mac80211/agg-tx.c
+ :doc: TX A-MPDU aggregation
+
+.. WARNING: DOCPROC directive not supported: !Cnet/mac80211/agg-tx.c
+
+RX A-MPDU aggregation
+---------------------
+
+.. kernel-doc:: net/mac80211/agg-rx.c
+ :doc: RX A-MPDU aggregation
+
+.. WARNING: DOCPROC directive not supported: !Cnet/mac80211/agg-rx.c
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_ampdu_mlme_action
+
+Spatial Multiplexing Powersave (SMPS)
+=====================================
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: Spatial multiplexing power save
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_request_smps
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_smps_mode
+
+TBD
+
+This part of the book describes the rate control algorithm interface and
+how it relates to mac80211 and drivers.
+
+Rate Control API
+================
+
+TBD
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_start_tx_ba_session
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_start_tx_ba_cb_irqsafe
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_stop_tx_ba_session
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_stop_tx_ba_cb_irqsafe
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_rate_control_changed
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tx_rate_control
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: rate_control_send_low
+
+TBD
+
+This part of the book describes mac80211 internals.
+
+Key handling
+============
+
+Key handling basics
+-------------------
+
+.. kernel-doc:: net/mac80211/key.c
+ :doc: Key handling basics
+
+MORE TBD
+--------
+
+TBD
+
+Receive processing
+==================
+
+TBD
+
+Transmit processing
+===================
+
+TBD
+
+Station info handling
+=====================
+
+Programming information
+-----------------------
+
+.. kernel-doc:: net/mac80211/sta_info.h
+ :functions: sta_info
+
+.. kernel-doc:: net/mac80211/sta_info.h
+ :functions: ieee80211_sta_info_flags
+
+STA information lifetime rules
+------------------------------
+
+.. kernel-doc:: net/mac80211/sta_info.c
+ :doc: STA information lifetime rules
+
+Aggregation
+===========
+
+.. kernel-doc:: net/mac80211/sta_info.h
+ :functions: sta_ampdu_mlme
+
+.. kernel-doc:: net/mac80211/sta_info.h
+ :functions: tid_ampdu_tx
+
+.. kernel-doc:: net/mac80211/sta_info.h
+ :functions: tid_ampdu_rx
+
+Synchronisation
+===============
+
+TBD
+
+Locking, lots of RCU
diff --git a/Documentation/80211/mac80211.rst b/Documentation/80211/mac80211.rst
new file mode 100644
index 000000000000..85a8335e80b6
--- /dev/null
+++ b/Documentation/80211/mac80211.rst
@@ -0,0 +1,216 @@
+===========================
+mac80211 subsystem (basics)
+===========================
+
+You should read and understand the information contained within this
+part of the book while implementing a mac80211 driver. In some chapters,
+advanced usage is noted, those may be skipped if this isn't needed.
+
+This part of the book only covers station and monitor mode
+functionality, additional information required to implement the other
+modes is covered in the second part of the book.
+
+Basic hardware handling
+=======================
+
+TBD
+
+This chapter shall contain information on getting a hw struct allocated
+and registered with mac80211.
+
+Since it is required to allocate rates/modes before registering a hw
+struct, this chapter shall also contain information on setting up the
+rate/mode structs.
+
+Additionally, some discussion about the callbacks and the general
+programming model should be in here, including the definition of
+ieee80211_ops which will be referred to a lot.
+
+Finally, a discussion of hardware capabilities should be done with
+references to other parts of the book.
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_hw
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_hw_flags
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: SET_IEEE80211_DEV
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: SET_IEEE80211_PERM_ADDR
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_ops
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_alloc_hw
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_register_hw
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_unregister_hw
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_free_hw
+
+PHY configuration
+=================
+
+TBD
+
+This chapter should describe PHY handling including start/stop callbacks
+and the various structures used.
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_conf
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_conf_flags
+
+Virtual interfaces
+==================
+
+TBD
+
+This chapter should describe virtual interface basics that are relevant
+to the driver (VLANs, MGMT etc are not.) It should explain the use of
+the add_iface/remove_iface callbacks as well as the interface
+configuration callbacks.
+
+Things related to AP mode should be discussed there.
+
+Things related to supporting multiple interfaces should be in the
+appropriate chapter, a BIG FAT note should be here about this though and
+the recommendation to allow only a single interface in STA mode at
+first!
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_vif
+
+Receive and transmit processing
+===============================
+
+what should be here
+-------------------
+
+TBD
+
+This should describe the receive and transmit paths in mac80211/the
+drivers as well as transmit status handling.
+
+Frame format
+------------
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: Frame format
+
+Packet alignment
+----------------
+
+.. kernel-doc:: net/mac80211/rx.c
+ :doc: Packet alignment
+
+Calling into mac80211 from interrupts
+-------------------------------------
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: Calling mac80211 from interrupts
+
+functions/definitions
+---------------------
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_rx_status
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: mac80211_rx_flags
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: mac80211_tx_info_flags
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: mac80211_tx_control_flags
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: mac80211_rate_control_flags
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tx_rate
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tx_info
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tx_info_clear_status
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_rx
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_rx_ni
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_rx_irqsafe
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tx_status
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tx_status_ni
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_tx_status_irqsafe
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_rts_get
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_rts_duration
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_ctstoself_get
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_ctstoself_duration
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_generic_frame_duration
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_wake_queue
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_stop_queue
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_wake_queues
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_stop_queues
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_queue_stopped
+
+Frame filtering
+===============
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: Frame filtering
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_filter_flags
+
+The mac80211 workqueue
+======================
+
+.. kernel-doc:: include/net/mac80211.h
+ :doc: mac80211 workqueue
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_queue_work
+
+.. kernel-doc:: include/net/mac80211.h
+ :functions: ieee80211_queue_delayed_work
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
deleted file mode 100644
index 800fe7a9024c..000000000000
--- a/Documentation/DocBook/80211.tmpl
+++ /dev/null
@@ -1,584 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE set PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
-<set>
- <setinfo>
- <title>The 802.11 subsystems – for kernel developers</title>
- <subtitle>
- Explaining wireless 802.11 networking in the Linux kernel
- </subtitle>
-
- <copyright>
- <year>2007-2009</year>
- <holder>Johannes Berg</holder>
- </copyright>
-
- <authorgroup>
- <author>
- <firstname>Johannes</firstname>
- <surname>Berg</surname>
- <affiliation>
- <address><email>johannes@sipsolutions.net</email></address>
- </affiliation>
- </author>
- </authorgroup>
-
- <legalnotice>
- <para>
- This documentation is free software; you can redistribute
- it and/or modify it under the terms of the GNU General Public
- License version 2 as published by the Free Software Foundation.
- </para>
- <para>
- This documentation is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- See the GNU General Public License for more details.
- </para>
- <para>
- You should have received a copy of the GNU General Public
- License along with this documentation; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
- </para>
- <para>
- For more details see the file COPYING in the source
- distribution of Linux.
- </para>
- </legalnotice>
-
- <abstract>
- <para>
- These books attempt to give a description of the
- various subsystems that play a role in 802.11 wireless
- networking in Linux. Since these books are for kernel
- developers they attempts to document the structures
- and functions used in the kernel as well as giving a
- higher-level overview.
- </para>
- <para>
- The reader is expected to be familiar with the 802.11
- standard as published by the IEEE in 802.11-2007 (or
- possibly later versions). References to this standard
- will be given as "802.11-2007 8.1.5".
- </para>
- </abstract>
- </setinfo>
- <book id="cfg80211-developers-guide">
- <bookinfo>
- <title>The cfg80211 subsystem</title>
-
- <abstract>
-!Pinclude/net/cfg80211.h Introduction
- </abstract>
- </bookinfo>
- <chapter>
- <title>Device registration</title>
-!Pinclude/net/cfg80211.h Device registration
-!Finclude/net/cfg80211.h ieee80211_channel_flags
-!Finclude/net/cfg80211.h ieee80211_channel
-!Finclude/net/cfg80211.h ieee80211_rate_flags
-!Finclude/net/cfg80211.h ieee80211_rate
-!Finclude/net/cfg80211.h ieee80211_sta_ht_cap
-!Finclude/net/cfg80211.h ieee80211_supported_band
-!Finclude/net/cfg80211.h cfg80211_signal_type
-!Finclude/net/cfg80211.h wiphy_params_flags
-!Finclude/net/cfg80211.h wiphy_flags
-!Finclude/net/cfg80211.h wiphy
-!Finclude/net/cfg80211.h wireless_dev
-!Finclude/net/cfg80211.h wiphy_new
-!Finclude/net/cfg80211.h wiphy_register
-!Finclude/net/cfg80211.h wiphy_unregister
-!Finclude/net/cfg80211.h wiphy_free
-
-!Finclude/net/cfg80211.h wiphy_name
-!Finclude/net/cfg80211.h wiphy_dev
-!Finclude/net/cfg80211.h wiphy_priv
-!Finclude/net/cfg80211.h priv_to_wiphy
-!Finclude/net/cfg80211.h set_wiphy_dev
-!Finclude/net/cfg80211.h wdev_priv
-!Finclude/net/cfg80211.h ieee80211_iface_limit
-!Finclude/net/cfg80211.h ieee80211_iface_combination
-!Finclude/net/cfg80211.h cfg80211_check_combinations
- </chapter>
- <chapter>
- <title>Actions and configuration</title>
-!Pinclude/net/cfg80211.h Actions and configuration
-!Finclude/net/cfg80211.h cfg80211_ops
-!Finclude/net/cfg80211.h vif_params
-!Finclude/net/cfg80211.h key_params
-!Finclude/net/cfg80211.h survey_info_flags
-!Finclude/net/cfg80211.h survey_info
-!Finclude/net/cfg80211.h cfg80211_beacon_data
-!Finclude/net/cfg80211.h cfg80211_ap_settings
-!Finclude/net/cfg80211.h station_parameters
-!Finclude/net/cfg80211.h rate_info_flags
-!Finclude/net/cfg80211.h rate_info
-!Finclude/net/cfg80211.h station_info
-!Finclude/net/cfg80211.h monitor_flags
-!Finclude/net/cfg80211.h mpath_info_flags
-!Finclude/net/cfg80211.h mpath_info
-!Finclude/net/cfg80211.h bss_parameters
-!Finclude/net/cfg80211.h ieee80211_txq_params
-!Finclude/net/cfg80211.h cfg80211_crypto_settings
-!Finclude/net/cfg80211.h cfg80211_auth_request
-!Finclude/net/cfg80211.h cfg80211_assoc_request
-!Finclude/net/cfg80211.h cfg80211_deauth_request
-!Finclude/net/cfg80211.h cfg80211_disassoc_request
-!Finclude/net/cfg80211.h cfg80211_ibss_params
-!Finclude/net/cfg80211.h cfg80211_connect_params
-!Finclude/net/cfg80211.h cfg80211_pmksa
-!Finclude/net/cfg80211.h cfg80211_rx_mlme_mgmt
-!Finclude/net/cfg80211.h cfg80211_auth_timeout
-!Finclude/net/cfg80211.h cfg80211_rx_assoc_resp
-!Finclude/net/cfg80211.h cfg80211_assoc_timeout
-!Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt
-!Finclude/net/cfg80211.h cfg80211_ibss_joined
-!Finclude/net/cfg80211.h cfg80211_connect_result
-!Finclude/net/cfg80211.h cfg80211_connect_bss
-!Finclude/net/cfg80211.h cfg80211_connect_timeout
-!Finclude/net/cfg80211.h cfg80211_roamed
-!Finclude/net/cfg80211.h cfg80211_disconnected
-!Finclude/net/cfg80211.h cfg80211_ready_on_channel
-!Finclude/net/cfg80211.h cfg80211_remain_on_channel_expired
-!Finclude/net/cfg80211.h cfg80211_new_sta
-!Finclude/net/cfg80211.h cfg80211_rx_mgmt
-!Finclude/net/cfg80211.h cfg80211_mgmt_tx_status
-!Finclude/net/cfg80211.h cfg80211_cqm_rssi_notify
-!Finclude/net/cfg80211.h cfg80211_cqm_pktloss_notify
-!Finclude/net/cfg80211.h cfg80211_michael_mic_failure
- </chapter>
- <chapter>
- <title>Scanning and BSS list handling</title>
-!Pinclude/net/cfg80211.h Scanning and BSS list handling
-!Finclude/net/cfg80211.h cfg80211_ssid
-!Finclude/net/cfg80211.h cfg80211_scan_request
-!Finclude/net/cfg80211.h cfg80211_scan_done
-!Finclude/net/cfg80211.h cfg80211_bss
-!Finclude/net/cfg80211.h cfg80211_inform_bss
-!Finclude/net/cfg80211.h cfg80211_inform_bss_frame_data
-!Finclude/net/cfg80211.h cfg80211_inform_bss_data
-!Finclude/net/cfg80211.h cfg80211_unlink_bss
-!Finclude/net/cfg80211.h cfg80211_find_ie
-!Finclude/net/cfg80211.h ieee80211_bss_get_ie
- </chapter>
- <chapter>
- <title>Utility functions</title>
-!Pinclude/net/cfg80211.h Utility functions
-!Finclude/net/cfg80211.h ieee80211_channel_to_frequency
-!Finclude/net/cfg80211.h ieee80211_frequency_to_channel
-!Finclude/net/cfg80211.h ieee80211_get_channel
-!Finclude/net/cfg80211.h ieee80211_get_response_rate
-!Finclude/net/cfg80211.h ieee80211_hdrlen
-!Finclude/net/cfg80211.h ieee80211_get_hdrlen_from_skb
-!Finclude/net/cfg80211.h ieee80211_radiotap_iterator
- </chapter>
- <chapter>
- <title>Data path helpers</title>
-!Pinclude/net/cfg80211.h Data path helpers
-!Finclude/net/cfg80211.h ieee80211_data_to_8023
-!Finclude/net/cfg80211.h ieee80211_data_from_8023
-!Finclude/net/cfg80211.h ieee80211_amsdu_to_8023s
-!Finclude/net/cfg80211.h cfg80211_classify8021d
- </chapter>
- <chapter>
- <title>Regulatory enforcement infrastructure</title>
-!Pinclude/net/cfg80211.h Regulatory enforcement infrastructure
-!Finclude/net/cfg80211.h regulatory_hint
-!Finclude/net/cfg80211.h wiphy_apply_custom_regulatory
-!Finclude/net/cfg80211.h freq_reg_info
- </chapter>
- <chapter>
- <title>RFkill integration</title>
-!Pinclude/net/cfg80211.h RFkill integration
-!Finclude/net/cfg80211.h wiphy_rfkill_set_hw_state
-!Finclude/net/cfg80211.h wiphy_rfkill_start_polling
-!Finclude/net/cfg80211.h wiphy_rfkill_stop_polling
- </chapter>
- <chapter>
- <title>Test mode</title>
-!Pinclude/net/cfg80211.h Test mode
-!Finclude/net/cfg80211.h cfg80211_testmode_alloc_reply_skb
-!Finclude/net/cfg80211.h cfg80211_testmode_reply
-!Finclude/net/cfg80211.h cfg80211_testmode_alloc_event_skb
-!Finclude/net/cfg80211.h cfg80211_testmode_event
- </chapter>
- </book>
- <book id="mac80211-developers-guide">
- <bookinfo>
- <title>The mac80211 subsystem</title>
- <abstract>
-!Pinclude/net/mac80211.h Introduction
-!Pinclude/net/mac80211.h Warning
- </abstract>
- </bookinfo>
-
- <toc></toc>
-
- <!--
- Generally, this document shall be ordered by increasing complexity.
- It is important to note that readers should be able to read only
- the first few sections to get a working driver and only advanced
- usage should require reading the full document.
- -->
-
- <part>
- <title>The basic mac80211 driver interface</title>
- <partintro>
- <para>
- You should read and understand the information contained
- within this part of the book while implementing a driver.
- In some chapters, advanced usage is noted, that may be
- skipped at first.
- </para>
- <para>
- This part of the book only covers station and monitor mode
- functionality, additional information required to implement
- the other modes is covered in the second part of the book.
- </para>
- </partintro>
-
- <chapter id="basics">
- <title>Basic hardware handling</title>
- <para>TBD</para>
- <para>
- This chapter shall contain information on getting a hw
- struct allocated and registered with mac80211.
- </para>
- <para>
- Since it is required to allocate rates/modes before registering
- a hw struct, this chapter shall also contain information on setting
- up the rate/mode structs.
- </para>
- <para>
- Additionally, some discussion about the callbacks and
- the general programming model should be in here, including
- the definition of ieee80211_ops which will be referred to
- a lot.
- </para>
- <para>
- Finally, a discussion of hardware capabilities should be done
- with references to other parts of the book.
- </para>
- <!-- intentionally multiple !F lines to get proper order -->
-!Finclude/net/mac80211.h ieee80211_hw
-!Finclude/net/mac80211.h ieee80211_hw_flags
-!Finclude/net/mac80211.h SET_IEEE80211_DEV
-!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
-!Finclude/net/mac80211.h ieee80211_ops
-!Finclude/net/mac80211.h ieee80211_alloc_hw
-!Finclude/net/mac80211.h ieee80211_register_hw
-!Finclude/net/mac80211.h ieee80211_unregister_hw
-!Finclude/net/mac80211.h ieee80211_free_hw
- </chapter>
-
- <chapter id="phy-handling">
- <title>PHY configuration</title>
- <para>TBD</para>
- <para>
- This chapter should describe PHY handling including
- start/stop callbacks and the various structures used.
- </para>
-!Finclude/net/mac80211.h ieee80211_conf
-!Finclude/net/mac80211.h ieee80211_conf_flags
- </chapter>
-
- <chapter id="iface-handling">
- <title>Virtual interfaces</title>
- <para>TBD</para>
- <para>
- This chapter should describe virtual interface basics
- that are relevant to the driver (VLANs, MGMT etc are not.)
- It should explain the use of the add_iface/remove_iface
- callbacks as well as the interface configuration callbacks.
- </para>
- <para>Things related to AP mode should be discussed there.</para>
- <para>
- Things related to supporting multiple interfaces should be
- in the appropriate chapter, a BIG FAT note should be here about
- this though and the recommendation to allow only a single
- interface in STA mode at first!
- </para>
-!Finclude/net/mac80211.h ieee80211_vif
- </chapter>
-
- <chapter id="rx-tx">
- <title>Receive and transmit processing</title>
- <sect1>
- <title>what should be here</title>
- <para>TBD</para>
- <para>
- This should describe the receive and transmit
- paths in mac80211/the drivers as well as
- transmit status handling.
- </para>
- </sect1>
- <sect1>
- <title>Frame format</title>
-!Pinclude/net/mac80211.h Frame format
- </sect1>
- <sect1>
- <title>Packet alignment</title>
-!Pnet/mac80211/rx.c Packet alignment
- </sect1>
- <sect1>
- <title>Calling into mac80211 from interrupts</title>
-!Pinclude/net/mac80211.h Calling mac80211 from interrupts
- </sect1>
- <sect1>
- <title>functions/definitions</title>
-!Finclude/net/mac80211.h ieee80211_rx_status
-!Finclude/net/mac80211.h mac80211_rx_flags
-!Finclude/net/mac80211.h mac80211_tx_info_flags
-!Finclude/net/mac80211.h mac80211_tx_control_flags
-!Finclude/net/mac80211.h mac80211_rate_control_flags
-!Finclude/net/mac80211.h ieee80211_tx_rate
-!Finclude/net/mac80211.h ieee80211_tx_info
-!Finclude/net/mac80211.h ieee80211_tx_info_clear_status
-!Finclude/net/mac80211.h ieee80211_rx
-!Finclude/net/mac80211.h ieee80211_rx_ni
-!Finclude/net/mac80211.h ieee80211_rx_irqsafe
-!Finclude/net/mac80211.h ieee80211_tx_status
-!Finclude/net/mac80211.h ieee80211_tx_status_ni
-!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
-!Finclude/net/mac80211.h ieee80211_rts_get
-!Finclude/net/mac80211.h ieee80211_rts_duration
-!Finclude/net/mac80211.h ieee80211_ctstoself_get
-!Finclude/net/mac80211.h ieee80211_ctstoself_duration
-!Finclude/net/mac80211.h ieee80211_generic_frame_duration
-!Finclude/net/mac80211.h ieee80211_wake_queue
-!Finclude/net/mac80211.h ieee80211_stop_queue
-!Finclude/net/mac80211.h ieee80211_wake_queues
-!Finclude/net/mac80211.h ieee80211_stop_queues
-!Finclude/net/mac80211.h ieee80211_queue_stopped
- </sect1>
- </chapter>
-
- <chapter id="filters">
- <title>Frame filtering</title>
-!Pinclude/net/mac80211.h Frame filtering
-!Finclude/net/mac80211.h ieee80211_filter_flags
- </chapter>
-
- <chapter id="workqueue">
- <title>The mac80211 workqueue</title>
-!Pinclude/net/mac80211.h mac80211 workqueue
-!Finclude/net/mac80211.h ieee80211_queue_work
-!Finclude/net/mac80211.h ieee80211_queue_delayed_work
- </chapter>
- </part>
-
- <part id="advanced">
- <title>Advanced driver interface</title>
- <partintro>
- <para>
- Information contained within this part of the book is
- of interest only for advanced interaction of mac80211
- with drivers to exploit more hardware capabilities and
- improve performance.
- </para>
- </partintro>
-
- <chapter id="led-support">
- <title>LED support</title>
- <para>
- Mac80211 supports various ways of blinking LEDs. Wherever possible,
- device LEDs should be exposed as LED class devices and hooked up to
- the appropriate trigger, which will then be triggered appropriately
- by mac80211.
- </para>
-!Finclude/net/mac80211.h ieee80211_get_tx_led_name
-!Finclude/net/mac80211.h ieee80211_get_rx_led_name
-!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
-!Finclude/net/mac80211.h ieee80211_get_radio_led_name
-!Finclude/net/mac80211.h ieee80211_tpt_blink
-!Finclude/net/mac80211.h ieee80211_tpt_led_trigger_flags
-!Finclude/net/mac80211.h ieee80211_create_tpt_led_trigger
- </chapter>
-
- <chapter id="hardware-crypto-offload">
- <title>Hardware crypto acceleration</title>
-!Pinclude/net/mac80211.h Hardware crypto acceleration
- <!-- intentionally multiple !F lines to get proper order -->
-!Finclude/net/mac80211.h set_key_cmd
-!Finclude/net/mac80211.h ieee80211_key_conf
-!Finclude/net/mac80211.h ieee80211_key_flags
-!Finclude/net/mac80211.h ieee80211_get_tkip_p1k
-!Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv
-!Finclude/net/mac80211.h ieee80211_get_tkip_p2k
- </chapter>
-
- <chapter id="powersave">
- <title>Powersave support</title>
-!Pinclude/net/mac80211.h Powersave support
- </chapter>
-
- <chapter id="beacon-filter">
- <title>Beacon filter support</title>
-!Pinclude/net/mac80211.h Beacon filter support
-!Finclude/net/mac80211.h ieee80211_beacon_loss
- </chapter>
-
- <chapter id="qos">
- <title>Multiple queues and QoS support</title>
- <para>TBD</para>
-!Finclude/net/mac80211.h ieee80211_tx_queue_params
- </chapter>
-
- <chapter id="AP">
- <title>Access point mode support</title>
- <para>TBD</para>
- <para>Some parts of the if_conf should be discussed here instead</para>
- <para>
- Insert notes about VLAN interfaces with hw crypto here or
- in the hw crypto chapter.
- </para>
- <section id="ps-client">
- <title>support for powersaving clients</title>
-!Pinclude/net/mac80211.h AP support for powersaving clients
-!Finclude/net/mac80211.h ieee80211_get_buffered_bc
-!Finclude/net/mac80211.h ieee80211_beacon_get
-!Finclude/net/mac80211.h ieee80211_sta_eosp
-!Finclude/net/mac80211.h ieee80211_frame_release_type
-!Finclude/net/mac80211.h ieee80211_sta_ps_transition
-!Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni
-!Finclude/net/mac80211.h ieee80211_sta_set_buffered
-!Finclude/net/mac80211.h ieee80211_sta_block_awake
- </section>
- </chapter>
-
- <chapter id="multi-iface">
- <title>Supporting multiple virtual interfaces</title>
- <para>TBD</para>
- <para>
- Note: WDS with identical MAC address should almost always be OK
- </para>
- <para>
- Insert notes about having multiple virtual interfaces with
- different MAC addresses here, note which configurations are
- supported by mac80211, add notes about supporting hw crypto
- with it.
- </para>
-!Finclude/net/mac80211.h ieee80211_iterate_active_interfaces
-!Finclude/net/mac80211.h ieee80211_iterate_active_interfaces_atomic
- </chapter>
-
- <chapter id="station-handling">
- <title>Station handling</title>
- <para>TODO</para>
-!Finclude/net/mac80211.h ieee80211_sta
-!Finclude/net/mac80211.h sta_notify_cmd
-!Finclude/net/mac80211.h ieee80211_find_sta
-!Finclude/net/mac80211.h ieee80211_find_sta_by_ifaddr
- </chapter>
-
- <chapter id="hardware-scan-offload">
- <title>Hardware scan offload</title>
- <para>TBD</para>
-!Finclude/net/mac80211.h ieee80211_scan_completed
- </chapter>
-
- <chapter id="aggregation">
- <title>Aggregation</title>
- <sect1>
- <title>TX A-MPDU aggregation</title>
-!Pnet/mac80211/agg-tx.c TX A-MPDU aggregation
-!Cnet/mac80211/agg-tx.c
- </sect1>
- <sect1>
- <title>RX A-MPDU aggregation</title>
-!Pnet/mac80211/agg-rx.c RX A-MPDU aggregation
-!Cnet/mac80211/agg-rx.c
-!Finclude/net/mac80211.h ieee80211_ampdu_mlme_action
- </sect1>
- </chapter>
-
- <chapter id="smps">
- <title>Spatial Multiplexing Powersave (SMPS)</title>
-!Pinclude/net/mac80211.h Spatial multiplexing power save
-!Finclude/net/mac80211.h ieee80211_request_smps
-!Finclude/net/mac80211.h ieee80211_smps_mode
- </chapter>
- </part>
-
- <part id="rate-control">
- <title>Rate control interface</title>
- <partintro>
- <para>TBD</para>
- <para>
- This part of the book describes the rate control algorithm
- interface and how it relates to mac80211 and drivers.
- </para>
- </partintro>
- <chapter id="ratecontrol-api">
- <title>Rate Control API</title>
- <para>TBD</para>
-!Finclude/net/mac80211.h ieee80211_start_tx_ba_session
-!Finclude/net/mac80211.h ieee80211_start_tx_ba_cb_irqsafe
-!Finclude/net/mac80211.h ieee80211_stop_tx_ba_session
-!Finclude/net/mac80211.h ieee80211_stop_tx_ba_cb_irqsafe
-!Finclude/net/mac80211.h ieee80211_rate_control_changed
-!Finclude/net/mac80211.h ieee80211_tx_rate_control
-!Finclude/net/mac80211.h rate_control_send_low
- </chapter>
- </part>
-
- <part id="internal">
- <title>Internals</title>
- <partintro>
- <para>TBD</para>
- <para>
- This part of the book describes mac80211 internals.
- </para>
- </partintro>
-
- <chapter id="key-handling">
- <title>Key handling</title>
- <sect1>
- <title>Key handling basics</title>
-!Pnet/mac80211/key.c Key handling basics
- </sect1>
- <sect1>
- <title>MORE TBD</title>
- <para>TBD</para>
- </sect1>
- </chapter>
-
- <chapter id="rx-processing">
- <title>Receive processing</title>
- <para>TBD</para>
- </chapter>
-
- <chapter id="tx-processing">
- <title>Transmit processing</title>
- <para>TBD</para>
- </chapter>
-
- <chapter id="sta-info">
- <title>Station info handling</title>
- <sect1>
- <title>Programming information</title>
-!Fnet/mac80211/sta_info.h sta_info
-!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
- </sect1>
- <sect1>
- <title>STA information lifetime rules</title>
-!Pnet/mac80211/sta_info.c STA information lifetime rules
- </sect1>
- </chapter>
-
- <chapter id="aggregation-internals">
- <title>Aggregation</title>
-!Fnet/mac80211/sta_info.h sta_ampdu_mlme
-!Fnet/mac80211/sta_info.h tid_ampdu_tx
-!Fnet/mac80211/sta_info.h tid_ampdu_rx
- </chapter>
-
- <chapter id="synchronisation">
- <title>Synchronisation</title>
- <para>TBD</para>
- <para>Locking, lots of RCU</para>
- </chapter>
- </part>
- </book>
-</set>
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 736f5916daea..fdf8232d0eeb 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -12,7 +12,7 @@ DOCBOOKS := z8530book.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
- 80211.xml debugobjects.xml sh.xml regulator.xml \
+ debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
diff --git a/Documentation/index.rst b/Documentation/index.rst
index d9ccb94fca95..c53d089455a4 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -17,6 +17,7 @@ Contents:
driver-api/index
media/index
gpu/index
+ 80211/index
Indices and tables
==================
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7df600c463eb..14b51d739c3b 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -796,9 +796,9 @@ enum station_parameters_apply_mask {
* (or NULL for no change)
* @supported_rates_len: number of supported rates
* @sta_flags_mask: station flags that changed
- * (bitmask of BIT(NL80211_STA_FLAG_...))
+ * (bitmask of BIT(%NL80211_STA_FLAG_...))
* @sta_flags_set: station flags values
- * (bitmask of BIT(NL80211_STA_FLAG_...))
+ * (bitmask of BIT(%NL80211_STA_FLAG_...))
* @listen_interval: listen interval or -1 for no change
* @aid: AID or zero for no change
* @peer_aid: mesh peer AID or zero for no change
@@ -3088,47 +3088,54 @@ struct ieee80211_iface_limit {
*
* 1. Allow #STA <= 1, #AP <= 1, matching BI, channels = 1, 2 total:
*
- * struct ieee80211_iface_limit limits1[] = {
- * { .max = 1, .types = BIT(NL80211_IFTYPE_STATION), },
- * { .max = 1, .types = BIT(NL80211_IFTYPE_AP}, },
- * };
- * struct ieee80211_iface_combination combination1 = {
- * .limits = limits1,
- * .n_limits = ARRAY_SIZE(limits1),
- * .max_interfaces = 2,
- * .beacon_int_infra_match = true,
- * };
+ * .. code-block:: c
+ *
+ * struct ieee80211_iface_limit limits1[] = {
+ * { .max = 1, .types = BIT(NL80211_IFTYPE_STATION), },
+ * { .max = 1, .types = BIT(NL80211_IFTYPE_AP}, },
+ * };
+ * struct ieee80211_iface_combination combination1 = {
+ * .limits = limits1,
+ * .n_limits = ARRAY_SIZE(limits1),
+ * .max_interfaces = 2,
+ * .beacon_int_infra_match = true,
+ * };
*
*
* 2. Allow #{AP, P2P-GO} <= 8, channels = 1, 8 total:
*
- * struct ieee80211_iface_limit limits2[] = {
- * { .max = 8, .types = BIT(NL80211_IFTYPE_AP) |
- * BIT(NL80211_IFTYPE_P2P_GO), },
- * };
- * struct ieee80211_iface_combination combination2 = {
- * .limits = limits2,
- * .n_limits = ARRAY_SIZE(limits2),
- * .max_interfaces = 8,
- * .num_different_channels = 1,
- * };
+ * .. code-block:: c
+ *
+ * struct ieee80211_iface_limit limits2[] = {
+ * { .max = 8, .types = BIT(NL80211_IFTYPE_AP) |
+ * BIT(NL80211_IFTYPE_P2P_GO), },
+ * };
+ * struct ieee80211_iface_combination combination2 = {
+ * .limits = limits2,
+ * .n_limits = ARRAY_SIZE(limits2),
+ * .max_interfaces = 8,
+ * .num_different_channels = 1,
+ * };
*
*
* 3. Allow #STA <= 1, #{P2P-client,P2P-GO} <= 3 on two channels, 4 total.
*
- * This allows for an infrastructure connection and three P2P connections.
- *
- * struct ieee80211_iface_limit limits3[] = {
- * { .max = 1, .types = BIT(NL80211_IFTYPE_STATION), },
- * { .max = 3, .types = BIT(NL80211_IFTYPE_P2P_GO) |
- * BIT(NL80211_IFTYPE_P2P_CLIENT), },
- * };
- * struct ieee80211_iface_combination combination3 = {
- * .limits = limits3,
- * .n_limits = ARRAY_SIZE(limits3),
- * .max_interfaces = 4,
- * .num_different_channels = 2,
- * };
+ * This allows for an infrastructure connection and three P2P connections.
+ *
+ * .. code-block:: c
+ *
+ * struct ieee80211_iface_limit limits3[] = {
+ * { .max = 1, .types = BIT(NL80211_IFTYPE_STATION), },
+ * { .max = 3, .types = BIT(NL80211_IFTYPE_P2P_GO) |
+ * BIT(NL80211_IFTYPE_P2P_CLIENT), },
+ * };
+ * struct ieee80211_iface_combination combination3 = {
+ * .limits = limits3,
+ * .n_limits = ARRAY_SIZE(limits3),
+ * .max_interfaces = 4,
+ * .num_different_channels = 2,
+ * };
+ *
*/
struct ieee80211_iface_combination {
const struct ieee80211_iface_limit *limits;
--
2.8.1
^ permalink raw reply related
* Re: [bug report] iwlwifi: mvm: Add mem debugfs entry
From: Luca Coelho @ 2016-10-11 11:50 UTC (permalink / raw)
To: Dan Carpenter, ido; +Cc: linux-wireless
In-Reply-To: <20161011105027.GA29933@mwanda>
Hi Dan.
On Tue, 2016-10-11 at 13:50 +0300, Dan Carpenter wrote:
> Hello Ido Yariv,
>
> The patch 2b55f43f8e47: "iwlwifi: mvm: Add mem debugfs entry" from
> Aug 23, 2016, leads to the following static checker warning:
>
> drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1561 iwl_dbgfs_mem_read()
> warn: unsigned 'len' is never less than zero.
Thanks for reporting! I already have a fix for this queued up in our
internal tree. I'll send it out soon, with my next series.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [v2,1/2] ath10k: clean up HTT tx buffer allocation and free
From: Kalle Valo @ 2016-10-11 11:36 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1475743188-12007-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> cleanup 'ath10k_htt_tx_alloc' by introducing the API's
> 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
> re-use them whereever needed
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Applies but fails to build:
drivers/net/wireless/ath/ath10k/htt_tx.c: In function ‘ath10k_htt_tx_free’:
drivers/net/wireless/ath/ath10k/htt_tx.c:424:19: error: ‘struct ath10k_htt’ has no member named ‘txrx_compl_task’
make[5]: *** [drivers/net/wireless/ath/ath10k/htt_tx.o] Error 1
make[4]: *** [drivers/net/wireless/ath/ath10k] Error 2
make[3]: *** [drivers/net/wireless/ath] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
2 patches set to Changes Requested.
9363863 [v2,1/2] ath10k: clean up HTT tx buffer allocation and free
9363861 [v2,2/2] ath10k: Remove extraneous error message in tx alloc
--
https://patchwork.kernel.org/patch/9363863/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [bug report] iwlwifi: mvm: Add mem debugfs entry
From: Dan Carpenter @ 2016-10-11 10:50 UTC (permalink / raw)
To: ido; +Cc: linux-wireless
Hello Ido Yariv,
The patch 2b55f43f8e47: "iwlwifi: mvm: Add mem debugfs entry" from
Aug 23, 2016, leads to the following static checker warning:
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1561 iwl_dbgfs_mem_read()
warn: unsigned 'len' is never less than zero.
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
1521 static ssize_t iwl_dbgfs_mem_read(struct file *file, char __user *user_buf,
1522 size_t count, loff_t *ppos)
1523 {
1524 struct iwl_mvm *mvm = file->private_data;
1525 struct iwl_dbg_mem_access_cmd cmd = {};
1526 struct iwl_dbg_mem_access_rsp *rsp;
1527 struct iwl_host_cmd hcmd = {
1528 .flags = CMD_WANT_SKB | CMD_SEND_IN_RFKILL,
1529 .data = { &cmd, },
1530 .len = { sizeof(cmd) },
1531 };
1532 size_t delta, len;
^^^
Unsigned.
1533 ssize_t ret;
1534
1535 hcmd.id = iwl_cmd_id(*ppos >> 24 ? UMAC_RD_WR : LMAC_RD_WR,
1536 DEBUG_GROUP, 0);
1537 cmd.op = cpu_to_le32(DEBUG_MEM_OP_READ);
1538
1539 /* Take care of alignment of both the position and the length */
1540 delta = *ppos & 0x3;
1541 cmd.addr = cpu_to_le32(*ppos - delta);
1542 cmd.len = cpu_to_le32(min(ALIGN(count + delta, 4) / 4,
1543 (size_t)DEBUG_MEM_MAX_SIZE_DWORDS));
1544
1545 mutex_lock(&mvm->mutex);
1546 ret = iwl_mvm_send_cmd(mvm, &hcmd);
1547 mutex_unlock(&mvm->mutex);
1548
1549 if (ret < 0)
1550 return ret;
1551
1552 rsp = (void *)hcmd.resp_pkt->data;
1553 if (le32_to_cpu(rsp->status) != DEBUG_MEM_STATUS_SUCCESS) {
1554 ret = -ENXIO;
1555 goto out;
1556 }
1557
1558 len = min((size_t)le32_to_cpu(rsp->len) << 2,
1559 iwl_rx_packet_payload_len(hcmd.resp_pkt) - sizeof(*rsp));
1560 len = min(len - delta, count);
1561 if (len < 0) {
^^^^^^^
Unpossible.
1562 ret = -EFAULT;
1563 goto out;
1564 }
1565
1566 ret = len - copy_to_user(user_buf, (void *)rsp->data + delta, len);
1567 *ppos += ret;
1568
1569 out:
1570 iwl_free_resp(&hcmd);
1571 return ret;
1572 }
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Paul Bolle @ 2016-10-11 10:11 UTC (permalink / raw)
To: Luca Coelho, Chris Rorvick, Intel Linux Wireless,
Emmanuel Grumbach, Johannes Berg, Kalle Valo, Oren Givon
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1476108164.5210.11.camel@coelho.fi>
Hi Luca,
On Mon, 2016-10-10 at 17:02 +0300, Luca Coelho wrote:
> On Mon, 2016-10-10 at 02:19 -0500, Chris Rorvick wrote:
> This is not coming from the NIC itself, but from the platform's ACPI
> tables. Can you tell us which platform you are using?
On my machine I'm seeing the same error as Chris. So what exactly do
you mean with "platform" here?
> > Name (SPLX, Package (0x04)
> > {
> > Zero,
> > Package (0x03)
> > {
> > 0,
> > 1200,
> > 1000
> > },
> > Package (0x03)
> > {
> > 0,
> > 1200,
> > 1000
> > },
> > Package (0x03)
> > {
> > 0,
> > 1200,
> > 1000
> > }
> > })
>
> This is not the structure that we are expecting. We expect this:
>
> Name (SPLX, Package (0x02)
> {
> Zero,
> Package (0x03)
> {
> 0x07,
> <value>,
> <value>
> }
> })
>
> ...as you correctly pointed out. The data in the structure you have is
> not for WiFi (actually I don't think 0 is a valid value, but I'll
> double-check).
For what it's worth, on my machine I have twenty (!) SPLX entries, all
reading:
Name (SPLX, Package (0x04)
{
Zero,
Package (0x03)
{
0x80000000,
0x80000000,
0x80000000
},
Package (0x03)
{
0x80000000,
0x80000000,
0x80000000
},
Package (0x03)
{
0x80000000,
0x80000000,
0x80000000
}
})
> There are other things that look a bit inconsistent in this code...
> I'll try to find the official ACPI table definitions for this entries
> to make sure it's correct.
When I looked into this error, some time ago, I searched around a bit
for documentation on this splx stuff. Sadly, commit bcb079a14d75
("iwlwifi: pcie: retrieve and parse ACPI power limitations") provides
very few clues and my searches turned up nothing useful. So a pointer
or two would be really appreciated.
> > --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
> > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
> > @@ -540,7 +540,7 @@ static u64 splx_get_pwr_limit(struct iwl_trans *trans, union acpi_object *splx)
> > splx->package.count != 2 ||
> > splx->package.elements[0].type != ACPI_TYPE_INTEGER ||
> > splx->package.elements[0].integer.value != 0) {
> > - IWL_ERR(trans, "Unsupported splx structure\n");
> > + IWL_WARN(trans, "Unsupported splx structure, not limiting WiFi power\n");
> > return 0;
> > }
>
> If this is really bothering you, I guess I could apply this patch for
> now. But as I said, this is not solving the actual problem.
Bikeshedding: I think IWL_INFO() is more appropriate, as info doesn't
imply one needs to act on this message, while warn does imply that
action is needed.
Thanks,
Paul Bolle
^ permalink raw reply
* Re: [PATCH] mac80211: fix sequence number allocation regression
From: Toke Høiland-Jørgensen @ 2016-10-11 9:39 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, johannes
In-Reply-To: <20161011092831.85565-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> The recent commit that moved around TX handlers dropped the sequence
> number allocation at the end of ieee80211_tx_dequeue and calls
> ieee80211_tx_h_sequence instead (for the non-fast-xmit case).
> However, it did not change the fast-xmit sequence allocation condition
> in ieee80211_xmit_fast_finish, which skipped seqno alloc if intermediate
> tx queues are being used.
>
> Drop the now obsolete condition.
>
> Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to aft=
er TXQ dequeue")
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
(Think this was introduced in the merging of mac80211-next and net-next?)
-Toke
^ permalink raw reply
* [PATCH] mac80211: fix sequence number allocation regression
From: Felix Fietkau @ 2016-10-11 9:28 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, toke
The recent commit that moved around TX handlers dropped the sequence
number allocation at the end of ieee80211_tx_dequeue and calls
ieee80211_tx_h_sequence instead (for the non-fast-xmit case).
However, it did not change the fast-xmit sequence allocation condition
in ieee80211_xmit_fast_finish, which skipped seqno alloc if intermediate
tx queues are being used.
Drop the now obsolete condition.
Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
net/mac80211/tx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index dc60784..8ff81fd 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3212,7 +3212,6 @@ static void ieee80211_xmit_fast_finish(struct ieee80211_sub_if_data *sdata,
struct sk_buff *skb)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
- struct ieee80211_local *local = sdata->local;
struct ieee80211_hdr *hdr = (void *)skb->data;
u8 tid = IEEE80211_NUM_TIDS;
@@ -3224,8 +3223,7 @@ static void ieee80211_xmit_fast_finish(struct ieee80211_sub_if_data *sdata,
if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
*ieee80211_get_qos_ctl(hdr) = tid;
- if (!ieee80211_get_txq(local, &sdata->vif, &sta->sta, skb))
- hdr->seq_ctrl = ieee80211_tx_next_seq(sta, tid);
+ hdr->seq_ctrl = ieee80211_tx_next_seq(sta, tid);
} else {
info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
hdr->seq_ctrl = cpu_to_le16(sdata->sequence_number);
--
2.10.1
^ permalink raw reply related
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-10-11 6:14 UTC (permalink / raw)
To: Arend Van Spriel
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <CAF7Mx6q+B4RoURNF5XxewjF9aVGCXg==XU0aDD6w+354yXZ70Q@mail.gmail.com>
Hi Arend,
Am 22. September 2016 16:00:36 MESZ, schrieb Arend Van Spriel <arend.vanspriel@broadcom.com>:
>Op 22 sep. 2016 14:52 schreef "Jörg Krause"
><joerg.krause@embedded.rocks>:
>>
>> On Do, 2016-09-22 at 10:09 +0200, Arend Van Spriel wrote:
>> > On 19-9-2016 8:36, Jörg Krause wrote:
>> > >
>> > > Hi Arend,
>> > >
>> > > On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote:
>> > > >
>> > > > On 14-9-2016 15:41, Jörg Krause wrote:
>> > > > >
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote:
>> > > > > >
>> > > > > >
>> > > > > > On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On 22-8-2016 15:37, Jörg Krause wrote:
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > Hi all,
>> > > > > > > >
>> > > > > > > > I am back from vacation and I'd like to do more
>> > > > > > > > investigations
>> > > > > > > > about
>> > > > > > > > this issue. Please see my comments below...
>> > > > > > > >
>> > > > > > > > On Sun, 2016-08-07 at 13:41 +0200, Arend van Spriel
>> > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On 06-08-16 16:12, Jörg Krause wrote:
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Hi all,
>> > > > > > > > >
>> > > > > > > > > A bit weird email format making it a bit hard to
>> > > > > > > > > determine
>> > > > > > > > > where
>> > > > > > > > > your
>> > > > > > > > > last reply starts...
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
>> > > > > > > > > >
>> > > > > > > > > > On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause
>> > > > > > > > > > <joerg.krause
>> > > > > > > > > > @emb
>> > > > > > > > > > ed
>> > > > > > > > > > ded.
>> > > > > > > > > > ro
>> > > > > > > > > > cks>
>> > > > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van
>> > > > > > > > > > Spriel
>> > > > > > > > > > <
>> > > > > > > > > > arend.vanspriel@broadcom.com>:
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Op 5 aug. 2016 22:46 schreef "Jörg Krause"
>> > > > > > > > > > <joerg.krause@embedded.rocks>:
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Hi,
>> > > > > > > > > >
>> > > > > > > > > > I'm using a custom ARM board with an BCM43362 wifi
>> > > > > > > > > > chip
>> > > > > > > > > > from
>> > > > > > > > > >
>> > > > > > > > > > Broadcom.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > The wifi chip is attached via SDIO to the
>controller
>> > > > > > > > > > with
>> > > > > > > > > > a
>> > > > > > > > > > clock of
>> > > > > > > > > > 48MHz. Linux kernel version is 4.7.
>> > > > > > > > > >
>> > > > > > > > > > When measuring the network bandwidth with iperf3 I
>> > > > > > > > > > get a
>> > > > > > > > > > bandwith of
>> > > > > > > > > > only around 5 Mbps. I found a similar thread at the
>> > > > > > > > > > Broadcom
>> > > > > > > > > >
>> > > > > > > > > > community
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > [1] where the test was done with a M4 CPU +
>BCM43362
>> > > > > > > > > > and
>> > > > > > > > > > an
>> > > > > > > > > > average
>> > > > > > > > > > result of 3.3 Mbps.
>> > > > > > > > > >
>> > > > > > > > > > Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a
>> > > > > > > > > > TCP
>> > > > > > > > > > data
>> > > > > > > > > >
>> > > > > > > > > > throughput
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > greater than 20 Mbps.
>> > > > > > > > > >
>> > > > > > > > > > Why is the throughput I measured much lower? Note
>> > > > > > > > > > that I
>> > > > > > > > > > measured
>> > > > > > > > > > several times with almost no neighbor devices or
>> > > > > > > > > > networks.
>> > > > > > > > > >
>> > > > > > > > > > This is a test sample measured with iperf3:
>> > > > > > > > > >
>> > > > > > > > > > $ iperf3 -c 192.168.2.1 -i 1 -t 10
>> > > > > > > > > > Connecting to host 192.168.2.1, port 5201
>> > > > > > > > > > [ 4] local 192.168.2.155 port 36442 connected
>to
>> > > > > > > > > > 192.168.2.1
>> > > > > > > > > >
>> > > > > > > > > > port
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > 5201
>> > > > > > > > > > [ ID]
>> > > > > > > > > > Interval Transfer Bandwidth
>Retr
>> > > > > > > > > > Cwn
>> > > > > > > > > > d
>> > > > > > > > > > [ 4] 0.00-1.00 sec 615 KBytes 5.04
>> > > > > > > > > > Mbits/sec 0 56.6
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 1.00-2.00 sec 622 KBytes 5.10
>> > > > > > > > > > Mbits/sec 0 84.8
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 2.00-3.00 sec 625 KBytes 5.12
>> > > > > > > > > > Mbits/sec 0 113
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 3.00-4.00 sec 571 KBytes 4.68
>> > > > > > > > > > Mbits/sec 0 140
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 4.00-5.00 sec 594 KBytes 4.87
>> > > > > > > > > > Mbits/sec 0 167
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 5.00-6.00 sec 628 KBytes 5.14
>> > > > > > > > > > Mbits/sec 0 195
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 6.00-7.00 sec 619 KBytes 5.07
>> > > > > > > > > > Mbits/sec 0 202
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 7.00-8.00 sec 608 KBytes 4.98
>> > > > > > > > > > Mbits/sec 0 202
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 8.00-9.00 sec 602 KBytes 4.93
>> > > > > > > > > > Mbits/sec 0 202
>> > > > > > > > > > KBytes
>> > > > > > > > > > [ 4] 9.00-10.00 sec 537 KBytes 4.40
>> > > > > > > > > > Mbits/sec 0 202
>> > > > > > > > > > KBytes
>> > > > > > > > > > - - - - - - - - - - - - - - - - - - - - - - - -
>-
>> > > > > > > > > > [ ID]
>> > > > > > > > > > Interval Transfer Bandwidth
>Retr
>> > > > > > > > > > [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
>> > > > > > > > > > Mbits/sec 0 sender
>> > > > > > > > > > [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
>> > > > > > > > > > Mbits/sec receiver
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Not overly familiar with iperf3. Do these lines
>mean
>> > > > > > > > > > you
>> > > > > > > > > > are
>> > > > > > > > > > doing
>> > > > > > > > > > bidirectional test, ie. upstream and downstream at
>> > > > > > > > > > the
>> > > > > > > > > > same
>> > > > > > > > > > time.
>> > > > > > > > > > Another
>> > > > > > > > > > thing affecting tput could be power-save.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > No, iperf3 does not support bidrectional test.
>Power-
>> > > > > > > > > > save
>> > > > > > > > > > is
>> > > > > > > > > > turned
>> > > > > > > > > > off.
>> > > > > > > > > >
>> > > > > > > > > > What does iw link say?
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > but I guess it starts here!
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > I compared the results with a Cubietruck I have:
>> > > > > > > > > >
>> > > > > > > > > > # iperf3 -s
>> > > > > > > > > > ---------------------------------------------------
>> > > > > > > > > > ----
>> > > > > > > > > > ----
>> > > > > > > > > > Server listening on 5201
>> > > > > > > > > > ---------------------------------------------------
>> > > > > > > > > > ----
>> > > > > > > > > > ----
>> > > > > > > > > > Accepted connection from 192.168.178.46, port 42906
>> > > > > > > > > > [ 5] local 192.168.178.38 port 5201 connected to
>> > > > > > > > > > 192.168.178.46
>> > > > > > > > > > port
>> > > > > > > > > > 42908
>> > > > > > > > > > [ ID] Interval Transfer Bandwidth
>> > > > > > > > > > [ 5] 0.00-1.00 sec 2.29 MBytes 19.2
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 1.00-2.00 sec 2.21 MBytes 18.5
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 2.00-3.00 sec 2.17 MBytes 18.2
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 3.00-4.00 sec 2.09 MBytes 17.6
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 4.00-5.00 sec 2.20 MBytes 18.5
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 5.00-6.00 sec 2.64 MBytes 22.1
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 6.00-7.00 sec 2.67 MBytes 22.4
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 7.00-8.00 sec 2.62 MBytes 22.0
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 8.00-9.00 sec 2.35 MBytes 19.8
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 9.00-10.00 sec 2.30 MBytes 19.3
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > [ 5] 10.00-10.03 sec 83.4 KBytes 23.5
>> > > > > > > > > > Mbits/sec
>> > > > > > > > > > - - - - - - - - - - - - - - - - - - - - - - - - -
>> > > > > > > > > > [ ID]
>> > > > > > > > > > Interval Transfer Bandwidth
>Retr
>> > > > > > > > > > [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
>> > > > > > > > > > Mbits/sec 0 sender
>> > > > > > > > > > [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
>> > > > > > > > > > Mbits/sec receiver
>> > > > > > > > > >
>> > > > > > > > > > # iw dev wlan0 link
>> > > > > > > > > > Connected to xx:xx:xx:xx:xx (on wlan0)
>> > > > > > > > > > SSID: xxx
>> > > > > > > > > > freq: 2437
>> > > > > > > > > > tx bitrate: 65.0 MBit/s
>> > > > > > > > > >
>> > > > > > > > > > bss flags: short-preamble short-slot-
>> > > > > > > > > > time
>> > > > > > > > > > dtim period: 1
>> > > > > > > > > > beacon int: 100
>> > > > > > > > >
>> > > > > > > > > Too bad RSSI is not in the output above. That may be
>> > > > > > > > > due to
>> > > > > > > > > a
>> > > > > > > > > regression
>> > > > > > > > > in our driver which has been fixed by commit
>> > > > > > > > > 94abd778a7bb
>> > > > > > > > > ("brcmfmac:
>> > > > > > > > > add fallback for devices that do not report per-chain
>> > > > > > > > > values").
>> > > > > > > > > However,
>> > > > > > > > > the tx bitrate seems within the same range as the
>other
>> > > > > > > > > platform.
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > The Cubietruck works also with the brcmfmac driver.
>> > > > > > > > > >
>> > > > > > > > > > May it depend on the NVRAM file?
>> > > > > > > > >
>> > > > > > > > > Not sure. Can you tell me a bit more about the custom
>> > > > > > > > > ARM
>> > > > > > > > > board.
>> > > > > > > > > Does
>> > > > > > > > > it
>> > > > > > > > > use the same wifi module as Cubietruck, ie. the AMPAK
>> > > > > > > > > AP6210?
>> > > > > > > > > If
>> > > > > > > > > you
>> > > > > > > > > can
>> > > > > > > > > make a wireshark sniff we can check the actual
>bitrate
>> > > > > > > > > and
>> > > > > > > > > medium
>> > > > > > > > > density in terms of packets. Another thing to look at
>> > > > > > > > > is
>> > > > > > > > > the
>> > > > > > > > > SDIO
>> > > > > > > > > host
>> > > > > > > > > controller. In brcmf_sdiod_sgtable_alloc() some key
>> > > > > > > > > values
>> > > > > > > > > are
>> > > > > > > > > used
>> > > > > > > > > from
>> > > > > > > > > the host controller. It only logs the number of
>entries
>> > > > > > > > > of
>> > > > > > > > > the
>> > > > > > > > > scatter-gather table, but could you add the other
>> > > > > > > > > values in
>> > > > > > > > > this
>> > > > > > > > > function that are used to determine the number of
>> > > > > > > > > entries.
>> > > > > > > >
>> > > > > > > > My board uses the BCM43362 chip solely (no Bluetooth)
>> > > > > > > > attached to
>> > > > > > > > the
>> > > > > > > > SDIO interface of a NXP i.MX28 processor.
>> > > > > > > >
>> > > > > > > > I added some additional printk() to
>> > > > > > > > brcmf_sdiod_sgtable_alloc().
>> > > > > > > > These
>> > > > > > > > are the values printed after modprobe brcmfmac:
>> > > > > > > >
>> > > > > > > > [ 8.926657] sg_support=1
>> > > > > > > > [ 8.929440] max_blocks=511
>> > > > > > > > [ 8.932213] max_request_size=261632
>> > > > > > > > [ 8.935741] max_segment_count=52
>> > > > > > > > [ 8.939005] max_segment_size=65280
>> > > > > > > > [ 8.946095] nents=35
>> > > > > > >
>> > > > > > > Thanks. That looks good.
>> > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > Additionally I attached a xz compresses wireshark sniff
>> > > > > > > > while
>> > > > > > > > running
>> > > > > > > > iper3 between the BCM43362 running as in AP mode with
>> > > > > > > > iperf3
>> > > > > > > > as a
>> > > > > > > > server and a PC in station mode running iperf3 as a
>> > > > > > > > client.
>> > > > > > >
>> > > > > > > Looking at the sniff it seems you captured on the
>ethernet
>> > > > > > > side.
>> > > > > > > That
>> > > > > > > does not give me any 802.11 specific info. Can you make a
>> > > > > > > wireless
>> > > > > > > capture preferably without encryption.
>> > > > > >
>> > > > > > You,re right! Sorry for this mistake. I did a re-capture on
>> > > > > > the
>> > > > > > wireless side now.
>> > > > >
>> > > > > Anything new about this? Anything I can do to help?
>> > > >
>> > > > I missed your previous email. Was already wondering whether to
>> > > > ping
>> > > > you.
>> > > > Digging around in my email folders I found it so will take a
>look
>> > > > at
>> > > > it.
>> > >
>> > > Did you had some time to look at this?
>> >
>> > Ehm. I still only see TCP stuff. To capture 802.11 management
>frames
>> > you
>> > need preferably a dedicated device using monitor mode [1].
>>
>> Stupid me! Now I used a monitor interface on a desktop to monitor the
>> traffic between the BCM43362 operating in soft-AP mode and a notebook
>> operating in managed mode.
>>
>> The BCM43362 runs the iperf server, the notebook the iperf client.
>
>Thanks.
>
>Week almost through so might next week.
Did you had some time to look at this?
Best regards
Jörg Krause
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
^ permalink raw reply
* Re: [PATCH v4 1/3] mwifiex: reset card->adapter during device unregister
From: Brian Norris @ 2016-10-11 0:22 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
Xinming Hu, abhishekbh, Dmitry Torokhov
In-Reply-To: <20161010205332.GB11254@localhost>
+ Dmitry
Hi Amit,
On Mon, Oct 10, 2016 at 01:53:32PM -0700, Brian Norris wrote:
> On Thu, Oct 06, 2016 at 11:36:24PM +0530, Amitkumar Karwar wrote:
> > From: Xinming Hu <huxm@marvell.com>
> >
> > card->adapter gets initialized during device registration.
> > As it's not cleared, we may end up accessing invalid memory
> > in some corner cases. This patch fixes the problem.
> >
> > Signed-off-by: Xinming Hu <huxm@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > ---
> > v4: Same as v1, v2, v3
> > ---
> > drivers/net/wireless/marvell/mwifiex/pcie.c | 1 +
> > drivers/net/wireless/marvell/mwifiex/sdio.c | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > index f1eeb73..ba9e068 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > @@ -3042,6 +3042,7 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
> > pci_disable_msi(pdev);
> > }
> > }
> > + card->adapter = NULL;
> > }
> >
> > /* This function initializes the PCI-E host memory space, WCB rings, etc.
> > diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> > index 8718950..4cad1c2 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> > @@ -2066,6 +2066,7 @@ mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
> > struct sdio_mmc_card *card = adapter->card;
> >
> > if (adapter->card) {
> > + card->adapter = NULL;
> > sdio_claim_host(card->func);
> > sdio_disable_func(card->func);
> > sdio_release_host(card->func);
>
> As discussed on v1, I had qualms about the raciness between reads/writes
> of card->adapter, but I believe we:
> (a) can't have any command activity while writing the ->adapter field
> (either we're just init'ing the device, or we've disabled interrupts and
> are tearing it down) and
> (b) can't have a race between suspend()/resume() and unregister_dev(),
> since unregister_dev() is called from device remove() (which should not
> be concurrent with suspend()).
>
> Also, I thought you had the same problem in usb.c, but in fact, you
> fixed that ages ago here:
>
> 353d2a69ea26 mwifiex: fix issues in driver unload path for USB chipsets
>
> Would be nice if fixes were bettery synchronized across the three
> interface drivers you support. We seem to be discovering unnecessary
> divergence on a few points recently.
>
> At any rate:
>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Tested-by: Brian Norris <briannorris@chromium.org>
Dmitry helped me re-realize my original qualms:
mwifiex_unregister_dev() is called in the failure path for your async FW
request, and so it may race with suspend(). So I retract my Reviewed-by.
Sorry.
I'm going to look into converting to asynchronous device probing, which
might remove the need for async FW request, and would therefore resolve
both patch 1 and 3's races without any additional complicated hacks. But
I'm not sure if that will satisfy all mwifiex users well enough. I'll
have to give it a little more thought. Any thoughts from your side,
Amit?
Brian
^ permalink raw reply
* Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister
From: Brian Norris @ 2016-10-10 23:54 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, rajatja@google.com, Xinming Hu
In-Reply-To: <20161010234708.GA19969@localhost>
(I think Dmitry noticed the same while I wrote this.)
On Mon, Oct 10, 2016 at 04:47:08PM -0700, Brian Norris wrote:
> [*] The other cases are in error handling cases. I guess I should make
> sure those didn't race too...
Ah, well I think I missed one case:
For the async FW request code path, the callback mwifiex_fw_dpc() can
fail to load FW, and so it unwinds with:
if (adapter->if_ops.unregister_dev)
adapter->if_ops.unregister_dev(adapter);
This all happens after probe() is finished, so we can have a race on
card->adapter being read in suspend() and written in the $subject patch.
Can I revoke my Reviewed-by? (Or make it Reviewed-and-found-wanting-by?)
Brian
^ permalink raw reply
* Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister
From: Dmitry Torokhov @ 2016-10-10 23:53 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, rajatja@google.com, Xinming Hu
In-Reply-To: <20161010234708.GA19969@localhost>
Hi Brian,
On Mon, Oct 10, 2016 at 4:47 PM, Brian Norris <briannorris@chromium.org> wrote:
> Hi Dmitry,
>
> On Mon, Oct 10, 2016 at 04:43:06PM -0700, Dmitry Torokhov wrote:
>> On Thu, Oct 6, 2016 at 6:03 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
>> >> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> >> owner@vger.kernel.org] On Behalf Of Brian Norris
>> >> Sent: Wednesday, October 05, 2016 10:00 PM
>> >> To: Amitkumar Karwar
>> >> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> >> rajatja@google.com; Xinming Hu
>> >> Subject: Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device
>> >> unregister
>> >>
>> >> On Wed, Oct 05, 2016 at 02:04:53PM +0000, Amitkumar Karwar wrote:
>> >> > > From: Brian Norris [mailto:briannorris@chromium.org]
>> >> > > Sent: Wednesday, October 05, 2016 3:28 AM
>> >> > > To: Amitkumar Karwar
>> >> > > Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> >> > > rajatja@google.com; briannorris@google.com; Xinming Hu
>> >> > > Subject: Re: [PATCH v2 1/2] mwifiex: reset card->adapter during
>> >> > > device unregister
>> >> > >
>> >> > > On Tue, Oct 04, 2016 at 10:38:24PM +0530, Amitkumar Karwar wrote:
>> >>
>> >> > > > --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
>> >> > > > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
>> >> > > > @@ -3042,6 +3042,7 @@ static void mwifiex_unregister_dev(struct
>> >> > > mwifiex_adapter *adapter)
>> >> > > > pci_disable_msi(pdev);
>> >> > > > }
>> >> > > > }
>> >> > > > + card->adapter = NULL;
>> >> > >
>> >> > > I think you have a similar problem here as in patch 2; there is no
>> >> > > locking to protect fields in struct pcie_service_card or struct
>> >> > > sdio_mmc_card below. That problem kind of already exists, except
>> >> > > that you only write the value of card->adapter once at registration
>> >> > > time, so it's not actually unsafe. But now that you're introducing a
>> >> > > second write, you have a problem.
>> >> > >
>> >> > > Brian
>> >> > >
>> >> >
>> >> > We have a global "add_remove_card_sem" semaphore in our code for
>> >> > synchronizing initialization and teardown threads. Ideally "init +
>> >> > teardown/reboot" should not have a race issue with this logic
>> >> >
>> >> > Later there was a loophole introduced in this after using async
>> >> > firmware download API. During initialization, firmware downloads
>> >> > asynchronously in a separate thread where might have released the
>> >> > semaphore. I am working on a patch to fix this.
>> >> >
>> >> > So "card->adapter" doesn't need to have locking. Even if we have two
>> >> > write operations, those two threads can't run simultaneously due to
>> >> > above mentioned logic.
>> >>
>> >> What about writes racing with reads? You have lots of unsynchronized
>> >> cases that read this, although most of them should be halted by now
>> >> (e.g., cmd processing). I was looking at suspend() in particular, which
>> >> I thought you were looking at in this patch series.
>> >
>> > Please note that "card->adapter" is used only in pcie.c/sdio.c/usb.c files
>> >
>> > Writes won't have race with reads.
>> >
>> > 1) write 1 --- "card->adapter = adapter;" in mwifiex_register_dev()
>> > This place is at the beginning of initialization.
>> > mwifiex_pcie_probe() -> mwifiex_add_card() -> adapter->if_ops.register_dev()
>> > There is no chance that "card->adapter" is read anywhere at this point. FW is not yet downloaded
>> >
>> > 2) write 2 ---- "card->adapter = NULL;" in mwifiex_unregister_dev()
>> > This place the end of teardown phase.
>> > Interrupts are disabled and all cleanup is done. We have "card->adapter" NULL checks at entry point of suspend/remove/resume, if they get called after this.
>>
>> How exactly are you preventing ->suspend() from being called *while*
>> you are running mwifiex_unregister_dev()? I.e. user slamming the lid
>> of a laptop and throwing it in their backpack?
>
> As I already commented, isn't this primarily [*] called from the driver
> remove() callback? remove() doesn't race with suspend(), does it?
Nope, there is request_firmware_nowait() path that is asynchronous
with device registration/unregistration and power management. Maybe
the right way is to move the driver to async probing and switch that
request_firmware_nowait() into plain request_firmware(). I haven't
looked that closely.
The wording "we may end up accessing invalid memory in some corner
cases" which is a synonym for "the code is racy" caught my eye, thus
the response on the patch.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister
From: Brian Norris @ 2016-10-10 23:47 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, rajatja@google.com, Xinming Hu
In-Reply-To: <CAKdAkRTKo3JVJPamM44jyG6QuHoQB89FMKj5vo3-z6T+XH1W9Q@mail.gmail.com>
Hi Dmitry,
On Mon, Oct 10, 2016 at 04:43:06PM -0700, Dmitry Torokhov wrote:
> On Thu, Oct 6, 2016 at 6:03 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
> >> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> >> owner@vger.kernel.org] On Behalf Of Brian Norris
> >> Sent: Wednesday, October 05, 2016 10:00 PM
> >> To: Amitkumar Karwar
> >> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> >> rajatja@google.com; Xinming Hu
> >> Subject: Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device
> >> unregister
> >>
> >> On Wed, Oct 05, 2016 at 02:04:53PM +0000, Amitkumar Karwar wrote:
> >> > > From: Brian Norris [mailto:briannorris@chromium.org]
> >> > > Sent: Wednesday, October 05, 2016 3:28 AM
> >> > > To: Amitkumar Karwar
> >> > > Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> >> > > rajatja@google.com; briannorris@google.com; Xinming Hu
> >> > > Subject: Re: [PATCH v2 1/2] mwifiex: reset card->adapter during
> >> > > device unregister
> >> > >
> >> > > On Tue, Oct 04, 2016 at 10:38:24PM +0530, Amitkumar Karwar wrote:
> >>
> >> > > > --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> >> > > > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> >> > > > @@ -3042,6 +3042,7 @@ static void mwifiex_unregister_dev(struct
> >> > > mwifiex_adapter *adapter)
> >> > > > pci_disable_msi(pdev);
> >> > > > }
> >> > > > }
> >> > > > + card->adapter = NULL;
> >> > >
> >> > > I think you have a similar problem here as in patch 2; there is no
> >> > > locking to protect fields in struct pcie_service_card or struct
> >> > > sdio_mmc_card below. That problem kind of already exists, except
> >> > > that you only write the value of card->adapter once at registration
> >> > > time, so it's not actually unsafe. But now that you're introducing a
> >> > > second write, you have a problem.
> >> > >
> >> > > Brian
> >> > >
> >> >
> >> > We have a global "add_remove_card_sem" semaphore in our code for
> >> > synchronizing initialization and teardown threads. Ideally "init +
> >> > teardown/reboot" should not have a race issue with this logic
> >> >
> >> > Later there was a loophole introduced in this after using async
> >> > firmware download API. During initialization, firmware downloads
> >> > asynchronously in a separate thread where might have released the
> >> > semaphore. I am working on a patch to fix this.
> >> >
> >> > So "card->adapter" doesn't need to have locking. Even if we have two
> >> > write operations, those two threads can't run simultaneously due to
> >> > above mentioned logic.
> >>
> >> What about writes racing with reads? You have lots of unsynchronized
> >> cases that read this, although most of them should be halted by now
> >> (e.g., cmd processing). I was looking at suspend() in particular, which
> >> I thought you were looking at in this patch series.
> >
> > Please note that "card->adapter" is used only in pcie.c/sdio.c/usb.c files
> >
> > Writes won't have race with reads.
> >
> > 1) write 1 --- "card->adapter = adapter;" in mwifiex_register_dev()
> > This place is at the beginning of initialization.
> > mwifiex_pcie_probe() -> mwifiex_add_card() -> adapter->if_ops.register_dev()
> > There is no chance that "card->adapter" is read anywhere at this point. FW is not yet downloaded
> >
> > 2) write 2 ---- "card->adapter = NULL;" in mwifiex_unregister_dev()
> > This place the end of teardown phase.
> > Interrupts are disabled and all cleanup is done. We have "card->adapter" NULL checks at entry point of suspend/remove/resume, if they get called after this.
>
> How exactly are you preventing ->suspend() from being called *while*
> you are running mwifiex_unregister_dev()? I.e. user slamming the lid
> of a laptop and throwing it in their backpack?
As I already commented, isn't this primarily [*] called from the driver
remove() callback? remove() doesn't race with suspend(), does it?
[*] The other cases are in error handling cases. I guess I should make
sure those didn't race too...
Brian
^ permalink raw reply
* Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister
From: Dmitry Torokhov @ 2016-10-10 23:43 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Brian Norris, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, rajatja@google.com, Xinming Hu
In-Reply-To: <127198026f5149c783bb0f5855dc87b9@SC-EXCH04.marvell.com>
On Thu, Oct 6, 2016 at 6:03 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
> Hi Brian,
>
>> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] On Behalf Of Brian Norris
>> Sent: Wednesday, October 05, 2016 10:00 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> rajatja@google.com; Xinming Hu
>> Subject: Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device
>> unregister
>>
>> Hi,
>>
>> On Wed, Oct 05, 2016 at 02:04:53PM +0000, Amitkumar Karwar wrote:
>> > > From: Brian Norris [mailto:briannorris@chromium.org]
>> > > Sent: Wednesday, October 05, 2016 3:28 AM
>> > > To: Amitkumar Karwar
>> > > Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> > > rajatja@google.com; briannorris@google.com; Xinming Hu
>> > > Subject: Re: [PATCH v2 1/2] mwifiex: reset card->adapter during
>> > > device unregister
>> > >
>> > > Hi,
>> > >
>> > > On Tue, Oct 04, 2016 at 10:38:24PM +0530, Amitkumar Karwar wrote:
>>
>> > > > --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
>> > > > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
>> > > > @@ -3042,6 +3042,7 @@ static void mwifiex_unregister_dev(struct
>> > > mwifiex_adapter *adapter)
>> > > > pci_disable_msi(pdev);
>> > > > }
>> > > > }
>> > > > + card->adapter = NULL;
>> > >
>> > > I think you have a similar problem here as in patch 2; there is no
>> > > locking to protect fields in struct pcie_service_card or struct
>> > > sdio_mmc_card below. That problem kind of already exists, except
>> > > that you only write the value of card->adapter once at registration
>> > > time, so it's not actually unsafe. But now that you're introducing a
>> > > second write, you have a problem.
>> > >
>> > > Brian
>> > >
>> >
>> > We have a global "add_remove_card_sem" semaphore in our code for
>> > synchronizing initialization and teardown threads. Ideally "init +
>> > teardown/reboot" should not have a race issue with this logic
>> >
>> > Later there was a loophole introduced in this after using async
>> > firmware download API. During initialization, firmware downloads
>> > asynchronously in a separate thread where might have released the
>> > semaphore. I am working on a patch to fix this.
>> >
>> > So "card->adapter" doesn't need to have locking. Even if we have two
>> > write operations, those two threads can't run simultaneously due to
>> > above mentioned logic.
>>
>> What about writes racing with reads? You have lots of unsynchronized
>> cases that read this, although most of them should be halted by now
>> (e.g., cmd processing). I was looking at suspend() in particular, which
>> I thought you were looking at in this patch series.
>
> Please note that "card->adapter" is used only in pcie.c/sdio.c/usb.c files
>
> Writes won't have race with reads.
>
> 1) write 1 --- "card->adapter = adapter;" in mwifiex_register_dev()
> This place is at the beginning of initialization.
> mwifiex_pcie_probe() -> mwifiex_add_card() -> adapter->if_ops.register_dev()
> There is no chance that "card->adapter" is read anywhere at this point. FW is not yet downloaded
>
> 2) write 2 ---- "card->adapter = NULL;" in mwifiex_unregister_dev()
> This place the end of teardown phase.
> Interrupts are disabled and all cleanup is done. We have "card->adapter" NULL checks at entry point of suspend/remove/resume, if they get called after this.
How exactly are you preventing ->suspend() from being called *while*
you are running mwifiex_unregister_dev()? I.e. user slamming the lid
of a laptop and throwing it in their backpack?
Thanks.
--
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox