* AR6003 SDIO can't received data if you didn't send any date for a while
From: Randy Li @ 2013-05-15 17:21 UTC (permalink / raw)
To: linux-wireless; +Cc: ath6kl-devel
I use this WNIC in a s3c6410 devboard called OK6410 made by
forlinx(http://www.forlinx.net/Other/6.htm)
The kernel is 3.0.1, the driver in the kernel source can't work. So I
tried compat-wireless-3.3-2-n and
compat-wireless-3.5.4-1. 3.3-2 is eaier to get -101 error when I load
the modules, in this time I have to replug WNIC card.
When networking is connected, I can't ping ar6003 in the other place,
if ar6003 didn't send any data
recently.Once ar6003 stoped sending, I can't send to ar6003 after a
very little while.
But if I send large data like video both of them still stop working
after a while, 3.3-2(about 5 minutes) seems to work more longer than
3.5.4-1(about 1 mintue). But both ip link and iw wlan0 link show my
link is up. I have to ifdown and ifup to use wireless again.
kvalo said it cause by irq problem.But when I compiled compat-wireless
with debug, I only have files in /sys/kernel/debug/ieee80211/
phy0/ , but there is ath6kl directory there. I have enabled all
debug_mask, but I don't get any irq infomation frome dmesg.
Could you tell me the correct way enable debug in compiling and load module?
P.S how to install compat-wireless? I can't use INSTALL_MOD_PATH, I
have to copy these directory and use find tool to remove .c .h .o
files.
Here is output of /proc/interrupts in ok6410
CPU0
16: 3 s3c-uart s3c6400-uart
18: 240 s3c-uart s3c6400-uart
20: 2 s3c-uart
22: 48 s3c-uart
35: 0 VIC s3c-fimc0
36: 0 VIC s3c-fimc1
40: 0 VIC s3c-g3d
41: 0 VIC s3c-pp
42: 0 VIC s3c-rotator
43: 0 VIC s3c-g2d
44: 0 VIC TV_ENCODER
45: 0 VIC TV_SCALER
47: 0 VIC s3c-jpeg
48: 4735 VIC s3c-mfc
54: 0 VIC s3c-keypad
58: 0 VIC s3c2410-wdt
62: 460074 VIC s3c-lcd
68: 26 VIC AC97
73: 0 VIC DMA
74: 0 VIC DMA
79: 177847 VIC ohci_hcd:usb1
82: 123 VIC s3c2440-i2c.0
88: 46540 VIC mmc0
94: 0 VIC s3c_updown
95: 0 VIC adc, s3c_action
100: 727214 s3c-timer S3C2410 Timer Tick
101: 0 s3c-eint BUTTON1
102: 0 s3c-eint BUTTON2
103: 0 s3c-eint BUTTON3
104: 0 s3c-eint BUTTON4
105: 0 s3c-eint BUTTON5
106: 0 s3c-eint BUTTON6
108: 59168 s3c-eint eth0
Err: 0
-----
ayaka
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc works poorly in 3.9
From: Corey Richardson @ 2013-05-15 17:31 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <5189E31F.2090200@rempel-privat.de>
On Wed, May 8, 2013 at 1:31 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> If it is an regression, can you please do "git bisect". If you can locate
> the patch which introduced this regression, it will be great.
>
It seems to have been an intermittent problem with my WAP as well; the
PoE wasn't consistent so it kept dropping out, also taking down the
adapter with it. It does seem to be a regression, but it's so hard to
reproduce that I don't think it's worth pursuing.
Thanks!
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc works poorly in 3.9
From: Ben Greear @ 2013-05-15 17:33 UTC (permalink / raw)
To: Corey Richardson; +Cc: Oleksij Rempel, ath9k-devel, linux-wireless
In-Reply-To: <CA++BO6TBrzJtD2cnNmUu4j6G2c5tSq228318avuGVF4r1NeW-A@mail.gmail.com>
On 05/15/2013 10:31 AM, Corey Richardson wrote:
> On Wed, May 8, 2013 at 1:31 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> If it is an regression, can you please do "git bisect". If you can locate
>> the patch which introduced this regression, it will be great.
>>
>
> It seems to have been an intermittent problem with my WAP as well; the
> PoE wasn't consistent so it kept dropping out, also taking down the
> adapter with it. It does seem to be a regression, but it's so hard to
> reproduce that I don't think it's worth pursuing.
Sometimes I see the NIC fail to boot up on reboot of the OS.
I've only tested 3.9 kernels with these NICs, as I haven't used
them previously.
The kernel message was something about not being able to upload
firmware to the adapter...I'll grab some logs next
time I see it.
Thanks,
Ben
>
> Thanks!
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: linux-next: Tree for May 15 (wireless/brcm)
From: Randy Dunlap @ 2013-05-15 17:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, linux-wireless, Brett Rudley,
Arend van Spriel
In-Reply-To: <20130515132627.817585a3d9fb3a3e502eb586@canb.auug.org.au>
On 05/14/13 20:26, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130514:
>
on x86_64:
drivers/built-in.o: In function `brcms_led_unregister':
(.text+0x136f0e): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `brcms_led_register':
(.text+0x1370b5): undefined reference to `led_classdev_register'
when CONFIG_NEW_LEDS is not enabled.
--
~Randy
^ permalink raw reply
* Re: [PATCHv2 03/18] mac80211: fix various components for the new 5 and 10 MHz widths
From: Johannes Berg @ 2013-05-15 18:12 UTC (permalink / raw)
To: Sam Leffler
Cc: Simon Wunderlich, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <CA+yqC4a6W6i9TUoEc1Boxe6a5eun_TSjLB0F+w3F2L_Hn+v_gA@mail.gmail.com>
On Wed, 2013-05-15 at 10:16 -0700, Sam Leffler wrote:
> On Wed, May 15, 2013 at 7:18 AM, Simon Wunderlich
> <simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> This is a collection of minor fixes:
> * don't allow HT IEs in IBSS for 5/10 MHz
> * don't allow HT IEs in Mesh for 5/10 MHz
> * consider 5 and 10 MHz channels when downgrading
> * don't try HT rates for 5 and 10 MHz channels when selecting
> rates
>
>
> Perhaps I missed a standards discussion but unilaterally disallowing
> HT rates on 5/10 channels breaks existing functionality (e.g. I use
> them on openwrt). NOHT should be a regulatory constraint just like it
> is for 20 channels.
I don't see how this would break anything, since we wouldn't advertise
HT capabilities (for now). My point was that that the standard doesn't
(currently) define this, so I think it should be a separate second step
for 5/10 MHz channels to see how to do it in a way that wouldn't break
when/if the standard is changed to allow it, etc.
johannes
^ permalink raw reply
* Re: [PATCHv2 03/18] mac80211: fix various components for the new 5 and 10 MHz widths
From: Simon Wunderlich @ 2013-05-15 20:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Sam Leffler, Simon Wunderlich, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1368641562.20897.11.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
On Wed, May 15, 2013 at 08:12:42PM +0200, Johannes Berg wrote:
> On Wed, 2013-05-15 at 10:16 -0700, Sam Leffler wrote:
> > On Wed, May 15, 2013 at 7:18 AM, Simon Wunderlich
> > <simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> > This is a collection of minor fixes:
> > * don't allow HT IEs in IBSS for 5/10 MHz
> > * don't allow HT IEs in Mesh for 5/10 MHz
> > * consider 5 and 10 MHz channels when downgrading
> > * don't try HT rates for 5 and 10 MHz channels when selecting
> > rates
> >
> >
> > Perhaps I missed a standards discussion but unilaterally disallowing
> > HT rates on 5/10 channels breaks existing functionality (e.g. I use
> > them on openwrt). NOHT should be a regulatory constraint just like it
> > is for 20 channels.
>
> I don't see how this would break anything, since we wouldn't advertise
> HT capabilities (for now). My point was that that the standard doesn't
> (currently) define this, so I think it should be a separate second step
> for 5/10 MHz channels to see how to do it in a way that wouldn't break
> when/if the standard is changed to allow it, etc.
I generally think that we could add HT rates too, but this patchset does not
include that yet. Felix also told me that HT rates work on current hardware,
and freebsd seems to have support as well. But I'd like to postpone this step
for now and fix this in a later patchset, where we can address concerns too.
Thanks,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH V3] rtlwifi: rtl8192cu: Add new USB ID
From: Sergei Shtylyov @ 2013-05-15 20:23 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, Albert Pool, netdev
In-Reply-To: <1368630196-14704-1-git-send-email-Larry.Finger@lwfinger.net>
Hello.
On 05/15/2013 07:03 PM, Larry Finger wrote:
> From: Albert Pool <albertpool@solcon.nl>
>
> This adds the USB ID of the On Networks N300MA, clone of Netgear WNA3100M.
>
> Signed-off-by: Albert Pool <albertpool@solcon.nl>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Reported-by: Ana Rey <Anazul77@hotmail.com>
> ---
>
> John,
>
> Please use this version. V2 still had some whitespace errors that I fixed.
>
> Albert,
>
> Please use scripts/checkpatch.pl to check the patch before you send it.
>
> Thanks,
>
> Larry
> ---
>
> drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
> index 23d640a..18da6de 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
> @@ -349,6 +349,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
> {RTL_USB_DEVICE(0x07aa, 0x0056, rtl92cu_hal_cfg)}, /*ATKK-Gemtek*/
> {RTL_USB_DEVICE(0x07b8, 0x8178, rtl92cu_hal_cfg)}, /*Funai -Abocom*/
> {RTL_USB_DEVICE(0x0846, 0x9021, rtl92cu_hal_cfg)}, /*Netgear-Sercomm*/
> + {RTL_USB_DEVICE(0x0846, 0xf001, rtl92cu_hal_cfg)}, /*On Netwrks N300MA*/
"Networks", perhaps? Or does it hit 80 columns limit this way?
WBR, Sergei
^ permalink raw reply
* Re: [PATCHv2 00/18] Add support for 5 and 10 MHz channels
From: Simon Wunderlich @ 2013-05-15 20:24 UTC (permalink / raw)
To: Simon Wunderlich
Cc: linux-wireless, Johannes Berg, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1368627549-22518-1-git-send-email-siwu@hrz.tu-chemnitz.de>
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]
On Wed, May 15, 2013 at 04:18:51PM +0200, Simon Wunderlich wrote:
> This patchset adds support for 5 and 10 MHz in nl80211/cfg80211/mac80211
> and enables support in ath5k and ath9k, which already support this feature
> on the driver side. 5 and 10 MHz wide channels might be useful for:
>
> * long shot links, as the transmissions are more robust
> * future support for 802.11y which allows some 5 and 10 MHz channels in
> 3.6 GHz range
> * future support for 802.11p which uses 10 MHz in 5.9 GHz range
> * ... and more "special" applications.
>
> This patchset enables 5 and 10 MHz channels only for OFDM, and without
> HT/MIMO/aggregation (for now). Support may be added later.
>
> Changes to PATCHv1:
> * the actual datarates are handled, not the corresponding 20MHz rates
> as before. This should make it compatible to freebsd, although I was
> informed that some other implementors might still use the corresponding
> 20MHz rates. Anyway, from looking at the standard using the actual rates
> should be the right thing to do.
Johannes and me agreed that these bitrates tables are rather ugly, and I'll
rework the patchset to use rate flags instead of these bitrate_half/bitrate_quarter
tables as introduced in this patchset. This will not neccesarily make the mac80211
changes smaller but should avoid this bloat and make the driver implementations
nicer too. I'll post PATCHv3 soon.
Cheers,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH V3] rtlwifi: rtl8192cu: Add new USB ID
From: Larry Finger @ 2013-05-15 20:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linville, linux-wireless, Albert Pool, netdev
In-Reply-To: <5193EEA8.8030900@cogentembedded.com>
On 05/15/2013 03:23 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 05/15/2013 07:03 PM, Larry Finger wrote:
>
>> From: Albert Pool <albertpool@solcon.nl>
>>
>> This adds the USB ID of the On Networks N300MA, clone of Netgear WNA3100M.
>>
>> Signed-off-by: Albert Pool <albertpool@solcon.nl>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Reported-by: Ana Rey <Anazul77@hotmail.com>
>> ---
>>
>> John,
>>
>> Please use this version. V2 still had some whitespace errors that I fixed.
>>
>> Albert,
>>
>> Please use scripts/checkpatch.pl to check the patch before you send it.
>>
>> Thanks,
>>
>> Larry
>> ---
>>
>> drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
>> b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
>> index 23d640a..18da6de 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
>> @@ -349,6 +349,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
>> {RTL_USB_DEVICE(0x07aa, 0x0056, rtl92cu_hal_cfg)}, /*ATKK-Gemtek*/
>> {RTL_USB_DEVICE(0x07b8, 0x8178, rtl92cu_hal_cfg)}, /*Funai -Abocom*/
>> {RTL_USB_DEVICE(0x0846, 0x9021, rtl92cu_hal_cfg)}, /*Netgear-Sercomm*/
>> + {RTL_USB_DEVICE(0x0846, 0xf001, rtl92cu_hal_cfg)}, /*On Netwrks N300MA*/
>
> "Networks", perhaps? Or does it hit 80 columns limit this way?
That is exactly the problem. I suppose I could allow one line to be 81
characters in length, but that would diminish the effectiveness of my suggestion
that checkpatch be used.
Thanks for noticing. At least someone is reading the patches.
Larry
^ permalink raw reply
* Re: [PATCHv2 00/18] Add support for 5 and 10 MHz channels
From: Adrian Chadd @ 2013-05-15 20:59 UTC (permalink / raw)
To: Simon Wunderlich
Cc: linux-wireless, Johannes Berg, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1368627549-22518-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Have you tried interoperating with FreeBSD?
Have you tried interoperating with some of the atheros AP builds that
are out there?
I'd like to do some interoperability tests with this at some point
soon just to ensure things aren't too crazy.
thanks,
Adrian
On 15 May 2013 07:18, Simon Wunderlich
<simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> This patchset adds support for 5 and 10 MHz in nl80211/cfg80211/mac80211
> and enables support in ath5k and ath9k, which already support this feature
> on the driver side. 5 and 10 MHz wide channels might be useful for:
>
> * long shot links, as the transmissions are more robust
> * future support for 802.11y which allows some 5 and 10 MHz channels in
> 3.6 GHz range
> * future support for 802.11p which uses 10 MHz in 5.9 GHz range
> * ... and more "special" applications.
>
> This patchset enables 5 and 10 MHz channels only for OFDM, and without
> HT/MIMO/aggregation (for now). Support may be added later.
>
> Changes to PATCHv1:
> * the actual datarates are handled, not the corresponding 20MHz rates
> as before. This should make it compatible to freebsd, although I was
> informed that some other implementors might still use the corresponding
> 20MHz rates. Anyway, from looking at the standard using the actual rates
> should be the right thing to do.
> * txpower is decremented according to channel bandwidth (the regulation I
> checked all define limits in dBm/MHz)
> * radiotap support for 5/10 MHz channel flag was added
> * some fixes for ath5k/ath9k were included to make them interoperable
> (having the same SIFS improved performance quite well,
> 300kbps -> 6600 kbps for 5 MHz channels :) )
>
> As always, any comments are appreciated!
> Cheers,
> Simon
>
> Simon Wunderlich (18):
> nl80211/cfg80211: add 5 and 10 MHz defines and wiphy flag
> nl80211: add half/quarter channel bitrate tables to supported band
> struct
> mac80211: fix various components for the new 5 and 10 MHz widths
> mac80211: fix timing for 5 MHz and 10 MHz channels
> mac80211: round rates to the next multiple of 500kbps
> mac80211: choose bitrate table according to bandwidth
> mac80211: add radiotap flag and handling for 5/10 MHz
> cfg80211/mac80211: use reduced txpower for 5 and 10 MHz
> mac80211: change IBSS channel state to chandef
> nl80211: allow 5 and 10 MHz channels for IBSS
> ath9k: always use SIFS times from OFDM for 5/10 MHz
> ath9k: use chandef instead of channel_type
> ath9k: add and use 5/10 MHz bitrate tables
> ath9k: report 5/10 MHz channels
> ath9k: announce that ath9k supports 5/10 MHz
> ath5k: add and use 5/10 MHz bitrate tables
> ath5k: report 5/10 MHz channels
> ath5k: enable support for 5 MHz and 10 MHz channels
>
> drivers/net/wireless/ath/ath5k/ath5k.h | 11 +-
> drivers/net/wireless/ath/ath5k/base.c | 133 +++++++++++++++++++++---
> drivers/net/wireless/ath/ath5k/base.h | 2 +-
> drivers/net/wireless/ath/ath5k/debug.c | 23 ++++-
> drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
> drivers/net/wireless/ath/ath5k/pcu.c | 30 +++++-
> drivers/net/wireless/ath/ath5k/qcu.c | 23 ++++-
> drivers/net/wireless/ath/ath9k/beacon.c | 13 ++-
> drivers/net/wireless/ath/ath9k/common.c | 67 +++++++-----
> drivers/net/wireless/ath/ath9k/common.h | 3 +-
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 +-
> drivers/net/wireless/ath/ath9k/hw.c | 5 +-
> drivers/net/wireless/ath/ath9k/init.c | 68 +++++++++---
> drivers/net/wireless/ath/ath9k/main.c | 8 +-
> drivers/net/wireless/ath/ath9k/rc.c | 13 ++-
> drivers/net/wireless/ath/ath9k/recv.c | 24 ++++-
> drivers/net/wireless/ath/ath9k/xmit.c | 14 ++-
> include/net/cfg80211.h | 66 ++++++++++++
> include/net/ieee80211_radiotap.h | 4 +
> include/net/mac80211.h | 40 ++++++-
> include/uapi/linux/nl80211.h | 4 +
> net/mac80211/cfg.c | 50 +++++++--
> net/mac80211/ibss.c | 58 +++++++----
> net/mac80211/ieee80211_i.h | 47 ++++++++-
> net/mac80211/iface.c | 7 +-
> net/mac80211/main.c | 7 +-
> net/mac80211/mesh.c | 4 +-
> net/mac80211/mesh_plink.c | 18 +++-
> net/mac80211/mlme.c | 84 ++++++++++-----
> net/mac80211/rate.c | 102 ++++++++++++------
> net/mac80211/rc80211_minstrel.c | 59 +++++++----
> net/mac80211/rc80211_minstrel_ht.c | 26 +++--
> net/mac80211/rc80211_pid.h | 2 +
> net/mac80211/rc80211_pid_algo.c | 68 +++++++++---
> net/mac80211/rx.c | 52 +++++++---
> net/mac80211/status.c | 18 +++-
> net/mac80211/tx.c | 43 ++++++--
> net/mac80211/util.c | 138 +++++++++++++++++++------
> net/wireless/chan.c | 57 ++++++++--
> net/wireless/nl80211.c | 23 ++++-
> net/wireless/util.c | 58 +++++++++++
> 41 files changed, 1179 insertions(+), 300 deletions(-)
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
From: Larry Finger @ 2013-05-15 21:55 UTC (permalink / raw)
To: Norbert Preining; +Cc: Matt Causey, linux-wireless, linux-kernel, hostap
In-Reply-To: <20130515120801.GA24670@gamma.logic.tuwien.ac.at>
On 05/15/2013 07:08 AM, Norbert Preining wrote:
> Hi everyone,
>
> sorry for the late reply, business trip to Tokyo.
No problem.
> On Do, 09 Mai 2013, Larry Finger wrote:
>> absolutely critical, namely the PCI ID. There are at least three
>
> 10ec:8172
That card is the 1x2 variant.
I tested my sample of that card using the wireless-testing git repo as merged
with mainline on May 13. I could connect with WEP, WPA, and WPA2 APs and the
connection was stable for at least 2 hours.
Performance could be improved. For WEP and WPA, netperf shows about 10 Mbps for
RX and TX. For WPA2, it is not that good. I will compare these results with the
latest vendor driver, but it does not build on 3.10 and I do not have time to
sort that out now.
Larry
^ permalink raw reply
* STA doesn't support ACM for QoS
From: Cyril Seg @ 2013-05-15 22:42 UTC (permalink / raw)
To: linux-wireless
Hello ,
In my testbed, there is an AP that works with ath9k_htc and hostapd and there
also are 2 STAs that work with ath9k_htc.
Video flows aren't in the good priority, they are in Best_Effort.
But if I enable the ACM parameter for VIDEO and BEST EFFORT, video flows are
now in BACKGROUND priority.
STAs doesn't support the admission control ...
Does someone have a solution ?
I work with Kali Linux, kernel 3.7
Thanks,
Cyril Segretain
^ permalink raw reply
* Re: STA doesn't support ACM for QoS
From: Ben Greear @ 2013-05-15 22:53 UTC (permalink / raw)
To: Cyril Seg; +Cc: linux-wireless
In-Reply-To: <loom.20130516T003547-82@post.gmane.org>
On 05/15/2013 03:42 PM, Cyril Seg wrote:
> Hello ,
>
> In my testbed, there is an AP that works with ath9k_htc and hostapd and there
> also are 2 STAs that work with ath9k_htc.
> Video flows aren't in the good priority, they are in Best_Effort.
> But if I enable the ACM parameter for VIDEO and BEST EFFORT, video flows are
> now in BACKGROUND priority.
> STAs doesn't support the admission control ...
>
> Does someone have a solution ?
>
> I work with Kali Linux, kernel 3.7
See what ToS bits are in your video frames. Some definitions
of ToS had low values for video (32), but wifi requires different
settings (something like 128).
Thanks,
Ben
>
> Thanks,
>
> Cyril Segretain
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: STA doesn't support ACM for QoS
From: Cyril Segretain @ 2013-05-15 23:26 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
2013/5/15 Ben Greear <greearb@candelatech.com>:
> On 05/15/2013 03:42 PM, Cyril Seg wrote:
>>
>> Hello ,
>>
>> In my testbed, there is an AP that works with ath9k_htc and hostapd and
>> there
>> also are 2 STAs that work with ath9k_htc.
>> Video flows aren't in the good priority, they are in Best_Effort.
>> But if I enable the ACM parameter for VIDEO and BEST EFFORT, video flows
>> are
>> now in BACKGROUND priority.
>> STAs doesn't support the admission control ...
>>
>> Does someone have a solution ?
>>
>> I work with Kali Linux, kernel 3.7
>
>
> See what ToS bits are in your video frames. Some definitions
> of ToS had low values for video (32), but wifi requires different
> settings (something like 128).
>
The ToS for Video Streaming should be at 160.
But in my testbed all ToS bits are 0. I don't know why...
> Thanks,
> Ben
>
>
>
>>
>> Thanks,
>>
>> Cyril Segretain
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
^ permalink raw reply
* [PATCH 3.10] cfg80211: fix sending WoWLAN TCP wakeup settings
From: Johannes Berg @ 2013-05-16 8:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The code sending the current WoWLAN TCP wakeup settings in
nl80211_send_wowlan_tcp() is not closing the nested attribute,
thus causing the parser to get confused on the receiver side
in userspace (iw). Fix this.
Cc: stable@vger.kernel.org [3.9]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 0dca987..dfdb5e6 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7577,6 +7577,8 @@ static int nl80211_send_wowlan_tcp(struct sk_buff *msg,
&tcp->payload_tok))
return -ENOBUFS;
+ nla_nest_end(msg, nl_tcp);
+
return 0;
}
--
1.8.0
^ permalink raw reply related
* Re: Standardisation - adding 2 bit STBC and Ness to MCS (repost 3)
From: Oleksij Rempel @ 2013-05-16 9:01 UTC (permalink / raw)
To: radiotap, simon, ath9k-devel@lists.ath9k.org, linux-wireless,
johannes
In-Reply-To: <518B72AE.4010402@rempel-privat.de>
Hallo all,
so, there is no updates or critic on this topic. That mean, every thing
is OK.
I assume "suggested-fields/MCS extension for STBC and Ness"
http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
can be moved to "defined-fields/MCS"
http://www.radiotap.org/defined-fields/MCS
Johannes, your word ;)
Am 09.05.2013 11:55, schrieb Oleksij Rempel:
> Hallo all,
>
> this is probably third repost of this standardisation request.
>
> History:
> - 11 May 2012. initial request made by Simon Barber.
> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>
>
> - 1 Okt 2012, Wireshark support this fields. Patches provided by
> Wojciech Dubowik.
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6720
>
> - 1 Nov 2012. patches for intel adapters, ieee80211 and wireshark was
> uploaded by Simon.
> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness?action=AttachFile
>
>
> - 17 Nov 2012. Simon posted new thread as suggested Johannes Berg.
>
> - 1 May 2013. I restarted this discussion.
>
> link to initial discussion:
> http://comments.gmane.org/gmane.network.wireless.radiotap/302
>
> As you can see it is already long standing issue...
>
> Now to proposal mad by Simon. Please add comments like: agreed or not
> agreed and why.
>
> ======================== Proposal ===========================
>
> This proposal is to extend the current MCS radiotap header to carry STBC
> and Ness information. This information is carried in the 802.11 HT-SIG
> field that carries all the other fields currently in this radiotap MCS
> header. Both STBC and Ness fields are needed alongside the others to
> calculate the length (duration in time) of a frame. This proposal adds 3
> bits to the known field and the flags field. See below for proposed text.
>
> = MCS =
>
> Bit Number:: 19
> Structure:: u8 known, u8 flags, u8 mcs
> Required Alignment:: 1
>
> The `mcs` field indicates the MCS rate index as in
> [[http://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates|IEEE_802.11n-2009]]
>
>
> The `known` field indicates which information is known:
> ||'''flag'''||'''definition'''||
> || `0x01` || bandwidth ||
> || `0x02` || MCS index known (in `mcs` part of the field) ||
> || `0x04` || guard interval ||
> || `0x08` || HT format ||
> || `0x10` || FEC type ||
> || `0x20` || STBC known ||
> || `0x40` || Ness known (Number of extension spatial streams) ||
> || `0x80` || Ness data - bit 1 (MSB) of Number of extension spatial
> streams ||
>
> The `flags` field is any combination of the following:
> || '''flag''' || '''definition''' ||
> || `0x03` || bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U ||
> || `0x04` || guard interval - 0: long GI, 1: short GI ||
> || `0x08` || HT format - 0: mixed, 1: greenfield ||
> || `0x10` || FEC type - 0: BCC, 1: LDPC ||
> || `0x60` || Number of STBC streams ||
> || `0x80` || Ness - bit 0 (LSB) of Number of extension spatial streams |
>
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH V3] rtlwifi: rtl8192cu: Add new USB ID
From: Albert Pool @ 2013-05-16 9:04 UTC (permalink / raw)
To: Larry Finger; +Cc: Sergei Shtylyov, linville, linux-wireless, netdev
In-Reply-To: <5193F146.3030206@lwfinger.net>
Op 15-05-13 22:34, Larry Finger schreef:
> On 05/15/2013 03:23 PM, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 05/15/2013 07:03 PM, Larry Finger wrote:
>>
>>> From: Albert Pool <albertpool@solcon.nl>
>>>
>>> This adds the USB ID of the On Networks N300MA, clone of Netgear
>>> WNA3100M.
>>>
>>> Signed-off-by: Albert Pool <albertpool@solcon.nl>
>>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>>> Reported-by: Ana Rey <Anazul77@hotmail.com>
>>> ---
>>>
>>> John,
>>>
>>> Please use this version. V2 still had some whitespace errors that I
>>> fixed.
>>>
>>> Albert,
>>>
>>> Please use scripts/checkpatch.pl to check the patch before you send it.
>>>
>>> Thanks,
>>>
>>> Larry
>>> ---
>>>
>>> drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
>>> b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
>>> index 23d640a..18da6de 100644
>>> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
>>> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
>>> @@ -349,6 +349,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
>>> {RTL_USB_DEVICE(0x07aa, 0x0056, rtl92cu_hal_cfg)},
>>> /*ATKK-Gemtek*/
>>> {RTL_USB_DEVICE(0x07b8, 0x8178, rtl92cu_hal_cfg)}, /*Funai
>>> -Abocom*/
>>> {RTL_USB_DEVICE(0x0846, 0x9021, rtl92cu_hal_cfg)},
>>> /*Netgear-Sercomm*/
>>> + {RTL_USB_DEVICE(0x0846, 0xf001, rtl92cu_hal_cfg)}, /*On Netwrks
>>> N300MA*/
>>
>> "Networks", perhaps? Or does it hit 80 columns limit this way?
>
> That is exactly the problem. I suppose I could allow one line to be 81
> characters in length, but that would diminish the effectiveness of my
> suggestion that checkpatch be used.
>
> Thanks for noticing. At least someone is reading the patches.
>
> Larry
>
>
So my patch v2 could not be used because the line was longer than 80
chars? (It was 82, indeed)
Also the problems with bad signal were due to Ana Rey's AP. It's being
fixed or replaced today.
Albert
^ permalink raw reply
* [PATCHv3 01/18] nl80211/cfg80211: add 5 and 10 MHz defines and wiphy flag
From: Simon Wunderlich @ 2013-05-16 11:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368702045-27598-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Add defines for 5 and 10 MHz channel width and fix channel
handling functions accordingly.
Also check for and report the WIPHY_FLAG_SUPPORTS_5_10_MHZ
capability.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
include/net/cfg80211.h | 2 ++
include/uapi/linux/nl80211.h | 4 +++
net/wireless/chan.c | 57 ++++++++++++++++++++++++++++++++++++------
net/wireless/nl80211.c | 21 +++++++++++++---
4 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 26b5b69..08489cc 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2307,6 +2307,7 @@ struct cfg80211_ops {
* responds to probe-requests in hardware.
* @WIPHY_FLAG_OFFCHAN_TX: Device supports direct off-channel TX.
* @WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL: Device supports remain-on-channel call.
+ * @WIPHY_FLAG_SUPPORTS_5_10_MHZ: Device supports 5 MHz and 10 MHz channels.
*/
enum wiphy_flags {
WIPHY_FLAG_CUSTOM_REGULATORY = BIT(0),
@@ -2330,6 +2331,7 @@ enum wiphy_flags {
WIPHY_FLAG_AP_PROBE_RESP_OFFLOAD = BIT(19),
WIPHY_FLAG_OFFCHAN_TX = BIT(20),
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL = BIT(21),
+ WIPHY_FLAG_SUPPORTS_5_10_MHZ = BIT(22),
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index d1e48b5..3e95e74 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2730,6 +2730,8 @@ enum nl80211_channel_type {
* and %NL80211_ATTR_CENTER_FREQ2 attributes must be provided as well
* @NL80211_CHAN_WIDTH_160: 160 MHz channel, the %NL80211_ATTR_CENTER_FREQ1
* attribute must be provided as well
+ * @NL80211_CHAN_WIDTH_5: 5 MHz OFDM channel
+ * @NL80211_CHAN_WIDTH_10: 10 MHz OFDM channel
*/
enum nl80211_chan_width {
NL80211_CHAN_WIDTH_20_NOHT,
@@ -2738,6 +2740,8 @@ enum nl80211_chan_width {
NL80211_CHAN_WIDTH_80,
NL80211_CHAN_WIDTH_80P80,
NL80211_CHAN_WIDTH_160,
+ NL80211_CHAN_WIDTH_5,
+ NL80211_CHAN_WIDTH_10,
};
/**
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index fd556ac..126e31c 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -54,6 +54,8 @@ bool cfg80211_chandef_valid(const struct cfg80211_chan_def *chandef)
control_freq = chandef->chan->center_freq;
switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
case NL80211_CHAN_WIDTH_20:
case NL80211_CHAN_WIDTH_20_NOHT:
if (chandef->center_freq1 != control_freq)
@@ -152,6 +154,12 @@ static int cfg80211_chandef_get_width(const struct cfg80211_chan_def *c)
int width;
switch (c->width) {
+ case NL80211_CHAN_WIDTH_5:
+ width = 5;
+ break;
+ case NL80211_CHAN_WIDTH_10:
+ width = 10;
+ break;
case NL80211_CHAN_WIDTH_20:
case NL80211_CHAN_WIDTH_20_NOHT:
width = 20;
@@ -194,6 +202,16 @@ cfg80211_chandef_compatible(const struct cfg80211_chan_def *c1,
if (c1->width == c2->width)
return NULL;
+ /*
+ * can't be compatible if one of them are 5 or 10 MHz,
+ * but they have not the same width.
+ */
+ if (c1->width == NL80211_CHAN_WIDTH_5 ||
+ c1->width == NL80211_CHAN_WIDTH_10 ||
+ c2->width == NL80211_CHAN_WIDTH_5 ||
+ c2->width == NL80211_CHAN_WIDTH_10)
+ return NULL;
+
if (c1->width == NL80211_CHAN_WIDTH_20_NOHT ||
c1->width == NL80211_CHAN_WIDTH_20)
return c2;
@@ -264,11 +282,17 @@ static int cfg80211_get_chans_dfs_required(struct wiphy *wiphy,
u32 bandwidth)
{
struct ieee80211_channel *c;
- u32 freq;
+ u32 freq, start_freq, end_freq;
- for (freq = center_freq - bandwidth/2 + 10;
- freq <= center_freq + bandwidth/2 - 10;
- freq += 20) {
+ if (bandwidth <= 20) {
+ start_freq = center_freq;
+ end_freq = center_freq;
+ } else {
+ start_freq = center_freq - bandwidth/2 + 10;
+ end_freq = center_freq + bandwidth/2 - 10;
+ }
+
+ for (freq = start_freq; freq <= end_freq; freq += 20) {
c = ieee80211_get_channel(wiphy, freq);
if (!c)
return -EINVAL;
@@ -310,11 +334,17 @@ static bool cfg80211_secondary_chans_ok(struct wiphy *wiphy,
u32 prohibited_flags)
{
struct ieee80211_channel *c;
- u32 freq;
+ u32 freq, start_freq, end_freq;
- for (freq = center_freq - bandwidth/2 + 10;
- freq <= center_freq + bandwidth/2 - 10;
- freq += 20) {
+ if (bandwidth <= 20) {
+ start_freq = center_freq;
+ end_freq = center_freq;
+ } else {
+ start_freq = center_freq - bandwidth/2 + 10;
+ end_freq = center_freq + bandwidth/2 - 10;
+ }
+
+ for (freq = start_freq; freq <= end_freq; freq += 20) {
c = ieee80211_get_channel(wiphy, freq);
if (!c)
return false;
@@ -349,6 +379,12 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
control_freq = chandef->chan->center_freq;
switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_5:
+ width = 5;
+ break;
+ case NL80211_CHAN_WIDTH_10:
+ width = 10;
+ break;
case NL80211_CHAN_WIDTH_20:
if (!ht_cap->ht_supported)
return false;
@@ -405,6 +441,11 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
if (width > 20)
prohibited_flags |= IEEE80211_CHAN_NO_OFDM;
+ /* 5 and 10 MHz are only defined for the OFDM PHY */
+ if (width < 20)
+ prohibited_flags |= IEEE80211_CHAN_NO_OFDM;
+
+
if (!cfg80211_secondary_chans_ok(wiphy, chandef->center_freq1,
width, prohibited_flags))
return false;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index afa2838..75070da 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1228,6 +1228,9 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *dev,
if ((dev->wiphy.flags & WIPHY_FLAG_TDLS_EXTERNAL_SETUP) &&
nla_put_flag(msg, NL80211_ATTR_TDLS_EXTERNAL_SETUP))
goto nla_put_failure;
+ if ((dev->wiphy.flags & WIPHY_FLAG_SUPPORTS_5_10_MHZ) &&
+ nla_put_flag(msg, WIPHY_FLAG_SUPPORTS_5_10_MHZ))
+ goto nla_put_failure;
(*split_start)++;
if (split)
@@ -1771,6 +1774,11 @@ static int nl80211_parse_chandef(struct cfg80211_registered_device *rdev,
IEEE80211_CHAN_DISABLED))
return -EINVAL;
+ if ((chandef->width == NL80211_CHAN_WIDTH_5 ||
+ chandef->width == NL80211_CHAN_WIDTH_10) &&
+ !(rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_5_10_MHZ))
+ return -EINVAL;
+
return 0;
}
@@ -6288,11 +6296,16 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef))
return -EINVAL;
- if (ibss.chandef.width > NL80211_CHAN_WIDTH_40)
- return -EINVAL;
- if (ibss.chandef.width != NL80211_CHAN_WIDTH_20_NOHT &&
- !(rdev->wiphy.features & NL80211_FEATURE_HT_IBSS))
+ switch (ibss.chandef.width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ break;
+ case NL80211_CHAN_WIDTH_20:
+ case NL80211_CHAN_WIDTH_40:
+ if (rdev->wiphy.features & NL80211_FEATURE_HT_IBSS)
+ break;
+ default:
return -EINVAL;
+ }
ibss.channel_fixed = !!info->attrs[NL80211_ATTR_FREQ_FIXED];
ibss.privacy = !!info->attrs[NL80211_ATTR_PRIVACY];
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 02/18] nl80211: add rate flags for 5/10 Mhz channels
From: Simon Wunderlich @ 2013-05-16 11:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368702045-27598-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
include/net/cfg80211.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 08489cc..c9f5194 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -188,6 +188,8 @@ struct ieee80211_channel {
* when used with 802.11g (on the 2.4 GHz band); filled by the
* core code when registering the wiphy.
* @IEEE80211_RATE_ERP_G: This is an ERP rate in 802.11g mode.
+ * @IEEE80211_RATE_SUPPORTS_5MHZ: Rate can be used in 5 MHz mode
+ * @IEEE80211_RATE_SUPPORTS_10MHZ: Rate can be used in 10 MHz mode
*/
enum ieee80211_rate_flags {
IEEE80211_RATE_SHORT_PREAMBLE = 1<<0,
@@ -195,6 +197,8 @@ enum ieee80211_rate_flags {
IEEE80211_RATE_MANDATORY_B = 1<<2,
IEEE80211_RATE_MANDATORY_G = 1<<3,
IEEE80211_RATE_ERP_G = 1<<4,
+ IEEE80211_RATE_SUPPORTS_5MHZ = 1<<5,
+ IEEE80211_RATE_SUPPORTS_10MHZ = 1<<6,
};
/**
@@ -433,6 +437,30 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
u32 prohibited_flags);
/**
+ * ieee80211_chandef_rate_flags - returns rate flags for a channel
+ *
+ * In some channel types, not all rates may be used - for example CCK
+ * rates may not be used in 5/10 MHz channels.
+ *
+ * @chandef: channel definition for the channel
+ *
+ * Returns: rate flags which apply for this channel
+ */
+static inline enum ieee80211_rate_flags
+ieee80211_chandef_rate_flags(struct cfg80211_chan_def *chandef)
+{
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_5:
+ return IEEE80211_RATE_SUPPORTS_5MHZ;
+ case NL80211_CHAN_WIDTH_10:
+ return IEEE80211_RATE_SUPPORTS_10MHZ;
+ default:
+ break;
+ }
+ return 0;
+}
+
+/**
* enum survey_info_flags - survey information flags
*
* @SURVEY_INFO_NOISE_DBM: noise (in dBm) was filled in
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 04/18] mac80211: fix various components for the new 5 and 10 MHz widths
From: Simon Wunderlich @ 2013-05-16 11:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368702045-27598-1-git-send-email-siwu@hrz.tu-chemnitz.de>
This is a collection of minor fixes:
* don't allow HT IEs in IBSS for 5/10 MHz
* don't allow HT IEs in Mesh for 5/10 MHz
* consider 5 and 10 MHz channels when downgrading
* don't try HT rates for 5 and 10 MHz channels when selecting rates
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/ibss.c | 2 ++
net/mac80211/mesh.c | 4 +++-
net/mac80211/mesh_plink.c | 8 +++++++-
net/mac80211/mlme.c | 12 ++++++++++++
net/mac80211/rate.c | 8 +++++++-
5 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 170f9a7..4e1fb81 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -176,6 +176,8 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
/* add HT capability and information IEs */
if (chandef.width != NL80211_CHAN_WIDTH_20_NOHT &&
+ chandef.width != NL80211_CHAN_WIDTH_5 &&
+ chandef.width != NL80211_CHAN_WIDTH_10 &&
sband->ht_cap.ht_supported) {
pos = ieee80211_ie_build_ht_cap(pos, &sband->ht_cap,
sband->ht_cap.cap);
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 6952760..5227b73 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -417,7 +417,9 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data *sdata,
sband = local->hw.wiphy->bands[band];
if (!sband->ht_cap.ht_supported ||
- sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT)
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
return 0;
if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 09bebed..02c05fa 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -154,8 +154,14 @@ static u32 mesh_set_ht_prot_mode(struct ieee80211_sub_if_data *sdata)
u16 ht_opmode;
bool non_ht_sta = false, ht20_sta = false;
- if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT)
+ switch (sdata->vif.bss_conf.chandef.width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
return 0;
+ default:
+ break;
+ }
rcu_read_lock();
list_for_each_entry_rcu(sta, &local->sta_list, list) {
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 29620bf..0eaee23 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -224,6 +224,12 @@ static u32 chandef_downgrade(struct cfg80211_chan_def *c)
c->width = NL80211_CHAN_WIDTH_20_NOHT;
ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
break;
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
+ WARN_ON_ONCE(1);
+ /* keep c->width */
+ ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
+ break;
}
WARN_ON_ONCE(!cfg80211_chandef_valid(c));
@@ -3809,6 +3815,12 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
*/
ret = ieee80211_vif_use_channel(sdata, &chandef,
IEEE80211_CHANCTX_SHARED);
+
+ /* don't downgrade for 5 and 10 MHz channels, though. */
+ if (chandef.width == NL80211_CHAN_WIDTH_5 ||
+ chandef.width == NL80211_CHAN_WIDTH_10)
+ return ret;
+
while (ret && chandef.width != NL80211_CHAN_WIDTH_20_NOHT) {
ifmgd->flags |= chandef_downgrade(&chandef);
ret = ieee80211_vif_use_channel(sdata, &chandef,
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 8b95819..118e47b 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -397,8 +397,14 @@ static void rate_idx_match_mask(struct ieee80211_tx_rate *rate,
return;
/* if HT BSS, and we handle a data frame, also try HT rates */
- if (chan_width == NL80211_CHAN_WIDTH_20_NOHT)
+ switch (chan_width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
return;
+ default:
+ break;
+ }
alt_rate.idx = 0;
/* keep protection flags */
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 03/18] mac80211: Fix rate control mask matching call
From: Simon Wunderlich @ 2013-05-16 11:00 UTC (permalink / raw)
To: linux-wireless
Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich,
Felix Fietkau
In-Reply-To: <1368702045-27598-1-git-send-email-siwu@hrz.tu-chemnitz.de>
The order of parameters was mixed up, introduced in commit
"mac80211: improve the rate control API"
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/rate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 0d51877..8b95819 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -615,7 +615,7 @@ static void rate_control_apply_mask(struct ieee80211_sub_if_data *sdata,
if (rates[i].idx < 0)
break;
- rate_idx_match_mask(&rates[i], sband, mask, chan_width,
+ rate_idx_match_mask(&rates[i], sband, chan_width, mask,
mcs_mask);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 00/18] Add support for 5 and 10 MHz channels
From: Simon Wunderlich @ 2013-05-16 11:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
This patchset adds support for 5 and 10 MHz in nl80211/cfg80211/mac80211
and enables support in ath5k and ath9k, which already support this feature
on the driver side. 5 and 10 MHz wide channels might be useful for:
* long shot links, as the transmissions are more robust
* future support for 802.11y which allows some 5 and 10 MHz channels in
3.6 GHz range
* future support for 802.11p which uses 10 MHz in 5.9 GHz range
* ... and more "special" applications.
This patchset enables 5 and 10 MHz channels only for OFDM, and without
HT/MIMO/aggregation (for now). Support may be added later.
Changes to PATCHv2:
* instead of introducing new bitrate tables, use bitrate flags which mark
the bitrate with support for 5/10 MHz. All bitrates have then to be
calculated manually.
--> this saves a few changes where we only operate on indexes anyway,
but requires some more checking at other parts where it is required
to see if the rate is supported in 5/10 MHz. At least it is not
that ugly and bloaty, and also saves a lot of code in drivers.
* various DIV_ROUND_UP()s have been used instead of manual conversions
--> this was squashed with the "big" bitrate adjustment patch (-1 patch)
* found a bug in the rate mask matching code, which is fixed (+1 patch)
* fixed a few bugs I introuced myself. :)
As always, any comments are appreciated!
Cheers,
Simon
Simon Wunderlich (18):
nl80211/cfg80211: add 5 and 10 MHz defines and wiphy flag
nl80211: add rate flags for 5/10 Mhz channels
mac80211: Fix rate control mask matching call
mac80211: fix various components for the new 5 and 10 MHz widths
mac80211: fix timing for 5 MHz and 10 MHz channels
mac80211: select and adjust bitrates according for channel mode
mac80211: add radiotap flag and handling for 5/10 MHz
cfg80211/mac80211: use reduced txpower for 5 and 10 MHz
mac80211: change IBSS channel state to chandef
nl80211: allow 5 and 10 MHz channels for IBSS
ath9k: always use SIFS times from OFDM for 5/10 MHz
ath9k: use chandef instead of channel_type
ath9k: report 5/10 MHz channels
ath9k: set 5/10 MHz supported channels and fix bitrate
ath9k: announce that ath9k supports 5/10 MHz
ath5k: report 5/10 MHz channels
ath5k: set 5/10 MHz supported channels and fix duration
ath5k: enable support for 5 MHz and 10 MHz channels
drivers/net/wireless/ath/ath5k/ath5k.h | 1 +
drivers/net/wireless/ath/ath5k/base.c | 59 ++++++++--
drivers/net/wireless/ath/ath5k/base.h | 2 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
drivers/net/wireless/ath/ath5k/pcu.c | 2 +
drivers/net/wireless/ath/ath5k/qcu.c | 25 +++-
drivers/net/wireless/ath/ath9k/common.c | 67 +++++++----
drivers/net/wireless/ath/ath9k/common.h | 3 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 +-
drivers/net/wireless/ath/ath9k/hw.c | 5 +-
drivers/net/wireless/ath/ath9k/init.c | 29 +++--
drivers/net/wireless/ath/ath9k/main.c | 8 +-
drivers/net/wireless/ath/ath9k/rc.c | 10 +-
drivers/net/wireless/ath/ath9k/recv.c | 11 ++
include/net/cfg80211.h | 55 +++++++++
include/net/ieee80211_radiotap.h | 4 +
include/net/mac80211.h | 5 +-
include/uapi/linux/nl80211.h | 4 +
net/mac80211/cfg.c | 36 +++++-
net/mac80211/ibss.c | 101 +++++++++++-----
net/mac80211/ieee80211_i.h | 45 ++++++-
net/mac80211/iface.c | 2 +-
net/mac80211/main.c | 2 +-
net/mac80211/mesh.c | 4 +-
net/mac80211/mesh_plink.c | 8 +-
net/mac80211/mlme.c | 99 ++++++++++++----
net/mac80211/rate.c | 60 +++++-----
net/mac80211/rc80211_minstrel.c | 29 ++++-
net/mac80211/rc80211_minstrel_ht.c | 11 +-
net/mac80211/rx.c | 28 +++--
net/mac80211/status.c | 17 ++-
net/mac80211/tx.c | 16 ++-
net/mac80211/util.c | 157 +++++++++++++++++++------
net/wireless/chan.c | 57 +++++++--
net/wireless/nl80211.c | 23 +++-
35 files changed, 761 insertions(+), 231 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCHv3 05/18] mac80211: fix timing for 5 MHz and 10 MHz channels
From: Simon Wunderlich @ 2013-05-16 11:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368702045-27598-1-git-send-email-siwu@hrz.tu-chemnitz.de>
according to IEEE 802.11-2012 section 18, various timings change
when using 5 MHz and 10 MHz. Reflect this by using a "divisor" when
calculating durations.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/ieee80211_i.h | 42 +++++++++++++++++++++++++++++++++++-
net/mac80211/rc80211_minstrel.c | 15 ++++++++-----
net/mac80211/rc80211_minstrel_ht.c | 8 ++++---
net/mac80211/tx.c | 10 ++++++---
net/mac80211/util.c | 39 ++++++++++++++++++++++-----------
5 files changed, 89 insertions(+), 25 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 158e6eb..0e8f2d0 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -793,6 +793,45 @@ ieee80211_get_sdata_band(struct ieee80211_sub_if_data *sdata)
return band;
}
+static inline int
+ieee80211_vif_get_divisor(struct ieee80211_vif *vif)
+{
+ struct ieee80211_chanctx_conf *chanctx_conf;
+ int divisor = 1;
+
+ rcu_read_lock();
+ chanctx_conf = rcu_dereference(vif->chanctx_conf);
+ if (chanctx_conf) {
+ switch (chanctx_conf->def.width) {
+ case NL80211_CHAN_WIDTH_5:
+ divisor = 4;
+ break;
+ case NL80211_CHAN_WIDTH_10:
+ divisor = 2;
+ break;
+ default:
+ divisor = 1;
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return divisor;
+}
+
+static inline int
+ieee80211_hw_get_divisor(struct ieee80211_hw *hw)
+{
+ switch (hw->conf.chandef.width) {
+ case NL80211_CHAN_WIDTH_5:
+ return 4;
+ case NL80211_CHAN_WIDTH_10:
+ return 2;
+ default:
+ return 1;
+ }
+}
+
enum sdata_queue_type {
IEEE80211_SDATA_QUEUE_TYPE_FRAME = 0,
IEEE80211_SDATA_QUEUE_AGG_START = 1,
@@ -1448,7 +1487,8 @@ extern void *mac80211_wiphy_privid; /* for wiphy privid */
u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len,
enum nl80211_iftype type);
int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
- int rate, int erp, int short_preamble);
+ int rate, int erp, int short_preamble,
+ int divisor);
void mac80211_ev_michael_mic_failure(struct ieee80211_sub_if_data *sdata, int keyidx,
struct ieee80211_hdr *hdr, const u8 *tsc,
gfp_t gfp);
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index ac7ef54..ffabe1d 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -382,14 +382,18 @@ minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
static void
calc_rate_durations(enum ieee80211_band band,
struct minstrel_rate *d,
- struct ieee80211_rate *rate)
+ struct ieee80211_rate *rate,
+ struct minstrel_priv *mp)
{
int erp = !!(rate->flags & IEEE80211_RATE_ERP_G);
+ int divisor = ieee80211_hw_get_divisor(mp->hw);
d->perfect_tx_time = ieee80211_frame_duration(band, 1200,
- rate->bitrate, erp, 1);
+ DIV_ROUND_UP(rate->bitrate, divisor), erp, 1,
+ divisor);
d->ack_time = ieee80211_frame_duration(band, 10,
- rate->bitrate, erp, 1);
+ DIV_ROUND_UP(rate->bitrate, divisor), erp, 1,
+ divisor);
}
static void
@@ -430,7 +434,8 @@ minstrel_rate_init(void *priv, struct ieee80211_supported_band *sband,
ctl_rate = &sband->bitrates[mi->lowest_rix];
mi->sp_ack_dur = ieee80211_frame_duration(sband->band, 10,
ctl_rate->bitrate,
- !!(ctl_rate->flags & IEEE80211_RATE_ERP_G), 1);
+ !!(ctl_rate->flags & IEEE80211_RATE_ERP_G), 1,
+ ieee80211_hw_get_divisor(mp->hw));
memset(mi->max_tp_rate, 0, sizeof(mi->max_tp_rate));
mi->max_prob_rate = 0;
@@ -448,7 +453,7 @@ minstrel_rate_init(void *priv, struct ieee80211_supported_band *sband,
mr->rix = i;
mr->bitrate = sband->bitrates[i].bitrate / 5;
- calc_rate_durations(sband->band, mr, &sband->bitrates[i]);
+ calc_rate_durations(sband->band, mr, &sband->bitrates[i], mp);
/* calculate maximum number of retransmissions before
* fallback (based on maximum segment size) */
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 5b2d301..f05eeff 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -844,7 +844,7 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
u16 sta_cap = sta->ht_cap.cap;
int n_supported = 0;
- int ack_dur;
+ int ack_dur, divisor;
int stbc;
int i;
@@ -861,8 +861,10 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
mi->sta = sta;
mi->stats_update = jiffies;
- ack_dur = ieee80211_frame_duration(sband->band, 10, 60, 1, 1);
- mi->overhead = ieee80211_frame_duration(sband->band, 0, 60, 1, 1) + ack_dur;
+ divisor = ieee80211_hw_get_divisor(mp->hw);
+ ack_dur = ieee80211_frame_duration(sband->band, 10, 60, 1, 1, divisor);
+ mi->overhead = ieee80211_frame_duration(sband->band, 0, 60, 1, 1,
+ divisor) + ack_dur;
mi->overhead_rtscts = mi->overhead + 2 * ack_dur;
mi->avg_ampdu_len = MINSTREL_FRAC(1, 1);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 9972e07..e1f18a8 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -40,7 +40,7 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
struct sk_buff *skb, int group_addr,
int next_frag_len)
{
- int rate, mrate, erp, dur, i;
+ int rate, mrate, erp, dur, i, divisor;
struct ieee80211_rate *txrate;
struct ieee80211_local *local = tx->local;
struct ieee80211_supported_band *sband;
@@ -153,6 +153,8 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
rate = mrate;
}
+ divisor = ieee80211_vif_get_divisor(&tx->sdata->vif);
+
/* Don't calculate ACKs for QoS Frames with NoAck Policy set */
if (ieee80211_is_data_qos(hdr->frame_control) &&
*(ieee80211_get_qos_ctl(hdr)) & IEEE80211_QOS_CTL_ACK_POLICY_NOACK)
@@ -162,7 +164,8 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
* (10 bytes + 4-byte FCS = 112 bits) plus SIFS; rounded up
* to closest integer */
dur = ieee80211_frame_duration(sband->band, 10, rate, erp,
- tx->sdata->vif.bss_conf.use_short_preamble);
+ tx->sdata->vif.bss_conf.use_short_preamble,
+ divisor);
if (next_frag_len) {
/* Frame is fragmented: duration increases with time needed to
@@ -171,7 +174,8 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
/* next fragment */
dur += ieee80211_frame_duration(sband->band, next_frag_len,
txrate->bitrate, erp,
- tx->sdata->vif.bss_conf.use_short_preamble);
+ tx->sdata->vif.bss_conf.use_short_preamble,
+ divisor);
}
return cpu_to_le16(dur);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 3f87fa4..5496764 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -107,7 +107,8 @@ void ieee80211_tx_set_protected(struct ieee80211_tx_data *tx)
}
int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
- int rate, int erp, int short_preamble)
+ int rate, int erp, int short_preamble,
+ int divisor)
{
int dur;
@@ -118,6 +119,9 @@ int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
*
* rate is in 100 kbps, so divident is multiplied by 10 in the
* DIV_ROUND_UP() operations.
+ *
+ * divisor may be 4 for 5 MHz channels or 2 for 1 MHz channels, and
+ * is assumed to be 1 otherwise.
*/
if (band == IEEE80211_BAND_5GHZ || erp) {
@@ -130,15 +134,21 @@ int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
* TXTIME = T_PREAMBLE + T_SIGNAL + T_SYM x N_SYM + Signal Ext
*
* T_SYM = 4 usec
- * 802.11a - 17.5.2: aSIFSTime = 16 usec
+ * 802.11a - 18.5.2: aSIFSTime = 16 usec
* 802.11g - 19.8.4: aSIFSTime = 10 usec +
* signal ext = 6 usec
*/
dur = 16; /* SIFS + signal ext */
- dur += 16; /* 17.3.2.3: T_PREAMBLE = 16 usec */
- dur += 4; /* 17.3.2.3: T_SIGNAL = 4 usec */
+ dur += 16; /* IEEE 802.11-2012 18.3.2.4: T_PREAMBLE = 16 usec */
+ dur += 4; /* IEEE 802.11-2012 18.3.2.4: T_SIGNAL = 4 usec */
dur += 4 * DIV_ROUND_UP((16 + 8 * (len + 4) + 6) * 10,
4 * rate); /* T_SYM x N_SYM */
+
+ /* IEEE 802.11-2012 18.3.2.4: all values above are:
+ * * times 4 for 5 MHz
+ * * times 2 for 10 MHz
+ */
+ dur *= divisor;
} else {
/*
* 802.11b or 802.11g with 802.11b compatibility:
@@ -168,7 +178,7 @@ __le16 ieee80211_generic_frame_duration(struct ieee80211_hw *hw,
{
struct ieee80211_sub_if_data *sdata;
u16 dur;
- int erp;
+ int erp, divisor = 1;
bool short_preamble = false;
erp = 0;
@@ -177,10 +187,11 @@ __le16 ieee80211_generic_frame_duration(struct ieee80211_hw *hw,
short_preamble = sdata->vif.bss_conf.use_short_preamble;
if (sdata->flags & IEEE80211_SDATA_OPERATING_GMODE)
erp = rate->flags & IEEE80211_RATE_ERP_G;
+ divisor = ieee80211_vif_get_divisor(vif);
}
dur = ieee80211_frame_duration(band, frame_len, rate->bitrate, erp,
- short_preamble);
+ short_preamble, divisor);
return cpu_to_le16(dur);
}
@@ -194,7 +205,7 @@ __le16 ieee80211_rts_duration(struct ieee80211_hw *hw,
struct ieee80211_rate *rate;
struct ieee80211_sub_if_data *sdata;
bool short_preamble;
- int erp;
+ int erp, divisor = 1;
u16 dur;
struct ieee80211_supported_band *sband;
@@ -210,17 +221,18 @@ __le16 ieee80211_rts_duration(struct ieee80211_hw *hw,
short_preamble = sdata->vif.bss_conf.use_short_preamble;
if (sdata->flags & IEEE80211_SDATA_OPERATING_GMODE)
erp = rate->flags & IEEE80211_RATE_ERP_G;
+ divisor = ieee80211_vif_get_divisor(vif);
}
/* CTS duration */
dur = ieee80211_frame_duration(sband->band, 10, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
/* Data frame duration */
dur += ieee80211_frame_duration(sband->band, frame_len, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
/* ACK duration */
dur += ieee80211_frame_duration(sband->band, 10, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
return cpu_to_le16(dur);
}
@@ -235,7 +247,7 @@ __le16 ieee80211_ctstoself_duration(struct ieee80211_hw *hw,
struct ieee80211_rate *rate;
struct ieee80211_sub_if_data *sdata;
bool short_preamble;
- int erp;
+ int erp, divisor = 1;
u16 dur;
struct ieee80211_supported_band *sband;
@@ -250,15 +262,16 @@ __le16 ieee80211_ctstoself_duration(struct ieee80211_hw *hw,
short_preamble = sdata->vif.bss_conf.use_short_preamble;
if (sdata->flags & IEEE80211_SDATA_OPERATING_GMODE)
erp = rate->flags & IEEE80211_RATE_ERP_G;
+ divisor = ieee80211_vif_get_divisor(vif);
}
/* Data frame duration */
dur = ieee80211_frame_duration(sband->band, frame_len, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
if (!(frame_txctl->flags & IEEE80211_TX_CTL_NO_ACK)) {
/* ACK duration */
dur += ieee80211_frame_duration(sband->band, 10, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
}
return cpu_to_le16(dur);
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 07/18] mac80211: add radiotap flag and handling for 5/10 MHz
From: Simon Wunderlich @ 2013-05-16 11:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368702045-27598-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Wireshark already defines radiotap channel flags for 5 and 10 MHz, so
just use them in Linux radiotap too. Furthermore, add rx status flags to
allow drivers to report when they received data on 5 or 10 MHz channels.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
include/net/ieee80211_radiotap.h | 4 ++++
include/net/mac80211.h | 4 ++++
net/mac80211/rx.c | 21 ++++++++++++---------
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..8b991ff 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -230,6 +230,10 @@ enum ieee80211_radiotap_type {
#define IEEE80211_CHAN_PASSIVE 0x0200 /* Only passive scan allowed */
#define IEEE80211_CHAN_DYN 0x0400 /* Dynamic CCK-OFDM channel */
#define IEEE80211_CHAN_GFSK 0x0800 /* GFSK channel (FHSS PHY) */
+#define IEEE80211_CHAN_GSM 0x1000 /* GSM (900 MHz) */
+#define IEEE80211_CHAN_STURBO 0x2000 /* Static Turbo */
+#define IEEE80211_CHAN_HALF 0x4000 /* Half channel (10 MHz wide) */
+#define IEEE80211_CHAN_QUARTER 0x8000 /* Quarter channel (5 MHz wide) */
/* For IEEE80211_RADIOTAP_FLAGS */
#define IEEE80211_RADIOTAP_F_CFP 0x01 /* sent/received
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 0ce4290..4dae129 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,8 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
* on this subframe
* @RX_FLAG_AMPDU_DELIM_CRC_KNOWN: The delimiter CRC field is known (the CRC
* is stored in the @ampdu_delimiter_crc field)
+ * @RX_FLAG_10MHZ: 10 MHz (half channel) was used
+ * @RX_FLAG_5MHZ: 5 MHz (quarter channel) was used
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -832,6 +834,8 @@ enum mac80211_rx_flags {
RX_FLAG_80MHZ = BIT(23),
RX_FLAG_80P80MHZ = BIT(24),
RX_FLAG_160MHZ = BIT(25),
+ RX_FLAG_10MHZ = BIT(26),
+ RX_FLAG_5MHZ = BIT(27),
};
/**
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 4d8f817..d64f284 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -146,6 +146,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
struct ieee80211_radiotap_header *rthdr;
unsigned char *pos;
u16 rx_flags = 0;
+ u16 channel_flags = 0;
int mpdulen;
mpdulen = skb->len;
@@ -220,20 +221,22 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
/* IEEE80211_RADIOTAP_CHANNEL */
put_unaligned_le16(status->freq, pos);
pos += 2;
+ if (status->flag & RX_FLAG_10MHZ)
+ channel_flags |= IEEE80211_CHAN_HALF;
+ else if (status->flag & RX_FLAG_5MHZ)
+ channel_flags |= IEEE80211_CHAN_QUARTER;
+
if (status->band == IEEE80211_BAND_5GHZ)
- put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_5GHZ,
- pos);
+ channel_flags |= IEEE80211_CHAN_OFDM | IEEE80211_CHAN_5GHZ;
else if (status->flag & (RX_FLAG_HT | RX_FLAG_VHT))
- put_unaligned_le16(IEEE80211_CHAN_DYN | IEEE80211_CHAN_2GHZ,
- pos);
+ channel_flags |= IEEE80211_CHAN_DYN | IEEE80211_CHAN_2GHZ;
else if (rate && rate->flags & IEEE80211_RATE_ERP_G)
- put_unaligned_le16(IEEE80211_CHAN_OFDM | IEEE80211_CHAN_2GHZ,
- pos);
+ channel_flags |= IEEE80211_CHAN_OFDM | IEEE80211_CHAN_2GHZ;
else if (rate)
- put_unaligned_le16(IEEE80211_CHAN_CCK | IEEE80211_CHAN_2GHZ,
- pos);
+ channel_flags |= IEEE80211_CHAN_OFDM | IEEE80211_CHAN_2GHZ;
else
- put_unaligned_le16(IEEE80211_CHAN_2GHZ, pos);
+ channel_flags |= IEEE80211_CHAN_2GHZ;
+ put_unaligned_le16(channel_flags, pos);
pos += 2;
/* IEEE80211_RADIOTAP_DBM_ANTSIGNAL */
--
1.7.10.4
^ permalink raw reply related
* [PATCHv3 11/18] ath9k: always use SIFS times from OFDM for 5/10 MHz
From: Simon Wunderlich @ 2013-05-16 11:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368702045-27598-1-git-send-email-siwu@hrz.tu-chemnitz.de>
5/10 MHz channels should always use SIFS times as defined in IEEE
802.11-2012 18.4.4 (OFDM PHY characteristics). This makes it compatible
to ath5k, which does the same.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
drivers/net/wireless/ath/ath9k/hw.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 7f25da8..89ee731 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1071,7 +1071,7 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
if (IS_CHAN_A_FAST_CLOCK(ah, chan))
tx_lat += 11;
- sifstime *= 2;
+ sifstime = 32;
ack_offset = 16;
slottime = 13;
} else if (IS_CHAN_QUARTER_RATE(chan)) {
@@ -1081,7 +1081,7 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
if (IS_CHAN_A_FAST_CLOCK(ah, chan))
tx_lat += 22;
- sifstime *= 4;
+ sifstime = 64;
ack_offset = 32;
slottime = 21;
} else {
@@ -1118,7 +1118,6 @@ void ath9k_hw_init_global_settings(struct ath_hw *ah)
ctstimeout += 48 - sifstime - ah->slottime;
}
-
ath9k_hw_set_sifs_time(ah, sifstime);
ath9k_hw_setslottime(ah, slottime);
ath9k_hw_set_ack_timeout(ah, acktimeout);
--
1.7.10.4
^ permalink raw reply related
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