* Re: [RFC 3/6] ath9k: initial radar pulse detection for DFS
From: Adrian Chadd @ 2011-10-03 14:23 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, ath9k-devel, kgiori, rodrigue, nbd
In-Reply-To: <4E89C4F1.2090708@neratec.com>
On 3 October 2011 22:21, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> Most probably it'll end being added to the lengthy TODO list.
:) No worries. I've just added the freebsd version of this to
FreeBSD-HEAD. I'll add in the duration calculation function soon.
Now all we need is an ISC/GPL dual licenced packet classification
module. *wink* :)
Adrian
^ permalink raw reply
* Re: [RFC 3/6] ath9k: initial radar pulse detection for DFS
From: Zefir Kurtisi @ 2011-10-03 14:21 UTC (permalink / raw)
To: Adrian Chadd; +Cc: linux-wireless, ath9k-devel, kgiori, rodrigue, nbd
In-Reply-To: <CAJ-Vmomx8eSBTEZ3A_vnw8GaWh2dO3CFD-MZ6zzBDmWKZx7=xw@mail.gmail.com>
On 10/03/2011 02:43 PM, Adrian Chadd wrote:
> On 3 October 2011 20:23, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>
>> There might be one, but I left it out (for now) for the sake of simplicity.
>>
>> I anyhow doubt it has a practical relevance, since the pulse width is reported with usec granularity and therefore a scaling factor of 1/811 vs. 1/800 has no impact on the re-scaled value for widths up to 50 usecs.
>
> I just remember this was a sticking point when porting the fusion code
> to FreeBSD.
> Without that particular fix, some of the radar patterns didn't
> actually match reliably.
>
> It's possible it doesn't matter as much for your classification code.
> I'm just bringing it up to be complete. :)
>
>
>
> Adrian
Thanks!
Most probably it'll end being added to the lengthy TODO list.
Zefir
^ permalink raw reply
* Re: [RFC 3/6] ath9k: initial radar pulse detection for DFS
From: Adrian Chadd @ 2011-10-03 12:43 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, ath9k-devel, kgiori, rodrigue, nbd
In-Reply-To: <4E89A941.8060208@neratec.com>
On 3 October 2011 20:23, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> There might be one, but I left it out (for now) for the sake of simplicity.
>
> I anyhow doubt it has a practical relevance, since the pulse width is reported with usec granularity and therefore a scaling factor of 1/811 vs. 1/800 has no impact on the re-scaled value for widths up to 50 usecs.
I just remember this was a sticking point when porting the fusion code
to FreeBSD.
Without that particular fix, some of the radar patterns didn't
actually match reliably.
It's possible it doesn't matter as much for your classification code.
I'm just bringing it up to be complete. :)
Adrian
^ permalink raw reply
* Re: [RFC 3/6] ath9k: initial radar pulse detection for DFS
From: Zefir Kurtisi @ 2011-10-03 12:23 UTC (permalink / raw)
To: Adrian Chadd; +Cc: linux-wireless, ath9k-devel, kgiori, rodrigue, nbd
In-Reply-To: <CAJ-VmonP5V2dL8aYiMRrkNcQR19kKAy2PCWHSkxb1biyJS7pow@mail.gmail.com>
On 10/03/2011 01:57 PM, Adrian Chadd wrote:
> Just out of curiousity, is there any "fast clock" on or off with the AR93xx ?
>
> (That's one of the gotchas I came across when porting DFS code to
> FreeBSD for the AR9160/AR9280.)
>
> Thanks,
>
>
> Adrian
There might be one, but I left it out (for now) for the sake of simplicity.
I anyhow doubt it has a practical relevance, since the pulse width is reported with usec granularity and therefore a scaling factor of 1/811 vs. 1/800 has no impact on the re-scaled value for widths up to 50 usecs.
Zefir
^ permalink raw reply
* [PATCH V2 4/4] ath6kl: Minor cleanup in msg_look_ahead parameter in ath6kl_htc_rxmsg_pending_handler()
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:56 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <1317642987-16026-1-git-send-email-vthiagar@qca.qualcomm.com>
It is just a four byte information of the received message
from ath6kl_htc_rxmsg_pending_handler(). Remove unnecessary
array representaion.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/htc.c | 4 ++--
drivers/net/wireless/ath/ath6kl/htc.h | 2 +-
drivers/net/wireless/ath/ath6kl/htc_hif.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc.c b/drivers/net/wireless/ath/ath6kl/htc.c
index ca3d084..9a9eae5 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.c
+++ b/drivers/net/wireless/ath/ath6kl/htc.c
@@ -1770,7 +1770,7 @@ fail_rx:
}
int ath6kl_htc_rxmsg_pending_handler(struct htc_target *target,
- u32 msg_look_ahead[], int *num_pkts)
+ u32 msg_look_ahead, int *num_pkts)
{
struct htc_packet *packets, *tmp_pkt;
struct htc_endpoint *endpoint;
@@ -1787,7 +1787,7 @@ int ath6kl_htc_rxmsg_pending_handler(struct htc_target *target,
* On first entry copy the look_aheads into our temp array for
* processing
*/
- memcpy(look_aheads, msg_look_ahead, sizeof(look_aheads));
+ look_aheads[0] = msg_look_ahead;
while (true) {
diff --git a/drivers/net/wireless/ath/ath6kl/htc.h b/drivers/net/wireless/ath/ath6kl/htc.h
index 8ce0c2c..69d44e3 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.h
+++ b/drivers/net/wireless/ath/ath6kl/htc.h
@@ -563,7 +563,7 @@ int ath6kl_htc_get_rxbuf_num(struct htc_target *target,
int ath6kl_htc_add_rxbuf_multiple(struct htc_target *target,
struct list_head *pktq);
int ath6kl_htc_rxmsg_pending_handler(struct htc_target *target,
- u32 msg_look_ahead[], int *n_pkts);
+ u32 msg_look_ahead, int *n_pkts);
static inline void set_htc_pkt_info(struct htc_packet *packet, void *context,
u8 *buf, unsigned int len,
diff --git a/drivers/net/wireless/ath/ath6kl/htc_hif.c b/drivers/net/wireless/ath/ath6kl/htc_hif.c
index 86b1cc7..37a13f0 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_hif.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_hif.c
@@ -417,7 +417,7 @@ static int proc_pending_irqs(struct ath6kl_device *dev, bool *done)
* we rapidly pull packets.
*/
status = ath6kl_htc_rxmsg_pending_handler(dev->htc_cnxt,
- &lk_ahd, &fetched);
+ lk_ahd, &fetched);
if (status)
goto out;
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 2/4] ath6kl: Fix htc_packet leak in ath6kl_htc_rx_fetch()
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:58 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
It is found during the code review. As the leak would happen only
in failure case, the imapct is not easily visible.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/htc.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
V2 -- Change in commit log
diff --git a/drivers/net/wireless/ath/ath6kl/htc.c b/drivers/net/wireless/ath/ath6kl/htc.c
index 7bc9884..4a03dac 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.c
+++ b/drivers/net/wireless/ath/ath6kl/htc.c
@@ -1715,12 +1715,10 @@ static int ath6kl_htc_rx_fetch(struct htc_target *target,
packet = list_first_entry(rx_pktq, struct htc_packet,
list);
- list_del(&packet->list);
-
/* fully synchronous */
packet->completion = NULL;
- if (!list_empty(rx_pktq))
+ if (!list_is_singular(rx_pktq))
/*
* look_aheads in all packet
* except the last one in the
@@ -1735,7 +1733,7 @@ static int ath6kl_htc_rx_fetch(struct htc_target *target,
if (status)
return status;
- list_add_tail(&packet->list, comp_pktq);
+ list_move_tail(&packet->list, comp_pktq);
}
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 1/4] ath6kl: Fix htc_packet leak in ath6kl_htc_rx_process_packets()
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:58 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
Packet is not reclaimed when ath6kl_htc_rx_process_hdr() fails.
Fix this by deferring the packet deletion from comp_pktq till
ath6kl_htc_rx_process_hdr() returns success. This bug is found
in code review, impact is not easily visible as the leak happens
only in failure cases.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/htc.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
V2 --- Commit log change
diff --git a/drivers/net/wireless/ath/ath6kl/htc.c b/drivers/net/wireless/ath/ath6kl/htc.c
index f88a7c9..7bc9884 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.c
+++ b/drivers/net/wireless/ath/ath6kl/htc.c
@@ -1643,7 +1643,6 @@ static int ath6kl_htc_rx_process_packets(struct htc_target *target,
int status = 0;
list_for_each_entry_safe(packet, tmp_pkt, comp_pktq, list) {
- list_del(&packet->list);
ep = &target->endpoint[packet->endpoint];
/* process header for each of the recv packet */
@@ -1652,6 +1651,8 @@ static int ath6kl_htc_rx_process_packets(struct htc_target *target,
if (status)
return status;
+ list_del(&packet->list);
+
if (list_empty(comp_pktq)) {
/*
* Last packet's more packet flag is set
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC 3/6] ath9k: initial radar pulse detection for DFS
From: Adrian Chadd @ 2011-10-03 11:57 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, ath9k-devel, kgiori, rodrigue, nbd
In-Reply-To: <1317637758-11907-4-git-send-email-zefir.kurtisi@neratec.com>
Just out of curiousity, is there any "fast clock" on or off with the AR93xx ?
(That's one of the gotchas I came across when porting DFS code to
FreeBSD for the AR9160/AR9280.)
Thanks,
Adrian
^ permalink raw reply
* [PATCH V2 3/4] ath6kl: Avoid processing failed rx packets
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:56 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <1317642987-16026-1-git-send-email-vthiagar@qca.qualcomm.com>
It is not necessary to process an htc_packet which is allocated for rx
but failed in sdio rx. Though it does not fix any real issue, it does
not make much sense to process the failed frame.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/htc.c | 48 +++++++++++++++++++++++---------
1 files changed, 34 insertions(+), 14 deletions(-)
V2 -- commit log change
diff --git a/drivers/net/wireless/ath/ath6kl/htc.c b/drivers/net/wireless/ath/ath6kl/htc.c
index 4a03dac..ca3d084 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.c
+++ b/drivers/net/wireless/ath/ath6kl/htc.c
@@ -1687,11 +1687,15 @@ static int ath6kl_htc_rx_fetch(struct htc_target *target,
int fetched_pkts;
bool part_bundle = false;
int status = 0;
+ struct list_head tmp_rxq;
+ struct htc_packet *packet, *tmp_pkt;
/* now go fetch the list of HTC packets */
while (!list_empty(rx_pktq)) {
fetched_pkts = 0;
+ INIT_LIST_HEAD(&tmp_rxq);
+
if (target->rx_bndl_enable && (get_queue_depth(rx_pktq) > 1)) {
/*
* There are enough packets to attempt a
@@ -1699,18 +1703,19 @@ static int ath6kl_htc_rx_fetch(struct htc_target *target,
* allowed.
*/
status = ath6kl_htc_rx_bundle(target, rx_pktq,
- comp_pktq,
+ &tmp_rxq,
&fetched_pkts,
part_bundle);
if (status)
- return status;
+ goto fail_rx;
if (!list_empty(rx_pktq))
part_bundle = true;
+
+ list_splice_tail_init(&tmp_rxq, comp_pktq);
}
if (!fetched_pkts) {
- struct htc_packet *packet;
packet = list_first_entry(rx_pktq, struct htc_packet,
list);
@@ -1730,13 +1735,37 @@ static int ath6kl_htc_rx_fetch(struct htc_target *target,
/* go fetch the packet */
status = ath6kl_htc_rx_packet(target, packet,
packet->act_len);
+
+ list_move_tail(&packet->list, &tmp_rxq);
+
if (status)
- return status;
+ goto fail_rx;
- list_move_tail(&packet->list, comp_pktq);
+ list_splice_tail_init(&tmp_rxq, comp_pktq);
}
}
+ return 0;
+
+fail_rx:
+
+ /*
+ * Cleanup any packets we allocated but didn't use to
+ * actually fetch any packets.
+ */
+
+ list_for_each_entry_safe(packet, tmp_pkt, rx_pktq, list) {
+ list_del(&packet->list);
+ htc_reclaim_rxbuf(target, packet,
+ &target->endpoint[packet->endpoint]);
+ }
+
+ list_for_each_entry_safe(packet, tmp_pkt, &tmp_rxq, list) {
+ list_del(&packet->list);
+ htc_reclaim_rxbuf(target, packet,
+ &target->endpoint[packet->endpoint]);
+ }
+
return status;
}
@@ -1826,15 +1855,6 @@ int ath6kl_htc_rxmsg_pending_handler(struct htc_target *target,
if (status) {
ath6kl_err("failed to get pending recv messages: %d\n",
status);
- /*
- * Cleanup any packets we allocated but didn't use to
- * actually fetch any packets.
- */
- list_for_each_entry_safe(packets, tmp_pkt, &rx_pktq, list) {
- list_del(&packets->list);
- htc_reclaim_rxbuf(target, packets,
- &target->endpoint[packets->endpoint]);
- }
/* cleanup any packets in sync completion queue */
list_for_each_entry_safe(packets, tmp_pkt, &comp_pktq, list) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/4] ath6kl: Fix htc_packet leak in ath6kl_htc_rx_fetch()
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:56 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <1317642987-16026-1-git-send-email-vthiagar@qca.qualcomm.com>
It is found during the code review. As the leak would happen only
in failure case, the imapct is not easily visible.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/htc.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
V2 -- Change in commit log
diff --git a/drivers/net/wireless/ath/ath6kl/htc.c b/drivers/net/wireless/ath/ath6kl/htc.c
index 7bc9884..4a03dac 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.c
+++ b/drivers/net/wireless/ath/ath6kl/htc.c
@@ -1715,12 +1715,10 @@ static int ath6kl_htc_rx_fetch(struct htc_target *target,
packet = list_first_entry(rx_pktq, struct htc_packet,
list);
- list_del(&packet->list);
-
/* fully synchronous */
packet->completion = NULL;
- if (!list_empty(rx_pktq))
+ if (!list_is_singular(rx_pktq))
/*
* look_aheads in all packet
* except the last one in the
@@ -1735,7 +1733,7 @@ static int ath6kl_htc_rx_fetch(struct htc_target *target,
if (status)
return status;
- list_add_tail(&packet->list, comp_pktq);
+ list_move_tail(&packet->list, comp_pktq);
}
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/4] ath6kl: Fix htc_packet leak in ath6kl_htc_rx_process_packets()
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:56 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
Packet is not reclaimed when ath6kl_htc_rx_process_hdr() fails.
Fix this by deferring the packet deletion from comp_pktq till
ath6kl_htc_rx_process_hdr() returns success. This bug is found
in code review, impact is not easily visible as the leak happens
only in failure cases.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/htc.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
V2 --- Commit log change
diff --git a/drivers/net/wireless/ath/ath6kl/htc.c b/drivers/net/wireless/ath/ath6kl/htc.c
index f88a7c9..7bc9884 100644
--- a/drivers/net/wireless/ath/ath6kl/htc.c
+++ b/drivers/net/wireless/ath/ath6kl/htc.c
@@ -1643,7 +1643,6 @@ static int ath6kl_htc_rx_process_packets(struct htc_target *target,
int status = 0;
list_for_each_entry_safe(packet, tmp_pkt, comp_pktq, list) {
- list_del(&packet->list);
ep = &target->endpoint[packet->endpoint];
/* process header for each of the recv packet */
@@ -1652,6 +1651,8 @@ static int ath6kl_htc_rx_process_packets(struct htc_target *target,
if (status)
return status;
+ list_del(&packet->list);
+
if (list_empty(comp_pktq)) {
/*
* Last packet's more packet flag is set
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 3/4] ath6kl: Avoid processing failed rx packets
From: Kalle Valo @ 2011-10-03 11:44 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <20111003114134.GC24335@vasanth-laptop>
On 10/03/2011 02:41 PM, Vasanthakumar Thiagarajan wrote:
> On Mon, Oct 03, 2011 at 02:18:01PM +0300, Kalle Valo wrote:
>> On 09/29/2011 06:01 PM, Vasanthakumar Thiagarajan wrote:
>>> It is not necessary to process an htc_packet which is allocated for rx
>>> but failed in sdio rx.
>>
>> Same question here: does it fix a visible bug or is it more like a
>> theoretical issue?
>>
>> I would prefer that fixes would also state the impact of the bug: is it
>> a theoretical issue, a random bug which almost nobody sees or really bad
>> bug visible almost everywhere? That way it's easier to decide which
>> trees it should be sent.
>
> Ok, I can add this to commit log. I'll resend everything with V2.
Excellent, thanks a lot.
Kalle
^ permalink raw reply
* Re: [PATCH 3/4] ath6kl: Avoid processing failed rx packets
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <4E8999E9.4090904@qca.qualcomm.com>
On Mon, Oct 03, 2011 at 02:18:01PM +0300, Kalle Valo wrote:
> On 09/29/2011 06:01 PM, Vasanthakumar Thiagarajan wrote:
> > It is not necessary to process an htc_packet which is allocated for rx
> > but failed in sdio rx.
>
> Same question here: does it fix a visible bug or is it more like a
> theoretical issue?
>
> I would prefer that fixes would also state the impact of the bug: is it
> a theoretical issue, a random bug which almost nobody sees or really bad
> bug visible almost everywhere? That way it's easier to decide which
> trees it should be sent.
Ok, I can add this to commit log. I'll resend everything with V2.
Vasanth
^ permalink raw reply
* Re: [PATCH 1/4] ath6kl: Fix htc_packet leak in ath6kl_htc_rx_process_packets()
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:40 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <4E899876.4060103@qca.qualcomm.com>
On Mon, Oct 03, 2011 at 02:11:50PM +0300, Kalle Valo wrote:
> On 09/29/2011 06:01 PM, Vasanthakumar Thiagarajan wrote:
> > Packet is not reclaimed when ath6kl_htc_rx_process_hdr() fails.
> > Fix this by deferring the packet deletion from comp_pktq till
> > ath6kl_htc_rx_process_hdr() returns success.
>
> Does this fix a user visible bug? Or is this just something you found
> while doing code review?
This one is found in code review, it does not fix any visible bug.
Vasanth
^ permalink raw reply
* Re: [PATCH V2 3/5] ath6kl: Claim sdio function only at appropriate places
From: Vasanthakumar Thiagarajan @ 2011-10-03 11:38 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <4E899830.2070506@qca.qualcomm.com>
On Mon, Oct 03, 2011 at 02:10:40PM +0300, Kalle Valo wrote:
> On 09/30/2011 07:16 PM, Vasanthakumar Thiagarajan wrote:
> > There are places where tx_complete callbacks are called with
> > claiming the sdio function. It is not necessary to hold the
> > sdio func for longer. This may even affect the host side power
> > save, if it is supported by the controller.
>
> Applied, thanks.
>
> But in the future, please resend the whole patchset even when you modify
> just one patch. Resending invidividual patches from a patchset is error
> prone and most likely I will apply the wrong patch.
Sure, thanks.
Vasanth
^ permalink raw reply
* [PATCH v2] libertas: detect TX lockups and reset hardware
From: Daniel Drake @ 2011-10-03 10:33 UTC (permalink / raw)
To: linville; +Cc: dcbw, linux-wireless, libertas-dev
Recent patches added support for resetting the SD8686 hardware when
commands time out, which seems to happen quite frequently soon after
resuming the system from a Wake-on-WLAN-triggered resume.
At http://dev.laptop.org/ticket/10969 we see the same thing happen
with transmits. In this case, the hardware will fail to respond to
a frame passed for transmission, and libertas (correctly) will block
all further commands and transmissions as the hardware can only
deal with one thing at a time. This results in a lockup while the
system waits indefinitely for the dead card to respond.
Hook up a TX lockup timer to detect this and reset the hardware.
Signed-off-by: Daniel Drake <dsd@laptop.org>
---
drivers/net/wireless/libertas/dev.h | 1 +
drivers/net/wireless/libertas/main.c | 35 ++++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 0 deletions(-)
v2: regenerated against wireless-next.git. Compared to the first version,
minor changes were needed to the way the timer is stopped when the interface
is brought down (these routines changed as a result of other recent work).
diff --git a/drivers/net/wireless/libertas/dev.h b/drivers/net/wireless/libertas/dev.h
index fb3e40b..f3fd447 100644
--- a/drivers/net/wireless/libertas/dev.h
+++ b/drivers/net/wireless/libertas/dev.h
@@ -158,6 +158,7 @@ struct lbs_private {
/* protected by hard_start_xmit serialization */
u8 txretrycount;
struct sk_buff *currenttxskb;
+ struct timer_list tx_lockup_timer;
/* Locks */
struct mutex lock;
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index d62d1fb..6a32623 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -188,6 +188,7 @@ int lbs_stop_iface(struct lbs_private *priv)
spin_unlock_irqrestore(&priv->driver_lock, flags);
cancel_work_sync(&priv->mcast_work);
+ del_timer_sync(&priv->tx_lockup_timer);
/* Disable command processing, and wait for all commands to complete */
lbs_deb_main("waiting for commands to complete\n");
@@ -243,6 +244,7 @@ void lbs_host_to_card_done(struct lbs_private *priv)
lbs_deb_enter(LBS_DEB_THREAD);
spin_lock_irqsave(&priv->driver_lock, flags);
+ del_timer(&priv->tx_lockup_timer);
priv->dnld_sent = DNLD_RES_RECEIVED;
@@ -585,6 +587,9 @@ static int lbs_thread(void *data)
if (ret) {
lbs_deb_tx("host_to_card failed %d\n", ret);
priv->dnld_sent = DNLD_RES_RECEIVED;
+ } else {
+ mod_timer(&priv->tx_lockup_timer,
+ jiffies + (HZ * 5));
}
priv->tx_pending_len = 0;
if (!priv->currenttxskb) {
@@ -601,6 +606,7 @@ static int lbs_thread(void *data)
}
del_timer(&priv->command_timer);
+ del_timer(&priv->tx_lockup_timer);
del_timer(&priv->auto_deepsleep_timer);
lbs_deb_leave(LBS_DEB_THREAD);
@@ -735,6 +741,32 @@ out:
}
/**
+ * lbs_tx_lockup_handler - handles the timeout of the passing of TX frames
+ * to the hardware. This is known to frequently happen with SD8686 when
+ * waking up after a Wake-on-WLAN-triggered resume.
+ *
+ * @data: &struct lbs_private pointer
+ */
+static void lbs_tx_lockup_handler(unsigned long data)
+{
+ struct lbs_private *priv = (struct lbs_private *)data;
+ unsigned long flags;
+
+ lbs_deb_enter(LBS_DEB_TX);
+ spin_lock_irqsave(&priv->driver_lock, flags);
+
+ netdev_info(priv->dev, "TX lockup detected\n");
+ if (priv->reset_card)
+ priv->reset_card(priv);
+
+ priv->dnld_sent = DNLD_RES_RECEIVED;
+ wake_up_interruptible(&priv->waitq);
+
+ spin_unlock_irqrestore(&priv->driver_lock, flags);
+ lbs_deb_leave(LBS_DEB_TX);
+}
+
+/**
* auto_deepsleep_timer_fn - put the device back to deep sleep mode when
* timer expires and no activity (command, event, data etc.) is detected.
* @data: &struct lbs_private pointer
@@ -820,6 +852,8 @@ static int lbs_init_adapter(struct lbs_private *priv)
setup_timer(&priv->command_timer, lbs_cmd_timeout_handler,
(unsigned long)priv);
+ setup_timer(&priv->tx_lockup_timer, lbs_tx_lockup_handler,
+ (unsigned long)priv);
setup_timer(&priv->auto_deepsleep_timer, auto_deepsleep_timer_fn,
(unsigned long)priv);
@@ -857,6 +891,7 @@ static void lbs_free_adapter(struct lbs_private *priv)
lbs_free_cmd_buffer(priv);
kfifo_free(&priv->event_fifo);
del_timer(&priv->command_timer);
+ del_timer(&priv->tx_lockup_timer);
del_timer(&priv->auto_deepsleep_timer);
lbs_deb_leave(LBS_DEB_MAIN);
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH 3/4] ath6kl: Avoid processing failed rx packets
From: Kalle Valo @ 2011-10-03 11:18 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1317308476-16204-3-git-send-email-vthiagar@qca.qualcomm.com>
On 09/29/2011 06:01 PM, Vasanthakumar Thiagarajan wrote:
> It is not necessary to process an htc_packet which is allocated for rx
> but failed in sdio rx.
Same question here: does it fix a visible bug or is it more like a
theoretical issue?
I would prefer that fixes would also state the impact of the bug: is it
a theoretical issue, a random bug which almost nobody sees or really bad
bug visible almost everywhere? That way it's easier to decide which
trees it should be sent.
Kalle
^ permalink raw reply
* Re: [PATCH 1/4] ath6kl: Fix htc_packet leak in ath6kl_htc_rx_process_packets()
From: Kalle Valo @ 2011-10-03 11:11 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1317308476-16204-1-git-send-email-vthiagar@qca.qualcomm.com>
On 09/29/2011 06:01 PM, Vasanthakumar Thiagarajan wrote:
> Packet is not reclaimed when ath6kl_htc_rx_process_hdr() fails.
> Fix this by deferring the packet deletion from comp_pktq till
> ath6kl_htc_rx_process_hdr() returns success.
Does this fix a user visible bug? Or is this just something you found
while doing code review?
Kalle
^ permalink raw reply
* Re: [PATCH V2 3/5] ath6kl: Claim sdio function only at appropriate places
From: Kalle Valo @ 2011-10-03 11:10 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1317399419-3929-1-git-send-email-vthiagar@qca.qualcomm.com>
On 09/30/2011 07:16 PM, Vasanthakumar Thiagarajan wrote:
> There are places where tx_complete callbacks are called with
> claiming the sdio function. It is not necessary to hold the
> sdio func for longer. This may even affect the host side power
> save, if it is supported by the controller.
Applied, thanks.
But in the future, please resend the whole patchset even when you modify
just one patch. Resending invidividual patches from a patchset is error
prone and most likely I will apply the wrong patch.
Kalle
^ permalink raw reply
* Re: [PATCH 1/5] ath6kl: Fix sparse warning "symbol 'conn' shadows an earlier one"
From: Kalle Valo @ 2011-10-03 11:08 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1317390526-3442-1-git-send-email-vthiagar@qca.qualcomm.com>
Thanks, patches 1,2,4 and 5 applied. For the patch 3 I took V2 which you
sent separately.
Kalle
^ permalink raw reply
* Re: Pull request: ath6kl 20111001
From: Kalle Valo @ 2011-10-03 11:02 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <4E86E7A9.9070909@qca.qualcomm.com>
Hi again John,
On 10/01/2011 01:12 PM, Kalle Valo wrote:
> here's a pretty big pull request from ath6kl.git. I was supposed to send
> this already earlier, but I wanted to have a fix for an important TCP
> corruption bug first. Even there are quite a few changes, I still ask
> you to consider this for the 3.2 release. It has received extensive
> testing and we have fixed a bunch of bugs from the current version in
> wireless-next.
Actually I had to do an update to the pull request and add the commit
below to make it properly compile on ARM.
commit 62c83ac4d6bcfa6a116c8f1c8ace05cb3933a4f1
Author: Kalle Valo <kvalo@qca.qualcomm.com>
Date: Mon Oct 3 13:44:40 2011 +0300
ath6kl: include vmalloc.h in debug.c
I just pushed that change to github to the same for-linville branch.
Also I noticed that while compiling ath6kl for beagleboard I need this:
diff --git a/include/linux/of.h b/include/linux/of.h
index 9180dc5..219c29d 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -17,6 +17,7 @@
*/
#include <linux/types.h>
#include <linux/bitops.h>
+#include <linux/errno.h>
#include <linux/kref.h>
#include <linux/mod_devicetable.h>
#include <linux/spinlock.h>
But I'll send that to the device tree maintainers.
Kalle
^ permalink raw reply related
* Re: [PATCH] ath6kl: include vmalloc.h in debug.c
From: Kalle Valo @ 2011-10-03 10:55 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20111003104440.27129.60479.stgit@localhost6.localdomain6>
On 10/03/2011 01:44 PM, Kalle Valo wrote:
> Fixes compilation errors when compiling for ARM:
>
> ath6kl/debug.c:312: error: implicit declaration of function 'vmalloc'
> ath6kl/debug.c:312: warning: assignment makes pointer from integer without a cast
> ath6kl/debug.c:342: error: implicit declaration of function 'vfree'
> ath6kl/debug.c:696: warning: assignment makes pointer from integer without a cast
> ath6kl/debug.c:871: warning: assignment makes pointer from integer without a cast
Applied.
Kalle
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: Add module.h to wireless/ath/ath6kl/sdio.c
From: Kalle Valo @ 2011-10-03 10:48 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: davem, netdev, linville, linux-wireless
In-Reply-To: <1317424079-31793-1-git-send-email-paul.gortmaker@windriver.com>
On 10/01/2011 02:07 AM, Paul Gortmaker wrote:
> This file uses various MODULE_* macros, and so needs the full
> module.h header called out explicitly.
FWIW last week I added a similar patch to ath6kl.git (but not the same
as the file has changed):
https://github.com/kvalo/ath6kl/commit/c6efe578fc5dd02463d2ee20343494da56bdd3a9
I also sent a pull request to John so it should be in wireless-next soon.
Kalle
^ permalink raw reply
* [PATCH] ath6kl: include vmalloc.h in debug.c
From: Kalle Valo @ 2011-10-03 10:44 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
Fixes compilation errors when compiling for ARM:
ath6kl/debug.c:312: error: implicit declaration of function 'vmalloc'
ath6kl/debug.c:312: warning: assignment makes pointer from integer without a cast
ath6kl/debug.c:342: error: implicit declaration of function 'vfree'
ath6kl/debug.c:696: warning: assignment makes pointer from integer without a cast
ath6kl/debug.c:871: warning: assignment makes pointer from integer without a cast
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/debug.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/debug.c b/drivers/net/wireless/ath/ath6kl/debug.c
index 5237369..ba3f23d 100644
--- a/drivers/net/wireless/ath/ath6kl/debug.c
+++ b/drivers/net/wireless/ath/ath6kl/debug.c
@@ -18,6 +18,7 @@
#include <linux/circ_buf.h>
#include <linux/fs.h>
+#include <linux/vmalloc.h>
#include "debug.h"
#include "target.h"
^ permalink raw reply related
* Re: [PATCH V2] ath6kl: Enable force foreground scan in connected state
From: Kalle Valo @ 2011-10-03 10:33 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1317465756-5978-1-git-send-email-vthiagar@qca.qualcomm.com>
On 10/01/2011 01:42 PM, Vasanthakumar Thiagarajan wrote:
> This was disabled beacause there was a network stall
> issue when scan is issued. This issue does not happen
> with the new firmware (3.1.1.609), enable it back.
Thanks, applied.
Kalle
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox