* [RFC][PATCH 5/6] ath9k: check error flags even if rx frame is marked ok
From: Johan Hovold @ 2010-04-16 10:52 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill, Johan Hovold
In-Reply-To: <20100416104850.GA13329@lundinova.se>
Check error flags even if frame is marked ok by hardware as this flag
may have been incorrectly set.
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
00000000: 88 41 30 00 00 80 48 68 08 af 00 b9 49 c3 e1 3f
00000010: 5a 9d 51 71 09 63 00 50 00 00 00 00 ff 54 00 20
00000020: 36 9d 46 02 90 31 2c e8 68 06 84 6e b5 00 29 e8
00000030: ef e3 6f a0 ee 99 7c 7e d8 7d 12 aa de 5c 20 69
00000040: d6 6a ad c4 99 bb c1 e4 c3 ba bd 77 51 7f a2 a5
00000050: 01 e4 81 a0 be 40 54 45 70 e4 cc 11 58 f8 ad 45
00000060: 84 1c 72 36 a1 fd b7 33 ad aa 4f 8b
rxstatus8 = 5994daab
Here AR_RxFrameOK is set even though AR_DecryptCRCErr and AR_MichaelErr are
set.
Note that this also happens for frames with non-corrupt PNs, e.g.:
FrameOK with error: c79e7573
FrameOK with error: 264786bf
FrameOK with error: f3a2446f
FrameOK with error: 2c054c4f
drivers/net/wireless/ath/ath9k/mac.c | 22 ++++++++++------------
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 891a294..2b4295b 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -925,18 +925,16 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
if (ads.ds_rxstatus8 & AR_KeyMiss)
rs->rs_flags |= ATH9K_RX_KEY_MISS;
- if ((ads.ds_rxstatus8 & AR_RxFrameOK) == 0) {
- if (ads.ds_rxstatus8 & AR_CRCErr)
- rs->rs_status |= ATH9K_RXERR_CRC;
- else if (ads.ds_rxstatus8 & AR_PHYErr) {
- rs->rs_status |= ATH9K_RXERR_PHY;
- phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
- rs->rs_phyerr = phyerr;
- } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
- rs->rs_status |= ATH9K_RXERR_DECRYPT;
- else if (ads.ds_rxstatus8 & AR_MichaelErr)
- rs->rs_status |= ATH9K_RXERR_MIC;
- }
+ if (ads.ds_rxstatus8 & AR_CRCErr)
+ rs->rs_status |= ATH9K_RXERR_CRC;
+ else if (ads.ds_rxstatus8 & AR_PHYErr) {
+ rs->rs_status |= ATH9K_RXERR_PHY;
+ phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
+ rs->rs_phyerr = phyerr;
+ } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
+ rs->rs_status |= ATH9K_RXERR_DECRYPT;
+ else if (ads.ds_rxstatus8 & AR_MichaelErr)
+ rs->rs_status |= ATH9K_RXERR_MIC;
return 0;
}
--
1.7.0.3
^ permalink raw reply related
* [RFC][PATCH 6/6] ath9k: clear mic error flag on encrypted frames
From: Johan Hovold @ 2010-04-16 10:52 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill, Johan Hovold
In-Reply-To: <20100416104850.GA13329@lundinova.se>
It does not make sense to forward MIC-errors on non-decrypted frames.
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
drivers/net/wireless/ath/ath9k/common.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index 1623af1..6efb388 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -255,11 +255,15 @@ void ath9k_cmn_rx_skb_postprocess(struct ath_common *common,
keyix = rx_stats->rs_keyix;
- if (ieee80211_has_protected(fc) && !decrypt_error &&
- !(rx_stats->rs_flags & ATH9K_RX_DECRYPT_BUSY) &&
- !(rx_stats->rs_flags & ATH9K_RX_KEY_MISS)) {
- if (keyix != ATH9K_RXKEYIX_INVALID)
+ if (ieee80211_has_protected(fc)) {
+ if (!decrypt_error &&
+ !(rx_stats->rs_flags & ATH9K_RX_DECRYPT_BUSY) &&
+ !(rx_stats->rs_flags & ATH9K_RX_KEY_MISS) &&
+ keyix != ATH9K_RXKEYIX_INVALID) {
rxs->flag |= RX_FLAG_DECRYPTED;
+ }
+ if (!(rxs->flag & RX_FLAG_DECRYPTED))
+ rxs->flag &= ~RX_FLAG_MMIC_ERROR;
}
if (ah->sw_mgmt_crypto &&
(rxs->flag & RX_FLAG_DECRYPTED) &&
--
1.7.0.3
^ permalink raw reply related
* Re: [PATCH] wireless: rt2x00: rt2800usb: delete Allwin devices
From: Ivo Van Doorn @ 2010-04-16 11:17 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: linux-wireless, users, linville, gwingerde
In-Reply-To: <1271413005-2509-1-git-send-email-xose.vazquez@gmail.com>
On Fri, Apr 16, 2010 at 12:16 PM, Xose Vazquez Perez
<xose.vazquez@gmail.com> wrote:
> Common sense says:
> (0x8516, 0x2070) is RT2070
> (0x8516, 0x2770) is RT2770
> (0x8516, 0x2870) is RT2870
> [...]
>
> but Allwin doesn't sell USB dongles nor PCI boards, only voip-routers
> http://www.allwin.com.tw/eng/modules/tinyd0/content/index.php?id=1
But how about the case where the company name is wrong and the ID's are valid?
That means we only should update the comment, rather then deleting the ID's.
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800usb.c | 8 --------
> 1 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index df7666f..41de405 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -1019,14 +1019,6 @@ static struct usb_device_id rt2800usb_device_table[] = {
> * Unclear what kind of devices these are (they aren't supported by the
> * vendor driver).
> */
> - /* Allwin */
> - { USB_DEVICE(0x8516, 0x2070), USB_DEVICE_DATA(&rt2800usb_ops) },
> - { USB_DEVICE(0x8516, 0x2770), USB_DEVICE_DATA(&rt2800usb_ops) },
> - { USB_DEVICE(0x8516, 0x2870), USB_DEVICE_DATA(&rt2800usb_ops) },
> - { USB_DEVICE(0x8516, 0x3070), USB_DEVICE_DATA(&rt2800usb_ops) },
> - { USB_DEVICE(0x8516, 0x3071), USB_DEVICE_DATA(&rt2800usb_ops) },
> - { USB_DEVICE(0x8516, 0x3072), USB_DEVICE_DATA(&rt2800usb_ops) },
> - { USB_DEVICE(0x8516, 0x3572), USB_DEVICE_DATA(&rt2800usb_ops) },
> /* Amigo */
> { USB_DEVICE(0x0e0b, 0x9031), USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x0e0b, 0x9041), USB_DEVICE_DATA(&rt2800usb_ops) },
> --
> 1.6.6.1
>
>
^ permalink raw reply
* Re: [ath9k-devel] [RFC][PATCH 2/6] ath9k: do not mark frames with RXKEY_IX_INVALID as decrypted
From: Jouni Malinen @ 2010-04-16 11:32 UTC (permalink / raw)
To: Johan Hovold; +Cc: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org
In-Reply-To: <1271415135-18317-2-git-send-email-johan.hovold@lundinova.se>
On Fri, 2010-04-16 at 03:52 -0700, Johan Hovold wrote:
> Frames tagged by hardware with ATH9K_RXKEYIX_INVALID should not
> incorrectly be marked decrypted (even if key index in frame is valid).
Have you tested this with static WEP configuration? Or broadcast RX with
WPA? There must be a reason for that odd looking code being there in the
first place and I can now only think of it being needed when the default
keys are used.
- Jouni
^ permalink raw reply
* Re: [PATCH] wl1251: add support for dedicated IRQ line
From: Bob Copeland @ 2010-04-16 12:15 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: John W. Linville, linux-wireless, Kalle Valo
In-Reply-To: <1271413332-2979-1-git-send-email-notasas@gmail.com>
On Fri, Apr 16, 2010 at 01:22:12PM +0300, Grazvydas Ignotas wrote:
> wl1251 has WLAN_IRQ pin for generating interrupts to host processor,
> which is mandatory in SPI mode and optional in SDIO mode (which can
> use SDIO interrupts instead). However TI recommends using deditated
> IRQ line for SDIO too.
>
> Add support for using dedicated interrupt line with SDIO, but also leave
> ability to switch to SDIO interrupts in case it's needed.
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Thanks, looks good to me!
Reviewed-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: John W. Linville @ 2010-04-16 13:37 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless
In-Reply-To: <p2ub170af451004152320y64c4615ub3d7186d936cdc62@mail.gmail.com>
On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
> John, I posted some time ago following patches:
>
> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
> [PATCH 1/2] ssb: Use relative offsets for SPROM
> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>
> while Michael has some doubts about "ssb: Look for SPROM at different
> offset on higher rev CC" I explained to him that what he does not like
> was fixed in next 2 posted patches.
>
> AFAIR you got some device with this recently-discovered location of
> SPROM. Could you test my set if it makes your card working? If so,
> could you take that patches to your tree?
Sorry, been busy w/ other things. FWIW, my implementation based on
the RE work from Larry did not work on the box in question, and my
implementation wasn't substantially different from yours. Anyway,
I'll try to confirm this soon w/ your patches and to collect more
information for Larry.
Thanks,
John
--
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
* Re: [RFC PATCH] mac80211: Prevent running sta_cleanup timer unnecessarily
From: John W. Linville @ 2010-04-16 13:41 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1271403308-23416-2-git-send-email-juuso.oikarinen@nokia.com>
On Fri, Apr 16, 2010 at 10:35:08AM +0300, Juuso Oikarinen wrote:
> The sta_cleanup timer is used to periodically expire buffered frames from the
> tx buf. The timer is executing periodically, regardless of the need for it.
> This is wasting resources.
>
> Fix this simply by not restarting the sta_cleanup timer if the tx buffer was
> empty. Restart the timer when there is some more tx-traffic.
>
> Cc: Janne Ylälehto <janne.ylalehto@nokia.com>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Seems reasonable to me...
--
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
* Re: [PATCH] wireless: rt2x00: rt2800usb: delete Allwin devices
From: John W. Linville @ 2010-04-16 13:43 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: Xose Vazquez Perez, linux-wireless, users, gwingerde
In-Reply-To: <u2ja32f33a41004160417jfcf1db3bw62d464405fead085@mail.gmail.com>
On Fri, Apr 16, 2010 at 01:17:07PM +0200, Ivo Van Doorn wrote:
> On Fri, Apr 16, 2010 at 12:16 PM, Xose Vazquez Perez
> <xose.vazquez@gmail.com> wrote:
> > Common sense says:
> > (0x8516, 0x2070) is RT2070
> > (0x8516, 0x2770) is RT2770
> > (0x8516, 0x2870) is RT2870
> > [...]
> >
> > but Allwin doesn't sell USB dongles nor PCI boards, only voip-routers
> > http://www.allwin.com.tw/eng/modules/tinyd0/content/index.php?id=1
>
> But how about the case where the company name is wrong and the ID's are valid?
> That means we only should update the comment, rather then deleting the ID's.
Or the case where someone ports Linux to those voip routers...
John
--
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
* [PATCH] iwlwifi: check scan request ie_len
From: Stanislaw Gruszka @ 2010-04-16 13:46 UTC (permalink / raw)
To: linux-wireless; +Cc: Reinette Chatre, wey-yi.w.guy, Stanislaw Gruszka
In mac80211 we always check both scan_req->ie and scan_req->ie_len
against zero before usage, in iwlwifi we should do the same.
Remove not needed "left -= ie_len" while at it.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlwifi/iwl-scan.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index d817c9c..83e6291 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -644,10 +644,10 @@ u16 iwl_fill_probe_req(struct iwl_priv *priv, struct ieee80211_mgmt *frame,
if (WARN_ON(left < ie_len))
return len;
- if (ies)
+ if (ies && ie_len) {
memcpy(pos, ies, ie_len);
- len += ie_len;
- left -= ie_len;
+ len += ie_len;
+ }
return (u16)len;
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH] iwlwifi: initialize iwl_wimax_coex_cmd.flags
From: Stanislaw Gruszka @ 2010-04-16 13:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Reinette Chatre, wey-yi.w.guy, Stanislaw Gruszka
iwl_wimax_coex_cmd.flags can be really uninitialized, so fix
that.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlwifi/iwl-core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index f09bff8..2e489cd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -2382,11 +2382,11 @@ EXPORT_SYMBOL(iwl_free_txq_mem);
int iwl_send_wimax_coex(struct iwl_priv *priv)
{
- struct iwl_wimax_coex_cmd uninitialized_var(coex_cmd);
+ struct iwl_wimax_coex_cmd coex_cmd;
if (priv->cfg->support_wimax_coexist) {
/* UnMask wake up src at associated sleep */
- coex_cmd.flags |= COEX_FLAGS_ASSOC_WA_UNMASK_MSK;
+ coex_cmd.flags = COEX_FLAGS_ASSOC_WA_UNMASK_MSK;
/* UnMask wake up src at unassociated sleep */
coex_cmd.flags |= COEX_FLAGS_UNASSOC_WA_UNMASK_MSK;
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 1/2] ath5k: Use high bitrates for ACK/CTS
From: Stanislaw Gruszka @ 2010-04-16 13:59 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, ath5k-devel, linux-wireless
In-Reply-To: <20100412073847.28215.87571.stgit@tt-desk>
On Mon, 12 Apr 2010 16:38:47 +0900
Bruno Randolf <br1@einfach.org> wrote:
> There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
> AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
> ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
> resulted in high bitrates, which i think is what we want anyways. Cleared the
> confusion and added some documentation.
I thought ACK and other control frames have to be modulated at slow/robust
bitrates, but can't remember where I read that ...
Stanislaw
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: Rafał Miłecki @ 2010-04-16 15:51 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100416133711.GB8554@tuxdriver.com>
W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
<linville@tuxdriver.com> napisał:
> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>> John, I posted some time ago following patches:
>>
>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>
>> while Michael has some doubts about "ssb: Look for SPROM at different
>> offset on higher rev CC" I explained to him that what he does not like
>> was fixed in next 2 posted patches.
>>
>> AFAIR you got some device with this recently-discovered location of
>> SPROM. Could you test my set if it makes your card working? If so,
>> could you take that patches to your tree?
>
> Sorry, been busy w/ other things. FWIW, my implementation based on
> the RE work from Larry did not work on the box in question, and my
> implementation wasn't substantially different from yours. Anyway,
> I'll try to confirm this soon w/ your patches and to collect more
> information for Larry.
Ah, I didn't know you got own implementation. Had to miss it.
Larry do you have any ideas what else may we do incorrectly?
John: may be worth checking if your card matched this new condition
and if driver actually used "new" offset.
--
Rafał
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: Larry Finger @ 2010-04-16 16:22 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: John W. Linville, linux-wireless
In-Reply-To: <m2wb170af451004160851veaed6df6r2e8ec0528f66685e@mail.gmail.com>
On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
> W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
> <linville@tuxdriver.com> napisał:
>> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>>> John, I posted some time ago following patches:
>>>
>>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>>
>>> while Michael has some doubts about "ssb: Look for SPROM at different
>>> offset on higher rev CC" I explained to him that what he does not like
>>> was fixed in next 2 posted patches.
>>>
>>> AFAIR you got some device with this recently-discovered location of
>>> SPROM. Could you test my set if it makes your card working? If so,
>>> could you take that patches to your tree?
>>
>> Sorry, been busy w/ other things. FWIW, my implementation based on
>> the RE work from Larry did not work on the box in question, and my
>> implementation wasn't substantially different from yours. Anyway,
>> I'll try to confirm this soon w/ your patches and to collect more
>> information for Larry.
>
> Ah, I didn't know you got own implementation. Had to miss it.
>
> Larry do you have any ideas what else may we do incorrectly?
No. AFAICT, we have implemented it correctly. Any additional info would
be welcome.
Larry
^ permalink raw reply
* Re: [PATCH] iwlwifi: check scan request ie_len
From: reinette chatre @ 2010-04-16 17:12 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org, Guy, Wey-Yi W
In-Reply-To: <1271425601-32518-1-git-send-email-sgruszka@redhat.com>
On Fri, 2010-04-16 at 06:46 -0700, Stanislaw Gruszka wrote:
> In mac80211 we always check both scan_req->ie and scan_req->ie_len
> against zero before usage, in iwlwifi we should do the same.
>
> Remove not needed "left -= ie_len" while at it.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH] iwlwifi: initialize iwl_wimax_coex_cmd.flags
From: reinette chatre @ 2010-04-16 18:04 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org, Guy, Wey-Yi W
In-Reply-To: <1271425676-32552-1-git-send-email-sgruszka@redhat.com>
On Fri, 2010-04-16 at 06:47 -0700, Stanislaw Gruszka wrote:
> iwl_wimax_coex_cmd.flags can be really uninitialized, so fix
> that.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
Thank you
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [ath9k_htc] Current patches against 2.6.34-rc3-git4
From: Sedat Dilek @ 2010-04-16 18:07 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless@vger.kernel.org, Vivek Natarajan,
Luis R. Rodriguez
In-Reply-To: <19389.36279.77368.650461@gargle.gargle.HOWL>
Thanks for the informations.
Compat-wireless is broken ATM (see IRC backlog below).
>From #linux-wireless/freenode (German local-time - UTC+2):
...
[06:52:54] <mcgrof> User-level discussions about wireless LANs on
Linux | compat-wireless-2.6 only available for kernels >= 2.6.23
(bleeding edge broken right now though)
...
[19:13:41] <jensp> fivetwentysix: He says that he removed the atheros
driver from compat-wireless and replaced it with
http://git.kernel.org/?p=linux/kernel/git/mcgrof/ath9k_htc.git;a=summary
...
I was more interested in following the ath9k_htc development -
especially against Linus-tree.
A GIT repository like in [1] w/could be helpful and if it is
"official" (don't know the status, last commit was before 7 weeks)
worth updating in [2]?
- Sedat -
[1] http://git.kernel.org/?p=linux/kernel/git/mcgrof/ath9k_htc.git;a=summary
[2] http://wireless.kernel.org/en/users/Drivers/ath9k_htc/
On Thu, Apr 8, 2010 at 10:03 AM, Sujith <Sujith.Manoharan@atheros.com> wrote:
> Sedat Dilek wrote:
>> Hi,
>>
>> I (hope I) collected all ath9k_htc patches pending in [1].
>> Unfortunately, my (quilt) series break against Linux 2.6.34-rc3-git4.
>> Any hints?
>
> An easier way to get the latest wireless drivers would be to use
> compat-wireless.
>
> See: http://linuxwireless.org/en/users/Download/
>
> Sujith
>
^ permalink raw reply
* Re: 2.6.33 iwl5350 firmware crash
From: reinette chatre @ 2010-04-16 18:26 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <g2rcb0375e11004151408m4a74639cz28e6129054824543@mail.gmail.com>
On Thu, 2010-04-15 at 14:08 -0700, Andrew Lutomirski wrote:
> [74944.425130] iwlagn 0000:03:00.0: Microcode SW error detected.
> Restarting 0x2000000.
> [74944.425154] iwlagn 0000:03:00.0: Start IWL Error Log Dump:
> [74944.425160] iwlagn 0000:03:00.0: Status: 0x000212E4, count: 5
> [74944.425291] iwlagn 0000:03:00.0: Desc
> Time data1 data2 line
> [74944.425301] iwlagn 0000:03:00.0: NMI_INTERRUPT_WDG (#04)
> 1638059893 0x00000002 0x07030000 3664
[...]
> [74981.401945] ------------[ cut here ]------------
> [74981.401980] WARNING: at net/mac80211/agg-tx.c:152
> ___ieee80211_stop_tx_ba_session+0x87/0x8c [mac80211]()
Please see https://bugzilla.kernel.org/show_bug.cgi?id=15374 - it has
patches that will help aggregation recovery after this NMI problem.
Unfortunately there is nothing we can do at this time to the firmware
error. I'll try to get these patches into 2.6.34 today.
Reinette
^ permalink raw reply
* Re: Survey mode
From: Holger Schurig @ 2010-04-16 18:43 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless; +Cc: Ivan Seskar
In-Reply-To: <z2p43e72e891004161046o81e032ddm20ce1e3528af0684@mail.gmail.com>
> Luiz:
> Holger, are these in PATCH form or were they RFCs?
Both patches work for me, so they're [PATCH]. If John want's them "extra", I
can make sure they apply to linux-wl and repost them.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Survey mode
From: John W. Linville @ 2010-04-16 18:47 UTC (permalink / raw)
To: Holger Schurig; +Cc: Luis R. Rodriguez, linux-wireless, Ivan Seskar
In-Reply-To: <201004162043.07085.holgerschurig@gmail.com>
On Fri, Apr 16, 2010 at 08:43:06PM +0200, Holger Schurig wrote:
> > Luiz:
> > Holger, are these in PATCH form or were they RFCs?
>
> Both patches work for me, so they're [PATCH]. If John want's them "extra", I
> can make sure they apply to linux-wl and repost them.
Sounds like people want them? If so, a repost would be nice...
John
--
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
* Re: [ath9k_htc] Current patches against 2.6.34-rc3-git4
From: Luis R. Rodriguez @ 2010-04-16 19:18 UTC (permalink / raw)
To: sedat.dilek; +Cc: Sujith, linux-wireless@vger.kernel.org, Vivek Natarajan
In-Reply-To: <m2y2d0a357f1004161107h2881b448ta8aebbc7fbc40486@mail.gmail.com>
On Fri, Apr 16, 2010 at 11:07 AM, Sedat Dilek
<sedat.dilek@googlemail.com> wrote:
> Thanks for the informations.
>
> Compat-wireless is broken ATM (see IRC backlog below).
>
> From #linux-wireless/freenode (German local-time - UTC+2):
> ...
> [06:52:54] <mcgrof> User-level discussions about wireless LANs on
> Linux | compat-wireless-2.6 only available for kernels >= 2.6.23
> (bleeding edge broken right now though)
> ...
> [19:13:41] <jensp> fivetwentysix: He says that he removed the atheros
> driver from compat-wireless and replaced it with
> http://git.kernel.org/?p=linux/kernel/git/mcgrof/ath9k_htc.git;a=summary
disregard that tree, its there just for historical purposes now.
> ...
>
> I was more interested in following the ath9k_htc development -
> especially against Linus-tree.
>
> A GIT repository like in [1] w/could be helpful and if it is
> "official" (don't know the status, last commit was before 7 weeks)
> worth updating in [2]?
I've noted elsewhere that what we need to do is to backport these
patches from linux-next:
22bedad3ce112d5ca1eaf043d4990fa2ed698c87 net: convert multicast list
to list_head
2f787b0b76bf5de2eaa3ca3a29d89123ae03c856 mac80211: Ensure initializing
private mc_list in prepare_multicast()
You can get compat-wireless working by reverting these patches (to
what does apply). Its what I would do to backpor t it. We cannot add
the new stuff as the new stuff relies on new changes to internal data
structures, so the way to properly backport this is to ifdef around
the new code and add the reverted code for older kernels.
I haven't had time to do this yet as it involves changes not only on
mac80211 but also on a few other drivers like libertas, etc. It should
be fairly easy to do just haven't had time yet.
Luis
^ permalink raw reply
* Re: [PATCH v3 09/97] ath9k_hw: Move some RF ops to the private callbacks
From: John W. Linville @ 2010-04-16 19:43 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1271367582-992-10-git-send-email-lrodriguez@atheros.com>
On Thu, Apr 15, 2010 at 05:38:14PM -0400, Luis R. Rodriguez wrote:
> The PHY split is easier done in a few steps. First move
> the RF ops to the private ops and rename them accordingly.
> We split PHY stuff up first for the AR5008 and AR9002
> families. There are some callbacks that AR9002 share
> with the AR5008 familiy so we set those first, if AR9002
> has some different callbacks it will override them upon
> hardware init.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/Makefile | 3 +-
> drivers/net/wireless/ath/ath9k/ani.c | 1 +
> .../net/wireless/ath/ath9k/{phy.c => ar5008_phy.c} | 884 ++++++++++----------
In general, it is better to do renames in a separate patch -- the
fixups are easier in cases where something else hit that file before
your patch is applied. It might also help if you based big patches
(or big series) on wireless-next-2.6 instead of wireless-testing, as I
need to apply them to wireless-next-2.6 before I can send them to Dave.
In this case, a patch that wireless-testing picked-up from linux-2.6
and which isn't in wireless-next-2.6 (and probably not net-next-2.6
either) causes this patch to fail to apply to wirless-next-2.6.
I'll fix it up, in the interest of putting this series behind us...
John
--
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
* Power consumption on 802.11 / ASPM / device measurements
From: Luis R. Rodriguez @ 2010-04-16 19:53 UTC (permalink / raw)
To: linux-wireless
Cc: linux-kernel, yanmin.zhang, shaohua.li, Sameer Nanda,
Jonathan May, David Quan
We've been accumulating a few power consumption related documents on
the wireless wiki for a while now. One which I saw was missing was for
actual power consumption and review of new PCI-E features which should
be taken into consideration when debugging power consumption or
reviewing it. ASPM is something that I can say I found little to no
documentation for when looking into it so I've done a brain dump of
what I recall from it, the code review of it, and some e-mail
exchanges I've had with Jonathan May @ Atheros.
I've stashed together all the power consumption docs at:
http://wireless.kernel.org/en/users/Documentation/Power-consumption
You'll see there some ASPM docs now and some ath9k specific power
consumption metrics/ASPM details. Please review and enhance as you see
fit.
Yanmin, Shaohua, I see CONFIG_PCIEASPM still marked as experimental,
I'm curious if this is still really that experimental and if there are
plans for it go out of experimental. Also I am little puzzled with
some of the aspm.c code, I see we fill the pci device struct with
capability stuff via pcie_aspm_cap_init() but I also see ASPM
capability stuff exposed on kernels without CONFIG_PCIEASPM (albeit I
see it always disabled on my system at home), so are we filling the
capability elsewhere? I think there are some boxes without this kernel
config enabled and where ASPM capability info is exposed and does show
up as enabled, could be wrong.
Also curious -- how often are BIOSes buggy enough for ASPM to get
disabled by mistake on the modern devices? And for systems that have
no Bios (*cough* ChromeOS) how is this handled?
Luis
^ permalink raw reply
* Re: [PATCH v3 09/97] ath9k_hw: Move some RF ops to the private callbacks
From: Luis R. Rodriguez @ 2010-04-16 19:56 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <20100416194335.GF8554@tuxdriver.com>
On Fri, Apr 16, 2010 at 12:43 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Thu, Apr 15, 2010 at 05:38:14PM -0400, Luis R. Rodriguez wrote:
>> The PHY split is easier done in a few steps. First move
>> the RF ops to the private ops and rename them accordingly.
>> We split PHY stuff up first for the AR5008 and AR9002
>> families. There are some callbacks that AR9002 share
>> with the AR5008 familiy so we set those first, if AR9002
>> has some different callbacks it will override them upon
>> hardware init.
>>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> drivers/net/wireless/ath/ath9k/Makefile | 3 +-
>> drivers/net/wireless/ath/ath9k/ani.c | 1 +
>> .../net/wireless/ath/ath9k/{phy.c => ar5008_phy.c} | 884 ++++++++++----------
>
> In general, it is better to do renames in a separate patch -- the
> fixups are easier in cases where something else hit that file before
> your patch is applied. It might also help if you based big patches
> (or big series) on wireless-next-2.6 instead of wireless-testing, as I
> need to apply them to wireless-next-2.6 before I can send them to Dave.
>
> In this case, a patch that wireless-testing picked-up from linux-2.6
> and which isn't in wireless-next-2.6 (and probably not net-next-2.6
> either) causes this patch to fail to apply to wirless-next-2.6.
> I'll fix it up, in the interest of putting this series behind us...
Thanks for addressing it on your end this time, next time we'll rebase
on top of wireless-next-2.6 when doing a larger series. I don't expect
this to happen quite often though. This was just a new hardware
family, which happens so far about every what, 4-5 years?
Thanks!!!
Luis
^ permalink raw reply
* RE: Power consumption on 802.11 / ASPM / device measurements
From: David Quan @ 2010-04-16 20:03 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless
Cc: linux-kernel@vger.kernel.org, yanmin.zhang@intel.com,
shaohua.li@intel.com, Sameer Nanda, Jonathan May
In-Reply-To: <n2q43e72e891004161253wbb9afe61y539206f010e91a78@mail.gmail.com>
it is a very complicated issue.
Different system have different limitation.
it is not a one size fits all.
So we let the BIOS of each system with the different chipset control this, and we work with that team
to make sure the correct settings work together for both RC and endpoint.
It should not be controlled by the endpoint as endpoint can get plug into many different systems and endpoint
will not know the limitations of each system/chipset in the system.
I highly recommend you all not to touch the aspm settings from the endpoint, point of view and let the system bios
do what it has been programmed to do.
David
-----Original Message-----
From: Luis R. Rodriguez [mailto:mcgrof@gmail.com]
Sent: Friday, April 16, 2010 12:54 PM
To: linux-wireless
Cc: linux-kernel@vger.kernel.org; yanmin.zhang@intel.com; shaohua.li@intel.com; Sameer Nanda; Jonathan May; David Quan
Subject: Power consumption on 802.11 / ASPM / device measurements
We've been accumulating a few power consumption related documents on
the wireless wiki for a while now. One which I saw was missing was for
actual power consumption and review of new PCI-E features which should
be taken into consideration when debugging power consumption or
reviewing it. ASPM is something that I can say I found little to no
documentation for when looking into it so I've done a brain dump of
what I recall from it, the code review of it, and some e-mail
exchanges I've had with Jonathan May @ Atheros.
I've stashed together all the power consumption docs at:
http://wireless.kernel.org/en/users/Documentation/Power-consumption
You'll see there some ASPM docs now and some ath9k specific power
consumption metrics/ASPM details. Please review and enhance as you see
fit.
Yanmin, Shaohua, I see CONFIG_PCIEASPM still marked as experimental,
I'm curious if this is still really that experimental and if there are
plans for it go out of experimental. Also I am little puzzled with
some of the aspm.c code, I see we fill the pci device struct with
capability stuff via pcie_aspm_cap_init() but I also see ASPM
capability stuff exposed on kernels without CONFIG_PCIEASPM (albeit I
see it always disabled on my system at home), so are we filling the
capability elsewhere? I think there are some boxes without this kernel
config enabled and where ASPM capability info is exposed and does show
up as enabled, could be wrong.
Also curious -- how often are BIOSes buggy enough for ASPM to get
disabled by mistake on the modern devices? And for systems that have
no Bios (*cough* ChromeOS) how is this handled?
Luis
^ permalink raw reply
* Re: 2.6.33 iwl5350 firmware crash
From: reinette chatre @ 2010-04-16 20:07 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org, stable
In-Reply-To: <1271442365.14052.13562.camel@rchatre-DESK>
On Fri, 2010-04-16 at 11:26 -0700, reinette chatre wrote:
> On Thu, 2010-04-15 at 14:08 -0700, Andrew Lutomirski wrote:
> > [74944.425130] iwlagn 0000:03:00.0: Microcode SW error detected.
> > Restarting 0x2000000.
> > [74944.425154] iwlagn 0000:03:00.0: Start IWL Error Log Dump:
> > [74944.425160] iwlagn 0000:03:00.0: Status: 0x000212E4, count: 5
> > [74944.425291] iwlagn 0000:03:00.0: Desc
> > Time data1 data2 line
> > [74944.425301] iwlagn 0000:03:00.0: NMI_INTERRUPT_WDG (#04)
> > 1638059893 0x00000002 0x07030000 3664
>
> [...]
>
> > [74981.401945] ------------[ cut here ]------------
> > [74981.401980] WARNING: at net/mac80211/agg-tx.c:152
> > ___ieee80211_stop_tx_ba_session+0x87/0x8c [mac80211]()
>
>
> Please see https://bugzilla.kernel.org/show_bug.cgi?id=15374 - it has
> patches that will help aggregation recovery after this NMI problem.
> Unfortunately there is nothing we can do at this time to the firmware
> error. I'll try to get these patches into 2.6.34 today.
The patches are already included in 2.6.34. I did try to get this
included into 2.6.33 and submitted it to stable on 03/18/2010,
unfortunately it was not accepted.
Reinette
^ 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