[ath9k-devel] open firmware for ath9k_htc
Hallo all, i would like to work on open firmware for ath9k_htc. i can C and and have Linux kernel driver development experience. But no Embedded Linux experience - it is the reason why I would like to do it. I tried to contact Luis R. Rodriguez but got no response. What should i do to obtain firmware source? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] open firmware for ath9k_htc
Hi Luis, one more try :) Am 22.10.2012 16:31, schrieb Adrian Chadd: On 20 October 2012 23:24, Oleksij Rempel bug-tr...@fisher-privat.net wrote: Hallo all, i would like to work on open firmware for ath9k_htc. i can C and and have Linux kernel driver development experience. But no Embedded Linux experience - it is the reason why I would like to do it. I tried to contact Luis R. Rodriguez but got no response. What should i do to obtain firmware source? Hi! Try again. He's just been busy. :-) Adrian -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] open firmware for ath9k_htc
New PING scheduled for this week. Any one alive? Am 22.10.2012 17:23, schrieb Oleksij Rempel: Hi Luis, one more try :) Am 22.10.2012 16:31, schrieb Adrian Chadd: On 20 October 2012 23:24, Oleksij Rempel bug-tr...@fisher-privat.net wrote: Hallo all, i would like to work on open firmware for ath9k_htc. i can C and and have Linux kernel driver development experience. But no Embedded Linux experience - it is the reason why I would like to do it. I tried to contact Luis R. Rodriguez but got no response. What should i do to obtain firmware source? Hi! Try again. He's just been busy. :-) Adrian -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Am 29.11.2012 00:50, schrieb Adrian Chadd: Hi all, I've done an updated build of the ath9k_htc firmware images. I don't currently have a HTC setup working so this is just a recompilation of the current firmware. http://dev.qca.qualcomm.com/~adrian/htc/20121128/ Please let me know if it works or doesn't work for you. The specific two changes from Sujith's last release: * Fix the TSF extension logic to correctly extend TSF from 32 bit to 64 bit; * Update the embedded runtime OS code to the latest from Tensilica, in preparation for open sourcing it; I don't plan on fixing any bugs that already exist in the latest ath9k_htc drop in the firmware git repository; I just want to check that the build hasn't broken any existing behaviour (ie, made things worse.) Thanks, Works without regressions on ALFA AWUS036NHA (Atheros AR9271 Rev:1) -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [ath9k] spectral scan update: HT40
Am 05.02.2013 10:59, schrieb Simon Wunderlich: Hey Adrian, thanks a lot for your update! On Fri, Feb 01, 2013 at 11:02:00AM -0800, Adrian Chadd wrote: Hi all, I've been tinkering with the HT40 spectral scan data (in FreeBSD, obviously :-) and I can finally state that I have it working and working reliably. The notes: * The MAC does silly things to the spectral scan payload problem there is in HT40 too, so you need similar correction code for that. I've not yet committed that to FreeBSD, but I will soon. * The HT40 lower and upper FFT bins in the radar / spectral scan are just that - lower and upper halves of a 40MHz wide FFT. * .. but the RSSI in the RX descriptor is Primary and Extension channel RSSI, so you need to match them up correctly with what's lower and upper - ie, in HT40- mode, the primary RSSI is the upper, and the extension RSSI is lower. * .. and yes, this means you calculate the bin power separately for the lower and upper bins. * On AR928x chips, the spectral scan FFT is done on chain 0. I don't think that's changed in AR93xx series chips. So, use RSSI and NF from chain 0, don't use the combined RSSI figures. Ah, OK, that's probably relevant for the ath9k part as well. * RSSI can be below 0 dB, so make sure you factor that in. * IIRC, RSSI from the RX header is in half-dB increments, so make sure you factor that in. * Because of the MAC corruption bug, you can't disable short report - otherwise you don't know whether the spectral scan data results are corrupted or not. So yes, you have to enable short report and thus you get one result at a time in a PHY error. Could we (in theory) enable short report stuff for newer chipsets, e.g. 93xx and newer? I thought there was a fix for that in latest silicon, although I don't know specifics I've mostly working code in FreeBSD's subversion tree - http://svn.freebsd.org/base/user/adrian/ath_radar_stuff/ - look in lib/libradarpkt and src/fft_eval . I've begun fleshing out some documentation about spectral scan - https://wiki.freebsd.org/dev/ath_hal%284%29/SpectralScan Excellent! That's provides a good resource. :) I'm going to work on the invalid packet length detection and correction, based on what our reference driver does and what Zefir has done. But once that's done, the basic data parsing and power calculation bits are done - I'll work on exporting it in a jquery-compatible fashion over a network socket so people (read: not me :-) can write some visualisation apps using HTML/javascript. That way both Linux and FreeBSD (and whoever else!) wifi hackers can leverage the same visualisation apps when hacking on this stuff. Again, thanks a lot for your work! I'm currently busy with a few other things and probably won't find time to work on the 40 MHz spectral in the next weeks, so if anyone else wants to pick up here - the code has been prepared for that. :) In any case, please keep us posted, and keep up your good work! Thanks, Simon Lots of thanks to all for this work! It works on my AR9285. I have one question. Some chips (for example ar9462) have 8-bit resolution for Spectral Analysis in product overview. What dos it mean? Is it about Spectral Scan? What kind of bit resolution is on on ar9285? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] question about ar2313
Hallo devs,
currently i porting barebox to ar2313a WiSoC. I know there is redboot,
but i do it just for fun.
Most basics are working now, including ethernet driver - except there is
one issue with it. After RX is enabled, rx ringbuffer starting getting
filled. If there is lots of broadcasts and buffer is full, first packet
of my transaction can be lost.
Are there any way to filter bcasts by hardware? Is it possible to get
documentation for this chip? It will be especially interesting then i
start to work on bootstrap part.
In attachment is the eth driver for barebox.
--
Regards,
Oleksij
/*
* ar231x.c: Linux driver for the Atheros AR231x Ethernet device.
* Based on Linux driver:
* Copyright (C) 2004 by Sameer Dekate sdek...@arubanetworks.com
* Copyright (C) 2006 Imre Kaloz ka...@openwrt.org
* Copyright (C) 2006-2009 Felix Fietkau n...@openwrt.org
* Ported to Barebox:
* Copyright (C) 2013 Oleksij Rempel bug-tr...@fisher-privat.net
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
/*
* Known issues:
* - broadcast packets are not filtered by hardware. On noisy network with
* lots of bcast packages rx_buffer can be completely filled after. It seems
* to be OK on transmission (we will clean it), but it is not nice on stand by.
* In this case we may lose first transmission after stand by.
*/
#include driver.h
#include init.h
#include mach/ar231x_platform.h
#include common.h
#include net.h
#include ar231x2.h
#include asm/addrspace.h
#include asm/io.h
#include linux/phy.h
/* Allocate 64 RX buffers. This will reduce packet loss, until we will start
* processing them. It is important in noisy network with lots of broadcasts. */
#define AR2313_RXDSC_ENTRIES 64
#define DSC_NEXT(idx)((idx + 1) (AR2313_RXDSC_ENTRIES - 1))
/* Use system default buffers size. At the moment of writing it was 1518 */
#define AR2313_RX_BUFSIZE PKTSIZE
#define CRC_LEN 4
#define virt_to_phys(x) ((u32)(x) 0x1fff)
static int ar231x_set_ethaddr(struct eth_device *edev, unsigned char *addr);
static void ar231x_reset_regs(struct eth_device *edev)
{
struct ar231x_eth_priv *priv = edev-priv;
struct ar231x_eth_platform_data *cfg = priv-cfg;
u32 flags;
debug(%s\n, __func__);
*priv-int_regs |= cfg-reset_mac;
mdelay(10);
*priv-int_regs = ~cfg-reset_mac;
mdelay(10);
*priv-int_regs |= cfg-reset_phy;
mdelay(10);
*priv-int_regs = ~cfg-reset_phy;
mdelay(10);
priv-dma_regs-bus_mode = DMA_BUS_MODE_SWR;
mdelay(10);
priv-dma_regs-bus_mode =
((32 DMA_BUS_MODE_PBL_SHIFT) | DMA_BUS_MODE_BLE);
priv-dma_regs-xmt_base = virt_to_phys(priv-tx_ring);
priv-dma_regs-rcv_base = virt_to_phys(priv-rx_ring);
priv-dma_regs-control =
(DMA_CONTROL_SR | DMA_CONTROL_ST | DMA_CONTROL_SF);
priv-eth_regs-flow_control = FLOW_CONTROL_FCE;
/* TODO: not sure if we need it here. */
priv-eth_regs-vlan_tag = (0x8100);
/* Enable Ethernet Interface */
flags = (MAC_CONTROL_TE | /* transmit enable */
/* MAC_CONTROL_PM - pass mcast.
* Seems like it makes no difference on some WiSoCs,
* for example ar2313. */
MAC_CONTROL_PM |
MAC_CONTROL_F | /* full duplex */
MAC_CONTROL_HBD); /* heart beat disabled */
priv-eth_regs-mac_control = flags;
}
static void ar231x_flash_rxdsc(ar231x_descr_t *rxdsc)
{
rxdsc-status = DMA_RX_OWN;
rxdsc-devcs = ((AR2313_RX_BUFSIZE DMA_RX1_BSIZE_SHIFT) |
DMA_RX1_CHAINED);
}
static void ar231x_allocate_dma_descriptors(struct eth_device *edev)
{
struct ar231x_eth_priv *priv = edev-priv;
u16 ar231x_descr_size = sizeof(ar231x_descr_t);
u16 i;
debug(%s\n, __func__);
priv-tx_ring = xmalloc(ar231x_descr_size);
dev_dbg(edev-dev, allocate tx_ring @ %p\n, priv-tx_ring);
priv-rx_ring = xmalloc(ar231x_descr_size * AR2313_RXDSC_ENTRIES);
dev_dbg(edev-dev, allocate rx_ring @ %p\n, priv-rx_ring);
priv-rx_buffer = xmalloc(AR2313_RX_BUFSIZE * AR2313_RXDSC_ENTRIES);
dev_dbg(edev-dev, allocate rx_buffer @ %p\n, priv-rx_buffer);
/* Initialize the rx Descriptors */
for (i = 0; i AR2313_RXDSC_ENTRIES; i++) {
ar231x_descr_t *rxdsc = priv-rx_ring[i];
ar231x_flash_rxdsc(rxdsc);
rxdsc-buffer_ptr = (uint)(priv-rx_buffer + AR2313_RX_BUFSIZE * i);
rxdsc-next_dsc_ptr = virt_to_phys(priv-rx_ring[DSC_NEXT(i)]);
}
}
static void ar231x_adjust_link(struct eth_device *edev)
{
struct ar231x_eth_priv *priv = edev-priv;
u32 mc;
debug(%s\n, __func__);
if (edev-phydev-duplex != priv-oldduplex) {
mc = priv-eth_regs-mac_control;
mc = ~(MAC_CONTROL_F | MAC_CONTROL_DRO);
if (edev-phydev-duplex)
mc |= MAC_CONTROL_F;
else
mc |= MAC_CONTROL_DRO;
priv-eth_regs-mac_control = mc;
priv-oldduplex = edev-phydev-duplex;
}
}
static int ar231x_eth_init(struct eth_device *edev)
{
struct ar231x_eth_priv *priv = edev-priv;
debug(%s\n, __func__
Re: [ath9k-devel] question about ar2313
Am 13.02.2013 21:59, schrieb Adrian Chadd: I'm (slowly) working on getting approval to open up datasheets.. I'll post when this is done. great, thx! what about firmware for ath9_htc? On 13 February 2013 04:39, Oleksij Rempel bug-tr...@fisher-privat.net wrote: Hallo devs, currently i porting barebox to ar2313a WiSoC. I know there is redboot, but i do it just for fun. Most basics are working now, including ethernet driver - except there is one issue with it. After RX is enabled, rx ringbuffer starting getting filled. If there is lots of broadcasts and buffer is full, first packet of my transaction can be lost. Are there any way to filter bcasts by hardware? Is it possible to get documentation for this chip? It will be especially interesting then i start to work on bootstrap part. In attachment is the eth driver for barebox. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFT] ath9k_htc - please test new images
Am 22.02.2013 20:33, schrieb Adrian Chadd:
Hi all,
I have a couple of new test images for ath9k_htc users to test.
http://developer.atheros.com/~adrian/htc/20130222/
These images are built by the open source tensilica toolchain rather
than the proprietary toolchain.
Their version id has been bumped from 1.3 to 1.4.
I'd appreciate any testing people can do.
Thanks!
Hi Adrian,
current driver has this check:
htc_drv_init.c: priv-fw_version_minor != MINOR_VERSION_REQ) {
htc_drv_init.c: MAJOR_VERSION_REQ, MINOR_VERSION_REQ);
so it wont accept 1.4. Currently i compiling kernel without this
restriction. Then i'll be able to test it.
--
Regards,
Oleksij
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFT] ath9k_htc - please test new images
Am 23.02.2013 12:41, schrieb Adrian Chadd:
On 23 February 2013 01:54, Oleksij Rempel bug-tr...@fisher-privat.net wrote:
Hi Adrian,
current driver has this check:
htc_drv_init.c: priv-fw_version_minor != MINOR_VERSION_REQ) {
htc_drv_init.c: MAJOR_VERSION_REQ, MINOR_VERSION_REQ);
so it wont accept 1.4. Currently i compiling kernel without this
restriction. Then i'll be able to test it.
Oops! Guess I shouldn't have bumped the version numbers :-)
Now results:
- Current wireless-testing.git is broken for my htc_* devices. none of
firmwares is working.
- I use 3.8.0-rc7 from wireless-testing.git for testing.
- htc_7010.fw is working.
- htc_9271.fw do not working. it fails on authentication:
[32305.187783] usb 3-2: Product: UB91C
[32305.187789] usb 3-2: Manufacturer: ATHEROS
[32305.187794] usb 3-2: SerialNumber: 12345
[32305.262708] usb 3-2: ath9k_htc: Firmware htc_9271.fw requested
[32305.263302] usbcore: registered new interface driver ath9k_htc
[32305.526943] usb 3-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 48820
[32305.763378] ath9k_htc 3-2:1.0: ath9k_htc: HTC initialized with 33 credits
[32306.076930] ath9k_htc 3-2:1.0: ath9k_htc: FW Version: 1.4
[32306.076939] ath: EEPROM regdomain: 0x0
[32306.076943] ath: EEPROM indicates default country code should be used
[32306.076946] ath: doing EEPROM country-regdmn map search
[32306.076950] ath: country maps to regdmn code: 0x3a
[32306.076954] ath: Country alpha2 being used: US
[32306.076957] ath: Regpair used: 0x3a
[32306.088331] ieee80211 phy6: Atheros AR9271 Rev:1
[32306.573836] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready
[32309.755882] wlan2: authenticate with 74:31:70:62:d3:cf
[32310.183668] wlan2: send auth to 74:31:70:62:d3:cf (try 1/3)
[32310.185673] wlan2: authenticated
[32310.187193] wlan2: associate with 74:31:70:62:d3:cf (try 1/3)
[32310.190965] wlan2: RX AssocResp from 74:31:70:62:d3:cf (capab=0x411
status=0 aid=4)
[32310.224419] wlan2: associated
[32310.224448] IPv6: ADDRCONF(NETDEV_CHANGE): wlan2: link becomes ready
[32320.218444] wlan2: disassociating from 74:31:70:62:d3:cf by local
choice (reason=3)
[32320.692076] wlan2: deauthenticating from 74:31:70:62:d3:cf by local
choice (reason=3)
--
Regards,
Oleksij
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFT] ath9k_htc - please test new images
Am 23.02.2013 22:05, schrieb Adrian Chadd: On 23 February 2013 12:47, Felix Fietkau n...@openwrt.org wrote: - I use 3.8.0-rc7 from wireless-testing.git for testing. - htc_7010.fw is working. - htc_9271.fw do not working. it fails on authentication: Same here (AR9271). Right. http://developer.atheros.com/~adrian/htc/ has another snapshot from november 2012 - would you mind checking if that firmware works on the AR9271, same driver? (but with the revision changed back, obviously.) snapshot from november 2012 is working. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFT] ath9k_htc - please test new images
Am 24.02.2013 06:57, schrieb Roman Elshin: AP mode with kernel-3.0.66 and TL-WN821N, htc_7010.fw works but data speed is very low ~100kb/s (version from 20121128 works fine here). Uff i forgot speed test ;) Netgera wnda3200 (AR7010 + AR9280), old (20121128) firmware ~10 MB/s (client mode) if close to AP. New firmware ~1 MB/s if close (1 meter) and ~5MB/s if not so close (3 meter) to ap. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [Announce] open ath9k_htc firmware
Great news and many thanks!!! Am 09.03.2013 00:46, schrieb Luis R. Rodriguez: Many thanks to Adrian for his hard work on all this and to everyone else who volunteered to help make this happen, including the understanding by our management at QCA and even Tensilica requires some handsome applause for their commitment, understanding on letting us get this out. We now have a public mailing list for development: http://lists.infradead.org/mailman/listinfo/ath9k_htc_fw Full steam ahead! Luis On Fri, Mar 8, 2013 at 3:32 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, I hate fanfare. You can all thank Luis Rodriguez for his ridiculously long and hard fighting to get this stuff pushed through the grinder to make this happen. There's also been a hard working team of developers behind the scene - Felix Fietkau, Eugene Krasnikov, Sujith Manoharan, and the team from Cozybit. They've been working hard to get the codebase converted over to using the open source tensilica toolchain and finding/fixing up any silly issues that may creep up from that. I've just been involved in shepharding this stuff into a sensible shape and pushing it through the final stage (legal review) before publication. You can find it here: https://github.com/qca/open-ath9k-htc-firmware There's a bunch of sorely needed work to do in the short term: * felix has a replacement cmake build system that I'd like to now integrate; * there's lots of build warnings which need to be removed (and then build this thing using -Wall -Werror); * some general code cleanup and documentation wouldn't be rejected - but I don't really want any sweeping code changes to go in until we've tidied up the build warnings and validated that the image(s) work right. I plan on doing some test builds shortly. I plan on bumping the firmware to 1.4 once felix's cmake system is in place and people have validated that this work.s Thanks, Adrian -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k not connecting to one particular network..
Am 25.03.2013 10:23, schrieb Linus Torvalds: On Sun, Mar 24, 2013 at 9:26 PM, Joel Wirāmu Pauling j...@aenertia.net wrote: Can you try disabling network manager from the init scripts (I am not sure which distro you are using as a base but /etc/init.d/network-manager stop ) tends to work for a percentage of machines. Then running wpa_supplicant manually. Bingo. Apparently this really is NetworkManager doing something wrong. I'm running F18, so doing systemctl stop NetworkManager.service ifconfig wlan0 up iwlist scan wpa_passphrase *essid* *password* wpa_conf.txt wpa_supplicant -i wlan0 -c wpa_conf.txt and then dhclient wlan0 worked. Presumably NetworkManager should do the same, but doesn't. Or more likely, does something *more*, and that something more ends up confusing the driver and resetting. Interestingly, the kernel messages from doing this were different: wlan0: RX AssocResp from 50:46:5d:02:85:08 (capab=0x411 status=0 aid=16) notice how now it says aid=16 instead of aid=10. WTF? So now I have working internet, can anybody suggest something for the NM bug-report? Some way for the NM people to guess at what they do wrong? Any ideas of why it would happen only for this particular network? For some months there was a bug in NetworkManager or dhcp client it used. If dhcp leas time is unlimited then it fails to connect. By changing default dhcpclient for NEtworkManager it was possible to work around it. MAy bit it is that issue. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [rft] ath9k_htc firmware test - 1.3.1
Am 30.03.2013 18:12, schrieb Adrian Chadd: (resending as gmail was in HTML mail mode for some odd reason) Hi, I've tagged and compiled up the 1.3.1 ath9k htc firmware. There's been a couple of minor bugfixes but it's mostly just been me going over and adding / fixing the QCA file licencing to have an explicit licence. You can find it here: http://people.freebsd.org/~adrian/ath9k_htc/1.3.1/ I'd appreciate any testing that people can give this. Tested: AR7010+AR9280 - OK AR9271 - OK Tests: - connect to AP - run default netperf test. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [rft] ath9k_htc firmware test - 1.3.1
Am 30.03.2013 18:47, schrieb Adrian Chadd: On 30 March 2013 10:21, Oleksij Rempel bug-tr...@fisher-privat.net wrote: You can find it here: http://people.freebsd.org/~adrian/ath9k_htc/1.3.1/ I'd appreciate any testing that people can give this. Tested: AR7010+AR9280 - OK AR9271 - OK Tests: - connect to AP - run default netperf test. Thanks! The performance figures are ok? Speed on AR7010+AR9280 is not constant. It variate from 2 to 49Mbit. On AR9271 and AR9285 variation is not so big. But the last two haw bigger antennas. On other hand only AR7010+AR9280 is 2x2:2. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] general question about AR7010 arch.
Hi all, do i understand correctly - AR7010 is generally a MIPS CPU? AR5523 is R4000 MIPS. How about AR9170 and other usb controllers? If it is true, are there any good reason to develop separate firmware for each of them? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] general question about AR7010 arch.
Am 01.04.2013 18:24, schrieb Adrian Chadd: On 1 April 2013 00:40, Oleksij Rempel li...@rempel-privat.de wrote: Hi all, do i understand correctly - AR7010 is generally a MIPS CPU? AR5523 is R4000 MIPS. How about AR9170 and other usb controllers? If it is true, are there any good reason to develop separate firmware for each of them? So! * AR5523 is a mips 4kp or 4kc, I forget * AR9170 is some SH core (SH4?); * AR7010/AR9271 is a Tensilica core. It'd be nice if there were some shared code between them! However a lot of code gets stuffed into ROM. So it's not necessarily easy to have a shared firmware between each. That said, it'd be nice if we could unify things over time if it were possible. There's not much code in each of these. Anyway - I'm trying to get the AR5523 firmware open sourced. I'll post updates when this has finished. Sounds great. I have AR5523+AR2112 and AR5523+AR5112.. so, some testing can be done :) -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] need help: ath9k_htc driver not working
Hi Izhar, Am 15.04.2013 14:48, schrieb izhar eyal: Hi Guys, I hope this is the right mailing list for help on bugs. Here are the detail: - have kernel 2.6.35.13 running on imx27, trying to use a TL-WN722N dongle (Atheros AR9271). that is a bit too old. - compiled ath9k_htc (tried both as statically linked and as kernel modules, same problem) - using firmware htc_9271.fw (rev 1.3)...also tried older ones with same result older should not work. but i do not know what firmware version was supported on this kernel. - firmware is loaded successfully by being compiled with the kernel (a menuconfig option, directory /firmware) I'm not sure that firmware source would be available in this old kernel. Are you sure? Or do you mean, pre compiled firmware was build in in module? - using REG_READ to get device registers returns always the same value: 0x01020101 this is why I get timeout on reading RTC register 0x7044 (probably the first read that uses ath9k_hw_wait function). hmm... do this dongle gets enough power? some parts of your dmesg are interesting: --- this adapter was initiated at usb 1-1:1.0 [4.82] usb 1-1: configuration #1 chosen from 1 choice [4.82] usb 1-1: adding 1-1:1.0 (config #1, interface 0) [4.82] usb 1-1:1.0: uevent [4.82] drivers/usb/core/inode.c: creating file '002' [4.82] usb 1-1: new device strings: Mfr=16, Product=32, SerialNumber=48 [4.82] usb 1-1: Product: USB2.0 WLAN [4.82] usb 1-1: Manufacturer: ATHEROS [4.82] usb 1-1: SerialNumber: 12345 [4.82] usbcore: registered new interface driver cdc_acm [4.82] cdc_acm: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters [4.82] usbcore: registered new interface driver libusual [4.83] usbcore: registered new interface driver usbserial [4.83] drivers/usb/serial/usb-serial.c: USB Serial support registered for generic but now 1-1:1.0 is serial driver. Hmmm... do i miss some thing? [4.83] usbserial_generic 1-1:1.0: usb_probe_interface [4.83] usbserial_generic 1-1:1.0: usb_probe_interface - got id [4.83] usbcore: registered new interface driver usbserial_generic [4.83] drivers/usb/serial/usb-serial.c: USB Serial Driver core now 1-1:1.0 is unregistred. 7[ 301.292000] usb 1-1: unregistering interface 1-1:1.0 7[ 301.292000] device: 'ep_01': device_unregister 7[ 301.292000] PM: Removing info for No Bus:ep_01 here is time out. 7[ 341.596000] *ath: timeout (10 us) on reg 0x7044: 0x01020101 0x000f != 0x0002* 7[ 341.596000] *ath: RTC not waking up* 7[ 341.596000] *ath: Couldn't reset chip* 7[ 341.596000] *ath: Unable to initialize hardware; initialization status: -5* 7[ 341.596000] ath: Unable to initialize hardware; initialization status: -5 3[ 341.596000] Failed to initialize the device 7[ 341.596000] usb 1-1: unlink qh1-0e01/c665a760 start 0 [1/3 us] 7[ 341.60] usb usb1: clear tt buffer port 1, a3 ep2 t40008d80 and ath9k_hif_usb confirms that 1-1:1.0 is our device. 4[ 341.60] ath9k_hif_usb: probe of 1-1:1.0 failed with error -22 7[ 341.60] device: 'ep_01': device_add 7[ 341.60] PM: Adding info for No Bus:ep_01 7[ 341.60] device: 'ep_82': device_add 7[ 341.60] PM: Adding info for No Bus:ep_82 i have some of ath9k_htc devices and all of them work with current firmware and 3.8.0-rc7 kernel... it is a bit old, but currently i do not have time to test never one. Is this a hardware issue? try exclude some part from the chain. do this adapter works on other hardware? Do other usb hardware works on your host? For example usb stick? Is it working at full speed? Do usb hist provide enough power? software issue? can you test this kernel on other host? can the system clock or other clocks be the issue? i can't help you here. If you have any insights please respond. You can use serial pins on the device to see if it is alive. check this links: https://github.com/qca/open-ath9k-htc-firmware/blob/master/docs/uart http://wikidevi.com/wiki/AR9271 thanks, izhar :) ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Severe issue with ath9k_htc driver - consistent full system crash since 3.8 kernels
Hi Dylan, can you please provide some pictures of it? One pic of the label, and if possible high resolution scans of pcb board. Similar to this: http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2 800 or 900dpi in jpg will be ok. Send it directly to me. Am 24.04.2013 03:04, schrieb Dylan: The ath9k_htc driver causes my computer to completely lock up, forcing me to restart. This occurs after anything between a few minutes to a few hours - generally less than an hour - of having the device using the driver connected to the computer and communicating with a network (I haven't tested having the device connected to the computer but not communicating with any network). The network adapter in question is a TP-Link TL-WN822N V3 (lsusb indicates it is TP-Link TL-WN821N v3). The only unusual thing that jumps to mind about it is that it was initially listed as a Realtek driver here http://wikidevi.com/wiki/TP-LINK_TL-WN821N_v1 and TP-Link's tech support informed me of the same. Now version 4 is listed as the Realtek one and this is listed as an Atheros one. Not sure whether that's worth pointing out but it was something that bugged me when I first got it. The issue has existed since the 3.8 kernels at least partway through the release candidates. I had the compat-wireless drivers installed for unrelated reasons which was how I first noticed it. I sent a message when the stable release of 3.8 came out shortly after and the issue still existed but received no response. I've tested the device with the new 3.9 kernel and the issue still occurs. I've also noted some signal loss while it functions at all but it's much less severe with the later 3.8s and 3.9 so I'm not confident that bit is even still a problem. I had no issues whatsoever with the driver in the 3.7 kernels and in fact I'm using it with 3.7.9 right now. Though I will comment that the 3.9 drivers reconnect to networks when disconnected much more smoothly. I'd be happy to provide any additional necessary information. I'm not sure where to get logs of whatever it is that's happening as the only ones I found that seemed relevant appeared to be erased on each boot. Since the only way to recover from the issue was a hard reboot I haven't got any logs of when it occurs. I might just be looking in the wrong places though. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k_htc: add STBC TX support
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc.h | 2 ++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4
3 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..db4a793 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,8 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */
+#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, TX streams %d, RX streams: %d\n,
tx_streams, rx_streams);
+ if (tx_streams = 2)
+ ht_info-cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info-mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info-mcs.tx_params |= ((tx_streams - 1)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..af08b4a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,10 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate-rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_RX_STBC)
+ caps |= WLAN_RC_RX_STBC_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
if (sta-ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta-ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40)
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k_htc: add STBC TX support
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc.h | 2 ++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4
3 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..db4a793 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,8 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */
+#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, TX streams %d, RX streams: %d\n,
tx_streams, rx_streams);
+ if (tx_streams = 2)
+ ht_info-cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info-mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info-mcs.tx_params |= ((tx_streams - 1)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..af08b4a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,10 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate-rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_RX_STBC)
+ caps |= WLAN_RC_RX_STBC_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
if (sta-ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta-ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40)
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] rx status registers for ar9280/ar9825/ar9287
Hallo all, i was playing with STBC functionality and wont to see more statistic about it. If i'm correct Some MACs can report if it got STBC frame or at least report duplicat frames. After greping the source, i'm confused about location of this registers. If i'm correct, STBC and Duplicate status bits loctaed together with GI and 2040. According to the source: ar9003_mac.c: rxs-rs_flags = (rxsp-status4 AR_GI) ? ATH9K_RX_GI : 0; mac.c: (ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0; So i it true for ar9280/ar9285/ar9287 and too? Shouldn't that be ds_rxstatus7 or some thing like this? And if it is different where should i add statistic for this chips? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] rx status registers for ar9280/ar9825/ar9287
Am 27.04.2013 10:27, schrieb Adrian Chadd: Hi, There's no way to know that you received an STBC encoded frame. :( GI is short/long guard interval, not STBC. I do not mean encoded frame, i mean only status flag. Looks like ar9271 provide it. Adrian On 27 April 2013 01:08, Oleksij Rempel li...@rempel-privat.de wrote: Hallo all, i was playing with STBC functionality and wont to see more statistic about it. If i'm correct Some MACs can report if it got STBC frame or at least report duplicat frames. After greping the source, i'm confused about location of this registers. If i'm correct, STBC and Duplicate status bits loctaed together with GI and 2040. According to the source: ar9003_mac.c: rxs-rs_flags = (rxsp-status4 AR_GI) ? ATH9K_RX_GI : 0; mac.c: (ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0; So i it true for ar9280/ar9285/ar9287 and too? Shouldn't that be ds_rxstatus7 or some thing like this? And if it is different where should i add statistic for this chips? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] rx status registers for ar9280/ar9825/ar9287
Am 27.04.2013 10:53, schrieb Adrian Chadd: On 27 April 2013 01:30, Oleksij Rempel li...@rempel-privat.de wrote: I do not mean encoded frame, i mean only status flag. Looks like ar9271 provide it. There's an STBC received status flag in the RX decriptor? Where? 7. Word, 3. bit. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Collect statistics about recived duplicate and STBC packets.
This information should help see if STBC is actually working.
Tested on ar9285;
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/debug.c | 20 +++-
drivers/net/wireless/ath/ath9k/debug.h | 4
drivers/net/wireless/ath/ath9k/mac.c | 5 +
drivers/net/wireless/ath/ath9k/mac.h | 14 +++---
4 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index e6307b8..f6c0288 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -848,7 +848,7 @@ static ssize_t read_file_recv(struct file *file, char
__user *user_buf,
struct ath_softc *sc = file-private_data;
char *buf;
- unsigned int len = 0, size = 1600;
+ unsigned int len = 0, size = 2048;
ssize_t retval = 0;
buf = kzalloc(size, GFP_KERNEL);
@@ -900,6 +900,11 @@ static ssize_t read_file_recv(struct file *file, char
__user *user_buf,
RXS_ERR(RX-Frags, rx_frags);
RXS_ERR(RX-Spectral, rx_spectral);
+ RXS_ERR(RX-GI, rx_gi);
+ RXS_ERR(RX-HT40, rx_ht40);
+ RXS_ERR(RX-Duplicate, rx_duplicate);
+ RXS_ERR(RX-STBC, rx_stbc);
+
if (len size)
len = size;
@@ -939,6 +944,14 @@ void ath_debug_stat_rx(struct ath_softc *sc, struct
ath_rx_status *rs)
if (rs-rs_phyerr ATH9K_PHYERR_MAX)
RX_PHY_ERR_INC(rs-rs_phyerr);
}
+ if (rs-rs_flags ATH9K_RX_GI)
+ RX_STAT_INC(rx_gi);
+ if (rs-rs_flags ATH9K_RX_2040)
+ RX_STAT_INC(rx_ht40);
+ if (rs-rs_flags_2 ATH9K_RX_DUP)
+ RX_STAT_INC(rx_duplicate);
+ if (rs-rs_flags_2 ATH9K_RX_STBC)
+ RX_STAT_INC(rx_stbc);
#ifdef CONFIG_ATH9K_MAC_DEBUG
spin_lock(sc-debug.samp_lock);
@@ -1993,6 +2006,11 @@ void ath9k_get_et_stats(struct ieee80211_hw *hw,
AWDATA(data_underrun);
AWDATA(delim_underrun);
+ AWDATA_RX(rx_gi);
+ AWDATA_RX(rx_ht40);
+ AWDATA_RX(rx_duplicate);
+ AWDATA_RX(rx_stbc);
+
AWDATA_RX(crc_err);
AWDATA_RX(decrypt_crc_err);
AWDATA_RX(phy_err);
diff --git a/drivers/net/wireless/ath/ath9k/debug.h
b/drivers/net/wireless/ath/ath9k/debug.h
index 794a7ec..bdae1fd 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -241,6 +241,10 @@ struct ath_rx_stats {
u32 rx_beacons;
u32 rx_frags;
u32 rx_spectral;
+ u32 rx_gi;
+ u32 rx_ht40;
+ u32 rx_duplicate;
+ u32 rx_stbc;
};
struct ath_stats {
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..75ea079 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
rs-rs_status = 0;
rs-rs_flags = 0;
+ rs-rs_flags_2 = 0;
rs-rs_datalen = ads.ds_rxstatus1 AR_DataLen;
rs-rs_tstamp = ads.AR_RcvTimestamp;
@@ -590,6 +591,10 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
(ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0;
rs-rs_flags |=
(ads.ds_rxstatus3 AR_2040) ? ATH9K_RX_2040 : 0;
+ rs-rs_flags_2 |=
+ (ads.ds_rxstatus3 AR_RXST_DUP) ? ATH9K_RX_DUP : 0;
+ rs-rs_flags_2 |=
+ (ads.ds_rxstatus3 AR_RXST_STBC) ? ATH9K_RX_STBC : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..958d72f 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -143,6 +143,7 @@ struct ath_rx_status {
u8 rs_moreaggr;
u8 rs_num_delims;
u8 rs_flags;
+ u8 rs_flags_2;
bool is_mybeacon;
u32 evm0;
u32 evm1;
@@ -185,6 +186,7 @@ struct ath_htc_rx_status {
#define ATH9K_RXERR_KEYMISS 0x20
#define ATH9K_RXERR_CORRUPT_DESC 0x40
+/* rs_flags */
#define ATH9K_RX_MORE 0x01
#define ATH9K_RX_MORE_AGGR0x02
#define ATH9K_RX_GI 0x04
@@ -193,6 +195,10 @@ struct ath_htc_rx_status {
#define ATH9K_RX_DELIM_CRC_POST 0x20
#define ATH9K_RX_DECRYPT_BUSY 0x40
+/* rs_flags_2 */
+#define ATH9K_RX_DUP 0x01
+#define ATH9K_RX_STBC 0x02
+
#define ATH9K_RXKEYIX_INVALID ((u8)-1)
#define ATH9K_TXKEYIX_INVALID ((u8)-1)
@@ -529,11 +535,13 @@ struct ar5416_desc {
#define AR_RcvTimestamp ds_rxstatus2
+/* rxstatus3 */
#define AR_GI 0x0001
#define AR_2040 0x0002
-#define AR_Parallel40 0x0004
-#define
[ath9k-devel] [PATCH v2] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Collect statistics about recived duplicate and STBC packets.
This information should help see if STBC is actually working.
Tested on ar9285; Should work for all chips after ar9280.
Changes:
- v2. test for stbc vield only on ar9280 and later.
reanme rx_gi to rx_short_gi
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/debug.c | 20 +++-
drivers/net/wireless/ath/ath9k/debug.h | 4
drivers/net/wireless/ath/ath9k/mac.c | 7 +++
drivers/net/wireless/ath/ath9k/mac.h | 13 ++---
4 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index e6307b8..fec68f3 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -848,7 +848,7 @@ static ssize_t read_file_recv(struct file *file, char
__user *user_buf,
struct ath_softc *sc = file-private_data;
char *buf;
- unsigned int len = 0, size = 1600;
+ unsigned int len = 0, size = 2048;
ssize_t retval = 0;
buf = kzalloc(size, GFP_KERNEL);
@@ -900,6 +900,11 @@ static ssize_t read_file_recv(struct file *file, char
__user *user_buf,
RXS_ERR(RX-Frags, rx_frags);
RXS_ERR(RX-Spectral, rx_spectral);
+ RXS_ERR(RX-ShortGI, rx_short_gi);
+ RXS_ERR(RX-HT40, rx_ht40);
+ RXS_ERR(RX-Duplicate, rx_duplicate);
+ RXS_ERR(RX-STBC, rx_stbc);
+
if (len size)
len = size;
@@ -939,6 +944,14 @@ void ath_debug_stat_rx(struct ath_softc *sc, struct
ath_rx_status *rs)
if (rs-rs_phyerr ATH9K_PHYERR_MAX)
RX_PHY_ERR_INC(rs-rs_phyerr);
}
+ if (rs-rs_flags ATH9K_RX_GI)
+ RX_STAT_INC(rx_short_gi);
+ if (rs-rs_flags ATH9K_RX_2040)
+ RX_STAT_INC(rx_ht40);
+ if (rs-rs_flags_2 ATH9K_RX_DUP)
+ RX_STAT_INC(rx_duplicate);
+ if (rs-rs_flags_2 ATH9K_RX_STBC)
+ RX_STAT_INC(rx_stbc);
#ifdef CONFIG_ATH9K_MAC_DEBUG
spin_lock(sc-debug.samp_lock);
@@ -1993,6 +2006,11 @@ void ath9k_get_et_stats(struct ieee80211_hw *hw,
AWDATA(data_underrun);
AWDATA(delim_underrun);
+ AWDATA_RX(rx_short_gi);
+ AWDATA_RX(rx_ht40);
+ AWDATA_RX(rx_duplicate);
+ AWDATA_RX(rx_stbc);
+
AWDATA_RX(crc_err);
AWDATA_RX(decrypt_crc_err);
AWDATA_RX(phy_err);
diff --git a/drivers/net/wireless/ath/ath9k/debug.h
b/drivers/net/wireless/ath/ath9k/debug.h
index 794a7ec..639dae9 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -241,6 +241,10 @@ struct ath_rx_stats {
u32 rx_beacons;
u32 rx_frags;
u32 rx_spectral;
+ u32 rx_short_gi;
+ u32 rx_ht40;
+ u32 rx_duplicate;
+ u32 rx_stbc;
};
struct ath_stats {
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..2064d45 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
rs-rs_status = 0;
rs-rs_flags = 0;
+ rs-rs_flags_2 = 0;
rs-rs_datalen = ads.ds_rxstatus1 AR_DataLen;
rs-rs_tstamp = ads.AR_RcvTimestamp;
@@ -590,6 +591,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
(ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0;
rs-rs_flags |=
(ads.ds_rxstatus3 AR_2040) ? ATH9K_RX_2040 : 0;
+ rs-rs_flags_2 |=
+ (ads.ds_rxstatus3 AR_RXST_DUP) ? ATH9K_RX_DUP : 0;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs-rs_flags_2 |=
+ (ads.ds_rxstatus3 AR_RXST_STBC) ? ATH9K_RX_STBC : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..5e5a3af 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -143,6 +143,7 @@ struct ath_rx_status {
u8 rs_moreaggr;
u8 rs_num_delims;
u8 rs_flags;
+ u8 rs_flags_2;
bool is_mybeacon;
u32 evm0;
u32 evm1;
@@ -185,6 +186,7 @@ struct ath_htc_rx_status {
#define ATH9K_RXERR_KEYMISS 0x20
#define ATH9K_RXERR_CORRUPT_DESC 0x40
+/* rs_flags */
#define ATH9K_RX_MORE 0x01
#define ATH9K_RX_MORE_AGGR0x02
#define ATH9K_RX_GI 0x04
@@ -193,6 +195,10 @@ struct ath_htc_rx_status {
#define ATH9K_RX_DELIM_CRC_POST 0x20
#define ATH9K_RX_DECRYPT_BUSY 0x40
+/* rs_flags_2 */
+#define ATH9K_RX_DUP 0x01
+#define ATH9K_RX_STBC 0x02
+
#define ATH9K_RXKEYIX_INVALID ((u8)-1)
#define ATH9K_TXKEYIX_INVALID ((u8)-1)
@@ -529,11
Re: [ath9k-devel] [PATCH v2] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Am 27.04.2013 20:51, schrieb Adrian Chadd: Hiya, Why not just bump rs_flags to be a u16, rather than a u8? then you don't need an rs_flags_2. ok (And then go and re-align things inside that struct so you don't waste space.) hmm.. what do you mean here? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v2] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Am 27.04.2013 21:06, schrieb Adrian Chadd: On 27 April 2013 11:53, Oleksij Rempel li...@rempel-privat.de wrote: (And then go and re-align things inside that struct so you don't waste space.) hmm.. what do you mean here? Structure alignment? Well, you typically want to have everything be dword aligned (32 bits) or word (16 bits) aligned. Otherwise the compiler may insert extra padding between fields in order to meet alignment requirements on platforms that need it (MIPS, older ARM) or platforms that perform slower (newer ARM.) Eg: u32 a; u16 b; u8 c; u8 d; .. that's fine - the u32 is dword aligned, the u16 is word aligned, the u8's don't need aligning. But, considder: u32 a; u8 b; u16 c; u8 d; .. u32 is dword aligned, u8 b is fine as it's a a byte and doesn't need aligning, but 'u16 c' isn't dword aligned! So the compiler will insert a byte padding between 'b' and 'c'. same deal with: u32 a; u16 b; u32 c; .. 'a' is fine; 'b' is fine, but 'c' starts at a word boundary, not a dword boundary. Hence why things like IP/TCP headers and such look the way they do. :-) Now, i don't know what 'bool' is, whether it's a byte, word or dword. That is_mybeacon field should probably be just another flag in rx_status, then just extend 'rs_flags' to 16 bits and include it. That way the alignment is easy to see - all the fields in rx_status and the htc rx_status structs have explicit sizes. :-) ok, i was not sure if you mean what i think :) I would prefer to do this in separate patch. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH v3] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Collect statistics about recived duplicate and STBC packets.
This information should help see if STBC is actually working.
Tested on ar9285; Should work for all chips after ar9280.
Changes:
- v2. test for stbc vield only on ar9280 and later.
reanme rx_gi to rx_short_gi
- v3. use u16 rs_flags instead of two u8
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/debug.c | 20 +++-
drivers/net/wireless/ath/ath9k/debug.h | 4
drivers/net/wireless/ath/ath9k/mac.c | 6 ++
drivers/net/wireless/ath/ath9k/mac.h | 26 +++---
4 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index e6307b8..3cb2ae9 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -848,7 +848,7 @@ static ssize_t read_file_recv(struct file *file, char
__user *user_buf,
struct ath_softc *sc = file-private_data;
char *buf;
- unsigned int len = 0, size = 1600;
+ unsigned int len = 0, size = 2048;
ssize_t retval = 0;
buf = kzalloc(size, GFP_KERNEL);
@@ -900,6 +900,11 @@ static ssize_t read_file_recv(struct file *file, char
__user *user_buf,
RXS_ERR(RX-Frags, rx_frags);
RXS_ERR(RX-Spectral, rx_spectral);
+ RXS_ERR(RX-ShortGI, rx_short_gi);
+ RXS_ERR(RX-HT40, rx_ht40);
+ RXS_ERR(RX-Duplicate, rx_duplicate);
+ RXS_ERR(RX-STBC, rx_stbc);
+
if (len size)
len = size;
@@ -939,6 +944,14 @@ void ath_debug_stat_rx(struct ath_softc *sc, struct
ath_rx_status *rs)
if (rs-rs_phyerr ATH9K_PHYERR_MAX)
RX_PHY_ERR_INC(rs-rs_phyerr);
}
+ if (rs-rs_flags ATH9K_RX_GI)
+ RX_STAT_INC(rx_short_gi);
+ if (rs-rs_flags ATH9K_RX_2040)
+ RX_STAT_INC(rx_ht40);
+ if (rs-rs_flags ATH9K_RX_DUP)
+ RX_STAT_INC(rx_duplicate);
+ if (rs-rs_flags ATH9K_RX_STBC)
+ RX_STAT_INC(rx_stbc);
#ifdef CONFIG_ATH9K_MAC_DEBUG
spin_lock(sc-debug.samp_lock);
@@ -1993,6 +2006,11 @@ void ath9k_get_et_stats(struct ieee80211_hw *hw,
AWDATA(data_underrun);
AWDATA(delim_underrun);
+ AWDATA_RX(rx_short_gi);
+ AWDATA_RX(rx_ht40);
+ AWDATA_RX(rx_duplicate);
+ AWDATA_RX(rx_stbc);
+
AWDATA_RX(crc_err);
AWDATA_RX(decrypt_crc_err);
AWDATA_RX(phy_err);
diff --git a/drivers/net/wireless/ath/ath9k/debug.h
b/drivers/net/wireless/ath/ath9k/debug.h
index 794a7ec..639dae9 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -241,6 +241,10 @@ struct ath_rx_stats {
u32 rx_beacons;
u32 rx_frags;
u32 rx_spectral;
+ u32 rx_short_gi;
+ u32 rx_ht40;
+ u32 rx_duplicate;
+ u32 rx_stbc;
};
struct ath_stats {
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..853cb09 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -590,6 +590,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
(ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0;
rs-rs_flags |=
(ads.ds_rxstatus3 AR_2040) ? ATH9K_RX_2040 : 0;
+ rs-rs_flags |=
+ (ads.ds_rxstatus3 AR_RXST_DUP) ? ATH9K_RX_DUP : 0;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs-rs_flags |=
+ (ads.ds_rxstatus3 AR_RXST_STBC) ? ATH9K_RX_STBC : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..8ea9566 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -142,7 +142,7 @@ struct ath_rx_status {
u8 rs_isaggr;
u8 rs_moreaggr;
u8 rs_num_delims;
- u8 rs_flags;
+ u16 rs_flags;
bool is_mybeacon;
u32 evm0;
u32 evm1;
@@ -185,13 +185,16 @@ struct ath_htc_rx_status {
#define ATH9K_RXERR_KEYMISS 0x20
#define ATH9K_RXERR_CORRUPT_DESC 0x40
-#define ATH9K_RX_MORE 0x01
-#define ATH9K_RX_MORE_AGGR0x02
-#define ATH9K_RX_GI 0x04
-#define ATH9K_RX_2040 0x08
-#define ATH9K_RX_DELIM_CRC_PRE0x10
-#define ATH9K_RX_DELIM_CRC_POST 0x20
-#define ATH9K_RX_DECRYPT_BUSY 0x40
+/* rs_flags */
+#define ATH9K_RX_MORE 0x0001
+#define ATH9K_RX_MORE_AGGR0x0002
+#define ATH9K_RX_GI 0x0004
+#define ATH9K_RX_2040 0x0008
+#define ATH9K_RX_DELIM_CRC_PRE0x0010
+#define ATH9K_RX_DELIM_CRC_POST 0x0020
+#define ATH9K_RX_DECRYPT_BUSY 0x0040
+#define ATH9K_RX_DUP 0x0080
+#define ATH9K_RX_STBC
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Am 28.04.2013 14:51, schrieb Felix Fietkau: On 2013-04-27 5:25 PM, Oleksij Rempel wrote: Collect statistics about recived duplicate and STBC packets. This information should help see if STBC is actually working. Tested on ar9285; Signed-off-by: Oleksij Rempel li...@rempel-privat.de I thought about this patch some more, and I'm wondering what's the point in doing this? These statistics are going to be completely useless for most people and they'll waste some memory/cpu cycles, especially on small-cache devices. I think it's much more useful to simply pass the information to mac80211 via rx flags and get them added to the radiotap header. Sure. I'd like to keep the number of 'poor man's debug hacks' in the driver to a minimum, well, i'll prefer it to call with my name: lazy man's hack ;) and there are some other things that I think should be removed: rx_frags and rx_beacons in struct ath_rx_stats, the tx/rx MAC sampling hack, and pretty much anything else that can be just as easily accessed from mac80211 through regular interfaces. I think there is more things to do in ath9k. Create the list and we can talk about it. For example one of it: I needed some time to understand how some parts of code relate to the hardware. Especially Rx and Tx descriptors. Some comments in header will help... I can add some of them (may be it will help other beginners), but i afraid that i spend time but my patches wont be included. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Am 28.04.2013 17:03, schrieb Oleksij Rempel: Am 28.04.2013 16:13, schrieb Oleksij Rempel: Am 28.04.2013 14:51, schrieb Felix Fietkau: On 2013-04-27 5:25 PM, Oleksij Rempel wrote: Collect statistics about recived duplicate and STBC packets. This information should help see if STBC is actually working. Tested on ar9285; Signed-off-by: Oleksij Rempel li...@rempel-privat.de I thought about this patch some more, and I'm wondering what's the point in doing this? These statistics are going to be completely useless for most people and they'll waste some memory/cpu cycles, especially on small-cache devices. I think it's much more useful to simply pass the information to mac80211 via rx flags and get them added to the radiotap header. Sure. Now i need some help. Why there is no traces of radiotap in ath9k. Some other drivers have them? Do it communicate in some different way or there is just no radiotap support in ath9k? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Am 29.04.2013 08:45, schrieb Wojciech Dubowik: On 04/28/2013 05:03 PM, Oleksij Rempel wrote: Am 28.04.2013 16:13, schrieb Oleksij Rempel: Am 28.04.2013 14:51, schrieb Felix Fietkau: On 2013-04-27 5:25 PM, Oleksij Rempel wrote: Collect statistics about recived duplicate and STBC packets. This information should help see if STBC is actually working. Tested on ar9285; Signed-off-by: Oleksij Rempel li...@rempel-privat.de I thought about this patch some more, and I'm wondering what's the point in doing this? These statistics are going to be completely useless for most people and they'll waste some memory/cpu cycles, especially on small-cache devices. I think it's much more useful to simply pass the information to mac80211 via rx flags and get them added to the radiotap header. Sure. I see Wojciech Dubowik sanded some patches, for at least one year, to make exactly what Felix suggested. Are there any reason why this patches was not accepted? Wojciech if you alive and have some time, can you update them? Sure. I will try to update them based on suggested radiotap field structure for STBC and Ness. On the other hand as Felix already mentioned it's yet another line of code one needs once in a lifetime. If one is checking whether stbc is working the easiest way is to create own debugging namespace in radiotap and dump all descriptor registers there. It probably doesn't go mainline but you could apply the patches when you need and they mostly rebase cleanly. At least that's what I do. Felix, will this patches go upstream if i make it raditap compatible? If yes, and performance and cache usage is an issue, it think we should remove this double flags mapping in ath9k. Currently we convert device specific flags to driver flags, and then convert them to mac80211 flags. There is lots of useless checks and conversations for each packet. Should i change it? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/4 RFC] STBC work for ath9k*
This serie of patches is about support for STBC on ath9k chips. It will add STBC Tx to ath9k-htc and allow tracing Rx packets. Radiotap part of this patch set based on Wojciech Dubowik work. Currently this values seems to be not compatible with STBC draft for radiotap: http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness but compatible with wireshark (thx Wojciech): http://code.wireshark.org/git/?p=wireshark;a=blob;f=epan/dissectors/packet-ieee80211-radiotap-defs.h;h=e0b9a6a0098b3b8ada30cacb75e6ff5009284d3a;hb=HEAD#l280 Oleksij Rempel (4): ath9k_htc: add STBC TX support mac80211: add STBC RX flag for radiotap ath9k: remove useless flag conversation. ath9k: check for Rx-STBC flag and pass it to ieee80211 drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++-- drivers/net/wireless/ath/ath9k/htc.h | 2 ++ drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++ drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 drivers/net/wireless/ath/ath9k/mac.c | 14 ++ drivers/net/wireless/ath/ath9k/mac.h | 4 +++- drivers/net/wireless/ath/ath9k/recv.c | 5 + include/net/ieee80211_radiotap.h | 2 ++ include/net/mac80211.h| 2 ++ net/mac80211/main.c | 3 ++- net/mac80211/rx.c | 2 ++ net/mac80211/status.c | 3 ++- 12 files changed, 36 insertions(+), 13 deletions(-) -- 1.8.1.2 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/4] ath9k_htc: add STBC TX support
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc.h | 2 ++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4
3 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..db4a793 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,8 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */
+#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, TX streams %d, RX streams: %d\n,
tx_streams, rx_streams);
+ if (tx_streams = 2)
+ ht_info-cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info-mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info-mcs.tx_params |= ((tx_streams - 1)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..af08b4a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,10 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate-rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_RX_STBC)
+ caps |= WLAN_RC_RX_STBC_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
if (sta-ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta-ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40)
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 2/4] mac80211: add STBC flag for radiotap
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
include/net/ieee80211_radiotap.h | 2 ++
include/net/mac80211.h | 2 ++
net/mac80211/main.c | 3 ++-
net/mac80211/rx.c| 2 ++
net/mac80211/status.c| 3 ++-
5 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..8d3455b 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20
#define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03
#defineIEEE80211_RADIOTAP_MCS_BW_200
@@ -278,6 +279,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SGI 0x04
#define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC0x10
+#define IEEE80211_RADIOTAP_MCS_STBC0x20
/* For IEEE80211_RADIOTAP_AMPDU_STATUS */
#define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN0x0001
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 04c2d46..76e7977 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,7 @@ 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_STBC: STBC was used
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -832,6 +833,7 @@ enum mac80211_rx_flags {
RX_FLAG_80MHZ = BIT(23),
RX_FLAG_80P80MHZ= BIT(24),
RX_FLAG_160MHZ = BIT(25),
+ RX_FLAG_STBC= BIT(26),
};
/**
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 8a7bfc4..44191a3 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -589,7 +589,8 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t
priv_data_len,
local-hw.conf.short_frame_max_tx_count = wiphy-retry_short;
local-hw.radiotap_mcs_details = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
IEEE80211_RADIOTAP_MCS_HAVE_GI |
-IEEE80211_RADIOTAP_MCS_HAVE_BW;
+IEEE80211_RADIOTAP_MCS_HAVE_BW |
+IEEE80211_RADIOTAP_MCS_HAVE_STBC;
local-hw.radiotap_vht_details = IEEE80211_RADIOTAP_VHT_KNOWN_GI |
IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH;
local-hw.uapsd_queues = IEEE80211_DEFAULT_UAPSD_QUEUES;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c8447af..fada697 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -267,6 +267,8 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
*pos |= IEEE80211_RADIOTAP_MCS_BW_40;
if (status-flag RX_FLAG_HT_GF)
*pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
+ if (status-flag RX_FLAG_STBC)
+ *pos |= IEEE80211_RADIOTAP_MCS_STBC;
pos++;
*pos++ = status-rate_idx;
}
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 4343920..41143f8 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -312,7 +312,8 @@ static void ieee80211_add_tx_radiotap_header(struct
ieee80211_supported_band
rthdr-it_present |= cpu_to_le32(1 IEEE80211_RADIOTAP_MCS);
pos[0] = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
IEEE80211_RADIOTAP_MCS_HAVE_GI |
-IEEE80211_RADIOTAP_MCS_HAVE_BW;
+IEEE80211_RADIOTAP_MCS_HAVE_BW |
+IEEE80211_RADIOTAP_MCS_HAVE_STBC;
if (info-status.rates[0].flags IEEE80211_TX_RC_SHORT_GI)
pos[1] |= IEEE80211_RADIOTAP_MCS_SGI;
if (info-status.rates[0].flags IEEE80211_TX_RC_40_MHZ_WIDTH)
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 3/4] ath9k: remove useless flag conversation.
some flags used only outside of ath9k - In this case we can use
enum mac80211_rx_flags and pass it upstream without extra
conversation.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/mac.c| 11 +++
drivers/net/wireless/ath/ath9k/mac.h| 1 +
drivers/net/wireless/ath/ath9k/recv.c | 5 +
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_status = 0;
rxs-rs_flags = 0;
+ rxs-flag = 0;
rxs-rs_datalen = rxsp-status2 AR_DataLen;
rxs-rs_tstamp = rxsp-status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_isaggr = (rxsp-status11 AR_RxAggr) ? 1 : 0;
rxs-rs_moreaggr = (rxsp-status11 AR_RxMoreAggr) ? 1 : 0;
rxs-rs_antenna = (MS(rxsp-status4, AR_RxAntenna) 0x7);
- rxs-rs_flags = (rxsp-status4 AR_GI) ? ATH9K_RX_GI : 0;
- rxs-rs_flags |= (rxsp-status4 AR_2040) ? ATH9K_RX_2040 : 0;
+ rxs-flag |= (rxsp-status4 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rxs-flag |= (rxsp-status4 AR_2040) ? RX_FLAG_40MHZ : 0;
rxs-evm0 = rxsp-status6;
rxs-evm1 = rxsp-status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
rs-rs_status = 0;
rs-rs_flags = 0;
+ rs-flag = 0;
rs-rs_datalen = ads.ds_rxstatus1 AR_DataLen;
rs-rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct
ath_desc *ds,
rs-rs_moreaggr =
(ads.ds_rxstatus8 AR_RxMoreAggr) ? 1 : 0;
rs-rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
- rs-rs_flags =
- (ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0;
- rs-rs_flags |=
- (ads.ds_rxstatus3 AR_2040) ? ATH9K_RX_2040 : 0;
+
+ /* directly mapped flags for ieee80211_rx_status */
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
u32 evm2;
u32 evm3;
u32 evm4;
+ u32 flag; /* see enum mac80211_rx_flags */
};
struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
if (rx_stats-rs_rate 0x80) {
/* HT rate */
rxs-flag |= RX_FLAG_HT;
- if (rx_stats-rs_flags ATH9K_RX_2040)
- rxs-flag |= RX_FLAG_40MHZ;
- if (rx_stats-rs_flags ATH9K_RX_GI)
- rxs-flag |= RX_FLAG_SHORT_GI;
+ rxs-flag |= rx_stats-flag;
rxs-rate_idx = rx_stats-rs_rate 0x7f;
return 0;
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 4/4] ath9k: check for Rx-STBC flag and pass it to ieee80211
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/mac.c | 3 +++
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..b924024 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,9 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
(ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
rs-flag |=
(ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_STBC) ? RX_FLAG_STBC : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
#define AR_2040 0x0002
#define AR_Parallel40 0x0004
#define AR_Parallel40_S 2
-#define AR_RxStatusRsvd30 0x00f8
+#define AR_STBC 0x0008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30 0x00f0
#define AR_RxAntenna 0xff00
#define AR_RxAntenna_S 8
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] mac80211: Add STBC RX flag to radiotap
Am 29.04.2013 11:04, schrieb Wojciech Dubowik: Add rx flag to radiotap header which tells whether Space-Time Block Code was used. At the moment only 1 stream STBC is supported. TODO: Pass information from the driver on how many STBC streams have been received. Hi, do i understand it correctly, on 2x2 or 2x1 system we will get one stream STBC. On 4x4 or 4x2 we will get one or two stream STBC, is it correct? Is it possible that we will get some thing like this any time soon? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 2/4] mac80211: add STBC flag for radiotap
Am 29.04.2013 12:14, schrieb Johannes Berg:
On Mon, 2013-04-29 at 11:33 +0200, Oleksij Rempel wrote:
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC0x20
Umm, need to do radiotap standardisation process, so NACK until then.
johannes
Until i get response from radiotap list, is it possible to merge or
review patches 1 and 3. They are independent from other patches.
--
Regards,
Oleksij
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Standardisation - adding 2 bit STBC and Ness to MCS
Hallo all, http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness I have posted 3 patches on the proposal page (see Attachments): 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new STBC and Ness parameters from a wireless driver, and add them into the MCS radiotap field. 2. A patch to the Intel wireless driver in the kernel to collect STBC and Ness information. 3. A patch to wireshark to display STBC and Ness information. With this I believe we have everything needed to start the 3 week comment period. There is a bit more then 3 week now. I would like to have this approved :) Are there any thing needed to finish this? Beside, i have one question about how STBC work. According to differnet docs, i assume that: - STBC is done by sending, at least, two stream with same data in different order. - It means for me, that real use of STBC can be made only on MIMO hardware. - If 1x1 receiver indicates that it got STBC encoded frame, it dos not meant, it would be able to use redundant data from second stream. - There are fallowing STBC schemes: Alamouti’s STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit antennas. According to this information, what do we call 1,2 or 3 stream STBC? Since STBC should have minimal 2 stream, but in same time we have 1x1 and 2x2 hardware which able to receive and decode STBC stream i assume: - RX-STBC1 is for compatibility only. No data redundancy. - RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly used method. - RX-STBC123 - is orthogonal schema and not widely used method. Since last method use wide spectrum to transmit data comparable to SISO stream, it makes almost no sense. But 3-stream method get optimal error corect in compare with 2 and 4 strea schemas. Do this assumptions correct? PS: My assumptions based on MIMO Space-Time Block Coding (STBC): Simulations and Results -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] uart interface issues (fixed)
Am 02.05.2013 09:15, schrieb Eugene Krasnikov: Hi Oleksij, Have you tried remote debugging? Or it's only about garbing logs from the chip. Have you tried to send commands to the chip? Yes, it works. You need this resistors to make chip start with ttl adapter attached. Without them this chip may not start. 2013/5/2 Oleksij Rempel li...@rempel-privat.de: Am 28.04.2013 16:17, schrieb Oleksij Rempel: Am 28.04.2013 13:38, schrieb Adrian Chadd: .. is it triggering BREAK interrupts or something? I don't know, there is no serial output on this stage. JTAG may help if the protocol is some how similar to EJTAG. Are there any documentation about Xtensa dubug interface ;)? I will need to dig in it, but not this week. That may be something that the boot ROM code interprets as a magical don't start sequence or something. So, this issue is fixed now. ttl TX --[2K]o RX pin on AR7010 |[4K pull up]--- 3,3V In attachment are pictures from my setup ;) -- Regards, Oleksij -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] uart interface issues (fixed)
Am 02.05.2013 09:22, schrieb Eugene Krasnikov: What kind of commands did you try to send? I will try the same with my dongle and update you if that works or not;) all command are here: ./target_firmware/magpie_fw_dev/target/cmnos/dbg_api.c working commands: help info ram wdt rst (restart system) wdt off (turn off watchdog) wdt on (...) memdmp 5 50010 (memdump of 0x5 0x50010 area) be careful with memdmp command. If watchdog enabled i can be triggered on memdmp, so disable it. If you hit some prottected memory area, system on chip will oops. 2013/5/2 Oleksij Rempel li...@rempel-privat.de: Am 02.05.2013 09:15, schrieb Eugene Krasnikov: Hi Oleksij, Have you tried remote debugging? Or it's only about garbing logs from the chip. Have you tried to send commands to the chip? Yes, it works. You need this resistors to make chip start with ttl adapter attached. Without them this chip may not start. 2013/5/2 Oleksij Rempel li...@rempel-privat.de: Am 28.04.2013 16:17, schrieb Oleksij Rempel: Am 28.04.2013 13:38, schrieb Adrian Chadd: .. is it triggering BREAK interrupts or something? I don't know, there is no serial output on this stage. JTAG may help if the protocol is some how similar to EJTAG. Are there any documentation about Xtensa dubug interface ;)? I will need to dig in it, but not this week. That may be something that the boot ROM code interprets as a magical don't start sequence or something. So, this issue is fixed now. ttl TX --[2K]o RX pin on AR7010 |[4K pull up]--- 3,3V In attachment are pictures from my setup ;) -- Regards, Oleksij -- Regards, Oleksij -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/2] work sync
Hello all, this patches currently pending for review or ack. Can please some one do it untill i forgt them :) Oleksij Rempel (2): ath9k_htc: add STBC TX support ath9k: remove useless flag conversation. drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++-- drivers/net/wireless/ath/ath9k/htc.h | 2 ++ drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++ drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 drivers/net/wireless/ath/ath9k/mac.c | 11 +++ drivers/net/wireless/ath/ath9k/mac.h | 1 + drivers/net/wireless/ath/ath9k/recv.c | 5 + 7 files changed, 21 insertions(+), 10 deletions(-) -- 1.8.1.2 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc.h | 2 ++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4
3 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..db4a793 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,8 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */
+#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, TX streams %d, RX streams: %d\n,
tx_streams, rx_streams);
+ if (tx_streams = 2)
+ ht_info-cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info-mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info-mcs.tx_params |= ((tx_streams - 1)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..af08b4a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,10 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate-rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_RX_STBC)
+ caps |= WLAN_RC_RX_STBC_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
if (sta-ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta-ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40)
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 2/2] ath9k: remove useless flag conversation.
some flags used only outside of ath9k - In this case we can use
enum mac80211_rx_flags and pass it upstream without extra
conversation.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/mac.c| 11 +++
drivers/net/wireless/ath/ath9k/mac.h| 1 +
drivers/net/wireless/ath/ath9k/recv.c | 5 +
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_status = 0;
rxs-rs_flags = 0;
+ rxs-flag = 0;
rxs-rs_datalen = rxsp-status2 AR_DataLen;
rxs-rs_tstamp = rxsp-status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_isaggr = (rxsp-status11 AR_RxAggr) ? 1 : 0;
rxs-rs_moreaggr = (rxsp-status11 AR_RxMoreAggr) ? 1 : 0;
rxs-rs_antenna = (MS(rxsp-status4, AR_RxAntenna) 0x7);
- rxs-rs_flags = (rxsp-status4 AR_GI) ? ATH9K_RX_GI : 0;
- rxs-rs_flags |= (rxsp-status4 AR_2040) ? ATH9K_RX_2040 : 0;
+ rxs-flag |= (rxsp-status4 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rxs-flag |= (rxsp-status4 AR_2040) ? RX_FLAG_40MHZ : 0;
rxs-evm0 = rxsp-status6;
rxs-evm1 = rxsp-status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
rs-rs_status = 0;
rs-rs_flags = 0;
+ rs-flag = 0;
rs-rs_datalen = ads.ds_rxstatus1 AR_DataLen;
rs-rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct
ath_desc *ds,
rs-rs_moreaggr =
(ads.ds_rxstatus8 AR_RxMoreAggr) ? 1 : 0;
rs-rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
- rs-rs_flags =
- (ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0;
- rs-rs_flags |=
- (ads.ds_rxstatus3 AR_2040) ? ATH9K_RX_2040 : 0;
+
+ /* directly mapped flags for ieee80211_rx_status */
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
u32 evm2;
u32 evm3;
u32 evm4;
+ u32 flag; /* see enum mac80211_rx_flags */
};
struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
if (rx_stats-rs_rate 0x80) {
/* HT rate */
rxs-flag |= RX_FLAG_HT;
- if (rx_stats-rs_flags ATH9K_RX_2040)
- rxs-flag |= RX_FLAG_40MHZ;
- if (rx_stats-rs_flags ATH9K_RX_GI)
- rxs-flag |= RX_FLAG_SHORT_GI;
+ rxs-flag |= rx_stats-flag;
rxs-rate_idx = rx_stats-rs_rate 0x7f;
return 0;
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Am 02.05.2013 18:55, schrieb Adrian Chadd: On 2 May 2013 01:11, Oleksij Rempel li...@rempel-privat.de wrote: +#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */ +#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */ I thought we covered this; why are you marking two bits here? becouse firmware checks for two bits (and then use it as bool ;)), so i pass what firmware can handle. Atheros 11n hardware only supports 1-stream STBC RX. Did you got my email with lots of assumptions and questions? What do you mean by 1-stream STBC RX? After i did some home work on STBC i see that it encoded from at least two spatial streams. Is 1-stream STBC RX = 2 spatial streams with mirrored data? and 2-stream STBC RX = 4 spatial streams with mirrored data? or 1-stream STBC RX = compatibility mode for one stream hardware(so only of two streams received)? That would make sense for 1x1:1 hardware, but if you say all atheros N hardware support only 1-stream STBC RX, will mean that STBC is useless on this hardware. Have you verified that we're actually negotiating 1-stream STBC RX with a peer? (Ie, by looking at packet captures?) Yes, i wrote this too :) I verified it, we negotiate only 1-stream STBC RX. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Hi Felix, thank you for your explanation and being pation with me. I learn it by my self and keywords you gave help me to find needed information. So, i continue to digg in to google books and wikis now. I see now, that my initial assumption that STBC some thing like frequency diversity is wrong. Well, it say by itself Space and Time, no freq :) Am 02.05.2013 20:01, schrieb Felix Fietkau: On 2013-05-02 7:32 PM, Oleksij Rempel wrote: Am 02.05.2013 18:55, schrieb Adrian Chadd: On 2 May 2013 01:11, Oleksij Rempel li...@rempel-privat.de wrote: +#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */ +#define WLAN_RC_RX_STBC_FLAG 0xC0 /* RX STBC ,2 bits */ I thought we covered this; why are you marking two bits here? becouse firmware checks for two bits (and then use it as bool ;)), so i pass what firmware can handle. Atheros 11n hardware only supports 1-stream STBC RX. Did you got my email with lots of assumptions and questions? What do you mean by 1-stream STBC RX? After i did some home work on STBC i see that it encoded from at least two spatial streams. Is 1-stream STBC RX = 2 spatial streams with mirrored data? and 2-stream STBC RX = 4 spatial streams with mirrored data? or 1-stream STBC RX = compatibility mode for one stream hardware(so only of two streams received)? When you're talking about 'streams', please specify where you're talking about Spatial Streams (Nss, defined by the MCS), or Space-Time Streams (Nsts). STBC is useful whenever the number of possible Space-Time streams exceeds the number of Spatial streams, i.e. if the number of tx chains is bigger than the number of spatial streams. There's an asymmetry between Rx and Tx here. If a receiver has 1 chain and the transmitter has 2 chains, tx can use 2 Space-Time streams to encode 1 Spatial stream to improve the reliability of the signal. The HT STBC capability field indicates the maximum number of Spatial Streams, not Space-Time streams. Atheros hardware only supports STBC with Nss = 1, so announcing 2-stream STBC is definitely wrong. Ok, i finally found it on ieee 802.11 specification. For STBC: Nsts=2 - Nss=1 Nsts=3 - Nss=2 Nsts=4 - Nss=2 Nsts=4 - Nss=3 That would make sense for 1x1:1 hardware, but if you say all atheros N hardware support only 1-stream STBC RX, will mean that STBC is useless on this hardware. Only STBC With Nss=1, Nsts=2 is supported, but this does not make it useless at all. It helps, even if the receiver only has one antenna. Found it too.. :) Thx! -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Patches for STBC Standartisation
Here are two series of patches. First are kernel patches and ath9k driver patch. Second, is patch for tcpdump. All of them was tested for 1,2 and 3 stream scenarious. Sinse i do not have hardware which can recive more than 1 STBC stream, i did some hacks to to produce this kind of captures. Oleksij Rempel (3): mac80211: add STBC flag for radiotap ath9k: remove useless flag conversation. ath9k: check for Rx-STBC flag and pass it to ieee80211 -- 1.8.1.2 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] tcpdump: add STBC Rx support
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
ieee802_11_radio.h | 6 ++
print-802_11.c | 5 +
2 files changed, 11 insertions(+)
diff --git a/ieee802_11_radio.h b/ieee802_11_radio.h
index 5aff137..65c25df 100644
--- a/ieee802_11_radio.h
+++ b/ieee802_11_radio.h
@@ -277,6 +277,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_GUARD_INTERVAL_KNOWN0x04
#define IEEE80211_RADIOTAP_MCS_HT_FORMAT_KNOWN 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_TYPE_KNOWN 0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_KNOWN 0x20
/* For IEEE80211_RADIOTAP_MCS flags */
#define IEEE80211_RADIOTAP_MCS_BANDWIDTH_MASK 0x03
@@ -287,5 +288,10 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SHORT_GI0x04 /* short guard
interval */
#define IEEE80211_RADIOTAP_MCS_HT_GREENFIELD 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60
+#defineIEEE80211_RADIOTAP_MCS_STBC_1 1
+#defineIEEE80211_RADIOTAP_MCS_STBC_2 2
+#defineIEEE80211_RADIOTAP_MCS_STBC_3 3
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5
#endif /* _NET_IF_IEEE80211RADIOTAP_H_ */
diff --git a/print-802_11.c b/print-802_11.c
index 97badb9..5f65752 100644
--- a/print-802_11.c
+++ b/print-802_11.c
@@ -2184,6 +2184,11 @@ print_radiotap_field(struct cpack_state *s, u_int32_t
bit, u_int8_t *flags,
(u2.u8 IEEE80211_RADIOTAP_MCS_FEC_LDPC) ?
LDPC : BCC);
}
+ if (u.u8 IEEE80211_RADIOTAP_MCS_STBC_KNOWN) {
+ printf(RX-STBC%u ,
+ (u2.u8 IEEE80211_RADIOTAP_MCS_STBC_MASK)
IEEE80211_RADIOTAP_MCS_STBC_SHIFT);
+ }
+
break;
}
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/3] mac80211: add STBC flag for radiotap
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
include/net/ieee80211_radiotap.h | 7 +++
include/net/mac80211.h | 4
net/mac80211/main.c | 3 ++-
net/mac80211/rx.c| 4
net/mac80211/status.c| 3 ++-
5 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20
#define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03
#defineIEEE80211_RADIOTAP_MCS_BW_200
@@ -278,6 +279,12 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SGI 0x04
#define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60
+#defineIEEE80211_RADIOTAP_MCS_STBC_1 1
+#defineIEEE80211_RADIOTAP_MCS_STBC_2 2
+#defineIEEE80211_RADIOTAP_MCS_STBC_3 3
+
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5
/* For IEEE80211_RADIOTAP_AMPDU_STATUS */
#define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN0x0001
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 04c2d46..2b8faeb 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,7 @@ 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_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -832,8 +833,11 @@ enum mac80211_rx_flags {
RX_FLAG_80MHZ = BIT(23),
RX_FLAG_80P80MHZ= BIT(24),
RX_FLAG_160MHZ = BIT(25),
+ RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
};
+#define RX_FLAG_STBC_SHIFT 26
+
/**
* struct ieee80211_rx_status - receive status
*
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 8a7bfc4..44191a3 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -589,7 +589,8 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t
priv_data_len,
local-hw.conf.short_frame_max_tx_count = wiphy-retry_short;
local-hw.radiotap_mcs_details = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
IEEE80211_RADIOTAP_MCS_HAVE_GI |
-IEEE80211_RADIOTAP_MCS_HAVE_BW;
+IEEE80211_RADIOTAP_MCS_HAVE_BW |
+IEEE80211_RADIOTAP_MCS_HAVE_STBC;
local-hw.radiotap_vht_details = IEEE80211_RADIOTAP_VHT_KNOWN_GI |
IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH;
local-hw.uapsd_queues = IEEE80211_DEFAULT_UAPSD_QUEUES;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c8447af..c6b3c62 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
pos += 2;
if (status-flag RX_FLAG_HT) {
+ unsigned int stbc = status-flag RX_FLAG_STBC_MASK;
rthdr-it_present |= cpu_to_le32(1 IEEE80211_RADIOTAP_MCS);
*pos++ = local-hw.radiotap_mcs_details;
*pos = 0;
@@ -267,6 +268,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
*pos |= IEEE80211_RADIOTAP_MCS_BW_40;
if (status-flag RX_FLAG_HT_GF)
*pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
+ if (stbc)
+ *pos |= (stbc RX_FLAG_STBC_SHIFT)
+IEEE80211_RADIOTAP_MCS_STBC_SHIFT;
pos++;
*pos++ = status-rate_idx;
}
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 4343920..41143f8 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -312,7 +312,8 @@ static void ieee80211_add_tx_radiotap_header(struct
ieee80211_supported_band
rthdr-it_present |= cpu_to_le32(1 IEEE80211_RADIOTAP_MCS);
pos[0] = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
IEEE80211_RADIOTAP_MCS_HAVE_GI |
-IEEE80211_RADIOTAP_MCS_HAVE_BW;
+IEEE80211_RADIOTAP_MCS_HAVE_BW |
+IEEE80211_RADIOTAP_MCS_HAVE_STBC;
if (info-status.rates[0].flags IEEE80211_TX_RC_SHORT_GI
[ath9k-devel] Patch for radiotap library
Am 03.05.2013 21:53, schrieb Oleksij Rempel:
Here are two series of patches. First are kernel patches
and ath9k driver patch.
Second, is patch for tcpdump.
All of them was tested for 1,2 and 3 stream scenarious.
Sinse i do not have hardware which can recive more than 1 STBC
stream, i did some hacks to to produce this kind of captures.
Oleksij Rempel (3):
mac80211: add STBC flag for radiotap
ath9k: remove useless flag conversation.
ath9k: check for Rx-STBC flag and pass it to ieee80211
One more patch for radiotap lib.
--
Regards,
Oleksij
From cf3cea707b5766d822ae595cc75849efa78cdb1e Mon Sep 17 00:00:00 2001
From: Oleksij Rempel li...@rempel-privat.de
Date: Sat, 4 May 2013 08:19:07 +0200
Subject: [PATCH] radiotap: add STBC Rx fields.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
radiotap.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/radiotap.h b/radiotap.h
index a566024..2538433 100644
--- a/radiotap.h
+++ b/radiotap.h
@@ -267,6 +267,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT 0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC 0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20
#define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03
#define IEEE80211_RADIOTAP_MCS_BW_20 0
@@ -276,5 +277,10 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SGI 0x04
#define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC 0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60
+#define IEEE80211_RADIOTAP_MCS_STBC_1 1
+#define IEEE80211_RADIOTAP_MCS_STBC_2 2
+#define IEEE80211_RADIOTAP_MCS_STBC_3 3
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5
#endif/* IEEE80211_RADIOTAP_H */
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Am 02.05.2013 22:15, schrieb Adrian Chadd: Well, let's dig into the firmware a bit more and tidy up how STBC is handled. Does it mean, i should change this patch and provide a patch for firmware too? I still do not think, changing peer caps i a good idea in any case. I mena this part of patch: + if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC) + caps |= WLAN_RC_TX_STBC_FLAG; Behaviour with this patch will be fallowing: - peer provide caps, even if it is RX-STBC12 - we pass this information to firmware and ratecontroller of FW, do right decision based on hardware it has. You suggestion, if i understand it correctly, is to filter caps: - if peer provide more than we can, we should tell firmware the value what we can. So, if peer say it can RX-STBC12, we should tell firmware that peer is RX-STBC1. In my opinion, this kind of filter is a source for hidden errors. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Am 04.05.2013 08:50, schrieb Oleksij Rempel: Am 02.05.2013 22:15, schrieb Adrian Chadd: Well, let's dig into the firmware a bit more and tidy up how STBC is handled. Does it mean, i should change this patch and provide a patch for firmware too? I still do not think, changing peer caps i a good idea in any case. I mena this part of patch: + if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC) + caps |= WLAN_RC_TX_STBC_FLAG; oops... my error. I see the problem now. I do not pass flags provided by peer. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH v2] ath9k_htc: add STBC TX support
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
- v2. Use one bit instead of two for RX STBC flags.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc.h | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4
3 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..037e9b8 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,9 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */
+/* RX STBC. Warning! FW checks for 0xC0. But we support only 1 stream anyway */
+#define WLAN_RC_RX_STBC_FLAG 0x40
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, TX streams %d, RX streams: %d\n,
tx_streams, rx_streams);
+ if (tx_streams = 2)
+ ht_info-cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info-mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info-mcs.tx_params |= ((tx_streams - 1)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..af08b4a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,10 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate-rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_RX_STBC)
+ caps |= WLAN_RC_RX_STBC_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
if (sta-ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta-ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40)
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v2] ath9k_htc: add STBC TX support
I forgot to CC one of ATH9K maintainers.
I hope Jouni or Senthil have time for it.
Am 04.05.2013 09:33, schrieb Oleksij Rempel:
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
- v2. Use one bit instead of two for RX STBC flags.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc.h | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4
3 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..037e9b8 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,9 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define WLAN_RC_TX_STBC_FLAG 0x20 /* TX STBC */
+/* RX STBC. Warning! FW checks for 0xC0. But we support only 1 stream anyway
*/
+#define WLAN_RC_RX_STBC_FLAG 0x40
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, TX streams %d, RX streams: %d\n,
tx_streams, rx_streams);
+ if (tx_streams = 2)
+ ht_info-cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info-mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info-mcs.tx_params |= ((tx_streams - 1)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..af08b4a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,10 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate-rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_RX_STBC)
+ caps |= WLAN_RC_RX_STBC_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
if (sta-ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta-ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40)
--
Regards,
Oleksij
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k_htc: add STBC TX support
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
- v2. Use one bit instead of two for RX STBC flags.
- v3. Use ATH_RC_*_STBC_FLAG instead of WLAN_RC_RX_STBC_FLAG
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc.h | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4
3 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..7e7fe62 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,9 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define ATH_RC_TX_STBC_FLAG 0x20 /* TX STBC */
+/* RX STBC. Warning! FW checks for 0xC0. But we support only 1 stream anyway */
+#define ATH_RC_RX_STBC_FLAG 0x40
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, TX streams %d, RX streams: %d\n,
tx_streams, rx_streams);
+ if (tx_streams = 2)
+ ht_info-cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info-mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info-mcs.tx_params |= ((tx_streams - 1)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..d4205e7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,10 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate-rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_RX_STBC)
+ caps |= ATH_RC_RX_STBC_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= ATH_RC_TX_STBC_FLAG;
if (sta-ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta-ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40)
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Am 04.05.2013 12:02, schrieb Felix Fietkau:
On 2013-05-04 8:50 AM, Oleksij Rempel wrote:
Am 02.05.2013 22:15, schrieb Adrian Chadd:
Well, let's dig into the firmware a bit more and tidy up how STBC is
handled.
Does it mean, i should change this patch and provide a patch for
firmware too?
I still do not think, changing peer caps i a good idea in any case.
I mena this part of patch:
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
Behaviour with this patch will be fallowing:
- peer provide caps, even if it is RX-STBC12
- we pass this information to firmware and ratecontroller of FW, do
right decision based on hardware it has.
You suggestion, if i understand it correctly, is to filter caps:
- if peer provide more than we can, we should tell firmware the value
what we can. So, if peer say it can RX-STBC12, we should tell firmware
that peer is RX-STBC1.
In my opinion, this kind of filter is a source for hidden errors.
I think the discussion regarding RX-STBC12 vs RX-STBC1 is purely
hypothetical. The hardware that this firmware was designed for only
supports sending STBC for MCS0-7. This will not change.
Also, there's no reason to tell the firmware about both rx and tx STBC
capabilities, the only thing it needs to know is what tells the rate
control part to enable/disable STBC.
As you can see, in version 2 of this path there was no more discussion
about it. I just did it.
In addition to that, using the WLAN_RC_* flags is wrong, you need to use
the ATH_RC_* flags, as this is what ath_rate_newassoc_11n checks for in
the firmware.
Renamed.
The only STBC related flag that actually gets used (when
passed from the driver) is ATH_RC_RX_STBC_FLAG.
Well, may be it is not used at the end. But it is present on some places
in the firmware.
For example here:
void
rcSibUpdate_11n(struct ath_softc_tgt *sc, struct ath_node_target *pSib,
A_UINT32 capflag, A_BOOL keepState, struct
ieee80211_rate *pRateSet)
{
rcSibUpdate_ht(sc,
pSib,
((capflag ATH_RC_DS_FLAG) ? WLAN_RC_DS_FLAG
: 0) |
((capflag ATH_RC_HT40_SGI_FLAG) ?
WLAN_RC_HT40_SGI_FLAG : 0) |
((capflag ATH_RC_HT_FLAG) ? WLAN_RC_HT_FLAG
: 0) |
((capflag ATH_RC_CW40_FLAG) ? WLAN_RC_40_FLAG
: 0) |
((capflag ATH_RC_TX_STBC_FLAG) ?
WLAN_RC_STBC_FLAG : 0),
keepState,
pRateSet);
So, should i remove ATH_RC_TX_STBC_FLAG from my patch?
--
Regards,
Oleksij
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Am 04.05.2013 13:16, schrieb Felix Fietkau:
On 2013-05-04 1:08 PM, Oleksij Rempel wrote:
Am 04.05.2013 12:02, schrieb Felix Fietkau:
On 2013-05-04 8:50 AM, Oleksij Rempel wrote:
Am 02.05.2013 22:15, schrieb Adrian Chadd:
Well, let's dig into the firmware a bit more and tidy up how STBC is
handled.
Does it mean, i should change this patch and provide a patch for
firmware too?
I still do not think, changing peer caps i a good idea in any case.
I mena this part of patch:
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_TX_STBC)
+ caps |= WLAN_RC_TX_STBC_FLAG;
Behaviour with this patch will be fallowing:
- peer provide caps, even if it is RX-STBC12
- we pass this information to firmware and ratecontroller of FW, do
right decision based on hardware it has.
You suggestion, if i understand it correctly, is to filter caps:
- if peer provide more than we can, we should tell firmware the value
what we can. So, if peer say it can RX-STBC12, we should tell firmware
that peer is RX-STBC1.
In my opinion, this kind of filter is a source for hidden errors.
I think the discussion regarding RX-STBC12 vs RX-STBC1 is purely
hypothetical. The hardware that this firmware was designed for only
supports sending STBC for MCS0-7. This will not change.
Also, there's no reason to tell the firmware about both rx and tx STBC
capabilities, the only thing it needs to know is what tells the rate
control part to enable/disable STBC.
As you can see, in version 2 of this path there was no more discussion
about it. I just did it.
In addition to that, using the WLAN_RC_* flags is wrong, you need to use
the ATH_RC_* flags, as this is what ath_rate_newassoc_11n checks for in
the firmware.
Renamed.
The only STBC related flag that actually gets used (when
passed from the driver) is ATH_RC_RX_STBC_FLAG.
Well, may be it is not used at the end. But it is present on some places
in the firmware.
For example here:
void
rcSibUpdate_11n(struct ath_softc_tgt *sc, struct ath_node_target *pSib,
A_UINT32 capflag, A_BOOL keepState, struct
ieee80211_rate *pRateSet)
{
rcSibUpdate_ht(sc,
pSib,
((capflag ATH_RC_DS_FLAG) ? WLAN_RC_DS_FLAG
: 0) |
((capflag ATH_RC_HT40_SGI_FLAG) ?
WLAN_RC_HT40_SGI_FLAG : 0) |
((capflag ATH_RC_HT_FLAG) ? WLAN_RC_HT_FLAG
: 0) |
((capflag ATH_RC_CW40_FLAG) ? WLAN_RC_40_FLAG
: 0) |
((capflag ATH_RC_TX_STBC_FLAG) ?
WLAN_RC_STBC_FLAG : 0),
keepState,
pRateSet);
So, should i remove ATH_RC_TX_STBC_FLAG from my patch?
I extensively reviewed this part, and it's really crazy. Here's what
happens:
ath_rate_newassoc_11n takes ATH_RC_* flags, converts them to WLAN_RC_*.
rcSibUpdate_11n interprets the WLAN_RC_* flags as ATH_RC_* and converts
them to WLAN_RC_* again. For most flags this is pretty much a no-op
because the definitions are identical.
For STBC the result 'accidentally' still contains WLAN_RC_STBC_FLAG, but
only because ath_rate_newassoc_11n converts ATH_RC_RX_STBC_FLAG to
WLAN_RC_STBC_FLAG and WLAN_RC_STBC_FLAG overlaps with ATH_RC_TX_STBC_FLAG.
In the end it doesn't matter anymore, because nothing in the code takes
the STBC info from the capflags.
STBC is used if ATH_NODE_ATHEROS(an)-stbc is non-zero, and this gets
set by ath_rate_newassoc_11n before all of those incredibly moronic
conversions happen.
Ok, thx.
I'll remove it from my patch. And will remove it from firmware.
Even if you wont to remove bigger part of firmware, i thing it wont
happen this year?
--
Regards,
Oleksij
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH v4] ath9k_htc: add STBC TX support
current firmware will enable STBC_TX, only if other peer support it.
This patch provide ht_peer_caps to firmware.
FW versions 1.3, 1.4 should be able to work with it.
Tested on ar7010+ar9280 and ar7010+ar9287.
- v2. Use one bit instead of two for RX STBC flags.
- v3. Use ATH_RC_*_STBC_FLAG instead of WLAN_RC_RX_STBC_FLAG
- v4. Remove TX flag. This flag is used only to keep AR7010 warm.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/htc.h | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 +++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..c56a0d4 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -142,6 +142,7 @@ struct ath9k_htc_target_aggr {
#define WLAN_RC_40_FLAG 0x02
#define WLAN_RC_SGI_FLAG 0x04
#define WLAN_RC_HT_FLAG 0x08
+#define ATH_RC_RX_STBC_FLAG 0x40
struct ath9k_htc_rateset {
u8 rs_nrates;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..c79c5ac 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -517,6 +517,9 @@ static void setup_ht_cap(struct ath9k_htc_priv *priv,
ath_dbg(common, CONFIG, TX streams %d, RX streams: %d\n,
tx_streams, rx_streams);
+ if (tx_streams = 2)
+ ht_info-cap |= IEEE80211_HT_CAP_TX_STBC;
+
if (tx_streams != rx_streams) {
ht_info-mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
ht_info-mcs.tx_params |= ((tx_streams - 1)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..c744135 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -623,6 +623,8 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv
*priv,
trate-rates.ht_rates.rs_nrates = j;
caps = WLAN_RC_HT_FLAG;
+ if (sta-ht_cap.cap IEEE80211_HT_CAP_RX_STBC)
+ caps |= ATH_RC_RX_STBC_FLAG;
if (sta-ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
if ((sta-ht_cap.cap IEEE80211_HT_CAP_SUP_WIDTH_20_40)
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/2] ath9k_htc: add STBC TX support
Am 04.05.2013 19:50, schrieb Adrian Chadd:
I've just reviewed it myself:
* oan-stbc is enabled only if the hardware itself supports STBC; so
it's an extra sanity check in case the firmware is told to enable STBC
in the WMI capflag field.
all STBC parts are not compiled for AR9271. Currently firmware will do
sanity check on htc_7010.fw and always return 1, and wont do any check
on htc_9271.fw (this part is just not compiled).
* is oan-htinfo used anywhere that may involve STBC?
hmm...oan-htinfo?
* .. we should check whether ath9k_htc ever set the STBC flags on
AR9271, or we'd end up confusing the hardware.
no, never. there are legion guardians ;) last on is on preparing tx
descriptor.
* .. I don't think that is important though, as we weren't _doing_ STBC, right?
correct, currently STBC is not working on linux ath9k_htc
* Why are the ATH_RC_* flags used in newassoc_11n? This comes from the
WMI WMI_RC_STATE_CHANGE_CMDID capflag field; where are _those_
defined?
they are in target_firmware/wlan/if_athrate.h
and well, there are a bit more problems thin them.
See attachment :) Attached patch can go on top of my merge request for
firmware. So, i will probably need to make Patch_v5 for ath9k_htc... since.
Felix,
In addition to that, using the WLAN_RC_* flags is wrong, you need to use
the ATH_RC_* flags,...
After some firmware cleaning i will need to use WLAN_RC_* flags :)
WLAN_RC_* have same values like ATH_RC_*...
Grr, so many things to tidy up.
--
Regards,
Oleksij
diff --git a/target_firmware/wlan/ratectrl11n.h b/target_firmware/wlan/ratectrl11n.h
index 64d0197..00fd156 100755
--- a/target_firmware/wlan/ratectrl11n.h
+++ b/target_firmware/wlan/ratectrl11n.h
@@ -156,20 +156,6 @@ typedef struct {
} RATE_TABLE_11N;
/*
- * Update the SIB's rate control information
- *
- * This should be called when the supported rates change
- * (e.g. SME operation, wireless mode change)
- *
- * It will determine which rates are valid for use.
- */
-void rcSibUpdate_11n(struct ath_softc_tgt *,
- struct ath_node_target *,
- A_UINT32 capflag,
- A_BOOL keepState,
- struct ieee80211_rate *rs);
-
-/*
* Determines and returns the new Tx rate index.
*/
void rcRateFind_11n(struct ath_softc_tgt *sc,
diff --git a/target_firmware/wlan/ratectrl_11n_ln.c b/target_firmware/wlan/ratectrl_11n_ln.c
index 52c1fc7..e64b254 100755
--- a/target_firmware/wlan/ratectrl_11n_ln.c
+++ b/target_firmware/wlan/ratectrl_11n_ln.c
@@ -429,19 +429,7 @@ rcSibUpdate_ht(struct ath_softc_tgt *sc, struct ath_node_target *an,
rcSortValidRates(pRateTable, pRc);
}
-void
-rcSibUpdate_11n(struct ath_softc_tgt *sc, struct ath_node_target *pSib,
- A_UINT32 capflag, A_BOOL keepState, struct ieee80211_rate *pRateSet)
-{
- rcSibUpdate_ht(sc,
- pSib,
- ((capflag ATH_RC_DS_FLAG) ? WLAN_RC_DS_FLAG : 0) |
- ((capflag ATH_RC_HT40_SGI_FLAG) ? WLAN_RC_HT40_SGI_FLAG : 0) |
- ((capflag ATH_RC_HT_FLAG) ? WLAN_RC_HT_FLAG : 0) |
- ((capflag ATH_RC_CW40_FLAG) ? WLAN_RC_40_FLAG : 0),
- keepState,
- pRateSet);
-}
+
/*
* Return the median of three numbers
@@ -1212,17 +1200,11 @@ ath_rate_newassoc_11n(struct ath_softc_tgt *sc, struct ath_node_target *an, int
if (isnew) {
struct atheros_node *oan = ATH_NODE_ATHEROS(an);
- oan-htcap = ((capflag ATH_RC_DS_FLAG) ? WLAN_RC_DS_FLAG : 0) |
- ((capflag ATH_RC_HT40_SGI_FLAG) ? WLAN_RC_HT40_SGI_FLAG : 0) |
- ((capflag ATH_RC_HT_FLAG) ? WLAN_RC_HT_FLAG : 0) |
- ((capflag ATH_RC_CW40_FLAG) ? WLAN_RC_40_FLAG : 0) |
- ((capflag ATH_RC_WEP_TKIP_FLAG) ? WLAN_RC_WEP_TKIP_FLAG : 0);
-
#ifdef MAGPIE_MERLIN
/* Only MERLIN can send STBC */
oan-stbc = (capflag ATH_RC_RX_STBC_FLAG) ? 1 : 0;
#endif
- rcSibUpdate_11n(sc, an, oan-htcap, 0, rs);
+ rcSibUpdate_ht(sc, an, capflag, 0, rs);
}
}
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Standardisation - adding 2 bit STBC and Ness to MCS
Am 02.05.2013 22:44, schrieb Johannes Berg: On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: With this I believe we have everything needed to start the 3 week comment period. Yeah, I guess there was plenty of time. I would have preferred a separate thread, but I guess there's little enough traffic on this list so it doesn't really matter. There is a bit more then 3 week now. I would like to have this approved :) Are there any thing needed to finish this? http://www.radiotap.org/Standardisation johannes ping. Johannes, are you the one who says last word on standardisation for radiotap? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Standardisation - adding 2 bit STBC and Ness to MCS
Am 07.05.2013 15:55, schrieb Johannes Berg: On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote: On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote: Am 02.05.2013 22:44, schrieb Johannes Berg: On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: With this I believe we have everything needed to start the 3 week comment period. Yeah, I guess there was plenty of time. I would have preferred a separate thread, but I guess there's little enough traffic on this list so it doesn't really matter. There is a bit more then 3 week now. I would like to have this approved :) Are there any thing needed to finish this? http://www.radiotap.org/Standardisation johannes ping. Johannes, are you the one who says last word on standardisation for radiotap? No? I thought the link made that pretty clear. But since nobody poked holes in this and it's been a long time, I think you should probably just post this has been adopted now ... Or actually, go to step 5, preferably reposting it as a separate thread. Simon, will you do it? You stared it and did most of the work... -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Spectral Scan in ath9k
Am 08.05.2013 18:15, schrieb Claudio: Alex Hacker hacker at epn.ru writes: On Thu, May 31, 2012 at 12:19:08PM -0700, Adrian Chadd wrote: Argh, there's more to it.. For AR9160 and later, you can enable the FFT bit in one of the radar registers and you'll get some FFT reports for longer radar pulses. It's enabled by default in the code that we've committed to ath9k and FreeBSD HAL. Spectral scan mode is related but different (and not in AR9160.) So for longer pulses, you'll get RADAR payload (phyerr code = 5) which may just have the pri/ext pulse duration and some config info, or it may have a series of FFT reports first. That's just for radar stuff though, it's not spectral scan. That's why he mentioned code = 5 or code = 38. Adrian Hi Adrian. Yes, I'm thinking same way. You right, some additional information required. But for guys who have an interest and time to do some reverse engineering we give a starting point. :) Just another more clear hint for them. Look into published DFS code (it's low level part) and HW radar filter parameters in AR_PHY_RADAR_* registers. Best regards to you, Alex. Hi all, first of all thank you for the code you have developed. I have tried to use it but at each time outputs a different number of FFT samples. I am using FFT_eval (https://github.com/simonwunderlich/FFT_eval) and the following commands: echo chanscan /sys/kernel/debug/ieee80211/phy0/ath9k/spectral_scan_ctl iw dev wlan0 scan cat /sys/kernel/debug/ieee80211/phy0/ath9k/spectral_scan0 /tmp/fft_resusts ./fft_eval /tmp/fft_results On average I get 200-400 samples but sometimes I got even 7k samples, which is very good. I was wondering what causes such variability on how (if possible) perform the spectral scan obtaining a high and constant sample set. I am not touching the other parameters and I am using compat-drivers-3.9- rc4-2-s each time driver do scheduled or unscheduled channel scan, it collect samples for spectral scan. make a lopp with iw dev wlan0 scan and you will got mach more samples :) -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Standardisation - adding 2 bit STBC and Ness to MCS (repost 3)
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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] minstrel_ht: problems with HT40
Hallo Felix, i found your patches for moving ath9k to minstrel_ht and decided to do some testing. For some reason, minstrel_ht exclude all HT40 rates in my network. With native ath9k rate controller I'm able to use HT40. Do you have any idea where to start digging? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] minstrel_ht: problems with HT40
Am 09.05.2013 16:41, schrieb Felix Fietkau: On 2013-05-09 3:42 PM, Oleksij Rempel wrote: Hallo Felix, i found your patches for moving ath9k to minstrel_ht and decided to do some testing. For some reason, minstrel_ht exclude all HT40 rates in my network. With native ath9k rate controller I'm able to use HT40. Do you have any idea where to start digging? Do the rates not even show up in the debugfs rate control stats? correct If so, check the value of sta-bandwidth at the time minstrel_ht_update_caps() is called. hmm... for some reasons sta-bandwidth is always 0. my rc_stats are in attachment -- Regards, Oleksij type rate throughput ewma prob this prob retry this succ/attempt successattempts CCK/LP1.0M 0.9 99.9 100.0 0 0( 0)29 30 CCK/SP2.0M 0.00.0 0.0 0 0( 0) 0 0 CCK/SP5.5M 0.00.0 0.0 0 0( 0) 0 0 CCK/SP 11.0M 0.00.0 0.0 0 0( 0) 0 0 HT20/LGI MCS06.2 100.0 100.0 1 0( 0) 1 1 HT20/LGI MCS1 11.7 100.0 100.0 0 0( 0) 1 1 HT20/LGI MCS2 16.4 100.0 100.0 0 0( 0) 1 1 HT20/LGI MCS3 20.7 100.0 100.0 0 0( 0) 1 1 HT20/LGI MCS4 28.0 100.0 100.0 5 0( 0) 1 1 HT20/LGI MCS5 27.9 82.9 100.0 5 0( 0)15 19 HT20/LGI t MCS6 28.9 80.225.0 5 0( 0) 109 123 HT20/LGI T P MCS7 38.9 99.9 100.0 5 1( 1) 782 813 Total packet count::ideal 975 lookaround 48 Average A-MPDU length: 1.0 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] minstrel_ht: problems with HT40
Am 09.05.2013 17:16, schrieb Felix Fietkau: On 2013-05-09 5:09 PM, Oleksij Rempel wrote: Am 09.05.2013 16:41, schrieb Felix Fietkau: On 2013-05-09 3:42 PM, Oleksij Rempel wrote: Hallo Felix, i found your patches for moving ath9k to minstrel_ht and decided to do some testing. For some reason, minstrel_ht exclude all HT40 rates in my network. With native ath9k rate controller I'm able to use HT40. Do you have any idea where to start digging? Do the rates not even show up in the debugfs rate control stats? correct If so, check the value of sta-bandwidth at the time minstrel_ht_update_caps() is called. hmm... for some reasons sta-bandwidth is always 0. OK, maybe it's a mac80211 issue then. Maybe ath9k rate control checks this field even between HT capability updates. Check when/where this is updated in mac80211. I found the reason. menstrel was doing everything right. For some reasons my speedport router decided to turn off HT40. I didn't checked it before and started digging to the code. After i restarted it i got HT40 back ... :/ -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Standardisation - adding 2 bit STBC and Ness to MCS (repost 3)
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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 15.05.2013 15:42, schrieb Ignacy Gawedzki: 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. Thanks for any suggestion. Hi Ignacy, i can't reproduce this issue on my system. I tested it with 4 different ath9_htc adapter. Without luck. Please provide as match information as possible: - Usb host controller - Adapter manufacture and version, or even better add it to the wiki, and upload some images: http://wikidevi.com/wiki/Main_Page - your kernel version I assume it is not firmware. May be there are some issue with boot loader on adapter. Are you sure that UART pins are not soldered? Current ath9k_htc do not have mechanism to reset an adapter. I will start to work on it after some other issues are done. PS: please find some way to enable uart, at least TX pin. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 16.05.2013 19:20, schrieb Ignacy Gawedzki: On Thu, May 16, 2013 at 03:27:15PM +0200, thus spake Oleksij Rempel: Am 15.05.2013 15:42, schrieb Ignacy Gawedzki: 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. Thanks for any suggestion. Hi Ignacy, i can't reproduce this issue on my system. I tested it with 4 different ath9_htc adapter. Without luck. Without luck, but it seems you're the lucky one anyway. =) Please provide as match information as possible: - Usb host controller Tested both on Raspberry Pi and on Dell XPS 13. The latter uses Intel EHCI, 8086:1c2d and Fresco Logic 1b73:1009, I don't know which one is used exactly. - Adapter manufacture and version, or even better add it to the wiki, and upload some images: http://wikidevi.com/wiki/Main_Page TP-Link TL-WN722NC, exactly as the one on the wiki. That is interesting. I have got today TL-WN722N, but i still can't reproduce this issue. - your kernel version Tested with 3.5.0 on XPS and 3.6.11, 3.8.12 and 3.9.2 on RPi (using a customized buildroot, but I can provide the .config if needed). I assume it is not firmware. May be there are some issue with boot loader on adapter. Are you sure that UART pins are not soldered? I opened the dongle, managed to solder the metal shield off and the pins weren't used (all four 48-51, among others). Current ath9k_htc do not have mechanism to reset an adapter. I will start to work on it after some other issues are done. Is it physically possible? may be. PS: please find some way to enable uart, at least TX pin. I tried to solder the TX pin, but it's really too tiny. I don't have an iron so small as to be able to do it, sorry. I would really love to have an UART connection, but that's just beyond my abilities. BTW, it would really be great to have a way to send debug message up the USB link, just as with carl9170. That make no sense. Debug message i need, are from boot loader. There is no way, that boot loader can send messages over usb. Or if firmwre will crash, it wont send any thing too. So what do we have: - TL-WN722N is working. Or your model is different, or it is broken one. - Did you checked the cable? - usb host controller? - other options? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 08:00, schrieb Johannes Stezenbach: On Thu, May 16, 2013 at 07:45:26PM -0400, Forest Bond wrote: On Fri, May 17, 2013 at 01:48:57AM +0200, Ignacy Gawedzki wrote: On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki: I'll try on yet another one and will tell you the results. Just tried on ICH7, same thing. The easiest way to reproduce the bug is to boot into single user mode (recovery mode on Ubuntu), in order to prevent any NetworkManager or udev from interfering. Then, without any attempt to up the interface, reboot the system by typing reboot in a root shell. FWIW, this has also been a problem for me on Ubuntu 12.04. I can reproduce it the same way. FWIW, I also met this problem after I added ath9k_htc to my initrd (via /etc/initramfs-tools/modules). So I removed it and the issue went away. I first noticed it after resume from suspend-to-disk, but later found it doesn't work after warm reboot, too. The mainboard has Intel H77 chipset, the TL-WN722N is plugged into USB2.0 port. OK, now i was able to reproduce it on ar9271. In attachment is the log i grubbed form adapter. Lines starting with # are my comments -- Regards, Oleksij [2013-05-17 09:49:10] ## turn on pc [2013-05-17 09:49:15] [2013-05-17 09:49:15] ASIC-ROM_1.8 [2013-05-17 09:49:15] 1. 40Mhz [2013-05-17 09:49:15] 2. post [2013-05-17 09:49:16] 3. eep chk [2013-05-17 09:49:16] [%s+] [2013-05-17 09:49:16] patch.offset: 0x%04x, patch.size : 0x%04x [2013-05-17 09:49:16] [%s+] [2013-05-17 09:49:16] CheckSum: 0x%08x [2013-05-17 09:49:16] size: %d bytes [2013-05-17 09:49:16] ld_addr: 0x%08x [2013-05-17 09:49:16] fun_addr: 0x%08x [2013-05-17 09:49:16] copy %d bytes from 0x%08x to 0x%08x[%s-] [2013-05-17 09:49:16] [%s-] [2013-05-17 09:49:16] 4. cold start [2013-05-17 09:49:16] 5. usb only!! [2013-05-17 09:49:16] 6. read usb_conf(0x%04x) to ram(0x%08x) [2013-05-17 09:49:16] 7. usb_hclk rdy [2013-05-17 09:49:16] 8. download [2013-05-17 09:49:16] - custom usb config [2013-05-17 09:49:37] [2013-05-17 09:49:38] start ubuntu kernel 3.8.0-13-generic [2013-05-17 09:50:04] - custom usb config [2013-05-17 09:50:06] - custom usb config [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [cUSB_REQ_DOWNLOAD]: 0x%08x, %02x [2013-05-17 09:50:07] [2013-05-17 09:50:07] ==[cUSB_REQ_COMP]: 0x%08x [2013-05-17 09:50:07] VendorCmd: DownloadComplete! [2013-05-17 09:50:07] 5. usb only!! [2013-05-17 09:50:07] A_WDT_INIT() [2013-05-17 09:50:07] ==cold start== [2013-05-17 09:50:07] ALLOCRAM start 0x50d7f4 size 106508 [2013-05-17 09:50:07] Enable Tx Stream mode [2013-05-17 09:50:08] [+++Magpie_init] [2013-05-17 09:50:08] [+++VBUF_init(100)] [2013-05-17 09:50:08] [+++VBUF_init(100)] [2013-05-17 09:50:08] wlan_pci_probe: Attaching the driver [2013-05-17 09:50:08] wlan_pci_probe: Vendor id 0x168c Dev id 0x24 [2013-05-17 09:50:08] ath_pci_probe 24 [2013-05-17 09:50:08] ath_hal = 0x00510910 [2013-05-17 09:50:08] [2013-05-17 09:50:08] =[dnQ] 0x0050f270 [2013-05-17 09:50:08] [ =[upQ] 0x0050f24c [2013-05-17 09:50:08] [ =[hp dnQ] 0x0050f228 [2013-05-17 09:50:08] [ =[mp dnQ] 0x0050f204 [2013-05-17 09:50:08] [Tgt running [2013-05-17 09:50:10] !USB suspend [2013-05-17 09:50:10] [2013-05-17 09:50:10] change clock to 22 and go to suspend now!øøøøxüøøx ÿ [2013-05-17 09:50:10] ASIC-ROM_1.8 [2013-05-17 09:50:10] 1. 40Mhz [2013-05-17 09:50:10] 2. post [2013-05-17 09:50:10] 3. eep chk [2013-05-17 09:50:10] [%s+] [2013-05-17 09:50:10] patch.offset: 0x%04x, patch.size : 0x%04x [2013-05-17 09:50:10] [%s+] [2013-05-17 09:50:10] CheckSum: 0x%08x [2013-05-17 09:50:10] size: %d bytes [2013-05-17 09:50:10] ld_addr: 0x%08x [2013-05-17 09:50:10] fun_addr: 0x%08x [2013-05-17 09:50:10] copy %d bytes from 0x%08x to 0x%08x[%s-] [2013-05-17 09:50:10] [%s-] [2013-05-17 09:50:10] 4. warm start [2013-05-17 09:50:10] 5. usb only!! [2013-05-17 09:50:10] 6. read usb_conf(0x%04x) to ram(0x%08x) [2013-05-17 09:50:10] 7. usb_hclk rdy [2013-05-17 09:50:10] 8. download [2013-05-17 09:50:10] [2013-05-17 09:50:40] ### kernel started [2013-05-17 09:50:40] ### reboot pc [2013-05-17 09:51:07] Generate Event [2013-05-17 09:51:07] - custom usb config [2013-05-17 09:51:13] [2013-05-17 09:51:17] starting kcurrent kernel [2013-05-17 09:51:31] - custom usb config
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 10:15, schrieb Ignacy Gawedzki: On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel: OK, now i was able to reproduce it on ar9271. Ah, good, but what did you do wrong previously then? Nothing. I needed to start single user mode first, and reboot the system to et this error. In attachment is the log i grubbed form adapter. Lines starting with # are my comments At least we can already diagnose a problem with A_PRINTF. :/ Do these logs speak to anyone? Here are some explanations: ASIC-ROM_1.8 - is start of boot loader on device. It should go immediately after adapter got power. 8. download - at this stage bootloader is ready to receive firmware. [Tgt running - firmware was downloaded and running. !USB suspend - means usb suspend was initiated And that is probably our problem. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 12:40, schrieb Ignacy Gawedzki: On Fri, May 17, 2013 at 12:30:34PM +0200, thus spake Ignacy Gawedzki: On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov: Did anybody tried to force the usb to go to suspend? If something like this echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level will help to reproduce this issue? This way of forcing suspend is apparently deprecated and doesn't work in my case. I tried to set power/control to auto, but it has no apparent effect on anything. :( Okay, I did manage to make it fail. In single-user mode (to prevent any daemon from interfering), I plugged the dongle, set power/control to auto and after a few seconds unloaded/reloaded the ath9k_htc module. This made the target unresponsive. If I do the same without setting power/control to auto (it is on by default), then unloading/reloading the module doesn't make the device unresponsive. BTW, Oleksij, just out of curiosity, how did you manage to solder those UART pins? Here an example of soldered pins, it is ar7010 device. I attached here jtag pins. https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk here is a workaround for this issue, please test it: https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 13:41, schrieb Ignacy Gawedzki: On Fri, May 17, 2013 at 01:22:43PM +0200, thus spake Ignacy Gawedzki: On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: Here an example of soldered pins, it is ar7010 device. I attached here jtag pins. https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk Wow, my soldering iron has too broad a tip for that precision work. :/ here is a workaround for this issue, please test it: https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend It seems to work just right on the PC. I'll test on the RPi and let you know. Works on the RPi as well! Are there any implications for this being a workaround and not a proper fix? Yes, i do not know what i did. I will need to find out, what it actually should do. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
Am 17.05.2013 17:37, schrieb Adrian Chadd: On 17 May 2013 05:00, Oleksij Rempel li...@rempel-privat.de wrote: here is a workaround for this issue, please test it: https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend It seems to work just right on the PC. I'll test on the RPi and let you know. Works on the RPi as well! Are there any implications for this being a workaround and not a proper fix? Yes, i do not know what i did. I will need to find out, what it actually should do. ... hm, is this reset type not working? Is this the whole reset through watchdog versus reset through reset thing you talked about a couple weeks ago? No, it is different issue, at least at different path. I did some more test and i'll try now to reflect all collected informations: - Only ar9271 devices are affected. ar7010 seems to be fine. - the issue is in: target_firmware/magpie_fw_dev/target/hif/k2_fw_usb_api.c: in _fw_usb_suspend_reboot() this function is called from two points: - _fw_usbfifo_recv_command(), this one is triggered if host go to supend - _fw_usb_fw_task(), this function is called on different events, including reset, some cases if suspend? and resume? last was never called. I'll need to check how exactly this part is working. So, _fw_usb_suspend_reboot() should theoretically prepare adapter for suspend, to reduce power consumption. But there are fallowing problems with this function: - some hosts will completely power down this device. Absolutely no power is consumed and all preparations made by this function are lost (cald reset). - some hosts keep usb port powered to be able to charge some device. It is done only on laptops/pcs connected to power supply (i have one of this, so i was able to check it). In this case we go to some undefined state, and probably prepared to receive firmware. In this state device use about 40mA. - in all cases linux will do reset on resume. So all side effects produced by _fw_usb_suspend_reboot() are reseted. This is why it is so hard to reproduce this case. The problem what we now have is passed from _fw_usb_fw_task(), in this case adapter will restart to boot loader and got ready to receive firmware. But it looks like usb descriptor in this case is incomplete: here is brocken descriptor: Bus 003 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice1.08 iManufacturer 16 iProduct 32 iSerial48 bNumConfigurations 1 ---end--- here is ok descriptor: Bus 003 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice1.08 iManufacturer 16 ATHEROS iProduct 32 UB91C iSerial48 12345 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 60 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA --- and some more after i disabled this function... see my workaround patch. I got fallowing process. Host send suspend command no changes was made, (currently i do not know what should we send as response), host trying to send it some more times and the send reset. After this, adapter is rebooting and firmware is uploaded... so it comes to normal working state. There is no way to support WoW here. So, there is no need to have some sort of reduced power state. I assume, we can remove most part of suspend sequence from firmware. And replace it with some correct response to the host that every thing is ok, or that we do not support this bit. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
To be able to reproduce this bug a bit easier, i added usbautosuspend to ath9k_htc. There is some interesting statistic of power usage for now: ar9271: • power on + wifi on = 160 uA • ifconfig wlan0 down without autosuspend = 60 uA • ifconfig wlan0 down with autosupend = 1,6 uA Current problem is to bring adapter back. Am 17.05.2013 20:51, schrieb Oleksij Rempel: Am 17.05.2013 17:37, schrieb Adrian Chadd: On 17 May 2013 05:00, Oleksij Rempel li...@rempel-privat.de wrote: here is a workaround for this issue, please test it: https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend It seems to work just right on the PC. I'll test on the RPi and let you know. Works on the RPi as well! Are there any implications for this being a workaround and not a proper fix? Yes, i do not know what i did. I will need to find out, what it actually should do. ... hm, is this reset type not working? Is this the whole reset through watchdog versus reset through reset thing you talked about a couple weeks ago? No, it is different issue, at least at different path. I did some more test and i'll try now to reflect all collected informations: - Only ar9271 devices are affected. ar7010 seems to be fine. - the issue is in: target_firmware/magpie_fw_dev/target/hif/k2_fw_usb_api.c: in _fw_usb_suspend_reboot() this function is called from two points: - _fw_usbfifo_recv_command(), this one is triggered if host go to supend - _fw_usb_fw_task(), this function is called on different events, including reset, some cases if suspend? and resume? last was never called. I'll need to check how exactly this part is working. So, _fw_usb_suspend_reboot() should theoretically prepare adapter for suspend, to reduce power consumption. But there are fallowing problems with this function: - some hosts will completely power down this device. Absolutely no power is consumed and all preparations made by this function are lost (cald reset). - some hosts keep usb port powered to be able to charge some device. It is done only on laptops/pcs connected to power supply (i have one of this, so i was able to check it). In this case we go to some undefined state, and probably prepared to receive firmware. In this state device use about 40mA. - in all cases linux will do reset on resume. So all side effects produced by _fw_usb_suspend_reboot() are reseted. This is why it is so hard to reproduce this case. The problem what we now have is passed from _fw_usb_fw_task(), in this case adapter will restart to boot loader and got ready to receive firmware. But it looks like usb descriptor in this case is incomplete: here is brocken descriptor: Bus 003 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice1.08 iManufacturer 16 iProduct 32 iSerial48 bNumConfigurations 1 ---end--- here is ok descriptor: Bus 003 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice1.08 iManufacturer 16 ATHEROS iProduct 32 UB91C iSerial48 12345 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 60 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA --- and some more after i disabled this function... see my workaround patch. I got fallowing process. Host send suspend command no changes was made, (currently i do not know what should we send as response), host trying to send it some more times and the send reset. After this, adapter is rebooting and firmware is uploaded... so it comes to normal working state. There is no way to support WoW here. So, there is no need to have some sort of reduced power state. I assume, we can remove most part of suspend sequence from firmware. And replace it with some correct response to the host that every thing
[ath9k-devel] [PATCH 3/3] ath9k: check for Rx-STBC flag and pass it to ieee80211
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/mac.c | 5 +
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..d055e38 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
(ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
rs-flag |=
(ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_STBC) ?
+ /* we can only Nss=1 STBC */
+ (1 RX_FLAG_STBC_SHIFT) : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
#define AR_2040 0x0002
#define AR_Parallel40 0x0004
#define AR_Parallel40_S 2
-#define AR_RxStatusRsvd30 0x00f8
+#define AR_STBC 0x0008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30 0x00f0
#define AR_RxAntenna 0xff00
#define AR_RxAntenna_S 8
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/3] Work on STBC Rx monitoring
This patch set will pass RxSTBC flags from ath9k to ieee80211 and to radiotap. This field is now a part of radiotap specification: http://www.radiotap.org/defined-fields/MCS Oleksij Rempel (3): mac80211: add STBC flag for radiotap ath9k: remove useless flag conversation. ath9k: check for Rx-STBC flag and pass it to ieee80211 drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++-- drivers/net/wireless/ath/ath9k/mac.c| 16 drivers/net/wireless/ath/ath9k/mac.h| 4 +++- drivers/net/wireless/ath/ath9k/recv.c | 5 + include/net/ieee80211_radiotap.h| 7 +++ include/net/mac80211.h | 4 net/mac80211/main.c | 3 ++- net/mac80211/rx.c | 4 net/mac80211/status.c | 3 ++- 9 files changed, 38 insertions(+), 13 deletions(-) -- 1.8.1.2 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/3] mac80211: add STBC flag for radiotap
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
include/net/ieee80211_radiotap.h | 7 +++
include/net/mac80211.h | 4
net/mac80211/main.c | 3 ++-
net/mac80211/rx.c| 4
net/mac80211/status.c| 3 ++-
5 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20
#define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03
#defineIEEE80211_RADIOTAP_MCS_BW_200
@@ -278,6 +279,12 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SGI 0x04
#define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60
+#defineIEEE80211_RADIOTAP_MCS_STBC_1 1
+#defineIEEE80211_RADIOTAP_MCS_STBC_2 2
+#defineIEEE80211_RADIOTAP_MCS_STBC_3 3
+
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5
/* For IEEE80211_RADIOTAP_AMPDU_STATUS */
#define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN0x0001
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 885898a..16705a9 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,7 @@ 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_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -832,8 +833,11 @@ enum mac80211_rx_flags {
RX_FLAG_80MHZ = BIT(23),
RX_FLAG_80P80MHZ= BIT(24),
RX_FLAG_160MHZ = BIT(25),
+ RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
};
+#define RX_FLAG_STBC_SHIFT 26
+
/**
* struct ieee80211_rx_status - receive status
*
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 8a7bfc4..44191a3 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -589,7 +589,8 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t
priv_data_len,
local-hw.conf.short_frame_max_tx_count = wiphy-retry_short;
local-hw.radiotap_mcs_details = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
IEEE80211_RADIOTAP_MCS_HAVE_GI |
-IEEE80211_RADIOTAP_MCS_HAVE_BW;
+IEEE80211_RADIOTAP_MCS_HAVE_BW |
+IEEE80211_RADIOTAP_MCS_HAVE_STBC;
local-hw.radiotap_vht_details = IEEE80211_RADIOTAP_VHT_KNOWN_GI |
IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH;
local-hw.uapsd_queues = IEEE80211_DEFAULT_UAPSD_QUEUES;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 8e29526..22bb2af 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
pos += 2;
if (status-flag RX_FLAG_HT) {
+ unsigned int stbc = status-flag RX_FLAG_STBC_MASK;
rthdr-it_present |= cpu_to_le32(1 IEEE80211_RADIOTAP_MCS);
*pos++ = local-hw.radiotap_mcs_details;
*pos = 0;
@@ -267,6 +268,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
*pos |= IEEE80211_RADIOTAP_MCS_BW_40;
if (status-flag RX_FLAG_HT_GF)
*pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
+ if (stbc)
+ *pos |= (stbc RX_FLAG_STBC_SHIFT)
+IEEE80211_RADIOTAP_MCS_STBC_SHIFT;
pos++;
*pos++ = status-rate_idx;
}
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 4343920..41143f8 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -312,7 +312,8 @@ static void ieee80211_add_tx_radiotap_header(struct
ieee80211_supported_band
rthdr-it_present |= cpu_to_le32(1 IEEE80211_RADIOTAP_MCS);
pos[0] = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
IEEE80211_RADIOTAP_MCS_HAVE_GI |
-IEEE80211_RADIOTAP_MCS_HAVE_BW;
+IEEE80211_RADIOTAP_MCS_HAVE_BW |
+IEEE80211_RADIOTAP_MCS_HAVE_STBC;
if (info-status.rates[0].flags IEEE80211_TX_RC_SHORT_GI
[ath9k-devel] [PATCH 2/3] ath9k: remove useless flag conversation.
some flags used only outside of ath9k - In this case we can use
enum mac80211_rx_flags and pass it upstream without extra
conversation.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/mac.c| 11 +++
drivers/net/wireless/ath/ath9k/mac.h| 1 +
drivers/net/wireless/ath/ath9k/recv.c | 5 +
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_status = 0;
rxs-rs_flags = 0;
+ rxs-flag = 0;
rxs-rs_datalen = rxsp-status2 AR_DataLen;
rxs-rs_tstamp = rxsp-status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_isaggr = (rxsp-status11 AR_RxAggr) ? 1 : 0;
rxs-rs_moreaggr = (rxsp-status11 AR_RxMoreAggr) ? 1 : 0;
rxs-rs_antenna = (MS(rxsp-status4, AR_RxAntenna) 0x7);
- rxs-rs_flags = (rxsp-status4 AR_GI) ? ATH9K_RX_GI : 0;
- rxs-rs_flags |= (rxsp-status4 AR_2040) ? ATH9K_RX_2040 : 0;
+ rxs-flag |= (rxsp-status4 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rxs-flag |= (rxsp-status4 AR_2040) ? RX_FLAG_40MHZ : 0;
rxs-evm0 = rxsp-status6;
rxs-evm1 = rxsp-status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
rs-rs_status = 0;
rs-rs_flags = 0;
+ rs-flag = 0;
rs-rs_datalen = ads.ds_rxstatus1 AR_DataLen;
rs-rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct
ath_desc *ds,
rs-rs_moreaggr =
(ads.ds_rxstatus8 AR_RxMoreAggr) ? 1 : 0;
rs-rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
- rs-rs_flags =
- (ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0;
- rs-rs_flags |=
- (ads.ds_rxstatus3 AR_2040) ? ATH9K_RX_2040 : 0;
+
+ /* directly mapped flags for ieee80211_rx_status */
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
u32 evm2;
u32 evm3;
u32 evm4;
+ u32 flag; /* see enum mac80211_rx_flags */
};
struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
if (rx_stats-rs_rate 0x80) {
/* HT rate */
rxs-flag |= RX_FLAG_HT;
- if (rx_stats-rs_flags ATH9K_RX_2040)
- rxs-flag |= RX_FLAG_40MHZ;
- if (rx_stats-rs_flags ATH9K_RX_GI)
- rxs-flag |= RX_FLAG_SHORT_GI;
+ rxs-flag |= rx_stats-flag;
rxs-rate_idx = rx_stats-rs_rate 0x7f;
return 0;
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH v3 1/3] mac80211: add STBC flag for radiotap
Some chips can tell us if received frame was
encoded with STBC or not. To make this information available
in user space we can use updated radiotap specification:
http://www.radiotap.org/defined-fields/MCS
This patch add HAVE_STBC flag and provide number
of STBC encoded spatial streams (Nss).
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
include/net/ieee80211_radiotap.h | 7 +++
include/net/mac80211.h | 4
net/mac80211/rx.c| 13 -
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20
#define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03
#defineIEEE80211_RADIOTAP_MCS_BW_200
@@ -278,6 +279,12 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SGI 0x04
#define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60
+#defineIEEE80211_RADIOTAP_MCS_STBC_1 1
+#defineIEEE80211_RADIOTAP_MCS_STBC_2 2
+#defineIEEE80211_RADIOTAP_MCS_STBC_3 3
+
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5
/* For IEEE80211_RADIOTAP_AMPDU_STATUS */
#define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN0x0001
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 885898a..16705a9 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,7 @@ 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_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -832,8 +833,11 @@ enum mac80211_rx_flags {
RX_FLAG_80MHZ = BIT(23),
RX_FLAG_80P80MHZ= BIT(24),
RX_FLAG_160MHZ = BIT(25),
+ RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
};
+#define RX_FLAG_STBC_SHIFT 26
+
/**
* struct ieee80211_rx_status - receive status
*
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 8e29526..db7c68a 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -258,8 +258,16 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
pos += 2;
if (status-flag RX_FLAG_HT) {
+ unsigned int stbc = status-flag RX_FLAG_STBC_MASK;
rthdr-it_present |= cpu_to_le32(1 IEEE80211_RADIOTAP_MCS);
- *pos++ = local-hw.radiotap_mcs_details;
+
+ /* MCS known field */
+ *pos = local-hw.radiotap_mcs_details;
+ if (stbc)
+ *pos |= IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+ *pos++;
+
+ /* MCS flags field */
*pos = 0;
if (status-flag RX_FLAG_SHORT_GI)
*pos |= IEEE80211_RADIOTAP_MCS_SGI;
@@ -267,6 +275,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
*pos |= IEEE80211_RADIOTAP_MCS_BW_40;
if (status-flag RX_FLAG_HT_GF)
*pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
+ if (stbc)
+ *pos |= (stbc RX_FLAG_STBC_SHIFT)
+IEEE80211_RADIOTAP_MCS_STBC_SHIFT;
pos++;
*pos++ = status-rate_idx;
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH v4 1/3] mac80211: add STBC flag for radiotap
Some chips can tell us if received frame was
encoded with STBC or not. To make this information available
in user space we can use updated radiotap specification:
http://www.radiotap.org/defined-fields/MCS
This patch will set number of STBC encoded spatial streams (Nss).
The HAVE_STBC flag should be provided by driver.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
include/net/ieee80211_radiotap.h | 7 +++
include/net/mac80211.h | 4
net/mac80211/rx.c| 4
3 files changed, 15 insertions(+)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20
#define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03
#defineIEEE80211_RADIOTAP_MCS_BW_200
@@ -278,6 +279,12 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SGI 0x04
#define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60
+#defineIEEE80211_RADIOTAP_MCS_STBC_1 1
+#defineIEEE80211_RADIOTAP_MCS_STBC_2 2
+#defineIEEE80211_RADIOTAP_MCS_STBC_3 3
+
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5
/* For IEEE80211_RADIOTAP_AMPDU_STATUS */
#define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN0x0001
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 885898a..16705a9 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,7 @@ 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_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -832,8 +833,11 @@ enum mac80211_rx_flags {
RX_FLAG_80MHZ = BIT(23),
RX_FLAG_80P80MHZ= BIT(24),
RX_FLAG_160MHZ = BIT(25),
+ RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
};
+#define RX_FLAG_STBC_SHIFT 26
+
/**
* struct ieee80211_rx_status - receive status
*
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 8e29526..811dd64 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
pos += 2;
if (status-flag RX_FLAG_HT) {
+ unsigned int stbc;
rthdr-it_present |= cpu_to_le32(1 IEEE80211_RADIOTAP_MCS);
*pos++ = local-hw.radiotap_mcs_details;
*pos = 0;
@@ -267,6 +268,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local
*local,
*pos |= IEEE80211_RADIOTAP_MCS_BW_40;
if (status-flag RX_FLAG_HT_GF)
*pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
+ stbc = status-flag RX_FLAG_STBC_MASK;
+ *pos |= (stbc RX_FLAG_STBC_SHIFT)
+IEEE80211_RADIOTAP_MCS_STBC_SHIFT;
pos++;
*pos++ = status-rate_idx;
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v4 1/3] mac80211: add STBC flag for radiotap
Am 24.05.2013 12:08, schrieb Johannes Berg: On Fri, 2013-05-24 at 12:05 +0200, Oleksij Rempel wrote: Some chips can tell us if received frame was encoded with STBC or not. To make this information available in user space we can use updated radiotap specification: http://www.radiotap.org/defined-fields/MCS This patch will set number of STBC encoded spatial streams (Nss). The HAVE_STBC flag should be provided by driver. Applied, thanks. thank you. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/2] ath9k: STBC Rx monitoring
this are two remaining patches to allow STBC Rx monitoring on ath9k devices. This patches depend on currently applied: [PATCH v4 1/3] mac80211: add STBC flag for radiotap Oleksij Rempel (2): ath9k: remove useless flag conversation. ath9k: check for Rx-STBC flag and pass it to ieee80211 drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++-- drivers/net/wireless/ath/ath9k/init.c | 9 +++-- drivers/net/wireless/ath/ath9k/mac.c| 16 drivers/net/wireless/ath/ath9k/mac.h| 4 +++- drivers/net/wireless/ath/ath9k/recv.c | 5 + 5 files changed, 26 insertions(+), 13 deletions(-) -- 1.8.1.2 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/2] ath9k: remove useless flag conversation.
some flags used only outside of ath9k - In this case we can use
enum mac80211_rx_flags and pass it upstream without extra
conversation.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/mac.c| 11 +++
drivers/net/wireless/ath/ath9k/mac.h| 1 +
drivers/net/wireless/ath/ath9k/recv.c | 5 +
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_status = 0;
rxs-rs_flags = 0;
+ rxs-flag = 0;
rxs-rs_datalen = rxsp-status2 AR_DataLen;
rxs-rs_tstamp = rxsp-status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_isaggr = (rxsp-status11 AR_RxAggr) ? 1 : 0;
rxs-rs_moreaggr = (rxsp-status11 AR_RxMoreAggr) ? 1 : 0;
rxs-rs_antenna = (MS(rxsp-status4, AR_RxAntenna) 0x7);
- rxs-rs_flags = (rxsp-status4 AR_GI) ? ATH9K_RX_GI : 0;
- rxs-rs_flags |= (rxsp-status4 AR_2040) ? ATH9K_RX_2040 : 0;
+ rxs-flag |= (rxsp-status4 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rxs-flag |= (rxsp-status4 AR_2040) ? RX_FLAG_40MHZ : 0;
rxs-evm0 = rxsp-status6;
rxs-evm1 = rxsp-status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
rs-rs_status = 0;
rs-rs_flags = 0;
+ rs-flag = 0;
rs-rs_datalen = ads.ds_rxstatus1 AR_DataLen;
rs-rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct
ath_desc *ds,
rs-rs_moreaggr =
(ads.ds_rxstatus8 AR_RxMoreAggr) ? 1 : 0;
rs-rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
- rs-rs_flags =
- (ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0;
- rs-rs_flags |=
- (ads.ds_rxstatus3 AR_2040) ? ATH9K_RX_2040 : 0;
+
+ /* directly mapped flags for ieee80211_rx_status */
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
u32 evm2;
u32 evm3;
u32 evm4;
+ u32 flag; /* see enum mac80211_rx_flags */
};
struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
if (rx_stats-rs_rate 0x80) {
/* HT rate */
rxs-flag |= RX_FLAG_HT;
- if (rx_stats-rs_flags ATH9K_RX_2040)
- rxs-flag |= RX_FLAG_40MHZ;
- if (rx_stats-rs_flags ATH9K_RX_GI)
- rxs-flag |= RX_FLAG_SHORT_GI;
+ rxs-flag |= rx_stats-flag;
rxs-rate_idx = rx_stats-rs_rate 0x7f;
return 0;
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/init.c | 9 +++--
drivers/net/wireless/ath/ath9k/mac.c | 5 +
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index aba4151..7739b05 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct
ieee80211_hw *hw)
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
IEEE80211_HW_SUPPORTS_RC_TABLE;
- if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT)
-hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+ if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT) {
+ hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ hw-radiotap_mcs_details |=
+ IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+ }
if (AR_SREV_9160_10_OR_LATER(sc-sc_ah) || ath9k_modparam_nohwcrypt)
hw-flags |= IEEE80211_HW_MFP_CAPABLE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..d055e38 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
(ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
rs-flag |=
(ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_STBC) ?
+ /* we can only Nss=1 STBC */
+ (1 RX_FLAG_STBC_SHIFT) : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
#define AR_2040 0x0002
#define AR_Parallel40 0x0004
#define AR_Parallel40_S 2
-#define AR_RxStatusRsvd30 0x00f8
+#define AR_STBC 0x0008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30 0x00f0
#define AR_RxAntenna 0xff00
#define AR_RxAntenna_S 8
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
Am 24.05.2013 12:29, schrieb Johannes Berg:
On Fri, 2013-05-24 at 12:18 +0200, Oleksij Rempel wrote:
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/init.c | 9 +++--
drivers/net/wireless/ath/ath9k/mac.c | 5 +
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index aba4151..7739b05 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct
ieee80211_hw *hw)
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
IEEE80211_HW_SUPPORTS_RC_TABLE;
-if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT)
- hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT) {
+hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+
+if (AR_SREV_9280_20_OR_LATER(ah))
+hw-radiotap_mcs_details |=
+IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+}
Are you sure this is right? It seems that if other devices don't support
STBC they can report all frames to be w/o STBC. Or do they support STBC
but don't report it?
They support STBC but don't report it. First device whhic can report it
is ar9280.
--
Regards,
Oleksij
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
Am 24.05.2013 12:18, schrieb Oleksij Rempel:
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/init.c | 9 +++--
drivers/net/wireless/ath/ath9k/mac.c | 5 +
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index aba4151..7739b05 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct
ieee80211_hw *hw)
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
IEEE80211_HW_SUPPORTS_RC_TABLE;
- if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT)
- hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+ if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT) {
+ hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ hw-radiotap_mcs_details |=
+ IEEE80211_RADIOTAP_MCS_HAVE_STBC;
comment for my self. i forgot to include net/ieee80211_radiotap.h
for IEEE80211_RADIOTAP_MCS_HAVE_STBC. This patch is broken.
--
Regards,
Oleksij
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] skb_under_panic in ath9k
Am 24.05.2013 10:47, schrieb Marc Kleine-Budde: added ath9k-devel to Cc On 05/23/2013 12:02 AM, Marc Kleine-Budde wrote: Hello, I'm on a kirkwood based armv5 system with an USB attached TP-Link TL-WN821N - Atheros AR7010+AR9287, [1]. the wlan is running in AP mode with hostapd-1.0. The kernel is v3.8.12 from debian (3.8-1-kirkwood #1 Debian 3.8.12-1). The system crashes repeatedly after about one week with the following oops: [633625.401875] skbuff: skb_under_panic: text:bf501028 len:128 put:8 head:d2788800 data:d27887fe tail:0xd278887e end:0xd2788f40 dev:wlan1 [633625.414180] [ cut here ] [633625.418909] kernel BUG at /build/buildd-linux_3.8.12-1-armel-7F6kBx/linux-3.8.12/net/core/skbuff.c:145! [633625.428430] Internal error: Oops - BUG: 0 [#1] ARM [633625.433322] Modules linked in: [...] [633625.583170] CPU: 0Not tainted (3.8-1-kirkwood #1 Debian 3.8.12-1) [633625.589821] PC is at skb_push+0x6c/0x84 [633625.593763] LR is at skb_push+0x6c/0x84 [633625.597707] pc : [c0282990]lr : [c0282990]psr: 2013 [633625.597707] sp : c04c1d50 ip : 08f8 fp : df04ea54 [633625.609404] r10: 0002 r9 : 0008 r8 : df00dca8 [633625.614734] r7 : 0006 r6 : c04410a0 r5 : d278887e r4 : d2788800 [633625.621378] r3 : c04d328c r2 : 2093 r1 : 0001 r0 : 0079 [633625.628015] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [633625.635443] Control: 0005317f Table: 1f224000 DAC: 0017 [633625.641295] Process swapper (pid: 0, stack limit = 0xc04c01b8) [633625.647241] Stack: (0xc04c1d50 to 0xc04c2000) [633625.657414] 1d40: 0008 d2788800 d27887fe d278887e [633625.666101] 1d60: d2788f40 df04e000 df00dc00 df2e0c00 0078 bf501028 df2e0c00 dfba3120 [633625.675025] 1d80: d278882a df04e9a0 bf504110 dfb3ce20 0201 00084502 [633625.683954] 1da0: 0001 df2e0c00 dfba3120 0008 0002 c04c1df4 0001 [633625.693553] 1dc0: 006a bf5058b0 c04c1df4 c04c1e30 dfba2300 c151ff18 df04e9a0 [633625.702041] 1de0: c04c1e30 bf37560c 000c 4288 c04c1e2c c151ff18 006a df2e0c00 [633625.710540] 1e00: dfba2300 006a df04e462 0001 6013 bf375760 [633625.718904] 1e20: 0001 c14c19a0 c14c0460 c04c1e30 c04c1e30 dfba2300 [633625.727374] 1e40: df04e460 c151fc00 de5af200 0002 0002 dfba2300 dfba2308 dfba28a8 [633625.787263] 1e60: c04c1e7c dfba28ac df2e0c00 bf376d58 c0508ae0 012c 0080 [633625.798914] 1e80: 03c66eab c0508ae8 c04d4c68 c04d3494 0006 0100 [633625.810249] 1ea0: c052b3a0 0009 c052b3c0 c0026e2c 0001 0018 c04c c0026644 [633625.818620] 1ec0: c04d8f74 c1484260 1144b25a c04d8f74 0020 c04c1f4c 0013 [633625.831230] 1ee0: fed20200 c04c1f4c 56251311 c04d0420 c0026a2c [633625.842695] 1f00: 2000 c000f28c c004e27c c0271318 2013 c000df94 c04c1f60 6013 [633625.853824] 1f20: 000e32dc 0002404f b5def004 0002404f c04d0698 56251311 [633625.864745] 1f40: c04d0420 0003 c04c1f60 c004e27c c0271318 2013 [633625.875714] 1f60: b5ed22e0 0002404f 0084d405 c04d0698 c04d0698 [633625.886646] 1f80: c04d0420 004b8074 c0270e88 c04d0698 c050918c c0271014 [633625.898317] 1fa0: c04c c0509b28 c04cc1cc c096f0e0 4000 c000f484 c04c8c20 [633625.909787] 1fc0: c04b9650 c0498764 c0498284 c04b9650 [633625.918159] 1fe0: 00053175 c04c8048 c04b964c c04cc1c4 8040 [633625.926557] [c0282990] (skb_push+0x6c/0x84) from [bf501028] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) [633625.937158] [bf501028] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) from [bf504110] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) [633625.949877] [bf504110] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) from [bf5058b0] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) [633625.961458] [bf5058b0] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) from [bf37560c] (__ieee80211_tx+0x210/0x2a8 [mac80211]) [633625.972695] [bf37560c] (__ieee80211_tx+0x210/0x2a8 [mac80211]) from [bf375760] (ieee80211_tx+0xbc/0xc4 [mac80211]) [633625.983816] [bf375760] (ieee80211_tx+0xbc/0xc4 [mac80211]) from [bf376d58] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) [633625.995326] [bf376d58] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) from [c0026e2c] (tasklet_action+0x84/0xcc) [633626.005905] [c0026e2c] (tasklet_action+0x84/0xcc) from [c0026644] (__do_softirq+0xdc/0x204) [633626.014750] [c0026644] (__do_softirq+0xdc/0x204) from [c0026a2c] (irq_exit+0x40/0x8c) [633626.023103] [c0026a2c] (irq_exit+0x40/0x8c) from [c000f28c] (handle_IRQ+0x64/0x84) [633626.031193] [c000f28c] (handle_IRQ+0x64/0x84) from [c000df94]
[ath9k-devel] [PATCH RFC] Re: skb_under_panic in ath9k
Am 26.05.2013 08:20, schrieb Oleksij Rempel: Am 24.05.2013 10:47, schrieb Marc Kleine-Budde: added ath9k-devel to Cc On 05/23/2013 12:02 AM, Marc Kleine-Budde wrote: Hello, I'm on a kirkwood based armv5 system with an USB attached TP-Link TL-WN821N - Atheros AR7010+AR9287, [1]. the wlan is running in AP mode with hostapd-1.0. The kernel is v3.8.12 from debian (3.8-1-kirkwood #1 Debian 3.8.12-1). The system crashes repeatedly after about one week with the following oops: [633625.401875] skbuff: skb_under_panic: text:bf501028 len:128 put:8 head:d2788800 data:d27887fe tail:0xd278887e end:0xd2788f40 dev:wlan1 [633625.414180] [ cut here ] [633625.418909] kernel BUG at /build/buildd-linux_3.8.12-1-armel-7F6kBx/linux-3.8.12/net/core/skbuff.c:145! [633625.428430] Internal error: Oops - BUG: 0 [#1] ARM [633625.433322] Modules linked in: [...] [633625.583170] CPU: 0Not tainted (3.8-1-kirkwood #1 Debian 3.8.12-1) [633625.589821] PC is at skb_push+0x6c/0x84 [633625.593763] LR is at skb_push+0x6c/0x84 [633625.597707] pc : [c0282990]lr : [c0282990]psr: 2013 [633625.597707] sp : c04c1d50 ip : 08f8 fp : df04ea54 [633625.609404] r10: 0002 r9 : 0008 r8 : df00dca8 [633625.614734] r7 : 0006 r6 : c04410a0 r5 : d278887e r4 : d2788800 [633625.621378] r3 : c04d328c r2 : 2093 r1 : 0001 r0 : 0079 [633625.628015] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [633625.635443] Control: 0005317f Table: 1f224000 DAC: 0017 [633625.641295] Process swapper (pid: 0, stack limit = 0xc04c01b8) [633625.647241] Stack: (0xc04c1d50 to 0xc04c2000) [633625.657414] 1d40: 0008 d2788800 d27887fe d278887e [633625.666101] 1d60: d2788f40 df04e000 df00dc00 df2e0c00 0078 bf501028 df2e0c00 dfba3120 [633625.675025] 1d80: d278882a df04e9a0 bf504110 dfb3ce20 0201 00084502 [633625.683954] 1da0: 0001 df2e0c00 dfba3120 0008 0002 c04c1df4 0001 [633625.693553] 1dc0: 006a bf5058b0 c04c1df4 c04c1e30 dfba2300 c151ff18 df04e9a0 [633625.702041] 1de0: c04c1e30 bf37560c 000c 4288 c04c1e2c c151ff18 006a df2e0c00 [633625.710540] 1e00: dfba2300 006a df04e462 0001 6013 bf375760 [633625.718904] 1e20: 0001 c14c19a0 c14c0460 c04c1e30 c04c1e30 dfba2300 [633625.727374] 1e40: df04e460 c151fc00 de5af200 0002 0002 dfba2300 dfba2308 dfba28a8 [633625.787263] 1e60: c04c1e7c dfba28ac df2e0c00 bf376d58 c0508ae0 012c 0080 [633625.798914] 1e80: 03c66eab c0508ae8 c04d4c68 c04d3494 0006 0100 [633625.810249] 1ea0: c052b3a0 0009 c052b3c0 c0026e2c 0001 0018 c04c c0026644 [633625.818620] 1ec0: c04d8f74 c1484260 1144b25a c04d8f74 0020 c04c1f4c 0013 [633625.831230] 1ee0: fed20200 c04c1f4c 56251311 c04d0420 c0026a2c [633625.842695] 1f00: 2000 c000f28c c004e27c c0271318 2013 c000df94 c04c1f60 6013 [633625.853824] 1f20: 000e32dc 0002404f b5def004 0002404f c04d0698 56251311 [633625.864745] 1f40: c04d0420 0003 c04c1f60 c004e27c c0271318 2013 [633625.875714] 1f60: b5ed22e0 0002404f 0084d405 c04d0698 c04d0698 [633625.886646] 1f80: c04d0420 004b8074 c0270e88 c04d0698 c050918c c0271014 [633625.898317] 1fa0: c04c c0509b28 c04cc1cc c096f0e0 4000 c000f484 c04c8c20 [633625.909787] 1fc0: c04b9650 c0498764 c0498284 c04b9650 [633625.918159] 1fe0: 00053175 c04c8048 c04b964c c04cc1c4 8040 [633625.926557] [c0282990] (skb_push+0x6c/0x84) from [bf501028] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) [633625.937158] [bf501028] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) from [bf504110] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) [633625.949877] [bf504110] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) from [bf5058b0] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) [633625.961458] [bf5058b0] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) from [bf37560c] (__ieee80211_tx+0x210/0x2a8 [mac80211]) [633625.972695] [bf37560c] (__ieee80211_tx+0x210/0x2a8 [mac80211]) from [bf375760] (ieee80211_tx+0xbc/0xc4 [mac80211]) [633625.983816] [bf375760] (ieee80211_tx+0xbc/0xc4 [mac80211]) from [bf376d58] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) [633625.995326] [bf376d58] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) from [c0026e2c] (tasklet_action+0x84/0xcc) [633626.005905] [c0026e2c] (tasklet_action+0x84/0xcc) from [c0026644] (__do_softirq+0xdc/0x204) [633626.014750] [c0026644] (__do_softirq+0xdc/0x204) from [c0026a2c] (irq_exit+0x40/0x8c) [633626.023103] [c0026a2c] (irq_exit+0x40/0x8c) from [c000f28c] (handle_IRQ+0x64/0x84) [633626.031193] [c000f28c] (handle_IRQ+0x64/0x84) from [c000df94] (__irq_svc+0x34/0x78) [633626.039412] [c000df94] (__irq_svc+0x34/0x78) from [c0271318
Re: [ath9k-devel] [PATCH 0/3] Work on STBC Rx monitoring
Any updates here? can some one please apply last two patches? Felix? Am 19.05.2013 09:38, schrieb Oleksij Rempel: This patch set will pass RxSTBC flags from ath9k to ieee80211 and to radiotap. This field is now a part of radiotap specification: http://www.radiotap.org/defined-fields/MCS Oleksij Rempel (3): mac80211: add STBC flag for radiotap ath9k: remove useless flag conversation. ath9k: check for Rx-STBC flag and pass it to ieee80211 drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++-- drivers/net/wireless/ath/ath9k/mac.c| 16 drivers/net/wireless/ath/ath9k/mac.h| 4 +++- drivers/net/wireless/ath/ath9k/recv.c | 5 + include/net/ieee80211_radiotap.h| 7 +++ include/net/mac80211.h | 4 net/mac80211/main.c | 3 ++- net/mac80211/rx.c | 4 net/mac80211/status.c | 3 ++- 9 files changed, 38 insertions(+), 13 deletions(-) -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Tplink TL-WN822N drops out connections randomly on Arch Linux with Kernel 3.9.4
Am 31.05.2013 18:56, schrieb Mark E. Lee: I recently purchased a TPLINK TL-WN822N for my desktop running 64 bit Arch Linux. For some reason, the connection drops out every now and then (it is especially evident during Skype calls). I have run skype on ethernet and have not been able to replicate this problem using ethernet. In addition, I have run the usb wifi adapter in Windows 8 without any issues. Anyone got any advice on how to fix the issue? From, Mark Hi Mark, please provide dmesg and usbid of this device. There are different versions of TL-WN822N. Which one do you have? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Tplink TL-WN822N drops out connections randomly on Arch Linux with Kernel 3.9.4 (Mark Lee)
Am 01.06.2013 19:00, schrieb Mark E. Lee: output of lsusb : Bus 006 Device 003: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010 +AR9287] Wireless N USb adapter has a version 2.0 label though. I have attached my dmesg. I have same adapter, here are images of it: http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2 but i don't have this problem. It will be interesting to have more information: - please send output of sudo iw dev wlan0 scan dump - information about your access point. if possible name of wireless chip in it. you can link it with wikidevi.com - do you use power_save mode? you can check it with iw dev wlan0 get power_save -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Tplink TL-WN822N drops out connections randomly on Arch Linux with Kernel 3.9.4 (Mark Lee)
Can you please do some test: - disable STBC on access point. You will probably need to edit hostapd.conf manually. - change or disable encryption type. Am 02.06.2013 18:39, schrieb Mark E. Lee: Access Point Firmware: DD-WRT v24-sp2 (03/19/12) std Access Point Hardware: netgear-wnr2000v3 Output of # iw dev wlan0 get power_save : Power save: off Output of $ iw dev wlan0 scan dump : Attached log file (unix ending) On Sun, 2013-06-02 at 12:00 +0200, ath9k-devel-requ...@lists.ath9k.org wrote: Send ath9k-devel mailing list submissions to ath9k-devel@lists.ath9k.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.ath9k.org/mailman/listinfo/ath9k-devel or, via email, send a message with subject or body 'help' to ath9k-devel-requ...@lists.ath9k.org You can reach the person managing the list at ath9k-devel-ow...@lists.ath9k.org When replying, please edit your Subject line so it is more specific than Re: Contents of ath9k-devel digest... Today's Topics: 1. Re: Tplink TL-WN822N drops out connections randomly on Arch Linux with Kernel 3.9.4 (Mark Lee) (Oleksij Rempel) -- Message: 1 Date: Sat, 01 Jun 2013 19:22:22 +0200 From: Oleksij Rempel li...@rempel-privat.de Subject: Re: [ath9k-devel] Tplink TL-WN822N drops out connections randomly on Arch Linux with Kernel 3.9.4 (Mark Lee) To: ath9k-devel@lists.ath9k.org Message-ID: 51aa2dce.20...@rempel-privat.de Content-Type: text/plain; charset=UTF-8; format=flowed Am 01.06.2013 19:00, schrieb Mark E. Lee: output of lsusb : Bus 006 Device 003: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010 +AR9287] Wireless N USb adapter has a version 2.0 label though. I have attached my dmesg. I have same adapter, here are images of it: http://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2 but i don't have this problem. It will be interesting to have more information: - please send output of sudo iw dev wlan0 scan dump - information about your access point. if possible name of wireless chip in it. you can link it with wikidevi.com - do you use power_save mode? you can check it with iw dev wlan0 get power_save ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH v4 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
This patch make use of STBC flag in DMA RX descriptor.
Only devices after ar9280 can provide this information.
If card support it we will set HAVE_STBC flag, to show
clint programm thet STBC is supported but not received.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/init.c | 10 --
drivers/net/wireless/ath/ath9k/mac.c | 5 +
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index aba4151..b9c97d4 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -21,6 +21,7 @@
#include linux/ath9k_platform.h
#include linux/module.h
#include linux/relay.h
+#include net/ieee80211_radiotap.h
#include ath9k.h
@@ -769,8 +770,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct
ieee80211_hw *hw)
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
IEEE80211_HW_SUPPORTS_RC_TABLE;
- if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT)
-hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+ if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT) {
+ hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ hw-radiotap_mcs_details |=
+ IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+ }
if (AR_SREV_9160_10_OR_LATER(sc-sc_ah) || ath9k_modparam_nohwcrypt)
hw-flags |= IEEE80211_HW_MFP_CAPABLE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..d055e38 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
(ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
rs-flag |=
(ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_STBC) ?
+ /* we can only Nss=1 STBC */
+ (1 RX_FLAG_STBC_SHIFT) : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
#define AR_2040 0x0002
#define AR_Parallel40 0x0004
#define AR_Parallel40_S 2
-#define AR_RxStatusRsvd30 0x00f8
+#define AR_STBC 0x0008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30 0x00f0
#define AR_RxAntenna 0xff00
#define AR_RxAntenna_S 8
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 0/2] ath9k: add STBC Rx flags (repost untill some one asnwers)
One more repost of old patches. I need, please, at least some kind of answer: we don't wont patches from you or you are doing some thing wrong. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH 1/2] ath9k: remove useless flag conversation.
some flags used only outside of ath9k - In this case we can use
enum mac80211_rx_flags and pass it upstream without extra
conversation.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/mac.c| 11 +++
drivers/net/wireless/ath/ath9k/mac.h| 1 +
drivers/net/wireless/ath/ath9k/recv.c | 5 +
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_status = 0;
rxs-rs_flags = 0;
+ rxs-flag = 0;
rxs-rs_datalen = rxsp-status2 AR_DataLen;
rxs-rs_tstamp = rxsp-status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct
ath_rx_status *rxs,
rxs-rs_isaggr = (rxsp-status11 AR_RxAggr) ? 1 : 0;
rxs-rs_moreaggr = (rxsp-status11 AR_RxMoreAggr) ? 1 : 0;
rxs-rs_antenna = (MS(rxsp-status4, AR_RxAntenna) 0x7);
- rxs-rs_flags = (rxsp-status4 AR_GI) ? ATH9K_RX_GI : 0;
- rxs-rs_flags |= (rxsp-status4 AR_2040) ? ATH9K_RX_2040 : 0;
+ rxs-flag |= (rxsp-status4 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rxs-flag |= (rxsp-status4 AR_2040) ? RX_FLAG_40MHZ : 0;
rxs-evm0 = rxsp-status6;
rxs-evm1 = rxsp-status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc
*ds,
rs-rs_status = 0;
rs-rs_flags = 0;
+ rs-flag = 0;
rs-rs_datalen = ads.ds_rxstatus1 AR_DataLen;
rs-rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct
ath_desc *ds,
rs-rs_moreaggr =
(ads.ds_rxstatus8 AR_RxMoreAggr) ? 1 : 0;
rs-rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
- rs-rs_flags =
- (ads.ds_rxstatus3 AR_GI) ? ATH9K_RX_GI : 0;
- rs-rs_flags |=
- (ads.ds_rxstatus3 AR_2040) ? ATH9K_RX_2040 : 0;
+
+ /* directly mapped flags for ieee80211_rx_status */
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rs-flag |=
+ (ads.ds_rxstatus3 AR_2040) ? RX_FLAG_40MHZ : 0;
if (ads.ds_rxstatus8 AR_PreDelimCRCErr)
rs-rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h
b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
u32 evm2;
u32 evm3;
u32 evm4;
+ u32 flag; /* see enum mac80211_rx_flags */
};
struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
if (rx_stats-rs_rate 0x80) {
/* HT rate */
rxs-flag |= RX_FLAG_HT;
- if (rx_stats-rs_flags ATH9K_RX_2040)
- rxs-flag |= RX_FLAG_40MHZ;
- if (rx_stats-rs_flags ATH9K_RX_GI)
- rxs-flag |= RX_FLAG_SHORT_GI;
+ rxs-flag |= rx_stats-flag;
rxs-rate_idx = rx_stats-rs_rate 0x7f;
return 0;
}
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 0/2] ath9k: add STBC Rx flags (repost untill some one asnwers)
Am 03.06.2013 11:59, schrieb Sujith Manoharan: Oleksij Rempel wrote: One more repost of old patches. I need, please, at least some kind of answer: we don't wont patches from you or you are doing some thing wrong. Both the patches have already been merged in wireless-testing. ah... i didn't noticed that. thank you ;) commit b0a1ae976d6cd40ff90ba87883e17eb2610dae3d Author: Oleksij Rempel li...@rempel-privat.de Date: Fri May 24 20:30:59 2013 +0200 ath9k: check for Rx-STBC flag and pass it to ieee80211 This patch make use of STBC flag in DMA RX descriptor. Only devices after ar9280 can provide this information. If card support it we will set HAVE_STBC flag, to show clint programm thet STBC is supported but not received. Signed-off-by: Oleksij Rempel li...@rempel-privat.de Signed-off-by: John W. Linville linvi...@tuxdriver.com commit ab276103357637fb26cc851369b5abbdc42afbf4 Author: Oleksij Rempel li...@rempel-privat.de Date: Fri May 24 12:18:30 2013 +0200 ath9k: remove useless flag conversation. some flags used only outside of ath9k - In this case we can use enum mac80211_rx_flags and pass it upstream without extra conversation. Signed-off-by: Oleksij Rempel li...@rempel-privat.de Signed-off-by: John W. Linville linvi...@tuxdriver.com Sujith -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k_htc: fix skb_under_panic error
This error seems to be really rare, and we do not know real couse of it.
But, in any case, we should check size of head before reducing it.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
Reported-by: Marc Kleine-Budde m...@blackshift.org
---
drivers/net/wireless/ath/ath9k/htc_hst.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.c
b/drivers/net/wireless/ath/ath9k/htc_hst.c
index aac4a40..2901351 100644
--- a/drivers/net/wireless/ath/ath9k/htc_hst.c
+++ b/drivers/net/wireless/ath/ath9k/htc_hst.c
@@ -26,6 +26,12 @@ static int htc_issue_send(struct htc_target *target, struct
sk_buff* skb,
struct htc_endpoint *endpoint = target-endpoint[epid];
int status;
+ if (skb_headroom(skb) len
+ pskb_expand_head(skb, len, 0, GFP_ATOMIC)) {
+ dev_err(target-dev, Unable to expand headrom to %d\n, len);
+ return -ENOMEM;
+ }
+
hdr = (struct htc_frame_hdr *)
skb_push(skb, sizeof(struct htc_frame_hdr));
hdr-endpoint_id = epid;
--
1.8.1.2
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k_htc: fix skb_under_panic error
Am 05.06.2013 16:26, schrieb Marc Kleine-Budde: On 06/05/2013 04:24 PM, Helmut Schaa wrote: On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel li...@rempel-privat.de wrote: This error seems to be really rare, and we do not know real couse of it. But, in any case, we should check size of head before reducing it. Mind to try the (completely untested) patch against wireless-testing instead? Helmut I will do, however I'm not in range of that USB wireless adapter for about 1,5 weeks. Helmut, thank you for patch! i'll do regression test, but not week long test. So i probably won't reproduce this issue. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
