* Re: [ath9k-devel] ath9k_htc: Target is unresponsive
From: Eugene Krasnikov @ 2013-05-15 16:11 UTC (permalink / raw)
To: Kalle Valo; +Cc: Ignacy Gawedzki, ath9k-devel, linux-wireless
In-Reply-To: <87a9nwpaaf.fsf@kamboji.qca.qualcomm.com>
there is a function in driver "ath9k_htc_reset"
http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/htc_drv_main.c#L189
but not sure that is what you are looking for.
2013/5/15 Kalle Valo <kvalo@qca.qualcomm.com>:
> Ignacy Gawedzki <i@lri.fr> writes:
>
>> Hi everyone,
>>
>> This is an old issue, about which it seems the first posts date back to 2009.
>> With the latest possible version of the firmware for AR9271 and the latest
>> possible wireless drivers, the issue is still there. Whether this is still
>> the exact same problem every time remains to be checked, but it is annoying
>> enough to deserve some consideration.
>>
>> The problem is that the driver can't talk to the device if the following
>> conditions are met:
>>
>> - The system cold boots with the USB dongle inserted or the USB dongle is
>> inserted on a running system.
>>
>> - The interface is *not* brought up.
>>
>> - The system (warm) reboots.
>>
>> Then the driver complains about the target being unresponsive after uploading
>> the firmware. Apparently the only way to make it work again is to unplug and
>> then plug the USB dongle back, physically. It seems that if the USB port is
>> not powered down during reboot (which happens with at least two different
>> setups that I've tested it with), the device is left in a broken state.
>>
>> I would gladly help in tracing down this bug if only I knew where to start.
>
> With ath6kl a cold reset helped in a similar situation. Try to find if
> ath9k_htc has a cold/warm reset and see if that helps.
>
> --
> Kalle Valo
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
--
Best regards,
Eugene
^ permalink raw reply
* Re: [PATCH 00/29] ath10k: mac80211 driver for Qualcomm Atheros qca988x devices
From: Kalle Valo @ 2013-05-15 16:22 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: Joe Perches, linux-wireless, ath10k-devel
In-Reply-To: <87wqr0ns47.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Sujith Manoharan <sujith@msujith.org> writes:
>
>> Joe Perches wrote:
>>> Perhaps it would be reasonable to create and use standardized
>>> logging ath_<level> functions for all the device ath<x>k_<level>s.
>>
>> Indeed.
>>
>> You already did that in "ath: Add and use ath_printk and ath_<level>" :)
>
> IIRC Sujith actually suggested this to me already earlier, but I didn't
> buy the idea even then. ath9k and ath10k are very different, so we
> cannot share all the debug levels. I just feel that it restricts and
> confuses the driver debugging too much, and all just to save something
> like 100 lines of code. I'm having hard time to see why bother.
I also noticed that ath.h doesn't support tracing. I would hate to lose
that.
--
Kalle Valo
^ permalink raw reply
* Re: [ath9k-devel] ath9k_htc: Target is unresponsive
From: Ignacy Gawedzki @ 2013-05-15 16:34 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: Kalle Valo, ath9k-devel, linux-wireless
In-Reply-To: <CAFSJ42bDB+c0=eRmBYZBaQnZ4-h2Jm_MWZbfSEhUELb9y0Qv_Q@mail.gmail.com>
On Wed, May 15, 2013 at 06:11:49PM +0200, thus spake Eugene Krasnikov:
> there is a function in driver "ath9k_htc_reset"
> http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/htc_drv_main.c#L189
> but not sure that is what you are looking for.
>From the issue report about watchdog problems, I gather that the device is
supposed to be prepared for reception of the firmware code from the driver.
This normally happens when the device boots up and passes the first stage of
the bootloader. I suppose (I'm really totally guessing) that the driver
somehow doesn't do something to prepare the device for firmware upload if the
device is already past stage 2.
I would love to have the UART pins connected to some terminal, but I don't
have the soldering tools for such small-scale work...
--
A person is shit's way of making more shit.
-- S. Barnett, anthropologist.
^ permalink raw reply
* 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
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