* [PATCH 1/8] ath5k: Use mac80211 channel mapping function
From: Bruno Randolf @ 2011-01-19 9:20 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <20110119091949.19628.28309.stgit@localhost6.localdomain6>
Use mac80211 channel mapping function instead of own homegrown version.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/ath5k/base.c | 23 ++++++++---------------
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 09ae4ef..6850112 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -242,18 +242,6 @@ static int ath5k_reg_notifier(struct wiphy *wiphy, struct regulatory_request *re
\********************/
/*
- * Convert IEEE channel number to MHz frequency.
- */
-static inline short
-ath5k_ieee2mhz(short chan)
-{
- if (chan <= 14 || chan >= 27)
- return ieee80211chan2mhz(chan);
- else
- return 2212 + chan * 20;
-}
-
-/*
* Returns true for the channel numbers used without all_channels modparam.
*/
static bool ath5k_is_standard_channel(short chan)
@@ -274,6 +262,7 @@ ath5k_copy_channels(struct ath5k_hw *ah,
unsigned int max)
{
unsigned int i, count, size, chfreq, freq, ch;
+ enum ieee80211_band band;
if (!test_bit(mode, ah->ah_modes))
return 0;
@@ -283,11 +272,13 @@ ath5k_copy_channels(struct ath5k_hw *ah,
/* 1..220, but 2GHz frequencies are filtered by check_channel */
size = 220 ;
chfreq = CHANNEL_5GHZ;
+ band = IEEE80211_BAND_5GHZ;
break;
case AR5K_MODE_11B:
case AR5K_MODE_11G:
size = 26;
chfreq = CHANNEL_2GHZ;
+ band = IEEE80211_BAND_2GHZ;
break;
default:
ATH5K_WARN(ah->ah_sc, "bad mode, not copying channels\n");
@@ -296,7 +287,10 @@ ath5k_copy_channels(struct ath5k_hw *ah,
for (i = 0, count = 0; i < size && max > 0; i++) {
ch = i + 1 ;
- freq = ath5k_ieee2mhz(ch);
+ freq = ieee80211_channel_to_frequency(ch, band);
+
+ if (freq == 0) /* mapping failed - not a standard channel */
+ continue;
/* Check if channel is supported by the chipset */
if (!ath5k_channel_ok(ah, freq, chfreq))
@@ -307,8 +301,7 @@ ath5k_copy_channels(struct ath5k_hw *ah,
/* Write channel info and increment counter */
channels[count].center_freq = freq;
- channels[count].band = (chfreq == CHANNEL_2GHZ) ?
- IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ;
+ channels[count].band = band;
switch (mode) {
case AR5K_MODE_11A:
case AR5K_MODE_11G:
^ permalink raw reply related
* [PATCH 0/8] ath5k 802.11j preparation and cleanup
From: Bruno Randolf @ 2011-01-19 9:20 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
This series prepares ath5k for 802.11j (4.9GHz) support but most of the patches
are just cleaning up things i found in the process. 802.11j is still not
enabled.
bruno
---
Bruno Randolf (8):
ath5k: Use mac80211 channel mapping function
ath5k: Simplify loop when setting up channels
ath5k: Rename ath5k_copy_channels
ath5k: ath5k_setup_channels cleanup and whitespace
ath5k: Add 802.11j 4.9GHz channels to allowed channels
ath5: Remove unused CTL definitions
ath5k: Remove unused sc->curmode
ath5k: Remove redundant sc->curband
drivers/net/wireless/ath/ath5k/base.c | 95 +++++++++++--------------------
drivers/net/wireless/ath/ath5k/base.h | 3 -
drivers/net/wireless/ath/ath5k/eeprom.h | 23 --------
3 files changed, 34 insertions(+), 87 deletions(-)
--
Signature
^ permalink raw reply
* Re: [PATCH 2.6.32.y] hostap_cs: fix sleeping function called from invalid context
From: Stanislaw Gruszka @ 2011-01-19 7:36 UTC (permalink / raw)
To: Tim Gardner; +Cc: stable, Dominik Brodowski, linux-wireless, linux-pcmcia
In-Reply-To: <4D3601BA.8040907@canonical.com>
On Tue, Jan 18, 2011 at 02:10:18PM -0700, Tim Gardner wrote:
> I don't know either, but this device is becoming rare enough that
> I'm not gonna lose any sleep over it.
Ok, so defer any change since we see a bug report (I hope
we do not see, patch was tested by 2 users, it fix bug
and device work for them).
Stanislaw
^ permalink raw reply
* Re: [PATCH v2] wl12xx: Add channel 14 to list of supported 2ghz channels
From: Arik Nemtsov @ 2011-01-19 7:06 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295420717.10758.111.camel@pimenta>
On Wed, Jan 19, 2011 at 09:05, Luciano Coelho <coelho@ti.com> wrote:
>
> On Tue, 2011-01-18 at 20:39 +0100, Arik Nemtsov wrote:
> > Channel 14 is only supported in Japan (JP country code in).
> > The FW limits tranmissions to CCK only on this channel.
> >
> > Tested in both STA and AP modes to work correctly.
> >
> > Signed-off-by: Arik Nemtsov <arik@wizery.com>
> > ---
>
> Good, thanks Arik!
>
> I guess instead of (JP country code in) you meant (JP country code in
> regdb), right? I'll fix that manually before applying.
>
Yes Luca. Thanks.
Regards,
Arik
^ permalink raw reply
* Re: [PATCH v2] wl12xx: Add channel 14 to list of supported 2ghz channels
From: Luciano Coelho @ 2011-01-19 7:05 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295379592-6223-1-git-send-email-arik@wizery.com>
On Tue, 2011-01-18 at 20:39 +0100, Arik Nemtsov wrote:
> Channel 14 is only supported in Japan (JP country code in).
> The FW limits tranmissions to CCK only on this channel.
>
> Tested in both STA and AP modes to work correctly.
>
> Signed-off-by: Arik Nemtsov <arik@wizery.com>
> ---
Good, thanks Arik!
I guess instead of (JP country code in) you meant (JP country code in
regdb), right? I'll fix that manually before applying.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 1/5] ath9k: warn when we get a ATH9K_INT_TIM_TIMER and are idle
From: Luis R. Rodriguez @ 2011-01-19 1:43 UTC (permalink / raw)
To: Ben Greear
Cc: Luis Rodriguez, linville@tuxdriver.com, johannes@sipsolutions.net,
linux-wireless@vger.kernel.org, Amod Bodas, pstew@google.com
In-Reply-To: <4D36417C.4080000@candelatech.com>
On Tue, Jan 18, 2011 at 05:42:20PM -0800, Ben Greear wrote:
> On 01/18/2011 05:38 PM, Luis R. Rodriguez wrote:
> > On Tue, Jan 18, 2011 at 5:34 PM, Ben Greear<greearb@candelatech.com> wrote:
> >> On 12/06/2010 06:48 PM, Luis R. Rodriguez wrote:
> >>>
> >>> We should not be idle when we get the ATH9K_INT_TIM_TIMER,
> >>> otherwise we wake up the chip and that throws off the idle
> >>> state, the driver needs to be in full sleep when idle and
> >>> nothing should turn it awake without turning it back to
> >>> full sleep again. If we leave the chip idle and suspend,
> >>> upon resume the device will become unusable and we get:
> >>>
> >>> ath: Starting driver with initial channel: 5745 MHz
> >>> ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef& 0x00000003 !=
> >>> 0x00000000
> >>>
> >>> Cc: Paul Stewart<pstew@google.com>
> >>> Cc: Amod Bodas<amod.bodas@atheros.com>
> >>> signed-off-by: Luis R. Rodriguez<lrodriguez@atheros.com>
> >>> ---
> >>> drivers/net/wireless/ath/ath9k/main.c | 1 +
> >>> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/drivers/net/wireless/ath/ath9k/main.c
> >>> b/drivers/net/wireless/ath/ath9k/main.c
> >>> index f026a03..fd27ec9 100644
> >>> --- a/drivers/net/wireless/ath/ath9k/main.c
> >>> +++ b/drivers/net/wireless/ath/ath9k/main.c
> >>> @@ -770,6 +770,7 @@ irqreturn_t ath_isr(int irq, void *dev)
> >>> if (status& ATH9K_INT_TIM_TIMER) {
> >>> /* Clear RxAbort bit so that we can
> >>> * receive frames */
> >>> + WARN_ON(sc->ps_idle);
> >>> ath9k_setpower(sc, ATH9K_PM_AWAKE);
> >>> ath9k_hw_setrxabort(sc->sc_ah, 0);
> >>> sc->ps_flags |= PS_WAIT_FOR_BEACON;
> >>
> >> Looks like this patch never made it in.
> >>
> >> Should it be in, or should I just drop it from my queue?
> >>
> >
> > Eh, it shouldn't happen and if we warn we should use the new debugging
> > warn once thingy you added. I never saw that trigger so probably we
> > can just ignore it.
>
> I've been running this patch for months and haven't noticed the
> WARN_ON hit, so probably it's not needed. Of course, I disable
> power-saving..so maybe I'm not a good test case :P
Which is why its OK if this goes in with the debug message thingy
only.
Luis
^ permalink raw reply
* Re: [PATCH 1/5] ath9k: warn when we get a ATH9K_INT_TIM_TIMER and are idle
From: Ben Greear @ 2011-01-19 1:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, johannes, linux-wireless, amod.bodas, pstew
In-Reply-To: <AANLkTi=cWF0UrHG2DXoYp1NLP6F179A6pQ3P-tLFBNTg@mail.gmail.com>
On 01/18/2011 05:38 PM, Luis R. Rodriguez wrote:
> On Tue, Jan 18, 2011 at 5:34 PM, Ben Greear<greearb@candelatech.com> wrote:
>> On 12/06/2010 06:48 PM, Luis R. Rodriguez wrote:
>>>
>>> We should not be idle when we get the ATH9K_INT_TIM_TIMER,
>>> otherwise we wake up the chip and that throws off the idle
>>> state, the driver needs to be in full sleep when idle and
>>> nothing should turn it awake without turning it back to
>>> full sleep again. If we leave the chip idle and suspend,
>>> upon resume the device will become unusable and we get:
>>>
>>> ath: Starting driver with initial channel: 5745 MHz
>>> ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef& 0x00000003 !=
>>> 0x00000000
>>>
>>> Cc: Paul Stewart<pstew@google.com>
>>> Cc: Amod Bodas<amod.bodas@atheros.com>
>>> signed-off-by: Luis R. Rodriguez<lrodriguez@atheros.com>
>>> ---
>>> drivers/net/wireless/ath/ath9k/main.c | 1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c
>>> b/drivers/net/wireless/ath/ath9k/main.c
>>> index f026a03..fd27ec9 100644
>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>> @@ -770,6 +770,7 @@ irqreturn_t ath_isr(int irq, void *dev)
>>> if (status& ATH9K_INT_TIM_TIMER) {
>>> /* Clear RxAbort bit so that we can
>>> * receive frames */
>>> + WARN_ON(sc->ps_idle);
>>> ath9k_setpower(sc, ATH9K_PM_AWAKE);
>>> ath9k_hw_setrxabort(sc->sc_ah, 0);
>>> sc->ps_flags |= PS_WAIT_FOR_BEACON;
>>
>> Looks like this patch never made it in.
>>
>> Should it be in, or should I just drop it from my queue?
>>
>
> Eh, it shouldn't happen and if we warn we should use the new debugging
> warn once thingy you added. I never saw that trigger so probably we
> can just ignore it.
I've been running this patch for months and haven't noticed the
WARN_ON hit, so probably it's not needed. Of course, I disable
power-saving..so maybe I'm not a good test case :P
Thanks,
Ben
>
> Luis
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/5] ath9k: warn when we get a ATH9K_INT_TIM_TIMER and are idle
From: Luis R. Rodriguez @ 2011-01-19 1:38 UTC (permalink / raw)
To: Ben Greear; +Cc: linville, johannes, linux-wireless, amod.bodas, pstew
In-Reply-To: <4D363FBA.3000207@candelatech.com>
On Tue, Jan 18, 2011 at 5:34 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 12/06/2010 06:48 PM, Luis R. Rodriguez wrote:
>>
>> We should not be idle when we get the ATH9K_INT_TIM_TIMER,
>> otherwise we wake up the chip and that throws off the idle
>> state, the driver needs to be in full sleep when idle and
>> nothing should turn it awake without turning it back to
>> full sleep again. If we leave the chip idle and suspend,
>> upon resume the device will become unusable and we get:
>>
>> ath: Starting driver with initial channel: 5745 MHz
>> ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef& 0x00000003 !=
>> 0x00000000
>>
>> Cc: Paul Stewart<pstew@google.com>
>> Cc: Amod Bodas<amod.bodas@atheros.com>
>> signed-off-by: Luis R. Rodriguez<lrodriguez@atheros.com>
>> ---
>> drivers/net/wireless/ath/ath9k/main.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/main.c
>> b/drivers/net/wireless/ath/ath9k/main.c
>> index f026a03..fd27ec9 100644
>> --- a/drivers/net/wireless/ath/ath9k/main.c
>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>> @@ -770,6 +770,7 @@ irqreturn_t ath_isr(int irq, void *dev)
>> if (status& ATH9K_INT_TIM_TIMER) {
>> /* Clear RxAbort bit so that we can
>> * receive frames */
>> + WARN_ON(sc->ps_idle);
>> ath9k_setpower(sc, ATH9K_PM_AWAKE);
>> ath9k_hw_setrxabort(sc->sc_ah, 0);
>> sc->ps_flags |= PS_WAIT_FOR_BEACON;
>
> Looks like this patch never made it in.
>
> Should it be in, or should I just drop it from my queue?
>
Eh, it shouldn't happen and if we warn we should use the new debugging
warn once thingy you added. I never saw that trigger so probably we
can just ignore it.
Luis
^ permalink raw reply
* Re: [PATCH 1/5] ath9k: warn when we get a ATH9K_INT_TIM_TIMER and are idle
From: Ben Greear @ 2011-01-19 1:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, johannes, linux-wireless, amod.bodas, pstew
In-Reply-To: <1291690135-4535-2-git-send-email-lrodriguez@atheros.com>
On 12/06/2010 06:48 PM, Luis R. Rodriguez wrote:
> We should not be idle when we get the ATH9K_INT_TIM_TIMER,
> otherwise we wake up the chip and that throws off the idle
> state, the driver needs to be in full sleep when idle and
> nothing should turn it awake without turning it back to
> full sleep again. If we leave the chip idle and suspend,
> upon resume the device will become unusable and we get:
>
> ath: Starting driver with initial channel: 5745 MHz
> ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef& 0x00000003 != 0x00000000
>
> Cc: Paul Stewart<pstew@google.com>
> Cc: Amod Bodas<amod.bodas@atheros.com>
> signed-off-by: Luis R. Rodriguez<lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/main.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index f026a03..fd27ec9 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -770,6 +770,7 @@ irqreturn_t ath_isr(int irq, void *dev)
> if (status& ATH9K_INT_TIM_TIMER) {
> /* Clear RxAbort bit so that we can
> * receive frames */
> + WARN_ON(sc->ps_idle);
> ath9k_setpower(sc, ATH9K_PM_AWAKE);
> ath9k_hw_setrxabort(sc->sc_ah, 0);
> sc->ps_flags |= PS_WAIT_FOR_BEACON;
Looks like this patch never made it in.
Should it be in, or should I just drop it from my queue?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] ath9k: Try more than one queue when scheduling new aggregate.
From: greearb @ 2011-01-19 1:30 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Try all xmit queues until the hardware buffers are full.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 2ad732d... 5f05a3a... M drivers/net/wireless/ath/ath9k/xmit.c
drivers/net/wireless/ath/ath9k/xmit.c | 64 +++++++++++++++++++--------------
1 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 2ad732d..5f05a3a 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1222,49 +1222,59 @@ void ath_tx_cleanupq(struct ath_softc *sc, struct ath_txq *txq)
sc->tx.txqsetup &= ~(1<<txq->axq_qnum);
}
+/* For each axq_acq entry, for each tid, try to schedule packets
+ * for transmit until ampdu_depth has reached min Q depth.
+ */
void ath_txq_schedule(struct ath_softc *sc, struct ath_txq *txq)
{
- struct ath_atx_ac *ac;
- struct ath_atx_tid *tid, *last;
+ struct ath_atx_ac *ac, *ac_tmp, *last_ac;
+ struct ath_atx_tid *tid, *last_tid;
if (list_empty(&txq->axq_acq) ||
txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH)
return;
ac = list_first_entry(&txq->axq_acq, struct ath_atx_ac, list);
- last = list_entry(ac->tid_q.prev, struct ath_atx_tid, list);
- list_del(&ac->list);
- ac->sched = false;
+ last_ac = list_entry(txq->axq_acq.prev, struct ath_atx_ac, list);
- do {
- if (list_empty(&ac->tid_q))
- return;
+ list_for_each_entry_safe(ac, ac_tmp, &txq->axq_acq, list) {
+ last_tid = list_entry(ac->tid_q.prev, struct ath_atx_tid, list);
+ list_del(&ac->list);
+ ac->sched = false;
- tid = list_first_entry(&ac->tid_q, struct ath_atx_tid, list);
- list_del(&tid->list);
- tid->sched = false;
+ while (!list_empty(&ac->tid_q)) {
+ tid = list_first_entry(&ac->tid_q, struct ath_atx_tid,
+ list);
+ list_del(&tid->list);
+ tid->sched = false;
- if (tid->paused)
- continue;
+ if (tid->paused)
+ continue;
- ath_tx_sched_aggr(sc, txq, tid);
+ ath_tx_sched_aggr(sc, txq, tid);
- /*
- * add tid to round-robin queue if more frames
- * are pending for the tid
- */
- if (!list_empty(&tid->buf_q))
- ath_tx_queue_tid(txq, tid);
+ /*
+ * add tid to round-robin queue if more frames
+ * are pending for the tid
+ */
+ if (!list_empty(&tid->buf_q))
+ ath_tx_queue_tid(txq, tid);
- if (tid == last || txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH)
- break;
- } while (!list_empty(&ac->tid_q));
+ if (tid == last_tid ||
+ txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH)
+ break;
+ }
- if (!list_empty(&ac->tid_q)) {
- if (!ac->sched) {
- ac->sched = true;
- list_add_tail(&ac->list, &txq->axq_acq);
+ if (!list_empty(&ac->tid_q)) {
+ if (!ac->sched) {
+ ac->sched = true;
+ list_add_tail(&ac->list, &txq->axq_acq);
+ }
}
+
+ if (ac == last_ac ||
+ txq->axq_ampdu_depth >= ATH_AGGR_MIN_QDEPTH)
+ return;
}
}
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] ath5k: fix locking in tx_complete_poll_work
From: Bruno Randolf @ 2011-01-19 0:58 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, jirislaby, mickflemm, lrodriguez, linux-wireless,
ath5k-devel
In-Reply-To: <1295356003-1425-1-git-send-email-me@bobcopeland.com>
On Tue January 18 2011 22:06:43 Bob Copeland wrote:
> ath5k_reset must be called with sc->lock. Since the tx queue
> watchdog runs in a workqueue and accesses sc, it's appropriate
> to just take the lock over the whole function.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/base.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index 019a74d..09ae4ef 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -2294,6 +2294,8 @@ ath5k_tx_complete_poll_work(struct work_struct *work)
> int i;
> bool needreset = false;
>
> + mutex_lock(&sc->lock);
> +
> for (i = 0; i < ARRAY_SIZE(sc->txqs); i++) {
> if (sc->txqs[i].setup) {
> txq = &sc->txqs[i];
> @@ -2321,6 +2323,8 @@ ath5k_tx_complete_poll_work(struct work_struct *work)
> ath5k_reset(sc, NULL, true);
> }
>
> + mutex_unlock(&sc->lock);
> +
> ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work,
> msecs_to_jiffies(ATH5K_TX_COMPLETE_POLL_INT));
> }
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [PATCH 1/2] ath9k: try more than one tid when scheduling a new aggregate
From: Ben Greear @ 2011-01-19 0:43 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <4D363165.1010306@openwrt.org>
On 01/18/2011 04:33 PM, Felix Fietkau wrote:
> On 2011-01-19 1:26 AM, Ben Greear wrote:
>> On 01/15/2011 05:30 AM, Felix Fietkau wrote:
>>> Sometimes the first TID in the first AC's list is not available for forming
>>> a new aggregate (the BAW might not allow it), however other TIDs may have
>>> data available for sending.
>>> Prevent a slowdown of other TIDs by going through multiple entries until
>>> we've either hit the last one or enough AMPDUs are pending in the hardware
>>> queue.
>>
>> I had attempted a similar patch, but I was thinking we should iterate
>> through all of the txq->axq_acq entries, not just use the first one?
>>
>> If you agree, I can merge my patch with your patch below
>> and re-post.
> My patch was merged, how about sending an incremental patch on top of it
> for review?
Right...I just wanted to make sure that it was a sane thing to do
before making the effort.
I'll try to get something posted soonish.
Thanks,
Ben
>
> - Felix
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/2] ath9k: try more than one tid when scheduling a new aggregate
From: Felix Fietkau @ 2011-01-19 0:33 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <4D362FC5.3090003@candelatech.com>
On 2011-01-19 1:26 AM, Ben Greear wrote:
> On 01/15/2011 05:30 AM, Felix Fietkau wrote:
>> Sometimes the first TID in the first AC's list is not available for forming
>> a new aggregate (the BAW might not allow it), however other TIDs may have
>> data available for sending.
>> Prevent a slowdown of other TIDs by going through multiple entries until
>> we've either hit the last one or enough AMPDUs are pending in the hardware
>> queue.
>
> I had attempted a similar patch, but I was thinking we should iterate
> through all of the txq->axq_acq entries, not just use the first one?
>
> If you agree, I can merge my patch with your patch below
> and re-post.
My patch was merged, how about sending an incremental patch on top of it
for review?
- Felix
^ permalink raw reply
* net-next-2.6 open for business...
From: David Miller @ 2011-01-19 0:29 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, linux-wireless
It is currently sync'd with net-2.6 and I will start adding
feature and cleanup patches to that tree.
Just FYI...
^ permalink raw reply
* Re: [PATCH 1/2] ath9k: try more than one tid when scheduling a new aggregate
From: Ben Greear @ 2011-01-19 0:26 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <1295098215-98910-1-git-send-email-nbd@openwrt.org>
On 01/15/2011 05:30 AM, Felix Fietkau wrote:
> Sometimes the first TID in the first AC's list is not available for forming
> a new aggregate (the BAW might not allow it), however other TIDs may have
> data available for sending.
> Prevent a slowdown of other TIDs by going through multiple entries until
> we've either hit the last one or enough AMPDUs are pending in the hardware
> queue.
I had attempted a similar patch, but I was thinking we should iterate
through all of the txq->axq_acq entries, not just use the first one?
If you agree, I can merge my patch with your patch below
and re-post.
Thanks,
Ben
>
> Signed-off-by: Felix Fietkau<nbd@openwrt.org>
> ---
> drivers/net/wireless/ath/ath9k/xmit.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index ab4f7b4..fffd13d 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -1224,12 +1224,14 @@ void ath_tx_cleanupq(struct ath_softc *sc, struct ath_txq *txq)
> void ath_txq_schedule(struct ath_softc *sc, struct ath_txq *txq)
> {
> struct ath_atx_ac *ac;
> - struct ath_atx_tid *tid;
> + struct ath_atx_tid *tid, *last;
>
> - if (list_empty(&txq->axq_acq))
> + if (list_empty(&txq->axq_acq) ||
> + txq->axq_ampdu_depth>= ATH_AGGR_MIN_QDEPTH)
> return;
>
> ac = list_first_entry(&txq->axq_acq, struct ath_atx_ac, list);
> + last = list_entry(ac->tid_q.prev, struct ath_atx_tid, list);
> list_del(&ac->list);
> ac->sched = false;
>
> @@ -1253,7 +1255,8 @@ void ath_txq_schedule(struct ath_softc *sc, struct ath_txq *txq)
> if (!list_empty(&tid->buf_q))
> ath_tx_queue_tid(txq, tid);
>
> - break;
> + if (tid == last || txq->axq_ampdu_depth>= ATH_AGGR_MIN_QDEPTH)
> + break;
> } while (!list_empty(&ac->tid_q));
>
> if (!list_empty(&ac->tid_q)) {
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2.6.32.y] hostap_cs: fix sleeping function called from invalid context
From: Tim Gardner @ 2011-01-18 21:10 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: stable, Dominik Brodowski, linux-wireless, linux-pcmcia
In-Reply-To: <20110118154305.GA2448@redhat.com>
On 01/18/2011 08:43 AM, Stanislaw Gruszka wrote:
> On Tue, Jan 18, 2011 at 07:49:33AM -0700, Tim Gardner wrote:
>> Yes - I think this patch is correct. I didn't drill deep enough to
>> notice the GFP_KERNEL memory allocation. However, I think there is
>> still a problem with the interrupt handler which will only be
>> noticed if there is another active device on the same shared
>> interrupt. Shouldn't it return IRQ_NONE? See attached.
>
> I'm not sure. I think kernel could disable interrupt line when IRQ_NONE
> is returned, but line is not shared.
>
I believe it is a shared IRQ, but its been so long since I've worked
with the PCMCIA version of the prism device that I can't remember for
sure. The PCI flavor definitely requests a shared IRQ, and both PCI and
PCMCIA use the same interrupt handler function.
> Generally hostap pcmcia initialization procedure does not look correct.
> It should be rahter rearranged to request irq when we are ready to
> receive it, like that:
>
> ret = pcmcia_enable_device(link);
> if (ret)
> goto failed;
>
> dev->irq = link->irq;
> dev->base_addr = link->resource[0]->start;
>
> ret = pcmcia_request_irq(link, prism2_interrupt);
> if (ret)
> goto failed;
>
> However I'm not sure if pcmcia_enable_device() does not require
> to have pcmcia_request_irq() before?
>
I don't know either, but this device is becoming rare enough that I'm
not gonna lose any sleep over it.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-01-18
From: David Miller @ 2011-01-18 20:51 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110118202135.GA15402@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 18 Jan 2011 15:21:35 -0500
> Here is another batch of fixes intended for 2.6.38. Included are a
> locking fix, and endian fix, a lockdep fix, an error code fix, a memory
> leak fix, a type fix, and a couple of others.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* pull request: wireless-2.6 2010-01-18
From: John W. Linville @ 2011-01-18 20:21 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of fixes intended for 2.6.38. Included are a
locking fix, and endian fix, a lockdep fix, an error code fix, a memory
leak fix, a type fix, and a couple of others.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 16c0f9362433a76f01d174bb8b9c87b9a96198ee:
qeth: l3 hw tx csum circumvent hw bug (2011-01-15 20:45:57 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Amitkumar Karwar (1):
ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro
Axel Lin (1):
iwmc3200wifi: Return proper error for iwm_if_alloc
Bob Copeland (1):
ath5k: fix locking in tx_complete_poll_work
Jesper Juhl (1):
rt2x00: Don't leak mem in error path of rt2x00lib_request_firmware()
Johannes Berg (1):
mac80211: fix lockdep warning
Luciano Coelho (1):
mac80211: use maximum number of AMPDU frames as default in BA RX
Luis R. Rodriguez (1):
ath9k_hw: ASPM interoperability fix for AR9380/AR9382
Rajkumar Manoharan (2):
ath9k_htc: Fix endian issue in tx header
ath9k_hw: do PA offset calibration only on longcal interval
Wey-Yi Guy (1):
iwlwifi: fix valid chain reading from EEPROM
drivers/net/wireless/ath/ath5k/base.c | 4 ++++
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 10 +++++-----
.../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 4 ++--
drivers/net/wireless/ath/ath9k/htc.h | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 8 +++++---
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 2 +-
drivers/net/wireless/iwmc3200wifi/netdev.c | 2 ++
drivers/net/wireless/rt2x00/rt2x00firmware.c | 1 +
include/linux/ieee80211.h | 2 +-
net/mac80211/agg-rx.c | 11 ++---------
net/mac80211/main.c | 12 +++++++++++-
12 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 019a74d..09ae4ef 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2294,6 +2294,8 @@ ath5k_tx_complete_poll_work(struct work_struct *work)
int i;
bool needreset = false;
+ mutex_lock(&sc->lock);
+
for (i = 0; i < ARRAY_SIZE(sc->txqs); i++) {
if (sc->txqs[i].setup) {
txq = &sc->txqs[i];
@@ -2321,6 +2323,8 @@ ath5k_tx_complete_poll_work(struct work_struct *work)
ath5k_reset(sc, NULL, true);
}
+ mutex_unlock(&sc->lock);
+
ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work,
msecs_to_jiffies(ATH5K_TX_COMPLETE_POLL_INT));
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index ea2e7d7..5e300bd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -679,10 +679,6 @@ static bool ar9002_hw_calibrate(struct ath_hw *ah,
/* Do NF cal only at longer intervals */
if (longcal || nfcal_pending) {
- /* Do periodic PAOffset Cal */
- ar9002_hw_pa_cal(ah, false);
- ar9002_hw_olc_temp_compensation(ah);
-
/*
* Get the value from the previous NF cal and update
* history buffer.
@@ -697,8 +693,12 @@ static bool ar9002_hw_calibrate(struct ath_hw *ah,
ath9k_hw_loadnf(ah, ah->curchan);
}
- if (longcal)
+ if (longcal) {
ath9k_hw_start_nfcal(ah, false);
+ /* Do periodic PAOffset Cal */
+ ar9002_hw_pa_cal(ah, false);
+ ar9002_hw_olc_temp_compensation(ah);
+ }
}
return iscaldone;
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h b/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
index 81f9cf2..9ecca93 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
@@ -1842,7 +1842,7 @@ static const u32 ar9300_2p2_soc_preamble[][2] = {
static const u32 ar9300PciePhy_pll_on_clkreq_disable_L1_2p2[][2] = {
/* Addr allmodes */
- {0x00004040, 0x08212e5e},
+ {0x00004040, 0x0821265e},
{0x00004040, 0x0008003b},
{0x00004044, 0x00000000},
};
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_hw.c b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
index 6137634..06fb2c8 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
@@ -146,8 +146,8 @@ static void ar9003_hw_init_mode_regs(struct ath_hw *ah)
/* Sleep Setting */
INIT_INI_ARRAY(&ah->iniPcieSerdesLowPower,
- ar9300PciePhy_clkreq_enable_L1_2p2,
- ARRAY_SIZE(ar9300PciePhy_clkreq_enable_L1_2p2),
+ ar9300PciePhy_pll_on_clkreq_disable_L1_2p2,
+ ARRAY_SIZE(ar9300PciePhy_pll_on_clkreq_disable_L1_2p2),
2);
/* Fast clock modal settings */
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index 1ce506f..780ac5e 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -78,7 +78,7 @@ struct tx_frame_hdr {
u8 node_idx;
u8 vif_idx;
u8 tidno;
- u32 flags; /* ATH9K_HTC_TX_* */
+ __be32 flags; /* ATH9K_HTC_TX_* */
u8 key_type;
u8 keyix;
u8 reserved[26];
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 33f3602..7a5ffca 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -113,6 +113,7 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv, struct sk_buff *skb)
if (ieee80211_is_data(fc)) {
struct tx_frame_hdr tx_hdr;
+ u32 flags = 0;
u8 *qc;
memset(&tx_hdr, 0, sizeof(struct tx_frame_hdr));
@@ -136,13 +137,14 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv, struct sk_buff *skb)
/* Check for RTS protection */
if (priv->hw->wiphy->rts_threshold != (u32) -1)
if (skb->len > priv->hw->wiphy->rts_threshold)
- tx_hdr.flags |= ATH9K_HTC_TX_RTSCTS;
+ flags |= ATH9K_HTC_TX_RTSCTS;
/* CTS-to-self */
- if (!(tx_hdr.flags & ATH9K_HTC_TX_RTSCTS) &&
+ if (!(flags & ATH9K_HTC_TX_RTSCTS) &&
(priv->op_flags & OP_PROTECT_ENABLE))
- tx_hdr.flags |= ATH9K_HTC_TX_CTSONLY;
+ flags |= ATH9K_HTC_TX_CTSONLY;
+ tx_hdr.flags = cpu_to_be32(flags);
tx_hdr.key_type = ath9k_cmn_get_hw_crypto_keytype(skb);
if (tx_hdr.key_type == ATH9K_KEY_TYPE_CLEAR)
tx_hdr.keyix = (u8) ATH9K_TXKEYIX_INVALID;
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index 97906dd..14ceb4d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -168,7 +168,7 @@ int iwl_eeprom_check_sku(struct iwl_priv *priv)
/* not using .cfg overwrite */
radio_cfg = iwl_eeprom_query16(priv, EEPROM_RADIO_CONFIG);
priv->cfg->valid_tx_ant = EEPROM_RF_CFG_TX_ANT_MSK(radio_cfg);
- priv->cfg->valid_rx_ant = EEPROM_RF_CFG_TX_ANT_MSK(radio_cfg);
+ priv->cfg->valid_rx_ant = EEPROM_RF_CFG_RX_ANT_MSK(radio_cfg);
if (!priv->cfg->valid_tx_ant || !priv->cfg->valid_rx_ant) {
IWL_ERR(priv, "Invalid chain (0X%x, 0X%x)\n",
priv->cfg->valid_tx_ant,
diff --git a/drivers/net/wireless/iwmc3200wifi/netdev.c b/drivers/net/wireless/iwmc3200wifi/netdev.c
index 13a69eb..5091d77 100644
--- a/drivers/net/wireless/iwmc3200wifi/netdev.c
+++ b/drivers/net/wireless/iwmc3200wifi/netdev.c
@@ -126,6 +126,7 @@ void *iwm_if_alloc(int sizeof_bus, struct device *dev,
ndev = alloc_netdev_mq(0, "wlan%d", ether_setup, IWM_TX_QUEUES);
if (!ndev) {
dev_err(dev, "no memory for network device instance\n");
+ ret = -ENOMEM;
goto out_priv;
}
@@ -138,6 +139,7 @@ void *iwm_if_alloc(int sizeof_bus, struct device *dev,
GFP_KERNEL);
if (!iwm->umac_profile) {
dev_err(dev, "Couldn't alloc memory for profile\n");
+ ret = -ENOMEM;
goto out_profile;
}
diff --git a/drivers/net/wireless/rt2x00/rt2x00firmware.c b/drivers/net/wireless/rt2x00/rt2x00firmware.c
index f0e1eb7..be0ff78 100644
--- a/drivers/net/wireless/rt2x00/rt2x00firmware.c
+++ b/drivers/net/wireless/rt2x00/rt2x00firmware.c
@@ -58,6 +58,7 @@ static int rt2x00lib_request_firmware(struct rt2x00_dev *rt2x00dev)
if (!fw || !fw->size || !fw->data) {
ERROR(rt2x00dev, "Failed to read Firmware.\n");
+ release_firmware(fw);
return -ENOENT;
}
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 6042228..294169e 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -959,7 +959,7 @@ struct ieee80211_ht_info {
/* block-ack parameters */
#define IEEE80211_ADDBA_PARAM_POLICY_MASK 0x0002
#define IEEE80211_ADDBA_PARAM_TID_MASK 0x003C
-#define IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFA0
+#define IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFC0
#define IEEE80211_DELBA_PARAM_TID_MASK 0xF000
#define IEEE80211_DELBA_PARAM_INITIATOR_MASK 0x0800
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index f138b19..227ca82 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -185,8 +185,6 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
struct ieee80211_mgmt *mgmt,
size_t len)
{
- struct ieee80211_hw *hw = &local->hw;
- struct ieee80211_conf *conf = &hw->conf;
struct tid_ampdu_rx *tid_agg_rx;
u16 capab, tid, timeout, ba_policy, buf_size, start_seq_num, status;
u8 dialog_token;
@@ -231,13 +229,8 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
goto end_no_lock;
}
/* determine default buffer size */
- if (buf_size == 0) {
- struct ieee80211_supported_band *sband;
-
- sband = local->hw.wiphy->bands[conf->channel->band];
- buf_size = IEEE80211_MIN_AMPDU_BUF;
- buf_size = buf_size << sband->ht_cap.ampdu_factor;
- }
+ if (buf_size == 0)
+ buf_size = IEEE80211_MAX_AMPDU_BUF;
/* examine state machine */
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 485d36b..a46ff06 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -39,6 +39,8 @@ module_param(ieee80211_disable_40mhz_24ghz, bool, 0644);
MODULE_PARM_DESC(ieee80211_disable_40mhz_24ghz,
"Disable 40MHz support in the 2.4GHz band");
+static struct lock_class_key ieee80211_rx_skb_queue_class;
+
void ieee80211_configure_filter(struct ieee80211_local *local)
{
u64 mc;
@@ -569,7 +571,15 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
spin_lock_init(&local->filter_lock);
spin_lock_init(&local->queue_stop_reason_lock);
- skb_queue_head_init(&local->rx_skb_queue);
+ /*
+ * The rx_skb_queue is only accessed from tasklets,
+ * but other SKB queues are used from within IRQ
+ * context. Therefore, this one needs a different
+ * locking class so our direct, non-irq-safe use of
+ * the queue's lock doesn't throw lockdep warnings.
+ */
+ skb_queue_head_init_class(&local->rx_skb_queue,
+ &ieee80211_rx_skb_queue_class);
INIT_DELAYED_WORK(&local->scan_work, ieee80211_scan_work);
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Compat-wireless release for 2011-01-18 is baked
From: Compat-wireless cronjob account @ 2011-01-18 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
3281fc3..8ffd020 history -> origin/history
+ f6c6cea...a4e85a5 master -> origin/master (forced update)
8a335bc..9e8a462 stable -> origin/stable
* [new tag] next-20110118 -> next-20110118
compat-wireless code metrics
782522 - Total upstream lines of code being pulled
2103 - backport code changes
1843 - backport code additions
260 - backport code deletions
7279 - backport from compat module
9382 - total backport code
1.1989 - % of code consists of backport work
1531 - Crap changes not yet posted
1488 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.1956 - % of crap code
Base tree: linux-next.git
Base tree version: next-20110118
compat-wireless release: compat-wireless-2011-01-06-3-g8db1608-pc
^ permalink raw reply
* [PATCH v2] wl12xx: Add channel 14 to list of supported 2ghz channels
From: Arik Nemtsov @ 2011-01-18 19:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho, Arik Nemtsov
Channel 14 is only supported in Japan (JP country code in).
The FW limits tranmissions to CCK only on this channel.
Tested in both STA and AP modes to work correctly.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
drivers/net/wireless/wl12xx/main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 9076555..59582ab 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -2771,6 +2771,7 @@ static struct ieee80211_channel wl1271_channels[] = {
{ .hw_value = 11, .center_freq = 2462, .max_power = 25 },
{ .hw_value = 12, .center_freq = 2467, .max_power = 25 },
{ .hw_value = 13, .center_freq = 2472, .max_power = 25 },
+ { .hw_value = 14, .center_freq = 2484, .max_power = 25 },
};
/* mapping to indexes for wl1271_rates */
--
1.7.1
^ permalink raw reply related
* Re: Does linux wireless support TL-WN861N
From: JD @ 2011-01-18 19:41 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTinS784Pw27axvMty578tK=gmvVoFGp6iUQNL7V3@mail.gmail.com>
On 01/18/2011 11:23 AM, Rafał Miłecki wrote:
> 2011/1/18 JD<jd1008@gmail.com>:
>> TP-Link TL-WN861N
>> see
>> http://www.tp-link.com/products/productDetails.asp?class=&content=spe&pmodel=TL-WN861N
> https://forum.openwrt.org/viewtopic.php?id=25431
> http://www.wikidevi.com/wiki/TP-LINK_TL-WN861N_v2
>
> Both sources tell about AR9223 chipset, but I is not mentioned on
> http://wireless.kernel.org/en/users/Drivers/ath9k
>
> Maybe someone from ath9k ML knows it? Or try to Google it.
>
Thanx Rafal.
I did find it listed on
http://wireless.kernel.org/en/users/Drivers/ath9k/products/external?highlight=%28TL-WN861N%29
However, I also found out that it has very very poor Rx sensitivity
(only -68 dBm) at 11g,
and much much less at 11N. My location relative to AP is very bad. I
need a card supported
by ath9k and with Rx sensitivity that can go all the way to -97dBm.
Cheers,
JD
^ permalink raw reply
* RE: [PATCH] mwifiex: remove duplicated NULL checks
From: Bing Zhao @ 2011-01-18 19:32 UTC (permalink / raw)
To: Julian Calaby
Cc: linux-wireless@vger.kernel.org, John W. Linville, Johannes Berg,
Amitkumar Karwar, Kiran Divekar, Frank Huang
In-Reply-To: <AANLkTi=UfKkYcX6CF9bQ84+anr74DKS-tXuH61NASObf@mail.gmail.com>
Hi Julian,
> -----Original Message-----
> From: Julian Calaby [mailto:julian.calaby@gmail.com]
> Sent: Monday, January 17, 2011 7:26 PM
> To: Bing Zhao
> Cc: linux-wireless@vger.kernel.org; John W. Linville; Johannes Berg; Amitkumar Karwar; Kiran Divekar;
> Frank Huang
> Subject: Re: [PATCH] mwifiex: remove duplicated NULL checks
>
> On Tue, Jan 18, 2011 at 14:07, Bing Zhao <bzhao@marvell.com> wrote:
> > Hi Julian,
> >
> >> -----Original Message-----
> >> From: Julian Calaby [mailto:julian.calaby@gmail.com]
> >> Sent: Friday, January 14, 2011 6:59 PM
> >> To: Bing Zhao
> >> Cc: linux-wireless@vger.kernel.org; John W. Linville; Johannes Berg; Amitkumar Karwar; Kiran
> Divekar;
> >> Frank Huang
> >> Subject: Re: [PATCH] mwifiex: remove duplicated NULL checks
> >>
> >> On Sat, Jan 15, 2011 at 06:36, Bing Zhao <bzhao@marvell.com> wrote:
> >> > From: Amitkumar Karwar <akarwar@marvell.com>
> >> >
> >> > Some functions have unnecessory NULL check for an input parameter
> >> > because the caller to those functions is already checking the parameter
> >> > for NULL before calling them.
> >>
> >> It may be more readable and efficient to eliminate the NULL checks in
> >> the callers - and adjust the code to inform the callers of the case
> >> where the pointer passed is null and make the callers to properly
> >> handle this case.
> >
> > Thank you very much for your comments.
> >
> > There are still some cases that the NULL check needs to be done at the first place. For example,
> >
> [snip]
>
> In this case, dropping the null check is the right thing to do, given
> that you can guarantee that all callers of mwiflex_init_cmd_node()
> will check that the pointer isn't null before calling it.
>
> >> This should also make the driver more robust as failures can be passed
> >> up the stack to places that can deal with them more effectively than
> >> just printing a message.
> >
> > I could have misunderstood your point, however. If so, could you please explain a little bit more
> on how you would make the changes based on above example?
>
> I was referring more to that fact that functions that appear to do
> things, e.g. mwifiex_init_cmd_node(), don't return anything - hence if
> something fails within them, e.g. being passed a null pointer, they
> can't notify their caller, e.g. mwifiex_prepare_cmd() that something
> has gone wrong.
>
> That said, I haven't looked at the code except through your patches,
> so I can't say if this is a scenario that actually could happen, and
> whether this added functionality is worthwhile.
Thanks for your comments.
mwifiex_init_cmd_node() just initializes the cmd_node structure with variables that have been validated before. But what you said makes sense in general. The function should return something to the caller if anything can go wrong.
Best regards,
Bing
>
> Thanks,
>
> --
> Julian Calaby
>
> Email: julian.calaby@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
> .Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: Fwd: [PATCH 06/10] mac80211: add HW flag for disabling auto link-PS in AP mode
From: Arik Nemtsov @ 2011-01-18 19:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luciano Coelho
In-Reply-To: <1295341531.3563.4.camel@jlt3.sipsolutions.net>
On Tue, Jan 18, 2011 at 11:05, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2011-01-18 at 00:47 +0200, Arik Nemtsov wrote:
>
>
> Well if for instance the station happens to send two frames with the PM
> bit set, meaning that it is in PS-poll mode but doesn't want to wake up
> even though it's transmitting a frame, mac80211 will only call
> sta_notify once for the first frame to tell the driver the station went
> to sleep -- the second frame just indicates that it's still asleep.
>
> The same might happen with this, but of course it depends on what the
> device does. If the driver will call the new API function twice, then
> mac80211 will be very confused. Therefore, I think the new API function
> should do some checks about whether the station is already asleep/awake
> before invoking ap_sta_ps_start/end so that the counters are correct.
>
> In this case, the driver might want to know if the station was already
> in the indicated state -- this might be indicated by the return value.
>
Yea i missed the double atomic_inc/dec in case the function is called
twice. I'll add a EINVAL return value in case the requested PM state
is already in effect.
Thanks,
Arik
^ permalink raw reply
* Re: Does linux wireless support TL-WN861N
From: Rafał Miłecki @ 2011-01-18 19:23 UTC (permalink / raw)
To: JD; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <4D35E5FD.8030804@gmail.com>
2011/1/18 JD <jd1008@gmail.com>:
> TP-Link TL-WN861N
> see
> http://www.tp-link.com/products/productDetails.asp?class=&content=spe&pmodel=TL-WN861N
https://forum.openwrt.org/viewtopic.php?id=25431
http://www.wikidevi.com/wiki/TP-LINK_TL-WN861N_v2
Both sources tell about AR9223 chipset, but I is not mentioned on
http://wireless.kernel.org/en/users/Drivers/ath9k
Maybe someone from ath9k ML knows it? Or try to Google it.
--
Rafał
^ permalink raw reply
* Does linux wireless support TL-WN861N
From: JD @ 2011-01-18 19:11 UTC (permalink / raw)
To: linux-wireless
TP-Link TL-WN861N
see
http://www.tp-link.com/products/productDetails.asp?class=&content=spe&pmodel=TL-WN861N
^ 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