* [PATCH] ath9k_hw: enable PCIe low power mode for AR9003
From: Luis R. Rodriguez @ 2010-05-07 22:23 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Paul Shaw, Don Breslin
Cc: Paul Shaw <paul.shaw@atheros.com>
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 5590192..c33f17d 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -574,6 +574,26 @@ static int __ath9k_hw_init(struct ath_hw *ah)
ath9k_hw_init_mode_regs(ah);
+ /*
+ * Configire PCIE after Ini init. SERDES values now come from ini file
+ * This enables PCIe low power mode.
+ */
+ if (AR_SREV_9300_20_OR_LATER(ah)) {
+ u32 regval;
+ unsigned int i;
+
+ /* Set Bits 16 and 17 in the AR_WA register. */
+ regval = REG_READ(ah, AR_WA);
+ regval |= 0x00030000;
+ REG_WRITE(ah, AR_WA, regval);
+
+ for (i = 0; i < ah->iniPcieSerdesLowPower.ia_rows; i++) {
+ REG_WRITE(ah,
+ INI_RA(&ah->iniPcieSerdesLowPower, i, 0),
+ INI_RA(&ah->iniPcieSerdesLowPower, i, 1));
+ }
+ }
+
if (ah->is_pciexpress)
ath9k_hw_configpcipowersave(ah, 0, 0);
else
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] mac80211: set IEEE80211_TX_CTL_FIRST_FRAGMENT for beacons
From: Luis R. Rodriguez @ 2010-05-07 21:43 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100507023519.GA7240@tuxdriver.com>
On Thu, May 6, 2010 at 7:35 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Thu, May 06, 2010 at 08:13:20PM -0400, John W. Linville wrote:
>> On Thu, May 06, 2010 at 03:01:25PM -0700, Luis R. Rodriguez wrote:
>> > On Thu, May 6, 2010 at 11:45 AM, John W. Linville
>> > <linville@tuxdriver.com> wrote:
>> >
>> > Why though?
>>
>> Because it is correct, appropriate, and zero additional cost. And
>> because if you use the same tx path for beacons as you use for normal
>> frames and if in that path you manage the sequence number in software
>> you should be checking that flag before bumping the sequence number.
>
> That isn't worded too clearly... If you manage the sequence number
> in software then you should be checking that flag before bumping
> the sequence number. If you use the same tx path for beacons as is
> used for normal frames and you don't set that flag for beacons,
> then beacons will reuse the sequence number from the previous frame.
>
> Does that make sense?
Yeah, thanks, perhaps the documentation should be expanded for this on
the mac80211.h. This verbiage might also come in handy on the commit
log. What do you think?
Luis
^ permalink raw reply
* Re: Packet injection with ath9k
From: Roberto Riggio @ 2010-05-07 19:09 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: linux-wireless
In-Reply-To: <j2v69e28c911005070935wb720d757labf3a0484aedefb8@mail.gmail.com>
Hi,
well, that is what i wanted to understand. These are the struct
that I'm using to compose the rediotap header:
struct ieee80211_radiotap_header {
u_int8_t it_version;
u_int8_t it_pad;
u_int16_t it_len;
u_int32_t it_present;
} __attribute__((__packed__));
struct click_radiotap_header {
struct ieee80211_radiotap_header wt_ihdr;
u_int8_t wt_rate;
u_int8_t wt_txpower;
u_int8_t wt_rts_retries;
u_int8_t wt_data_retries;
};
The flags are set in order to take into account the fields that I
specify. But i do not know at which point the frame are
dropped.
R.
On 05/07/2010 06:35 PM, Gábor Stefanik wrote:
> Hi!
> Are you sure it is not your injector that is having alignment issues?
> AFAIK the radiotap parser explicitly uses endianness-aware function
> everywhere.
>
> On Fri, May 7, 2010 at 6:13 PM, Roberto Riggio
> <roberto.riggio@create-net.org> wrote:
>
>> Hi,
>>
>> I'm writing an application to inject traffic over a wireless interface. This
>> app
>> is working fine on an x86 machine. However if i compile the same app for
>> an arm platform, no frame are sent over the wireless interface (ath9k).
>>
>> I'm guessing that this is because of some alignment issues but i cannot
>> track
>> the piece of code that is actually parsing the frame. I've found the
>> __ieee80211_parse_tx_radiotap in net/mac80211/tx.c function, but it is
>> not called when i try to inject some traffic, so the frame are dropped
>> before that.
>>
>> Any hints?
>>
>> Thanks
>> R.
>> --
>> 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
>>
>>
>
>
>
^ permalink raw reply
* Re: Packet injection with ath9k
From: Gábor Stefanik @ 2010-05-07 16:35 UTC (permalink / raw)
To: Roberto Riggio; +Cc: linux-wireless
In-Reply-To: <4BE43C18.2030806@create-net.org>
Hi!
Are you sure it is not your injector that is having alignment issues?
AFAIK the radiotap parser explicitly uses endianness-aware function
everywhere.
On Fri, May 7, 2010 at 6:13 PM, Roberto Riggio
<roberto.riggio@create-net.org> wrote:
> Hi,
>
> I'm writing an application to inject traffic over a wireless interface. This
> app
> is working fine on an x86 machine. However if i compile the same app for
> an arm platform, no frame are sent over the wireless interface (ath9k).
>
> I'm guessing that this is because of some alignment issues but i cannot
> track
> the piece of code that is actually parsing the frame. I've found the
> __ieee80211_parse_tx_radiotap in net/mac80211/tx.c function, but it is
> not called when i try to inject some traffic, so the frame are dropped
> before that.
>
> Any hints?
>
> Thanks
> R.
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: The case of the bogus SSID
From: Javier Cardona @ 2010-05-07 16:29 UTC (permalink / raw)
To: pigiron; +Cc: Steve deRosier, linux-wireless
In-Reply-To: <20100506215613.43477434@atom.pigiron.org>
Hi,
On Thu, May 6, 2010 at 7:56 PM, pigiron <pigiron@gmx.com> wrote:
> On Thu, 6 May 2010 11:12:15 -0700 Steve deRosier <steve@cozybit.com> wrote:
>
>> On Wed, May 5, 2010 at 10:01 AM, pigiron <pigiron@gmx.com> wrote:
>> > I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the
>> > ieee80211.h file, and recently the same 52 was also assigned to
>> > WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{} structure.
>> >
>>
>> I can't answer the rest of your question, but AFAIK, the element IDs
>> for 802.11s mesh haven't been approved yet as the 802.11s draft
>> contains a note to that effect. The current ANA database sheet I
>> could find (Feb 2010) does have 52 assigned to Neighbor Report, and
>> the mesh element IDs are nowhere to be found.
>>
> I agree. The 802.11k-2008 standard has already been approved with Element ID
> 52 = Neighbor Report, so it's probably almost a guarantee that 802.11s won't be
> assigning 52 to anything in the future.
>
> I'm kind of stuck on this problem. I could probably find out what's causing the
> failure and create a patch... but the patch wouldn't be "The Right Thing To
> Do(tm)" if the router isn't supposed to be spewing that data to begin with.
I don't know about the router, nor if the IE ID clash is causing your
problem, but moving the mesh codes somewhere else in the unassigned ID
space would be a "A Good Thing To Do (tm)".
Cheers,
Javier
^ permalink raw reply
* Packet injection with ath9k
From: Roberto Riggio @ 2010-05-07 16:13 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm writing an application to inject traffic over a wireless interface.
This app
is working fine on an x86 machine. However if i compile the same app for
an arm platform, no frame are sent over the wireless interface (ath9k).
I'm guessing that this is because of some alignment issues but i cannot
track
the piece of code that is actually parsing the frame. I've found the
__ieee80211_parse_tx_radiotap in net/mac80211/tx.c function, but it is
not called when i try to inject some traffic, so the frame are dropped
before that.
Any hints?
Thanks
R.
^ permalink raw reply
* Re: 2.6.34-rc6 pci bridge problems
From: Bjorn Helgaas @ 2010-05-07 15:46 UTC (permalink / raw)
To: Christian Lamparter; +Cc: dhlii, linux-wireless, linux-kernel, linux-pci
In-Reply-To: <201005060909.58503.bjorn.helgaas@hp.com>
On Thursday, May 06, 2010 09:09:58 am Bjorn Helgaas wrote:
> On Wednesday, May 05, 2010 01:59:55 pm Christian Lamparter wrote:
> > On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> > > When I build out of the wireless-testing git tree (puled today)
> > > 2.6.34-rc6 using my current systems .config I get a very quick error
> > > on boot about PCI bridge windows.
> > > googling the error indicates this is a know 2.6.34 problem and that
> > > there are fixes in other 2.6.34 trees.
> > > I have been unable to find the actual patches or I would just apply
> > > them to wireless-testing.
>
> I made significant changes in the way we handle PCI bridge windows,
> and I'm eager to fix any issues in that area. But "very quick error
> on boot" doesn't give me any information to work with.
>
> Please attach your complete dmesg output, serial console log (with
> "ignore_loglevel"), digital photo of the error, or other specific
> details.
Ping! If there's a problem here, I want to fix it as soon as possible.
Do you have any more details? What error message did you google?
Thanks,
Bjorn
^ permalink raw reply
* Re: rt61pci: WEP broken in current wireless-testing
From: Pavel Roskin @ 2010-05-07 13:24 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless
In-Reply-To: <4BE3ABB0.9040506@gmail.com>
Quoting Gertjan van Wingerde <gwingerde@gmail.com>:
> It might be that one of my recent patches broke this. Can you try the
> attached patch?
I'm not sure I'll be able to test it before Monday.
But the patch looks good. If the encrypted Tx is broken, it would be
entirely consistent with my observations (monitor mode works,
association works, but no data flowing).
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCHv2] rt2x00: rt2800: use correct txop value in tx descriptor
From: Gertjan van Wingerde @ 2010-05-07 11:04 UTC (permalink / raw)
To: Helmut Schaa, John Linville; +Cc: linux-wireless, Ivo van Doorn
In-Reply-To: <201005071103.08186.helmut.schaa@googlemail.com>
On 05/07/10 11:03, Helmut Schaa wrote:
> rt2800 devices use a different enumeration to specify what IFS values should
> be used on frame transmission compared to the other rt2x00 devices. Hence,
> create a new enum called txop that contains the valid values.
>
> Furthermore use the appropriate txop values as found in the ralink drivers:
> - TXOP_BACKOFF for management frames
> - TXOP_SIFS for subsequent fragments in a burst
> - TXOP_HTTXOP for all data frames
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Thanks for doing the proper patch.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
> drivers/net/wireless/rt2x00/rt2x00ht.c | 17 +++++++++++++++++
> drivers/net/wireless/rt2x00/rt2x00queue.h | 2 ++
> drivers/net/wireless/rt2x00/rt2x00reg.h | 10 ++++++++++
> 5 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
> index f08b6a3..df2c3fb 100644
> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
> @@ -643,7 +643,7 @@ static int rt2800pci_write_tx_data(struct queue_entry* entry,
> rt2x00_set_field32(&word, TXWI_W0_AMPDU,
> test_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags));
> rt2x00_set_field32(&word, TXWI_W0_MPDU_DENSITY, txdesc->mpdu_density);
> - rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->ifs);
> + rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->txop);
> rt2x00_set_field32(&word, TXWI_W0_MCS, txdesc->mcs);
> rt2x00_set_field32(&word, TXWI_W0_BW,
> test_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags));
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index e3f3a97..c9e1320 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -417,7 +417,7 @@ static void rt2800usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
> rt2x00_set_field32(&word, TXWI_W0_AMPDU,
> test_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags));
> rt2x00_set_field32(&word, TXWI_W0_MPDU_DENSITY, txdesc->mpdu_density);
> - rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->ifs);
> + rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->txop);
> rt2x00_set_field32(&word, TXWI_W0_MCS, txdesc->mcs);
> rt2x00_set_field32(&word, TXWI_W0_BW,
> test_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags));
> diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> index 1056c92..5a40760 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> @@ -35,6 +35,7 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> {
> struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(entry->skb);
> struct ieee80211_tx_rate *txrate = &tx_info->control.rates[0];
> + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)entry->skb->data;
>
> if (tx_info->control.sta)
> txdesc->mpdu_density =
> @@ -66,4 +67,20 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> +
> + /*
> + * Determine IFS values
> + * - Use TXOP_BACKOFF for management frames
> + * - Use TXOP_SIFS for fragment bursts
> + * - Use TXOP_HTTXOP for everything else
> + *
> + * Note: rt2800 devices won't use CTS protection (if used)
> + * for frames not transmitted with TXOP_HTTXOP
> + */
> + if (ieee80211_is_mgmt(hdr->frame_control))
> + txdesc->txop = TXOP_BACKOFF;
> + else if (!(tx_info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT))
> + txdesc->txop = TXOP_SIFS;
> + else
> + txdesc->txop = TXOP_HTTXOP;
> }
> diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
> index 94a48c1..36a957a 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00queue.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
> @@ -299,6 +299,7 @@ enum txentry_desc_flags {
> * @retry_limit: Max number of retries.
> * @aifs: AIFS value.
> * @ifs: IFS value.
> + * @txop: IFS value for 11n capable chips.
> * @cw_min: cwmin value.
> * @cw_max: cwmax value.
> * @cipher: Cipher type used for encryption.
> @@ -328,6 +329,7 @@ struct txentry_desc {
> short retry_limit;
> short aifs;
> short ifs;
> + short txop;
> short cw_min;
> short cw_max;
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00reg.h b/drivers/net/wireless/rt2x00/rt2x00reg.h
> index 603bfc0..b9fe948 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00reg.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00reg.h
> @@ -101,6 +101,16 @@ enum ifs {
> };
>
> /*
> + * IFS backoff values for HT devices
> + */
> +enum txop {
> + TXOP_HTTXOP = 0,
> + TXOP_PIFS = 1,
> + TXOP_SIFS = 2,
> + TXOP_BACKOFF = 3,
> +};
> +
> +/*
> * Cipher types for hardware encryption
> */
> enum cipher {
^ permalink raw reply
* ath5k deadlock w/ blob transfer
From: Nils Radtke @ 2010-05-07 10:50 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel
Hi,
Guess, this is better suited in here:
> - ath5k: when starting a blob transfer eg. ssh summer.jpg to the
> notebook with the ath5k driver running, the wNIC freezes almost
> immediately! Dead device. This is unfortunately too easily reproducible.
> In fact, this is a blocker, wireless blob transfer via ssh (other means
> not tested) is not possible w/o locking it up.
But wait! I just remembered another case. Using the (incomprehensibly) "obsolete"
madwifi diver (note aside: this driver _does_ reduce the _felt_ deadlock frequency
or kernel panics, referenced by http://lkml.org/lkml/2010/5/3/229, but not
entirely make them go away). It evenly locks the wireless NIC while transferring
blobs.
So where should I be posting this? When both drivers deadlock it's either a common
base in the wireless driver premisses or yet up the path somewhere in the kernel code.
Ideas?
Thanks,
Nils
^ permalink raw reply
* Re: [PATCHv2] rt2x00: rt2800: use correct txop value in tx descriptor
From: Helmut Schaa @ 2010-05-07 10:48 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <u2ia32f33a41005070333m4c3b4831q2d0afa42c3669807@mail.gmail.com>
Am Freitag 07 Mai 2010 schrieb Ivo Van Doorn:
> On Fri, May 7, 2010 at 11:48 AM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
> > I guess you mean rt2x00queue_create_tx_descriptor in rt2x00queue.c, right?
> > It's not exactly the same but at least the check for the first fragment are
> > there already. We could also move it there. Why I've decided to put it in
> > rt2x00ht.c is because it only applies to HT devices ;)
> >
> > If you'd prefer to have it in rt2x00queue I'm glad to resend.
>
> Ah true this is HT stuff only. I'll look into the exact code later, and perhaps
> I'll update it later. But this patch can be merged:
>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Ok, thanks for the quick review.
Helmut
^ permalink raw reply
* Re: [PATCHv2] rt2x00: rt2800: use correct txop value in tx descriptor
From: Ivo Van Doorn @ 2010-05-07 10:33 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005071148.12280.helmut.schaa@googlemail.com>
On Fri, May 7, 2010 at 11:48 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Am Freitag 07 Mai 2010 schrieb Ivo Van Doorn:
>> Hi,
>>
>>
>> > diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
>> > index 1056c92..5a40760 100644
>> > --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
>> > +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
>> > @@ -35,6 +35,7 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
>> > {
>> > struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(entry->skb);
>> > struct ieee80211_tx_rate *txrate = &tx_info->control.rates[0];
>> > + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)entry->skb->data;
>> >
>> > if (tx_info->control.sta)
>> > txdesc->mpdu_density =
>> > @@ -66,4 +67,20 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
>> > __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
>> > if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
>> > __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
>> > +
>> > + /*
>> > + * Determine IFS values
>> > + * - Use TXOP_BACKOFF for management frames
>> > + * - Use TXOP_SIFS for fragment bursts
>> > + * - Use TXOP_HTTXOP for everything else
>> > + *
>> > + * Note: rt2800 devices won't use CTS protection (if used)
>> > + * for frames not transmitted with TXOP_HTTXOP
>> > + */
>> > + if (ieee80211_is_mgmt(hdr->frame_control))
>> > + txdesc->txop = TXOP_BACKOFF;
>> > + else if (!(tx_info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT))
>> > + txdesc->txop = TXOP_SIFS;
>> > + else
>> > + txdesc->txop = TXOP_HTTXOP;
>>
>> I can't check it right now, but I am sure this function contains
>> exactly the same checks
>> for determining the correct ifs value. It would be easier to move the
>> assignment to txop
>> to the same if-statements.
>
> I guess you mean rt2x00queue_create_tx_descriptor in rt2x00queue.c, right?
> It's not exactly the same but at least the check for the first fragment are
> there already. We could also move it there. Why I've decided to put it in
> rt2x00ht.c is because it only applies to HT devices ;)
>
> If you'd prefer to have it in rt2x00queue I'm glad to resend.
Ah true this is HT stuff only. I'll look into the exact code later, and perhaps
I'll update it later. But this patch can be merged:
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCHv2] rt2x00: rt2800: use correct txop value in tx descriptor
From: Helmut Schaa @ 2010-05-07 9:48 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <n2qa32f33a41005070206j5909b348r62777da0cc7d214@mail.gmail.com>
Am Freitag 07 Mai 2010 schrieb Ivo Van Doorn:
> Hi,
>
>
> > diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > index 1056c92..5a40760 100644
> > --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> > +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > @@ -35,6 +35,7 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> > {
> > struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(entry->skb);
> > struct ieee80211_tx_rate *txrate = &tx_info->control.rates[0];
> > + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)entry->skb->data;
> >
> > if (tx_info->control.sta)
> > txdesc->mpdu_density =
> > @@ -66,4 +67,20 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> > __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> > if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> > __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> > +
> > + /*
> > + * Determine IFS values
> > + * - Use TXOP_BACKOFF for management frames
> > + * - Use TXOP_SIFS for fragment bursts
> > + * - Use TXOP_HTTXOP for everything else
> > + *
> > + * Note: rt2800 devices won't use CTS protection (if used)
> > + * for frames not transmitted with TXOP_HTTXOP
> > + */
> > + if (ieee80211_is_mgmt(hdr->frame_control))
> > + txdesc->txop = TXOP_BACKOFF;
> > + else if (!(tx_info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT))
> > + txdesc->txop = TXOP_SIFS;
> > + else
> > + txdesc->txop = TXOP_HTTXOP;
>
> I can't check it right now, but I am sure this function contains
> exactly the same checks
> for determining the correct ifs value. It would be easier to move the
> assignment to txop
> to the same if-statements.
I guess you mean rt2x00queue_create_tx_descriptor in rt2x00queue.c, right?
It's not exactly the same but at least the check for the first fragment are
there already. We could also move it there. Why I've decided to put it in
rt2x00ht.c is because it only applies to HT devices ;)
If you'd prefer to have it in rt2x00queue I'm glad to resend.
Helmut
^ permalink raw reply
* Re: [PATCHv2] rt2x00: rt2800: use correct txop value in tx descriptor
From: Ivo Van Doorn @ 2010-05-07 9:06 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Gertjan van Wingerde
In-Reply-To: <201005071103.08186.helmut.schaa@googlemail.com>
Hi,
> diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> index 1056c92..5a40760 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> @@ -35,6 +35,7 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> {
> struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(entry->skb);
> struct ieee80211_tx_rate *txrate = &tx_info->control.rates[0];
> + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)entry->skb->data;
>
> if (tx_info->control.sta)
> txdesc->mpdu_density =
> @@ -66,4 +67,20 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> +
> + /*
> + * Determine IFS values
> + * - Use TXOP_BACKOFF for management frames
> + * - Use TXOP_SIFS for fragment bursts
> + * - Use TXOP_HTTXOP for everything else
> + *
> + * Note: rt2800 devices won't use CTS protection (if used)
> + * for frames not transmitted with TXOP_HTTXOP
> + */
> + if (ieee80211_is_mgmt(hdr->frame_control))
> + txdesc->txop = TXOP_BACKOFF;
> + else if (!(tx_info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT))
> + txdesc->txop = TXOP_SIFS;
> + else
> + txdesc->txop = TXOP_HTTXOP;
I can't check it right now, but I am sure this function contains
exactly the same checks
for determining the correct ifs value. It would be easier to move the
assignment to txop
to the same if-statements.
Ivo
^ permalink raw reply
* [PATCHv2] rt2x00: rt2800: use correct txop value in tx descriptor
From: Helmut Schaa @ 2010-05-07 9:03 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Ivo van Doorn, Gertjan van Wingerde
rt2800 devices use a different enumeration to specify what IFS values should
be used on frame transmission compared to the other rt2x00 devices. Hence,
create a new enum called txop that contains the valid values.
Furthermore use the appropriate txop values as found in the ralink drivers:
- TXOP_BACKOFF for management frames
- TXOP_SIFS for subsequent fragments in a burst
- TXOP_HTTXOP for all data frames
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00ht.c | 17 +++++++++++++++++
drivers/net/wireless/rt2x00/rt2x00queue.h | 2 ++
drivers/net/wireless/rt2x00/rt2x00reg.h | 10 ++++++++++
5 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index f08b6a3..df2c3fb 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -643,7 +643,7 @@ static int rt2800pci_write_tx_data(struct queue_entry* entry,
rt2x00_set_field32(&word, TXWI_W0_AMPDU,
test_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags));
rt2x00_set_field32(&word, TXWI_W0_MPDU_DENSITY, txdesc->mpdu_density);
- rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->ifs);
+ rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->txop);
rt2x00_set_field32(&word, TXWI_W0_MCS, txdesc->mcs);
rt2x00_set_field32(&word, TXWI_W0_BW,
test_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags));
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index e3f3a97..c9e1320 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -417,7 +417,7 @@ static void rt2800usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(&word, TXWI_W0_AMPDU,
test_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags));
rt2x00_set_field32(&word, TXWI_W0_MPDU_DENSITY, txdesc->mpdu_density);
- rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->ifs);
+ rt2x00_set_field32(&word, TXWI_W0_TX_OP, txdesc->txop);
rt2x00_set_field32(&word, TXWI_W0_MCS, txdesc->mcs);
rt2x00_set_field32(&word, TXWI_W0_BW,
test_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags));
diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
index 1056c92..5a40760 100644
--- a/drivers/net/wireless/rt2x00/rt2x00ht.c
+++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
@@ -35,6 +35,7 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
{
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(entry->skb);
struct ieee80211_tx_rate *txrate = &tx_info->control.rates[0];
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)entry->skb->data;
if (tx_info->control.sta)
txdesc->mpdu_density =
@@ -66,4 +67,20 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
__set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
__set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
+
+ /*
+ * Determine IFS values
+ * - Use TXOP_BACKOFF for management frames
+ * - Use TXOP_SIFS for fragment bursts
+ * - Use TXOP_HTTXOP for everything else
+ *
+ * Note: rt2800 devices won't use CTS protection (if used)
+ * for frames not transmitted with TXOP_HTTXOP
+ */
+ if (ieee80211_is_mgmt(hdr->frame_control))
+ txdesc->txop = TXOP_BACKOFF;
+ else if (!(tx_info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT))
+ txdesc->txop = TXOP_SIFS;
+ else
+ txdesc->txop = TXOP_HTTXOP;
}
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
index 94a48c1..36a957a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.h
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
@@ -299,6 +299,7 @@ enum txentry_desc_flags {
* @retry_limit: Max number of retries.
* @aifs: AIFS value.
* @ifs: IFS value.
+ * @txop: IFS value for 11n capable chips.
* @cw_min: cwmin value.
* @cw_max: cwmax value.
* @cipher: Cipher type used for encryption.
@@ -328,6 +329,7 @@ struct txentry_desc {
short retry_limit;
short aifs;
short ifs;
+ short txop;
short cw_min;
short cw_max;
diff --git a/drivers/net/wireless/rt2x00/rt2x00reg.h b/drivers/net/wireless/rt2x00/rt2x00reg.h
index 603bfc0..b9fe948 100644
--- a/drivers/net/wireless/rt2x00/rt2x00reg.h
+++ b/drivers/net/wireless/rt2x00/rt2x00reg.h
@@ -101,6 +101,16 @@ enum ifs {
};
/*
+ * IFS backoff values for HT devices
+ */
+enum txop {
+ TXOP_HTTXOP = 0,
+ TXOP_PIFS = 1,
+ TXOP_SIFS = 2,
+ TXOP_BACKOFF = 3,
+};
+
+/*
* Cipher types for hardware encryption
*/
enum cipher {
--
1.6.4.2
^ permalink raw reply related
* [PATCH 0/5] wl1271: patches for wk18
From: Luciano Coelho @ 2010-05-07 8:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Hi John,
Here's our weekly patchset for the wl1271 driver.
Cheers,
Luca.
Juuso Oikarinen (4):
wl1271: Add sysfs file to retrieve HW PG-version and ROM-version
wl1271: Fix 32 bit register read related endiannes bug
wl1271: Fix to join and channel number handling
wl1271: Reduce PSM entry hang over period from 128 => 1 ms
Teemu Paasikivi (1):
wl1271: Increase timeout for command event waiting
drivers/net/wireless/wl12xx/wl1271.h | 4 +-
drivers/net/wireless/wl12xx/wl1271_boot.c | 12 +++++
drivers/net/wireless/wl12xx/wl1271_boot.h | 3 +
drivers/net/wireless/wl12xx/wl1271_cmd.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_cmd.h | 2 +-
drivers/net/wireless/wl12xx/wl1271_io.h | 4 +-
drivers/net/wireless/wl12xx/wl1271_main.c | 63 ++++++++++++++++++++++++++---
7 files changed, 79 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH 1/5] wl1271: Add sysfs file to retrieve HW PG-version and ROM-version
From: Luciano Coelho @ 2010-05-07 8:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1273221542-14283-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
This patch reads the HW PG version (along with a ROM-version, embedded in the
same value) from the wl1271 hardware and publishes the value in a sysfs -file.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271.h | 2 +
drivers/net/wireless/wl12xx/wl1271_boot.c | 12 ++++++++++
drivers/net/wireless/wl12xx/wl1271_boot.h | 3 ++
drivers/net/wireless/wl12xx/wl1271_main.c | 34 +++++++++++++++++++++++++++++
4 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h b/drivers/net/wireless/wl12xx/wl1271.h
index 75887e7..3e1769d 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -388,6 +388,8 @@ struct wl1271 {
size_t fw_len;
struct wl1271_nvs_file *nvs;
+ s8 hw_pg_ver;
+
u8 bssid[ETH_ALEN];
u8 mac_addr[ETH_ALEN];
u8 bss_type;
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.c b/drivers/net/wireless/wl12xx/wl1271_boot.c
index acb1d9e..1a36d8a 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.c
@@ -441,11 +441,23 @@ static int wl1271_boot_write_irq_polarity(struct wl1271 *wl)
return 0;
}
+static void wl1271_boot_hw_version(struct wl1271 *wl)
+{
+ u32 fuse;
+
+ fuse = wl1271_top_reg_read(wl, REG_FUSE_DATA_2_1);
+ fuse = (fuse & PG_VER_MASK) >> PG_VER_OFFSET;
+
+ wl->hw_pg_ver = (s8)fuse;
+}
+
int wl1271_boot(struct wl1271 *wl)
{
int ret = 0;
u32 tmp, clk, pause;
+ wl1271_boot_hw_version(wl);
+
if (REF_CLOCK == 0 || REF_CLOCK == 2 || REF_CLOCK == 4)
/* ref clk: 19.2/38.4/38.4-XTAL */
clk = 0x3;
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.h b/drivers/net/wireless/wl12xx/wl1271_boot.h
index 95ecc52..f829699 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.h
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.h
@@ -55,6 +55,9 @@ struct wl1271_static_data {
#define OCP_REG_CLK_POLARITY 0x0cb2
#define OCP_REG_CLK_PULL 0x0cb4
+#define REG_FUSE_DATA_2_1 0x050a
+#define PG_VER_MASK 0x3c
+#define PG_VER_OFFSET 2
#define CMD_MBOX_ADDRESS 0x407B4
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index b167248..5ad94fc 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -2233,6 +2233,29 @@ static DEVICE_ATTR(bt_coex_state, S_IRUGO | S_IWUSR,
wl1271_sysfs_show_bt_coex_state,
wl1271_sysfs_store_bt_coex_state);
+static ssize_t wl1271_sysfs_show_hw_pg_ver(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct wl1271 *wl = dev_get_drvdata(dev);
+ ssize_t len;
+
+ /* FIXME: what's the maximum length of buf? page size?*/
+ len = 500;
+
+ mutex_lock(&wl->mutex);
+ if (wl->hw_pg_ver >= 0)
+ len = snprintf(buf, len, "%d\n", wl->hw_pg_ver);
+ else
+ len = snprintf(buf, len, "n/a\n");
+ mutex_unlock(&wl->mutex);
+
+ return len;
+}
+
+static DEVICE_ATTR(hw_pg_ver, S_IRUGO | S_IWUSR,
+ wl1271_sysfs_show_hw_pg_ver, NULL);
+
int wl1271_register_hw(struct wl1271 *wl)
{
int ret;
@@ -2352,6 +2375,7 @@ struct ieee80211_hw *wl1271_alloc_hw(void)
wl->vif = NULL;
wl->flags = 0;
wl->sg_enabled = true;
+ wl->hw_pg_ver = -1;
for (i = 0; i < ACX_TX_DESCRIPTORS; i++)
wl->tx_frames[i] = NULL;
@@ -2381,8 +2405,18 @@ struct ieee80211_hw *wl1271_alloc_hw(void)
goto err_platform;
}
+ /* Create sysfs file to get HW PG version */
+ ret = device_create_file(&wl->plat_dev->dev, &dev_attr_hw_pg_ver);
+ if (ret < 0) {
+ wl1271_error("failed to create sysfs file hw_pg_ver");
+ goto err_bt_coex_state;
+ }
+
return hw;
+err_bt_coex_state:
+ device_remove_file(&wl->plat_dev->dev, &dev_attr_bt_coex_state);
+
err_platform:
platform_device_unregister(wl->plat_dev);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 5/5] wl1271: Reduce PSM entry hang over period from 128 => 1 ms
From: Luciano Coelho @ 2010-05-07 8:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1273221542-14283-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Currently, we configure a 128ms hang over period for the PSM entry
(the firmware will remain active for 128ms after sending the null func for
PSM and getting an ack for it.) This is a huge power consumption issue, and
appears unnecessary. So, configure the value to 1 ms.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Janne Ylalehto <janne.ylalehto@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_cmd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_cmd.c b/drivers/net/wireless/wl12xx/wl1271_cmd.c
index 62c11af..19393e2 100644
--- a/drivers/net/wireless/wl12xx/wl1271_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1271_cmd.c
@@ -516,7 +516,7 @@ int wl1271_cmd_ps_mode(struct wl1271 *wl, u8 ps_mode, bool send)
ps_params->ps_mode = ps_mode;
ps_params->send_null_data = send;
ps_params->retries = 5;
- ps_params->hang_over_period = 128;
+ ps_params->hang_over_period = 1;
ps_params->null_data_rate = cpu_to_le32(1); /* 1 Mbps */
ret = wl1271_cmd_send(wl, CMD_SET_PS_MODE, ps_params,
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/5] wl1271: Fix to join and channel number handling
From: Luciano Coelho @ 2010-05-07 8:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1273221542-14283-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
This patch changes the way JOIN's are performed, and channel numbers updated.
The reason for this is that the firmware JOIN command clears WPA(2) key
material, and if done while associated to a WPA(2) secured AP, will render
the data-path unusable.
While the channel is not usually changed while associated (and currently we
could not even support something like that), after performing a scan operation
while associated, mac80211 will re-set the current channel to the driver. This
caused our problem.
Also, the mac80211 is assuming that the driver channel configuration remains
persistent over periods of IDLE. Therefore remove channel resetting to zero
from the unjoin function.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 29 +++++++++++++++++++++++------
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index 5ad94fc..360daf8 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -1140,10 +1140,25 @@ out:
return ret;
}
-static int wl1271_join(struct wl1271 *wl)
+static int wl1271_join(struct wl1271 *wl, bool set_assoc)
{
int ret;
+ /*
+ * One of the side effects of the JOIN command is that is clears
+ * WPA/WPA2 keys from the chipset. Performing a JOIN while associated
+ * to a WPA/WPA2 access point will therefore kill the data-path.
+ * Currently there is no supported scenario for JOIN during
+ * association - if it becomes a supported scenario, the WPA/WPA2 keys
+ * must be handled somehow.
+ *
+ */
+ if (test_bit(WL1271_FLAG_STA_ASSOCIATED, &wl->flags))
+ wl1271_info("JOIN while associated.");
+
+ if (set_assoc)
+ set_bit(WL1271_FLAG_STA_ASSOCIATED, &wl->flags);
+
ret = wl1271_cmd_join(wl, wl->set_bss_type);
if (ret < 0)
goto out;
@@ -1190,7 +1205,6 @@ static int wl1271_unjoin(struct wl1271 *wl)
goto out;
clear_bit(WL1271_FLAG_JOINED, &wl->flags);
- wl->channel = 0;
memset(wl->bssid, 0, ETH_ALEN);
/* stop filterting packets based on bssid */
@@ -1250,7 +1264,9 @@ static int wl1271_op_config(struct ieee80211_hw *hw, u32 changed)
goto out;
/* if the channel changes while joined, join again */
- if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
+ if (changed & IEEE80211_CONF_CHANGE_CHANNEL &&
+ ((wl->band != conf->channel->band) ||
+ (wl->channel != channel))) {
wl->band = conf->channel->band;
wl->channel = channel;
@@ -1270,7 +1286,7 @@ static int wl1271_op_config(struct ieee80211_hw *hw, u32 changed)
"failed %d", ret);
if (test_bit(WL1271_FLAG_JOINED, &wl->flags)) {
- ret = wl1271_join(wl);
+ ret = wl1271_join(wl, false);
if (ret < 0)
wl1271_warning("cmd join to update channel "
"failed %d", ret);
@@ -1652,6 +1668,7 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
enum wl1271_cmd_ps_mode mode;
struct wl1271 *wl = hw->priv;
bool do_join = false;
+ bool set_assoc = false;
int ret;
wl1271_debug(DEBUG_MAC80211, "mac80211 bss info changed");
@@ -1761,7 +1778,7 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
if (bss_conf->assoc) {
u32 rates;
wl->aid = bss_conf->aid;
- set_bit(WL1271_FLAG_STA_ASSOCIATED, &wl->flags);
+ set_assoc = true;
/*
* use basic rates from AP, and determine lowest rate
@@ -1861,7 +1878,7 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
}
if (do_join) {
- ret = wl1271_join(wl);
+ ret = wl1271_join(wl, set_assoc);
if (ret < 0) {
wl1271_warning("cmd join failed %d", ret);
goto out_sleep;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/5] wl1271: Increase timeout for command event waiting
From: Luciano Coelho @ 2010-05-07 8:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Teemu Paasikivi
In-Reply-To: <1273221542-14283-1-git-send-email-luciano.coelho@nokia.com>
From: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Incresed the timeout value for command complete event waiting from 100
ms to 750 ms. In some rare cases it can take about 600 ms before
complete event for join command is received. This is most propably
caused by the firmware being busy with scanning related activities.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_cmd.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_cmd.h b/drivers/net/wireless/wl12xx/wl1271_cmd.h
index 00f78b7..f2820b4 100644
--- a/drivers/net/wireless/wl12xx/wl1271_cmd.h
+++ b/drivers/net/wireless/wl12xx/wl1271_cmd.h
@@ -129,7 +129,7 @@ enum cmd_templ {
/* unit ms */
#define WL1271_COMMAND_TIMEOUT 2000
#define WL1271_CMD_TEMPL_MAX_SIZE 252
-#define WL1271_EVENT_TIMEOUT 100
+#define WL1271_EVENT_TIMEOUT 750
struct wl1271_cmd_header {
__le16 id;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/5] wl1271: Fix 32 bit register read related endiannes bug
From: Luciano Coelho @ 2010-05-07 8:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1273221542-14283-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reading single registers did not pay attention to data endianness. This patch
fix that.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271.h | 2 +-
drivers/net/wireless/wl12xx/wl1271_io.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h b/drivers/net/wireless/wl12xx/wl1271.h
index 3e1769d..6f1b6b5 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -481,7 +481,7 @@ struct wl1271 {
struct wl1271_stats stats;
struct wl1271_debugfs debugfs;
- u32 buffer_32;
+ __le32 buffer_32;
u32 buffer_cmd;
u32 buffer_busyword[WL1271_BUSY_WORD_CNT];
diff --git a/drivers/net/wireless/wl12xx/wl1271_io.h b/drivers/net/wireless/wl12xx/wl1271_io.h
index d8837ef..bc806c7 100644
--- a/drivers/net/wireless/wl12xx/wl1271_io.h
+++ b/drivers/net/wireless/wl12xx/wl1271_io.h
@@ -74,12 +74,12 @@ static inline u32 wl1271_raw_read32(struct wl1271 *wl, int addr)
wl1271_raw_read(wl, addr, &wl->buffer_32,
sizeof(wl->buffer_32), false);
- return wl->buffer_32;
+ return le32_to_cpu(wl->buffer_32);
}
static inline void wl1271_raw_write32(struct wl1271 *wl, int addr, u32 val)
{
- wl->buffer_32 = val;
+ wl->buffer_32 = cpu_to_le32(val);
wl1271_raw_write(wl, addr, &wl->buffer_32,
sizeof(wl->buffer_32), false);
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 3/3] rt2x00: rt2800: use correct txop value in tx descriptor
From: Gertjan van Wingerde @ 2010-05-07 8:21 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Ivo van Doorn
In-Reply-To: <201005071011.19735.helmut.schaa@googlemail.com>
On 05/07/10 10:11, Helmut Schaa wrote:
> Am Donnerstag 06 Mai 2010 schrieb Helmut Schaa:
>> Am Donnerstag 06 Mai 2010 schrieb Gertjan van Wingerde:
>>> On 05/06/10 12:29, Helmut Schaa wrote:
>>
>> [...]
>>
>>>> diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
>>>> index 1056c92..5483fec 100644
>>>> --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
>>>> +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
>>>> @@ -66,4 +66,6 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
>>>> __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
>>>> if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
>>>> __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
>>>> +
>>>> + txdesc->txop = TXOP_HTTXOP;
>>>> }
>>>
>>> I am not too sure about this part. If I look at the Ralink vendor driver, they are most of the time
>>> using IFS_BACKOFF (value 3). Why did you put this on TXOP_HTTXOP?
>>
>> From what I saw in the ralink driver IFS_BACKOFF is only used for management frames, IFS_SIFS only
>> for subsequent frames in a fragment burst and IFS_HTTXOPS for "normal" data frames. But that's
>> just the result of a _quick_ review. So I might be wrong here as well :)
>>
>> To be honest I don't really know what the device does in case IFS_HTTXOPS is set but that was
>> the value we've passed to the driver before ;) (==IFS_BACKOFF on all other ralink chips) and it
>> works quite well. I also tried IFS_BACKOFF and I wasn't able to see a difference when using
>> legacy (11b & 11g) rates (neither on the device itself nor with a second machine monitoring
>> the traffic).
>
> Ok, after further examination it turns out to be:
>
> - Management frames are sent with IFS_BACKOFF
> - Special case for PsPoll frames also with IFS_BACKOFF
> - Data frames are sent with IFS_HTTXOP
> - Data frame subsequent fragments are send with IFS_SIFS
> - CTS frames (in AP mode) use IFS_SIFS
>
> So, I guess I resend this patch after some testing with IFS_BACKOFF for
> management frames and IFS_HTTXOP for data frames and SIFS for subsequent
> fragments.
>
> John, please don't merge this patch yet. Thanks.
Thanks for investigating this further. I think the approach you describe above is the correct
approach for this.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH 3/3] rt2x00: rt2800: use correct txop value in tx descriptor
From: Helmut Schaa @ 2010-05-07 8:11 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John Linville, linux-wireless, Ivo van Doorn
In-Reply-To: <201005062057.38692.helmut.schaa@googlemail.com>
Am Donnerstag 06 Mai 2010 schrieb Helmut Schaa:
> Am Donnerstag 06 Mai 2010 schrieb Gertjan van Wingerde:
> > On 05/06/10 12:29, Helmut Schaa wrote:
>
> [...]
>
> > > diff --git a/drivers/net/wireless/rt2x00/rt2x00ht.c b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > > index 1056c92..5483fec 100644
> > > --- a/drivers/net/wireless/rt2x00/rt2x00ht.c
> > > +++ b/drivers/net/wireless/rt2x00/rt2x00ht.c
> > > @@ -66,4 +66,6 @@ void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
> > > __set_bit(ENTRY_TXD_HT_BW_40, &txdesc->flags);
> > > if (txrate->flags & IEEE80211_TX_RC_SHORT_GI)
> > > __set_bit(ENTRY_TXD_HT_SHORT_GI, &txdesc->flags);
> > > +
> > > + txdesc->txop = TXOP_HTTXOP;
> > > }
> >
> > I am not too sure about this part. If I look at the Ralink vendor driver, they are most of the time
> > using IFS_BACKOFF (value 3). Why did you put this on TXOP_HTTXOP?
>
> From what I saw in the ralink driver IFS_BACKOFF is only used for management frames, IFS_SIFS only
> for subsequent frames in a fragment burst and IFS_HTTXOPS for "normal" data frames. But that's
> just the result of a _quick_ review. So I might be wrong here as well :)
>
> To be honest I don't really know what the device does in case IFS_HTTXOPS is set but that was
> the value we've passed to the driver before ;) (==IFS_BACKOFF on all other ralink chips) and it
> works quite well. I also tried IFS_BACKOFF and I wasn't able to see a difference when using
> legacy (11b & 11g) rates (neither on the device itself nor with a second machine monitoring
> the traffic).
Ok, after further examination it turns out to be:
- Management frames are sent with IFS_BACKOFF
- Special case for PsPoll frames also with IFS_BACKOFF
- Data frames are sent with IFS_HTTXOP
- Data frame subsequent fragments are send with IFS_SIFS
- CTS frames (in AP mode) use IFS_SIFS
So, I guess I resend this patch after some testing with IFS_BACKOFF for
management frames and IFS_HTTXOP for data frames and SIFS for subsequent
fragments.
John, please don't merge this patch yet. Thanks.
Helmut
^ permalink raw reply
* [PATCH] ath9k_htc: Handle IDLE LED properly
From: Sujith @ 2010-05-07 8:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Switch LED off/on when handling CONF_CHANGE_IDLE.
Not doing this would leave the radio LED on even
though the chip would be in full sleep mode.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 26 ++++++++++++++++++------
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 7c9e33b..f503586 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1099,7 +1099,7 @@ fail_tx:
return 0;
}
-static int ath9k_htc_radio_enable(struct ieee80211_hw *hw)
+static int ath9k_htc_radio_enable(struct ieee80211_hw *hw, bool led)
{
struct ath9k_htc_priv *priv = hw->priv;
struct ath_hw *ah = priv->ah;
@@ -1147,6 +1147,13 @@ static int ath9k_htc_radio_enable(struct ieee80211_hw *hw)
priv->tx_queues_stop = false;
spin_unlock_bh(&priv->tx_lock);
+ if (led) {
+ /* Enable LED */
+ ath9k_hw_cfg_output(ah, ah->led_pin,
+ AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
+ ath9k_hw_set_gpio(ah, ah->led_pin, 0);
+ }
+
ieee80211_wake_queues(hw);
return ret;
@@ -1158,13 +1165,13 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
int ret = 0;
mutex_lock(&priv->mutex);
- ret = ath9k_htc_radio_enable(hw);
+ ret = ath9k_htc_radio_enable(hw, false);
mutex_unlock(&priv->mutex);
return ret;
}
-static void ath9k_htc_radio_disable(struct ieee80211_hw *hw)
+static void ath9k_htc_radio_disable(struct ieee80211_hw *hw, bool led)
{
struct ath9k_htc_priv *priv = hw->priv;
struct ath_hw *ah = priv->ah;
@@ -1177,6 +1184,12 @@ static void ath9k_htc_radio_disable(struct ieee80211_hw *hw)
return;
}
+ if (led) {
+ /* Disable LED */
+ ath9k_hw_set_gpio(ah, ah->led_pin, 1);
+ ath9k_hw_cfg_gpio_input(ah, ah->led_pin);
+ }
+
/* Cancel all the running timers/work .. */
cancel_work_sync(&priv->ps_work);
cancel_delayed_work_sync(&priv->ath9k_ani_work);
@@ -1217,7 +1230,7 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
struct ath9k_htc_priv *priv = hw->priv;
mutex_lock(&priv->mutex);
- ath9k_htc_radio_disable(hw);
+ ath9k_htc_radio_disable(hw, false);
mutex_unlock(&priv->mutex);
}
@@ -1337,7 +1350,7 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
if (enable_radio) {
ath9k_htc_setpower(priv, ATH9K_PM_AWAKE);
- ath9k_htc_radio_enable(hw);
+ ath9k_htc_radio_enable(hw, true);
ath_print(common, ATH_DBG_CONFIG,
"not-idle: enabling radio\n");
}
@@ -1389,10 +1402,9 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
if (priv->ps_idle) {
ath_print(common, ATH_DBG_CONFIG,
"idle: disabling radio\n");
- ath9k_htc_radio_disable(hw);
+ ath9k_htc_radio_disable(hw, true);
}
-
mutex_unlock(&priv->mutex);
return 0;
--
1.7.1
^ permalink raw reply related
* Re: rt61pci: WEP broken in current wireless-testing
From: Gertjan van Wingerde @ 2010-05-07 5:57 UTC (permalink / raw)
To: Pavel Roskin; +Cc: John W. Linville, linux-wireless
In-Reply-To: <20100506211435.1nfaq83vkg4ccc0g-cebfxv@webmail.spamcop.net>
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On 05/07/10 03:14, Pavel Roskin wrote:
> Quoting "John W. Linville" <linville@tuxdriver.com>:
>
>> When you get to this, you probably should use wireless-next-2.6
>> (or wireless-2.6) for the bisection. The pulls from linux-2.6 in
>> wireless-testing make bisection much more painful than necessary
>> (as long as the problem is actually evident in the other kernels).
>
> I know it's painful!
>
>> You can use the 'master-<date>' tags as guidelines for matching
>> wireless-testing versions to representative wireless-next-2.6 (or
>> wireless-2.6) tree versions.
>
> Thank you for the tips!
>
Hi,
It might be that one of my recent patches broke this. Can you try the
attached patch?
---
Gertjan
[-- Attachment #2: rt61pci-wep-fix.diff --]
[-- Type: text/plain, Size: 529 bytes --]
diff --git a/drivers/net/wireless/rt2x00/rt2x00crypto.c b/drivers/net/wireless/rt2x00/rt2x00crypto.c
index d291c78..583dacd 100644
--- a/drivers/net/wireless/rt2x00/rt2x00crypto.c
+++ b/drivers/net/wireless/rt2x00/rt2x00crypto.c
@@ -128,6 +128,7 @@ void rt2x00crypto_tx_remove_iv(struct sk_buff *skb, struct txentry_desc *txdesc)
/* Pull buffer to correct size */
skb_pull(skb, txdesc->iv_len);
+ txdesc->length -= txdesc->iv_len;
/* IV/EIV data has officially been stripped */
skbdesc->flags |= SKBDESC_IV_STRIPPED;
^ permalink raw reply related
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