Janusz Dziedzic wrote:
Add p2p dev support when ath9k loaded with
use_chanctx=1. This will fix problem, when first
interface is an AP and next we would like to run
p2p_find. Before p2p scan failed.
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
@Felix, Sujith please review.
Janusz Dziedzic wrote:
case ATH_OFFCHANNEL_ROC_START:
+ /* Allow to receive probe requests */
+ rfilt = ath_calcrxfilter(sc);
+ rfilt |= ATH9K_RX_FILTER_PROBEREQ;
+ ath9k_hw_setrxfilter(sc-sc_ah, rfilt);
+
Janusz Dziedzic wrote:
At least the callbacks for adding/removing interfaces need
to be handled ?
Strange, but I didn't hit any problem yet with my simple patch.
Ok. But I am not very familiar with how p2p-device is supposed
to be used...
Sujith
Arend van Spriel wrote:
The p2p-device is designed to be used for p2p discovery and p2p action
frame exchange. It make it easier for driver and/or firmware to
determine if user-space request is p2p related or not. However, in
discussions with Jouni I got the impression that ath (or qca)
Bob Copeland wrote:
Ok, got it, so if I have a need to wake up for beacons from multiple
APs with different TSFs, then autosleep probably wouldn't work for me?
(I already implemented what I need with the TIM_TIMER on these chips,
just asking to confirm my understanding.)
I think so, I haven't
Bob Copeland wrote:
So I'm still missing the part where we wake hardware up on this version.
It seemed to work for me though.
Sorry, I was referring to the PS mechanism on chips which don't
support autosleep.
For autosleep, no special handling in the driver is required
except the initial
Adrian Chadd wrote:
I'm still debugging some of the sleep stuff with the AR9380 on
FreeBSD. The later chips do the right thing, but the AR9380 beacon
programming for /some/ reason is not hearing beacons in network sleep
mode and eventually the BMISS interrupts cause a rescan/reassociation.
IT
Frank Zafka wrote:
As per suggestions, I tried modprobe -r ehci_hcd. No difference I'm
afraid. I have another laptop with almost identical hardward (acer
1810tz) and I recently installed the very same wifi card. I tested
suspend on that last night and it didn't experience any significant
Adrian Chadd wrote:
Sujith - do you have access to the PCIe breakout stuff at QCA?
Something that we can use to measure the current draw of the NIC?
Nope, no access.
I asked internally if using a card that has been reworked for WOW
support can be used on a different mainboard - didn't get any
Adrian Chadd wrote:
Maybe leaving WOW enabled is leaving the PCIe PHYs online and active?
And/or USB/bluetooth?
It has to be drawing significant current for it to flatten the battery
whilst suspended, so my guess is that quite a large chunk of the
hardware between the NIC and the battery is
Sujith Manoharan wrote:
Frank Zafka wrote:
02:00.0 Network controller [0280]: Qualcomm Atheros AR9462 Wireless
Network Adapter [168c:0034] (rev 01)
Subsystem: Lenovo Device [17aa:3214]
Was this card obtained from a different machine ?
From an earlier email, your machine is Acer ?
I think
From: Sujith Manoharan c_man...@qca.qualcomm.com
AIC needs to be registered only when BTCOEX is enabled.
This fixes the error reported by kbuild:
ERROR: ar9003_hw_attach_aic_ops
[drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
Frank Zafka wrote:
So has anyone got any good ideas on how to proceed with this issue?
I have an AR9565 card which also appears to show similar behavior.
The rate of power drain is slower, but the battery does reach zero
capacity after suspend. WOW is enabled on this machine/chip too.
Frank Zafka wrote:
02:00.0 Network controller [0280]: Qualcomm Atheros AR9462 Wireless
Network Adapter [168c:0034] (rev 01)
Subsystem: Lenovo Device [17aa:3214]
This card supports WOWLAN and is a BT combo device. Maybe
ath9k is missing something in the suspend path.
Can you check if unloading
Frank Zafka wrote:
Hello. Looking for some advice regarding a massive powerdrain during
suspend caused by the wifi card.
I have a new Atheros AR9462 connected to my n-wireless network.
Everything works fine. I put the computer into suspend (shut lid) and
everything goes as expected. However
Saurabh Pal wrote:
Just wanted to know whether it is possible to switch the channel without
resetting the chip. Also if possible can anybody tell me how much time it
takes to switch the channel by resetting the chip?
Fast Channel Change is used to switch channels without a full chip reset.
The
From: Sujith Manoharan c_man...@qca.qualcomm.com
This patch adds a function to handle the
MCI message MCI_STATE_AIC_START.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 33 +
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
This patch adds support for post-processing
the AIC calibration results.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 245
1 file changed, 245 insertions
From: Sujith Manoharan c_man...@qca.qualcomm.com
Add the main AIC calibration function to
handle MCI_STATE_AIC_CAL.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 28 ++--
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
When a MCI reset is done, make sure that AIC
is started.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_mci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath
From: Sujith Manoharan c_man...@qca.qualcomm.com
Since various MCI messages need to be
handled, along with driver-level support
in upper layers, disable AIC for now.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 6 ++
drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
Set the appropriate bits in the HW after
AIC calibration is done.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 78 -
1 file changed, 77 insertions(+), 1
From: Sujith Manoharan c_man...@qca.qualcomm.com
Add a routine to handle the MCI_STATE_AIC_CAL_RESET
message.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 8
drivers/net/wireless/ath/ath9k/ar9003_aic.h | 1 +
drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
Various registers to control and check AIC
status.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 1 +
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 25 -
drivers/net/wireless
From: Sujith Manoharan c_man...@qca.qualcomm.com
This patch adds routines to handle the MCI
message AIC_CAL_SINGLE, starting the required
HW calibration.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 169
From: Sujith Manoharan c_man...@qca.qualcomm.com
AIC can be disabled or enabled on a per-card
basis using MCI configuration, so register a function
to check its status.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/Makefile | 3 ++-
drivers
From: Sujith Manoharan c_man...@qca.qualcomm.com
These are necessary for implementing AIC,
supported by chips like WB222.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.h | 49 +
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
AIC support, for -next.
v2 : Address warning reported by Kalle:
ar9003_aic.c: In function 'ar9003_aic_cal_post_process':
ar9003_aic.c:431:1: warning: the frame size of 1312 bytes is larger than
1024 bytes [-Wframe-larger-than=]
Sujith
From: Sujith Manoharan c_man...@qca.qualcomm.com
This patch adds a function to handle the
MCI message MCI_STATE_AIC_START.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 33 +
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
More support for AIC, for -next.
Sujith Manoharan (4):
ath9k: Handle MCI_STATE_AIC_CAL_RESET
ath9k: Handle MCI_STATE_AIC_START
ath9k: Handle MCI_STATE_AIC_CAL
ath9k: Start AIC calibration during MCI reset
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
When a MCI reset is done, make sure that AIC
is started.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_mci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath
From: Sujith Manoharan c_man...@qca.qualcomm.com
Add a routine to handle the MCI_STATE_AIC_CAL_RESET
message.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 8
drivers/net/wireless/ath/ath9k/ar9003_aic.h | 1 +
drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
Add the main AIC calibration function to
handle MCI_STATE_AIC_CAL.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 28 ++--
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
AIC can be disabled or enabled on a per-card
basis using MCI configuration, so register a function
to check its status.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/Makefile | 3 ++-
drivers
From: Sujith Manoharan c_man...@qca.qualcomm.com
These are necessary for implementing AIC,
supported by chips like WB222.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.h | 49 +
drivers/net/wireless/ath/ath9k
From: Sujith Manoharan c_man...@qca.qualcomm.com
Various registers to control and check AIC
status.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 1 +
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 25 -
drivers/net/wireless
Hi Kalle,
Sorry, I forgot to mention that this is intended for -next.
Sujith
Sujith Manoharan wrote:
From: Sujith Manoharan c_man...@qca.qualcomm.com
This series adds initial support for AIC.
Active Interference Cancellation is a method
implemented in the HW to counter WLAN RX
From: Sujith Manoharan c_man...@qca.qualcomm.com
This series adds initial support for AIC.
Active Interference Cancellation is a method
implemented in the HW to counter WLAN RX
sensitivity degradation when BT is transmitting
at the same time. This feature is supported by
cards like WB222 based
From: Sujith Manoharan c_man...@qca.qualcomm.com
This patch adds routines to handle the MCI
message AIC_CAL_SINGLE, starting the required
HW calibration.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 169
From: Sujith Manoharan c_man...@qca.qualcomm.com
Set the appropriate bits in the HW after
AIC calibration is done.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 78 -
1 file changed, 77 insertions(+), 1
From: Sujith Manoharan c_man...@qca.qualcomm.com
This patch adds support for post-processing
the AIC calibration results.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 245
1 file changed, 245 insertions
Jouni Malinen wrote:
Even I think that this goes a bit too far especially on 2.4 GHz band,
but I would actually consider limiting EAPOL frames to using non-HT/VHT
(e.g., 6 Mbps OFDM at least for EAPOL-Key frames) to avoid some
interoperability issues. I would say that the current minstrel_ht
Linus Torvalds wrote:
14:07:23.542927: wlp1s0: Event DEAUTH (12) received
14:07:23.542946: wlp1s0: Deauthentication notification
14:07:23.542964: wlp1s0: * reason 2
14:07:23.542982: wlp1s0: * address 20:9f:db:e7:80:80
14:07:23.542997: Deauthentication frame IE(s) - hexdump(len=0): [NULL]
Sujith Manoharan wrote:
'iw dev wlp1s0 set bitrates ht-mcs-2.4 1' would choose a lower
rate for the key-exchange frames.
Or 'iw dev wlp1s0 set bitrates ht-mcs-2.4 0' to choose the lowest
HT rate.
Sujith
___
ath9k-devel mailing list
ath9k-devel
Linus Torvalds wrote:
I've got the wpa supplicant log for this timeframe, but I'd rather not
send it out in public. I see [REMOVED] for what looks like the key
data, but there's a lot of other hex data. Is any of it sensitive?
Unless the '-K' option is used with wpa_s, the keys are not
Linus Torvalds wrote:
So I've had problems connecting to some networks before on my
Chromebook Pixel, but now I'm testing a new Ubiquiti network at home,
and can see this issue at home too.
Can you please post the output of 'iw dev wlp1s0 scan' ?
Sujith
Adrian Chadd wrote:
It's already doing MIMO diversity. If you have a chainmask that has 2
or more antennas enabled it already is doing it.
I think that variable is slow antenna diversity, not MIMO diversity.
It's for LNA diversity - 1x1 chips like AR9485, AR9565 etc.
Sujith
Sekou DIAKITE wrote:
How do I find the firmware filename/path ?
The ath3k firmware is usually in /lib/firmware/ar3k
Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ 22.294028] hid-generic 0005:046D:B008.0002: input,hidraw1:
BLUETOOTH HID v3.18 Mouse [Bluetooth Laser Travel Mouse] on
10:08:b1:c7:88:62
2015-01-13 23:07 GMT+01:00 Sujith Manoharan suj...@msujith.org:
Sekou DIAKITE wrote:
I've installed the latest backport driver and added
Sekou DIAKITE wrote:
[9.918557] Bluetooth: Error in firmware loading err = -110,len = 448,
size = 4096
[9.918572] Bluetooth: Loading patch file failed
[9.918584] ath3k: probe of 2-5:1.0 failed with error -110
The errno corresponds to -ETIMEDOUT, not sure why the ath3k fw fails to
Jeremy wrote:
It looks like the firmware needed has changed, at least the file names
This bug report https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1383184
The lsusb shows: Bus 001 Device 003: ID 0cf3:3004 Atheros Communications, Inc,
which is supported but the dmesg shows:
Sekou DIAKITE wrote:
I've installed the latest backport driver and added the btcoex_enable=1.
It doesn't change the behavior (bluetooth works only after a reboot
from Windows).
From the askubuntu page, 0489:e076 is the USB ID for your card.
It doesn't appear to be present in the kernel and I
Sekou DIAKITE wrote:
Hello,
I have some troubles making my bluetooth device work on Ubutun 14.10
(Kernel: 3.16.0-29-generic, linux-firmware* installed).
Can you install the latest backports driver ?
https://backports.wiki.kernel.org/index.php/Main_Page
Arend van Spriel wrote:
So the content of the modified debugfs files looks sane?
Yep, as sane as the code populating the debug data. :-)
Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
Arend van Spriel ar...@broadcom.com writes:
Use the helper to get rid of the file operations per debugfs file. The
device driver data contains struct ieee80211_hw pointer and the
struct ath9k_softc pointer is assigned to ieee80211_hw::priv so it can
be accessed in the seq_file read
杨铁军 wrote:
Does somebody know where I could download AR9580 driver for Kernel 2.26.31?
Linux backports: https://backports.wiki.kernel.org/index.php/Main_Page
2.6.31 is not supported by the latest releases.
Sujith
___
ath9k-devel mailing list
Tony Kitzky wrote:
How can I disable BT on AR9462 chip in Ubuntu kernel
I am looking for a way to disable the bluetooth capabilities on the Atheros
AR9462 chipset in Ubuntu. I am having problems getting BT to work properly. I
have a cheap USB BT adapter that works but it conflicts with BT on
Yahia Shabara wrote:
I am doing an experiment that involves implementing a proposed channel access
scheme and I need to enable or disable physical spectrum sensing in a dynamic
manner. In addition to disabling the back-off time intended for collision
avoidance since my experiment and system
Hubert Feurstein wrote:
Well, in fact it does. To understand my post you have to know the
behaviour of ath_txq_setup. The point here is that on the first call
of ath_txq_setup(..ATH9K_TX_QUEUE_DATA..), hw-queue 0 is returned. On
the second call hw-queue 1 is returned, ... . And IEEE80211_AC_VO
John W. Linville wrote:
Any word from the ath9k posse?
Looks good to me...
Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Giuseppe Torelli wrote:
Bus 001 Device 003: ID 04ca:300b Lite-On Technology Corp.
Device Descriptor:
idVendor 0x04ca Lite-On Technology Corp.
idProduct 0x300b
Support for this card appears to be already present in the
ath3k bluetooth driver since v3.14 kernel. You
Giuseppe Torelli wrote:
I have an ACER E1-570 whose bluetooth is not working:
t@Aspire-E1-570 ~ $ hcitool dev
Devices:
hci0 48:D2:24:D6:C7:34
gt@Aspire-E1-570 ~
t@Aspire-E1-570 ~ $ uname -a
Linux Aspire-E1-570 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC
2014 x86_64
Channel
Capabilities: [128] Power Budgeting ?
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 ?
Kernel driver in use: nouveauOn Monday, November 3, 2014, Sujith Manoharan
suj...@msujith.org wrote:
Jeremy whocares wrote:
A windows inf file shows 13d3:3408
Jeremy whocares wrote:
A windows inf file shows 13d3:3408 as VID_13D3PID_3408 = Qualcomm Atheros
Bluetooth 4.0 + HS
The wifi combo card is QCWB335
Can you please post the output of /sys/kernel/debug/usb/devices ?
Also 'sudo lspci -vnn'.
Sujith
Joris Guisson wrote:
I recently purchased an MSI GT 72 gaming laptop with a killer n1525 wifi card
in it. The wifi didn't work, so I took a look at the latest kernel release
(3.18-rc3), and it seems there is no support in it for the card. I didn't find
the PCI device id (0x003e) listed in any
Oleksij Rempel wrote:
Should ask some one from QCA,
i have no idea who is still working there. Sujith, may be you know?
Nope, this is not run by QCA. I think someone from madwifi is the admin.
Luis, who runs this list these days ?
Sujith
___
Tsaixiong wrote:
I am trying to get RTS/CTS and ACK frame in mac80211 or ath9k in order to
make
sure the receiver and transimitter and duration of next data frame .but i
cannot get them correctly,have you solved this problem,any reply will be much
apprecited !!
Control bit
Charounson Saintilus wrote:
Could you provide a high level explanation of the bluetooth co-existence
algorithm that's implemented in the ath9k driver. I am particularly interested
in the file structure and the algorithm itself. Is this solely for co-located
bluetooh and wi-fi or does the
Ben Greear wrote:
Took a while, but I found the regression that has been bugging me.
This is on stock kernel, with hand-patched fixup from Felix that fixes
crash related to minstrel (patch made it upstream later, so that isn't
a current problem).
The test case is easily reproducible on my
Charounson Saintilus wrote:
Essentially, I would like to use the table to learn how the various rates are
represented. Say I wanted to force the driver to use 6.5 Mb/s for all data
frames it transmits. I'd like to initialize info-rates[i].Rate = in xmit.c
, but what are the possible options?
Charounson Saintilus wrote:
Thank you for the response!! What I would actually like to do is to modify the
driver code and recompile the kernel. Any idea as to how I might go about
modifying (hard-coding) the data rate within the driver code and then
recompiling the kernel or just the ath9k
Charounson Saintilus wrote:
Forgive me, I am new to driver development. I am working on a project
which requires me to modify the data rate of the ath9k driver. It can be
found at kernel-top-directory/drivers/net/wireless/ath/ath9k. For testing
purposes, it's necessary to set the data rate
Ben Greear wrote:
Thanks, that must be this thread:
http://comments.gmane.org/gmane.linux.kernel.wireless.general/84459
I think that explains much of my confusion. I too would like a way to
really disable RTS for testing. On a mostly quiet channel, sending UDP
frames one way, I still
Adrien Decostre wrote:
Would you know if there exists an open software tool to trigger the tests
required for EN 300 328 v1.8.1.
As far as I know, Atheros has developed the ART tool but this is not open
source software. Is there any alternative for ath9k?
I am not sure. But, maybe the ART
Dave Taht wrote:
cc-ing ath9k-devel for this update on http://www.bufferbloat.net/issues/442
this bug, which some people (usually on macs with low signal strength)
can get to occur fairly rapidly, but I can't, is driving me 9 kinds of
crazy...
Does stock OpenWrt also have this bug, or is
Lorenzo Bianconi wrote:
+/*
+ * Copyright 2014, Lorenzo Bianconi lorenzo.biancon...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+
Yi-Hung Wei wrote:
I am doing some experiments about virtual carrier sense that I manipulate the
duration field in RTS/CTS frames. I manually inject CTS frames, set the
duration field to a specific number (i.e. 2000), and use a sniffer to monitor
those frames. However, the duration filed is
mahaveer gupta wrote:
Actually, Is there another way to pull out individual RSSI values from
individual antennas. which is what I am actually interested in.
One alternative I can think of is to set the rx-chain-mask to 1 and 2 to get
the RSSI from antenna 0 and 1 respectively. Wondering if
Adrien Decostre wrote:
I have read that a new ETSI regulation (EN 300 328 v.1.8.1) will become
mandatory from 31-12-2014 onwards.
I am wondering if the current ath9k driver is already compliant with this new
regulation?
Are the patches provided by Sujith Manoharan (“ath9k: Fix regulatory
From: Sujith Manoharan c_man...@qca.qualcomm.com
Along with AR9340 and AR955x, this is also needed for
the QCA953x SoC.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/ath9k/mac.c | 2 +-
2 files changed, 2
From: Sujith Manoharan c_man...@qca.qualcomm.com
The registers for temperature compensation need to
be programmed only for active chains. Use the TX chainmask
to make sure that this is done properly for QCA953x.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless
Oleksij Rempel wrote:
Last response was about initvals, my patch set affect only beacon code.
Since i don't plan to rewrite ath9k_htc from scratch, i would assume it
will be better to continue this periodic clean work.
I didn't review the patches, but someone else needs to make sure that
Mathy wrote:
You can abuse the NAV (virtual carrier sense) to prevent a station from
transmitting packets. I'm not aware of a method to force a station into sleep
mode.
A better way to stop transmission for sometime is to use the QUIET_TIME
feature that the chip supports. Check AR_QUIET1 in
Oleksij Rempel wrote:
I was thinking about it too, but suddenly i don't have enough time and
experience to do it. Beside, there is no need to write usb layer. It is
clean and separate from other part of the driver. But the HTC/WMI
interface is not completely separate.
Sure. It is just another
Adrian Chadd wrote:
The AR9287 is the first chip with a second TSF counter, designed to be
free-running and not be locked into the AP broadcast TSF. Ie, if you
wanted to be an AP and a STA, you'd have one TSF for the AP and one
TSF for the STA association. But I don't know how it all works in
Marco André Dinis wrote:
Could you point me to a link on how can I do that?
I found this:
http://blog.securism.com/2009/01/how-to-cutting-edge-wireless-drivers-in-ubuntu/
but not sure i can use it since it's using another repo.
backports is the easiest way to get the latest driver.
Felix Fietkau wrote:
Wouldn't it be better to do this for all AR93xx chipsets in
ar9003_hw_apply_minccapwr_thresh instead of initvals?
I'm pretty sure this patch will leave most other devices non-compliant.
The threshold values are adjusted for each chip and are not the same
for all chips in
Felix Fietkau wrote:
Almost all chips are using the same values in the initvals - the
exceptions seem to be the ones that have had ETSI compliance fix
attempts already. I'm pretty sure the new values (if adjusted for
different bands) would be fully compatible.
For most of the chips, adjusting
Joshua Richenhagen wrote:
Dear Sujith,
finally I found the real reason, ath3k fails to work approximately 2/3
of the time if btusb is connected to a pin which uses the xhci driver.
I compiled a dkms kernel package, with the help of a very nice
canonical employee, which switches the usb pin
From: Sujith Manoharan c_man...@qca.qualcomm.com
The minimum CCA power threshold values have to be adjusted
for existing cards to be in compliance with new regulations.
Newer cards will make use of the values obtained from EEPROM,
support for this was added earlier. To make sure that cards
Oleksij Rempel wrote:
what is about this change set? Should i resend it.
As long as it doesn't introduce any regression or behavioral change
in ath9k, they look good. :)
Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
Ben Greear wrote:
Can you let us know the details on how your set up that TCP
traffic? For instance, number of streams, write size, socket
buffer sizes, etc? Upload, download, or are both similar
throughput in your testing?
Stock OpenWrt (trunk) running on a 3x3 Scorpion board (AP136/AP135)
From: Sujith Manoharan c_man...@qca.qualcomm.com
Calibration data is not reused for SoC chips, so
call ar9003_hw_tx_iq_cal_post_proc() with the correct
argument. The 'is_reusable' flag is currently used
only for PC-OEM chips, but it makes things clearer to
specify it explicity.
Signed-off
From: Sujith Manoharan c_man...@qca.qualcomm.com
This series updates the IQ calibration code, fixing various
issues. There are still some more issues to be addressed.
Sujith Manoharan (7):
ath9k: Fix IQ cal post processing for SoC
ath9k: Check explicitly for IQ calibration
ath9k: Rename
From: Sujith Manoharan c_man...@qca.qualcomm.com
In chips like AR955x, the initvals contain the information
whether IQ calibration is to be done in the HW when an
AGC calibration is triggered. Check if IQ-CAL is enabled
in the initvals before flagging 'txiqcal_done' as true.
Signed-off
From: Sujith Manoharan c_man...@qca.qualcomm.com
Use ar9003_hw_tx_iq_cal_outlier_detection instead.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net
From: Sujith Manoharan c_man...@qca.qualcomm.com
Incorrect values are programmed in the registers
containing the IQ correction coefficients by the IQ-CAL
post-processing code. Fix this.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c
From: Sujith Manoharan c_man...@qca.qualcomm.com
This patch adds a routine to calculate the median IQ correction
values for AR955x, which is used for outlier detection.
The normal method which is used for all other chips is
bypassed for AR955x.
Signed-off-by: Sujith Manoharan c_man
From: Sujith Manoharan c_man...@qca.qualcomm.com
This will be used for storing data for mutiple
IQ calibration runs, for AR955x.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 41 ++-
1 file changed, 21
From: Sujith Manoharan c_man...@qca.qualcomm.com
The commit, ath9k_hw: Fix incorrect Tx control power in AR9003 template
fixed the incorrect values in the eeprom templates, but if
boards have already been calibrated with incorrect values,
they would still be using the wrong TX power. Fix
1 - 100 of 475 matches
Mail list logo
