Hi,
This adds extra prints and information for
debugging purposes.
v2:
* merge scnprintfs
Michal Kazior (3):
ath10k: print wmi version info
ath10k: dump hex bytes with dev string prefix
ath10k: add debug dump for pci rx
drivers/net/wireless/ath/ath10k/debug.c | 25 +
This makes it easier to debug hex dumps on systems
with more than a single ath10k device.
Signed-off-by: Michal Kazior
---
Notes:
v2:
* merge 2 scnprintfs into 1 [Kalle]
drivers/net/wireless/ath/ath10k/debug.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
di
HTT version is already printed so print WMI
version as well for consistency.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/debug.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/at
This makes it easier to debug the device-target
communication at a very low level.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/pci.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index
On 22 September 2014 22:54, wrote:
> From: Ben Greear
>
> It appears it takes more than just setting the
> hardware's chainmask to make things work well. Without
> this patch, a vdev would only use 1x1 rates when chainmask
> was set to 0x3.
>
> Setting the 'nss' (number of spatial streams) on t
On 23 September 2014 01:00, wrote:
> From: Ben Greear
>
> When re-associating a station, the nss was set back to
> maximum value even if user had configured small number
> of tx chains. So, pay attention to user's config in
> this case as well.
>
> Signed-off-by: Ben Greear
> ---
> drivers/ne
On 19 September 2014 20:04, wrote:
> From: Ben Greear
>
> This can allow more than 32 stations to be supported
> without over-running the bitmap.
>
> Signed-off-by: Ben Greear
> ---
> drivers/net/wireless/ath/ath10k/core.c | 4 ++--
> drivers/net/wireless/ath/ath10k/core.h | 2 +-
> drivers/
On 09/23/14 00:49, Emil Goode wrote:
In the brcmf_count_20mhz_channels function we are looping through a list
of channels received from firmware. Since the index of the first channel
is 0 the condition leads to an off by one bug. This is causing us to hit
the WARN_ON_ONCE(1) calls in the brcmu_d1
On 19 September 2014 20:17, wrote:
> From: Ben Greear
>
> Add support for reading firmware stats through the ethtool
> API. This may be easier for applications to manipulate
> compared to parsing a text based debugfs file.
You also seem to be adding fw crash and reset countes. It's probably
wo
On 19 September 2014 20:28, wrote:
[...]
> + /* If we are CT firmware, ask it to flush all tids on all peers on
> +* all vdevs. Normal firmware will just crash if you do this.
> +*/
> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT, ar->fw_features))
> + ath
Hi John,
a new pull request just with ath10k changes this time. Changelog below
and please let me know if there are any problems.
--
The only new feature is testmode support from me. Ben added a new method
to crash the firmware
Michal Kazior writes:
> Some firmware revisions don't wait for beacon tx
> completion before sending another SWBA event. This
> could lead to hardware using old (freed) beacon
> data in some cases, e.g. tx credit starvation
> combined with missed TBTT. This is very very rare.
>
> On non-IOMMU-ena
Michal Kazior writes:
> Here's a bunch of clean up patches for WMI and a
> single fix. I'm including the fix in this patchset
> because one of the clean up patches depends on it.
>
>
> Michal Kazior (9):
> ath10k: fix tx/rx chainmask init
> ath10k: remove unused pdev_set_channel command
> a
On 09/23/14 01:08, Emil Goode wrote:
Hello Arend,
Sorry for the late reply. I have attached a kernel log with brcmfmac
debugging enabled (without my patch applied).
Let me know if I can provide any other useful information.
No problem, Emil
I was wondering what was returned on "chanspecs" qu
upstream: 87c4790330810fe5caf0172d9320cf24ef19cebe
The firmware notifies about interface changes through the IF event
which has a NO_IF flag that means host can ignore the event. This
behaviour was introduced in the driver by:
commit 2ee8382fc6c763c76396a6aaff77a27089eed3aa
Author: Arend van
again. Not only after resume but also
after could power up, it stalls right at start of wget for example.
> http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this
> is a trace collected after resuming from suspend-to-disk
And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4
I write here since I am currently performing experiments in which I need
specifically to disable RTS frames. Intuitively, I tried to set
iw phyXX set rts off
but btained counter-intuitive results, since RTS effectively dissappear
only for low traffic demands from upper layers (around 1Mbps with 3
"Grumbach, Emmanuel" writes:
>> Emmanuel Grumbach writes:
>>
>> > diff --git a/drivers/net/wireless/iwlwifi/iwl-8000.c
>> > b/drivers/net/wireless/iwlwifi/iwl-8000.c
>> > index 4ae8ba6..e435148 100644
>> > --- a/drivers/net/wireless/iwlwifi/iwl-8000.c
>> > +++ b/drivers/net/wireless/iwlwifi/iwl-
> "Grumbach, Emmanuel" writes:
> >> Emmanuel Grumbach writes:
> >>
> >> > diff --git a/drivers/net/wireless/iwlwifi/iwl-8000.c
> >> > b/drivers/net/wireless/iwlwifi/iwl-8000.c
> >> > index 4ae8ba6..e435148 100644
> >> > --- a/drivers/net/wireless/iwlwifi/iwl-8000.c
> >> > +++ b/drivers/net/wirele
I write here since I am currently performing experiments in which I need
specifically to disable RTS frames. Intuitively, I tried to set
iw phyXX set rts off
but btained counter-intuitive results, since RTS effectively
dissappeared
only for low traffic demands from upper layers (around 1Mbps with
/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz
is another trace, after insmod brcmutils& brcmsmac, starting trace-cmd record
(with network-manager running in the background), and running a wget on
http://ip-add-ress-of-the-access-point/somefile (which immediately stalls,
showing minimal progress
On 09/15/14 16:54, Marc & Karen Vincent wrote:
HelloSeth and Arend,
Thanks for getting back to me so quickly.
I hope that this gives some pointers -
* dmesg output attached as requested. The lines 30.649061 and
30.649285 (ref brcms) appear as error messages on the screen
during
gree...@candelatech.com writes:
> From: Ben Greear
>
> This can allow more than 32 stations to be supported
> without over-running the bitmap.
>
> Signed-off-by: Ben Greear
[...]
> - ar->monitor_vdev_id = bit - 1;
> + ar->monitor_vdev_id = bit;
[...]
> - arvif->vdev_id = bit - 1;
gree...@candelatech.com writes:
> From: Ben Greear
>
> Support up to 32 stations when using CT firmware.
>
> Signed-off-by: Ben Greear
[...]
> - if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT, ar->fw_features))
> + ar
gree...@candelatech.com writes:
> From: Ben Greear
>
> There are not many of these messages producted by the
> firmware, but they are generally fairly useful, so print
> them at info level.
>
> Signed-off-by: Ben Greear
> ---
> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
> 1 file changed, 1 i
On Tue, Sep 23, 2014 at 11:52:26AM +0200, Arend van Spriel wrote:
> upstream: 87c4790330810fe5caf0172d9320cf24ef19cebe
That commit id doesn't match anything in Linus's tree :(
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.k
gree...@candelatech.com writes:
> From: Ben Greear
>
> Should help debug firmware crashes, and give users a way
> to provide some useful debug reports to firmware developers.
>
> Signed-off-by: Ben Greear
> Signed-off-by: Kalle Valo
Like we talked on IRC, I think it's better to take a dump of
On 09/23/14 15:22, Greg KH wrote:
On Tue, Sep 23, 2014 at 11:52:26AM +0200, Arend van Spriel wrote:
upstream: 87c4790330810fe5caf0172d9320cf24ef19cebe
That commit id doesn't match anything in Linus's tree :(
Hmmm, that is weird:
[arend@lb-bun-235 ~/scm/brcm80211-next]
$ git remote show tor
> >>http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this
> >>is a trace collected after resuming from suspend-to-disk
> >
> >And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz
> >is another trace, after insmod brcmutils&a
.dat.gz -- this
is a trace collected after resuming from suspend-to-disk
And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz
is another trace, after insmod brcmutils& brcmsmac, starting trace-cmd record
(with network-manager running in the background), and running a
On Tue, Sep 23, 2014 at 03:42:42PM +0200, Arend van Spriel wrote:
> On 09/23/14 15:22, Greg KH wrote:
> >On Tue, Sep 23, 2014 at 11:52:26AM +0200, Arend van Spriel wrote:
> >>upstream: 87c4790330810fe5caf0172d9320cf24ef19cebe
> >
> >That commit id doesn't match anything in Linus's tree :(
> >
>
>
On 09/23/14 15:51, Greg KH wrote:
On Tue, Sep 23, 2014 at 03:42:42PM +0200, Arend van Spriel wrote:
On 09/23/14 15:22, Greg KH wrote:
On Tue, Sep 23, 2014 at 11:52:26AM +0200, Arend van Spriel wrote:
upstream: 87c4790330810fe5caf0172d9320cf24ef19cebe
That commit id doesn't match anything in
On Monday, September 22, 2014 10:35:34 AM Joe Perches wrote:
> Other miscellanea:
>
> o add __printf verification to wil6210 logging functions
> No format/argument mismatches found
>
> Signed-off-by: Joe Perches
>
For wil6210:
Acked-by: Vladimir Kondratiev
--
To unsubscribe from this lis
On 09/23/2014 02:16 AM, Michal Kazior wrote:
On 19 September 2014 20:28, wrote:
[...]
+ /* If we are CT firmware, ask it to flush all tids on all peers on
+* all vdevs. Normal firmware will just crash if you do this.
+*/
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_C
On 09/23/2014 05:54 AM, Kalle Valo wrote:
gree...@candelatech.com writes:
From: Ben Greear
This can allow more than 32 stations to be supported
without over-running the bitmap.
Signed-off-by: Ben Greear
[...]
- ar->monitor_vdev_id = bit - 1;
+ ar->monitor_vdev_id = bit;
23.09.2014 17:50, Arend van Spriel wrote:
> On 09/23/14 15:44, Seth Forshee wrote:
[]
>> Well, there are a few different trace events defined for brcmsmac. This
>> would enable the full set:
>>
>> $ trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg
>>
>> It's been quite some time since
23.09.2014 18:25, Michael Tokarev wrote:
> 23.09.2014 17:50, Arend van Spriel wrote:
>> On 09/23/14 15:44, Seth Forshee wrote:
[]
>>> It's been quite some time since I used them, but I think brcmsmac_tx is
>>> quite noisy so you may only want to enable that if you already suspect a
>>> tx problem.
On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote:
> 23.09.2014 18:25, Michael Tokarev wrote:
> > 23.09.2014 17:50, Arend van Spriel wrote:
> >> On 09/23/14 15:44, Seth Forshee wrote:
> []
> >>> It's been quite some time since I used them, but I think brcmsmac_tx is
> >>> quite noisy
The diagnostic window (CE7) uses polling and is not initiliased to retrieve
interrupts so disable interrupts altogether for CE7. Otherwise ath10k crashes
when using the diagnostic window while the firmware is running due to NULL
dereference and polling reads timeout.
Signed-off-by: Kalle Valo
---
diag_read() is used for reading from firmware memory via the diagnose window.
First user will be cal_data debugfs file.
To serialise diagnostic window access and make it safe to use while firmware is
running take ce_lock both in ath10k_pci_diag_write_mem() and
ath10k_pci_diag_read_mem(). Because o
Provide calibration data used by the firmware to user space via a debugfs file.
This makes it easier to debug calibration related problems.
Example:
sudo cp /sys/kernel/debug/ieee80211/phy0/ath10k/cal_data 1.cal
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/debug.c | 81 +
Hi,
I forgot add --edit-cover to stg. So here's the cover letter :)
ath10k: export calibration data to user space
here's a small patchset exporting firmware calibration data to user space. This
makes it easier to debug various calibration data related problems.
Please comment.
v2:
* never unm
On 09/23/2014 05:59 AM, Kalle Valo wrote:
gree...@candelatech.com writes:
From: Ben Greear
Support up to 32 stations when using CT firmware.
Signed-off-by: Ben Greear
[...]
- if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X
Dave,
Please consider pulling this one last batch of fixes intended for the 3.17
stream!
For the NFC bits, Samuel says:
"Hopefully not too late for a handful of NFC fixes:
- 2 potential build failures for ST21NFCA and ST21NFCB, triggered by a
depmod dependenyc cycle.
- One potential buffer o
On 09/23/2014 06:13 AM, Kalle Valo wrote:
gree...@candelatech.com writes:
From: Ben Greear
There are not many of these messages producted by the
firmware, but they are generally fairly useful, so print
them at info level.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/wmi
On Tue, Sep 23, 2014 at 07:20:53AM +0300, Kalle Valo wrote:
> Joe Perches writes:
>
> > The return values are not used by callers of these functions
> > so change the functions to return void.
> >
> > Other miscellanea:
> >
> > o add __printf verification to wil6210 logging functions
> > No for
"John W. Linville" writes:
> On Tue, Sep 23, 2014 at 07:20:53AM +0300, Kalle Valo wrote:
>> Joe Perches writes:
>>
>> > drivers/net/wireless/ath/wil6210/debug.c | 14 --
>> > drivers/net/wireless/ath/wil6210/wil6210.h | 7 +--
>> > 7 files changed, 32 insertions(+), 56 delet
23.09.2014 18:31, Seth Forshee пишет:
> On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote:
>> 23.09.2014 18:25, Michael Tokarev wrote:
>>> 23.09.2014 17:50, Arend van Spriel wrote:
On 09/23/14 15:44, Seth Forshee wrote:
>> []
> It's been quite some time since I used them, but
On 09/23/2014 01:59 AM, Michal Kazior wrote:
> On 23 September 2014 01:00, wrote:
>> From: Ben Greear
>>
>> When re-associating a station, the nss was set back to
>> maximum value even if user had configured small number
>> of tx chains. So, pay attention to user's config in
>> this case as wel
On 09/23/2014 01:53 AM, Michal Kazior wrote:
> On 22 September 2014 22:54, wrote:
>> From: Ben Greear
>>
>> It appears it takes more than just setting the
>> hardware's chainmask to make things work well. Without
>> this patch, a vdev would only use 1x1 rates when chainmask
>> was set to 0x3.
>
On 09/23/14 18:02, Michael Tokarev wrote:
23.09.2014 18:31, Seth Forshee пишет:
On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote:
23.09.2014 18:25, Michael Tokarev wrote:
23.09.2014 17:50, Arend van Spriel wrote:
On 09/23/14 15:44, Seth Forshee wrote:
[]
It's been quite some
23.09.2014 21:35, Arend van Spriel wrote:
> On 09/23/14 18:02, Michael Tokarev wrote:
>> Oh. Indeed. While I enabled it, I recompiled only drivers/net/wireless,
>> but not net/. Rebuilt, another trace is here --
>>
>> http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409233.dat.gz
>>
>> Than
Hi,
While investigating relatively poor performance on an 802.11n link, I noticed
the following in the logs:
wlp2s0: capabilities/regulatory prevented using AP HT/VHT configuration,
downgraded
On investigation, I found that the message comes from routine
ieee80211_determine_chantype(). I am
From: Ben Greear
Add placeholder so CT firmware can more easily co-exist with upstream
kernel.
Signed-off-by: Ben Greear
---
v2: Patch is same as last time, different subsequent patch added
in case that justifies this better. I have more, such as
tx-status (ie, tx rate) reporting, but th
From: Ben Greear
It appears it takes more than just setting the
hardware's chainmask to make things work well. Without
this patch, a vdev would only use 1x1 rates when chainmask
was set to 0x3.
Setting the 'nss' (number of spatial streams) on the vdev
helps the firmware's rate-control algorithm
From: Ben Greear
There are not many of these messages producted by the
firmware, but they are generally fairly useful, so print
them at info level.
Signed-off-by: Ben Greear
---
v2: Add and use a new debug-msg flag, change message
preamble slightly.
drivers/net/wireless/ath/ath10k/debu
From: Ben Greear
This gives user-space a normal-ish way to detect that
firmware has failed to start and that a reboot is
probably required.
Signed-off-by: Ben Greear
---
v2: New patch for this series, goes well with the other
ethtool patch.
drivers/net/wireless/ath/ath10k/core.h | 2 +-
From: Ben Greear
When re-associating a station, the nss was set back to
maximum value even if user had configured small number
of tx chains. So, pay attention to user's config in
this case as well.
Signed-off-by: Ben Greear
---
v2: No changes from v1.
drivers/net/wireless/ath/ath10k/mac.c
From: Ben Greear
CT firmware now supports flushing all tids for all
peers for all vdevs. This appears to help the ath10k_flush
logic work faster and not cause timeouts.
Signed-off-by: Ben Greear
---
v2: No changes, just added it to the series in case it
helps justify adding the CT feature
From: Michal Kazior
This simplifies tx credit management and tries to
address a problem where driver runs out of credits
and is unable to recover when firmware stalls.
This also makes it a little more easy to track and
debug htc tx credit flow since there should be no
laziness involved.
Signed-
From: Ben Greear
It can be nice to update the firmware's stats while
debugging other bits of the driver, so add helper method
to do this.
Signed-off-by: Ben Greear
---
v2: No changes.
drivers/net/wireless/ath/ath10k/debug.c | 26 +-
drivers/net/wireless/ath/ath10k/de
From: Ben Greear
This can allow more than 32 stations to be supported
without over-running the bitmap.
Signed-off-by: Ben Greear
---
v2: Change debug message.
drivers/net/wireless/ath/ath10k/core.c | 4 ++--
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/ma
From: Ben Greear
Add support for reading firmware stats through the ethtool
API. This may be easier for applications to manipulate
compared to parsing a text based debugfs file.
This patch also adds and reports firmware reset and
crash counters.
Signed-off-by: Ben Greear
---
v2: Add data-lo
On 09/22/2014 09:26 AM, Arnd Bergmann wrote:
> On Monday 22 September 2014 00:38:27 Hauke Mehrtens wrote:
>> +
>> +- reg : iomem address range of chipcommon core
>> +
>> +The cores on the AXI bus are automatically detected by bcma with the
>> +memory ranges they are using and they get registered af
Hello
I'm having "trouble" with output of iw (Debian Wheezy, Voyage-0.9.2)
iw version: 3.4-1
libiw30 version: 30~pre9-8
The output of iw dev X survey dump is very different for the
WLM54AGP23 card (ath5k) and WLM200NX (ath9k).
Is there any reason for ath9k to print the whole stuff?
Is there any o
In ath9k, when you set the chainmask to 2x2 on a 3x3 NIC,
the ht-caps appear as 2-streams in station association requests.
But, in ath10k, they still appear as 3x3. I don't see any obvious way
that ath9k notifies the mac80211 stack that it changed the
ht-caps, but it must be working somehow.
Any
Ben Greear wrote:
> In ath9k, when you set the chainmask to 2x2 on a 3x3 NIC,
> the ht-caps appear as 2-streams in station association requests.
>
> But, in ath10k, they still appear as 3x3. I don't see any obvious way
> that ath9k notifies the mac80211 stack that it changed the
> ht-caps, but it
On 09/23/2014 05:19 PM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> In ath9k, when you set the chainmask to 2x2 on a 3x3 NIC,
>> the ht-caps appear as 2-streams in station association requests.
>>
>> But, in ath10k, they still appear as 3x3. I don't see any obvious way
>> that ath9k notifies th
From: Ben Greear
We will need to use these in set-antenna, so move them
so that we do not have to define the method signatures.
Signed-off-by: Ben Greear
---
This appears to work, but needs more testing before it should
be applied. I'll do that testing tomorrow.
drivers/net/wireless/ath/ath
From: Ben Greear
This lets the mac80211 stack use the proper ht-caps when
negotiating with the peer. Note that all vdevs are guaranteed
to be down when antenna changes, so we can set the ht_caps
without worrying about messing up existing stations.
This patch also moves the get_nss_from_chainmas
Hi John,
This is the NFC pull request for 3.18.
We've had major updates for TI and ST Microelectronics drivers, and a
few NCI related changes.
For TI's trf7970a driver:
- Target mode support for trf7970a
- Suspend/resume support for trf7970a
- DT properties additions to handle different quirks
From: Sujith Manoharan
MCC fixes. Please review !
Sujith Manoharan (4):
ath9k: Fix queue management
ath9k: Use normal queues for offchannel frames
ath9k: Fix force_channel usage for offchannel frames
ath9k: Fix offchannel queuing
drivers/net/wireless/ath/ath9k/xmit.c | 20 ++---
From: Sujith Manoharan
Since RoC is done before frames marked with
IEEE80211_TX_CTL_TX_OFFCHAN are received by the driver,
setting force_channel is useless. We will be in
the required offchannel, so incoming frames can
be transmitted immediately.
Signed-off-by: Sujith Manoharan
---
drivers/net
From: Sujith Manoharan
There is no reason why frames marked with
IEEE80211_TX_CTL_TX_OFFCHAN have to be sent using
the UAPSD queue. Since mac80211 makes sure that
RoC is done before pushing an offchannel frame
to the driver, we can use the normal TX queues
for transmission.
Signed-off-by: Sujith
From: Sujith Manoharan
Since we use IEEE80211_HW_QUEUE_CONTROL now, the
CAB/Offchannel queues are registered as the last
two queues. There is no need to check and reassign
the queues in the TX start()/done() routines.
CAB frames will not reach the tx() callback since
we set IEEE80211_HW_HOST_BRO
From: Sujith Manoharan
Clearing IEEE80211_TX_CTL_PS_RESPONSE in a frame
that is not in the current context doesn't seem right.
Instead make sure that we don't add such frames
to the UAPSD queue by using a local variable.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/xmit.c
Sujith Manoharan wrote:
> From: Sujith Manoharan
>
> Since RoC is done before frames marked with
> IEEE80211_TX_CTL_TX_OFFCHAN are received by the driver,
> setting force_channel is useless. We will be in
> the required offchannel, so incoming frames can
> be transmitted immediately.
>
> Signed-
From: Sujith Manoharan
MCC fixes for 3.18. This includes the two patches that were posted earlier.
Sujith Manoharan (5):
ath9k: Cache BSS information
ath9k: Fix p2p address management
ath9k: Fix queue management
ath9k: Use normal queues for offchannel frames
ath9k: Fix offchannel queui
From: Sujith Manoharan
When multiple channel contexts are enabled, a p2p interface
that is assigned to a context will have an address that
is different from the device mac address, which is used
by wpa_s as the p2p device ID.
Certain frames like provision requests use the device address
and thes
From: Sujith Manoharan
Using the BSS information stored in mac80211 directly
is racy in certain conditions. For example, in a MCC
setup, if the scheduler is switching channels when
a local deauth is issued, calculation of the opmode/bssid
etc. is incorrect. To avoid this, store the bss params
in
From: Sujith Manoharan
There is no reason why frames marked with
IEEE80211_TX_CTL_TX_OFFCHAN have to be sent using
the UAPSD queue. Since mac80211 makes sure that
RoC is done before pushing an offchannel frame
to the driver, we can use the normal TX queues
for transmission.
Signed-off-by: Sujith
From: Sujith Manoharan
Since we use IEEE80211_HW_QUEUE_CONTROL now, the
CAB/Offchannel queues are registered as the last
two queues. There is no need to check and reassign
the queues in the TX start()/done() routines.
CAB frames will not reach the tx() callback since
we set IEEE80211_HW_HOST_BRO
From: Sujith Manoharan
Clearing IEEE80211_TX_CTL_PS_RESPONSE in a frame
that is not in the current context doesn't seem right.
Instead make sure that we don't add such frames
to the UAPSD queue by using a local variable.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/xmit.c
On 23 September 2014 16:19, Ben Greear wrote:
> On 09/23/2014 02:16 AM, Michal Kazior wrote:
>> On 19 September 2014 20:28, wrote:
>> [...]
>>>
>>> + /* If we are CT firmware, ask it to flush all tids on all peers
>>> on
>>> +* all vdevs. Normal firmware will just crash if you do
On 23 September 2014 16:32, Kalle Valo wrote:
[...]
> - for (ce_id = 0; ce_id < CE_COUNT; ce_id++)
> + /* Skip the last copy engine, CE7 the diagnostic window, as that
> +* uses polling and isn't initialized for interrupts. */
Comment style :-)
Michał
--
To unsubscribe from
85 matches
Mail list logo
