[ath9k-devel] power save mode in ath9k driver
Hello, I am performing some tests with various wireless nics and an access point. I have a question about the driver: As far as I know, this driver does support power save mode. When the device enters power saving mode, it should send a control frame (beacon) with power management bit set to 1, to the access point it is associated with (I am talking about infrastructure network). When it exits power save mode, it should send PSPOLL frame to retrieve the frames that the AP had buffered for it. I tried to delve into the driver code and could not find the code which handles entering power save mode. Grepping for IEEE80211_FCTL_PM in the driver code did not find anything (IEEE80211_FCTL_PM is the power save mode bit in a control frame). (I am looking at the code of the latest wireless-testing git tree). Where is the code that handles entering power save mode in this driver? Rgs, Mark ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [stable] [PATCH 0/3] ath9k: several fixes ported to 2.6.27
On Tue, Dec 2, 2008 at 1:27 PM, Greg KH [EMAIL PROTECTED] wrote: On Tue, Dec 02, 2008 at 12:51:19PM -0800, Luis R. Rodriguez wrote: This fixes a few issues seen on MacBook Pros: http://bugzilla.kernel.org/show_bug.cgi?id=11811 I've ported them to 2.6.27 to help with them being applied sooner. What do you mean by sooner? They need to be in Linus's tree before we can add them to the 2.6.27-stable tree. Please let us know when that happens, and what the git ids of them are, so we can add them to the next -stable release. Heh, well once applied there it may not apply on 27, so by sooner I mean that you don't have to do backport work as I did it for you. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Rx filter Baseband
hi,all I would like to switch RX filter bandwidth 20M(default) to 5/10MHz in Atheros AR5413 chipset, I fixed baseband 0x9944 register , but I'm not sure whether is right , someone helps me or gives me a clue ? thank you in advance . advan advan_xiang 2008-12-03 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH v2 2/2] ath9k: Use GFP_ATOMIC when allocating TX private area
Luis R. Rodriguez wrote:
@@ -1813,10 +1815,30 @@ int ath_tx_start(struct ath_softc *sc, struct sk_buff
*skb,
r = ath_tx_setup_buffer(sc, bf, skb, txctl);
if (r) {
- spin_lock_bh(sc-sc_txbuflock);
+ struct ath_txq *txq = NULL;
+ int qnum;
+
+ qnum = ath_get_hal_qnum(skb_get_queue_mapping(skb), sc);
+ txq = sc-sc_txq[qnum];
+
DPRINTF(sc, ATH_DBG_FATAL, TX mem alloc failure\n);
+
+ /* upon ath_tx_processq() this TX queue will be resumed, we
+ * guarantee this will happen by knowing beforehand that
+ * we will at least have to run TX completionon one buffer
+ * on the queue */
+ spin_lock_bh(txq-axq_lock);
+ if (ath_txq_depth(sc, txq-axq_qnum) 1) {
+ ieee80211_stop_queue(sc-hw,
+ skb_get_queue_mapping(skb));
+ txq-stopped = 1;
+ }
+ spin_unlock_bh(txq-axq_lock);
+
+ spin_lock_bh(sc-sc_txbuflock);
list_add_tail(bf-list, sc-sc_txbuf);
spin_unlock_bh(sc-sc_txbuflock);
+
The queue is already available, we make sure of that before calling
ath_tx_start().
And the queue is sent through txctl.txq, you don't have to calculate the queue
number again.
So, just stopping the queue and moving the buffer back to the free list would
be enough.
Sujith
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v2 2/2] ath9k: Use GFP_ATOMIC when allocating TX private area
On Tue, Dec 2, 2008 at 7:46 PM, Sujith [EMAIL PROTECTED] wrote:
Luis R. Rodriguez wrote:
@@ -1813,10 +1815,30 @@ int ath_tx_start(struct ath_softc *sc, struct
sk_buff *skb,
r = ath_tx_setup_buffer(sc, bf, skb, txctl);
if (r) {
- spin_lock_bh(sc-sc_txbuflock);
+ struct ath_txq *txq = NULL;
+ int qnum;
+
+ qnum = ath_get_hal_qnum(skb_get_queue_mapping(skb), sc);
+ txq = sc-sc_txq[qnum];
+
DPRINTF(sc, ATH_DBG_FATAL, TX mem alloc failure\n);
+
+ /* upon ath_tx_processq() this TX queue will be resumed, we
+ * guarantee this will happen by knowing beforehand that
+ * we will at least have to run TX completionon one buffer
+ * on the queue */
+ spin_lock_bh(txq-axq_lock);
+ if (ath_txq_depth(sc, txq-axq_qnum) 1) {
+ ieee80211_stop_queue(sc-hw,
+ skb_get_queue_mapping(skb));
+ txq-stopped = 1;
+ }
+ spin_unlock_bh(txq-axq_lock);
+
+ spin_lock_bh(sc-sc_txbuflock);
list_add_tail(bf-list, sc-sc_txbuf);
spin_unlock_bh(sc-sc_txbuflock);
+
The queue is already available, we make sure of that before calling
ath_tx_start().
And the queue is sent through txctl.txq, you don't have to calculate the
queue number again.
So, just stopping the queue and moving the buffer back to the free list would
be enough.
ath_test_get_txq() will not return the queue only if the queue is
getting full. What the check above guarantees is we have at least one
buffer to run through procesq before disabling the TX queue, otherwise
the queue won't be be woken up. Or am I missing something? That is,
say you just have to TX one skb and we hit -ENOMEM on
ath_tx_setup_buffer() and you disable the queue. How will this queue
be awoken if this is true in ath_tx_processq():
list_empty(txq-axq_q)
Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] patch ath9k-fix-sw-iommu-bounce-buffer-starvation.patch added to 2.6.27-stable tree
This is a note to let you know that we have just queued up the patch titled
Subject: ath9k: Fix SW-IOMMU bounce buffer starvation
to the 2.6.27-stable tree. Its filename is
ath9k-fix-sw-iommu-bounce-buffer-starvation.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
From [EMAIL PROTECTED] Tue Dec 2 16:08:24 2008
From: Luis R. Rodriguez [EMAIL PROTECTED]
Date: Tue, 2 Dec 2008 12:51:20 -0800
Subject: ath9k: Fix SW-IOMMU bounce buffer starvation
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Luis R. Rodriguez [EMAIL
PROTECTED], Maciej Zenczykowski [EMAIL PROTECTED], Bennyam Malavazi [EMAIL
PROTECTED]
Message-ID: [EMAIL PROTECTED]
From: Luis R. Rodriguez [EMAIL PROTECTED]
commit ca0c7e5101fd4f37fed8e851709f08580b92fbb3 upstream.
This should fix the SW-IOMMU bounce buffer starvation
seen ok kernel.org bugzilla 11811:
http://bugzilla.kernel.org/show_bug.cgi?id=11811
Users on MacBook Pro 3.1/MacBook v2 would see something like:
DMA: Out of SW-IOMMU space for 4224 bytes at device :0b:00.0
Unfortunately its only easy to trigger on MacBook Pro 3.1/MacBook v2
so far so its difficult to debug (even with swiotlb=force).
We were pci_unmap_single()'ing less bytes than what we called
for with pci_map_single() and as such we were starving
the swiotlb from its 64MB amount of bounce buffers. We remain
consistent and now always use sc-rxbufsize for RX. While at
it we update the beacon DMA maps as well to only use the data
portion of the skb, previous to this we were pci_map_single()'ing
more data for beaconing than what we tell the hardware it can use,
therefore pushing more iotlb abuse.
Still not sure why this is so easily triggerable on
MacBook Pro 3.1, it may be the hardware configuration
tends to use more memory 3GB mark for DMA.
Signed-off-by: Maciej Zenczykowski [EMAIL PROTECTED]
Signed-off-by: Bennyam Malavazi [EMAIL PROTECTED]
Signed-off-by: Luis R. Rodriguez [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/net/wireless/ath9k/recv.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@ -1011,7 +1011,7 @@ int ath_rx_tasklet(struct ath_softc *sc,
pci_dma_sync_single_for_cpu(sc-pdev,
bf-bf_buf_addr,
- skb_tailroom(skb),
+ sc-sc_rxbufsize,
PCI_DMA_FROMDEVICE);
pci_unmap_single(sc-pdev,
bf-bf_buf_addr,
@@ -1303,8 +1303,7 @@ dma_addr_t ath_skb_map_single(struct ath
* NB: do NOT use skb-len, which is 0 on initialization.
* Use skb's entire data area instead.
*/
- *pa = pci_map_single(sc-pdev, skb-data,
- skb_end_pointer(skb) - skb-head, direction);
+ *pa = pci_map_single(sc-pdev, skb-data, sc-sc_rxbufsize, direction);
return *pa;
}
@@ -1314,6 +1313,5 @@ void ath_skb_unmap_single(struct ath_sof
dma_addr_t *pa)
{
/* Unmap skb's entire data area */
- pci_unmap_single(sc-pdev, *pa,
- skb_end_pointer(skb) - skb-head, direction);
+ pci_unmap_single(sc-pdev, *pa, sc-sc_rxbufsize, direction);
}
Patches currently in stable-queue which might be from [EMAIL PROTECTED] are
queue-2.6.27/ath9k-fix-sw-iommu-bounce-buffer-starvation.patch
queue-2.6.27/ath9k-correct-expected-max-rx-buffer-size.patch
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [stable] [PATCH 1/3] ath9k: Handle -ENOMEM on RX gracefully
I don't see this patch upstream in Linus's tree. Am I just missing it
and if so, do you know the git commit id?
thanks,
greg k-h
On Tue, Dec 02, 2008 at 12:51:22PM -0800, Luis R. Rodriguez wrote:
We would get an oops on RX on -ENOMEM by passing
NULL to the hardware on ath_rx_buf_link(). The oops
would look something like this:
ath_rx_tasklet
...
RIP: ath_rx_buf_link
We correct this by handling the allocation for the next
skb we will put in our RX tail directly on the ath_rx_tasklet()
*prior* to sending up the last hardware processed
skb. If we run out of memory this gauranteees we have
skbs to work with while it simply drops new received
frames.
Signed-off-by: Luis R. Rodriguez [EMAIL PROTECTED]
---
drivers/net/wireless/ath9k/recv.c | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath9k/recv.c
b/drivers/net/wireless/ath9k/recv.c
index 0941589..a4f92b2 100644
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@ -441,18 +441,16 @@ static void ath_rx_requeue(struct ath_softc *sc, struct
sk_buff *skb)
*/
static int ath_rx_indicate(struct ath_softc *sc,
struct sk_buff *skb,
+struct sk_buff *nskb,
struct ath_recv_status *status,
u16 keyix)
{
struct ath_buf *bf = ATH_RX_CONTEXT(skb)-ctx_rxbuf;
- struct sk_buff *nskb;
int type;
/* indicate frame to the stack, which will free the old skb. */
type = ath__rx_indicate(sc, skb, status, keyix);
- /* allocate a new skb and queue it to for H/W processing */
- nskb = ath_rxbuf_alloc(sc, sc-sc_rxbufsize);
if (nskb != NULL) {
bf-bf_mpdu = nskb;
bf-bf_buf_addr = ath_skb_map_single(sc,
@@ -741,6 +739,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
struct ath_desc *ds;
struct ieee80211_hdr *hdr;
struct sk_buff *skb = NULL;
+ struct sk_buff *nskb = NULL;
struct ath_recv_status rx_status;
struct ath_hal *ah = sc-sc_ah;
int type, rx_processed = 0;
@@ -963,6 +962,17 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
*/
if (sc-sc_rxbufsize ds-ds_rxstat.rs_datalen)
goto rx_next;
+
+ /* allocate a new skb and queue it to for H/W processing */
+ nskb = ath_rxbuf_alloc(sc, sc-sc_rxbufsize);
+
+ /* Diregard current RX'd frame and reuse the old skb */
+ if (!nskb) {
+ list_move_tail(bf-list, sc-sc_rxbuf);
+ ath_rx_buf_link(sc, bf);
+ goto rx_next;
+ }
+
/*
* Sync and unmap the frame. At this point we're
* committed to passing the sk_buff somewhere so
@@ -1052,7 +1062,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush)
/* Pass frames up to the stack. */
- type = ath_rx_indicate(sc, skb,
+ type = ath_rx_indicate(sc, skb, nskb,
rx_status, ds-ds_rxstat.rs_keyix);
/*
--
1.5.6.rc2.15.g457bb.dirty
___
stable mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/stable
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] patch ath9k-correct-expected-max-rx-buffer-size.patch added to 2.6.27-stable tree
This is a note to let you know that we have just queued up the patch titled Subject: ath9k: correct expected max RX buffer size to the 2.6.27-stable tree. Its filename is ath9k-correct-expected-max-rx-buffer-size.patch A git repo of this tree can be found at http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary From [EMAIL PROTECTED] Tue Dec 2 16:09:29 2008 From: Luis R. Rodriguez [EMAIL PROTECTED] Date: Tue, 2 Dec 2008 12:51:21 -0800 Subject: ath9k: correct expected max RX buffer size To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Luis R. Rodriguez [EMAIL PROTECTED], Bennyam Malavazi [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] From: Luis R. Rodriguez [EMAIL PROTECTED] commit b4b6cda2298b0c9a0af902312184b775b8867c65 upstream We should only tell the hardware its capable of DMA'ing to us only what we asked dev_alloc_skb(). Prior to this it is possible a large RX'd frame could have corrupted DMA data but for us but we were saved only because we were previously also pci_map_single()'ing the same large value. The issue prior to this though was we were unmapping a smaller amount which the prior DMA patch fixed. Signed-off-by: Bennyam Malavazi [EMAIL PROTECTED] Signed-off-by: Luis R. Rodriguez [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- drivers/net/wireless/ath9k/recv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/ath9k/recv.c +++ b/drivers/net/wireless/ath9k/recv.c @@ -52,7 +52,7 @@ static void ath_rx_buf_link(struct ath_s /* setup rx descriptors */ ath9k_hw_setuprxdesc(ah, ds, -skb_tailroom(skb), /* buffer size */ +sc-sc_rxbufsize, 0); if (sc-sc_rxlink == NULL) Patches currently in stable-queue which might be from [EMAIL PROTECTED] are queue-2.6.27/ath9k-fix-sw-iommu-bounce-buffer-starvation.patch queue-2.6.27/ath9k-correct-expected-max-rx-buffer-size.patch ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
