* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Pavel Roskin @ 2009-07-16 20:20 UTC (permalink / raw)
To: Jon Fairbairn; +Cc: linux-wireless
In-Reply-To: <wf1vogmujw.fsf@calligramme.charmers>
On Thu, 2009-07-16 at 18:01 +0100, Jon Fairbairn wrote:
> Ah, thanks for that. Three questions arise:
>
> Are the pci ids quoted above recognised as needing ath5k?
Yes, 168c:001c is served by ath5k.
> Is the WLP-01 really ath5k/really have those ids?
The Abit site had only one driver for WLP-01. There are references that
some WLP-01 devices use Atheros chipset. Thus we conclude that all
WLP-01 use Atheros chipset, or there would be more that one driver.
The Atheros PCI ID is 168c. Search on Google for "WLP-01 168c" without
quotes finds 001c everywhere. So it should work with ath5k.
I cannot guarantee anything, but I think chances are very high.
> The distro I'm using (fedora 11) has 2.6.29 -- will the relevant modules
> build for that, or would I have to build a whole 2.6.31?
You can build compat-wireless, which includes the latest ath5k driver
backported from the wireless-testing kernel. Alternatively, you can
build madwifi (be sure to use the trunk snapshot).
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] handle broken V4 fw region code shift
From: Luis R. Rodriguez @ 2009-07-16 20:11 UTC (permalink / raw)
To: Marek Vasut; +Cc: linux-wireless, Dan Williams, libertas-dev
In-Reply-To: <200907162032.00777.marek.vasut@gmail.com>
On Thu, Jul 16, 2009 at 11:32 AM, Marek Vasut<marek.vasut@gmail.com> wrote:
> Dne Čt 16. července 2009 20:21:30 Dan Williams napsal(a):
>> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
>> > Hi,
>> >
>> > please consider applying/commenting on the following trivial fix. The
>> > description is in the patch. Thanks.
>>
>> Please CC to linux-wireless@vger.kernel and I'll ack there so Linville
>> will pick it up. Any patch that you consider appropriate for actual
>> inclusion at the time you send it is better on linux-wireless.
>> libertas-dev should really be only for hardware/firmware discussions and
>> not-yet-ready patches.
>>
>> Thanks!
>> Dan
>
> Done, thanks! :-)
> (sorry for sending it twice, I missed the address was incomplete in your mail)
>
Please resend inline
Luis
^ permalink raw reply
* Re: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: David Miller @ 2009-07-16 20:07 UTC (permalink / raw)
To: marcel; +Cc: tomasw, yi.zhu, drzeus-list, netdev, linux-wireless, linux-kernel
In-Reply-To: <1247763454.4549.56.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Thu, 16 Jul 2009 18:57:34 +0200
> Hi Dave,
>
>> > > Subject: RE: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
>> >
>> > BTW, subject should be "iwmc3200".
>>
>> Thanks. I'll address all comments although I'm not sure how to split
>> the patch since adding SDIO_VENDOR_ID_INTEL to sdio_ids.h it affects
>> all the drivers anyhow, so I'm suggesting to route it through netdev.
>
> I think it is best that you take the whole patch via net-next-2.6 to
> avoid breakage during the next merge window.
Fair enough.
^ permalink raw reply
* Re: Cross compiling crda and SSL word size
From: Johannes Berg @ 2009-07-16 19:27 UTC (permalink / raw)
To: Jon Smirl; +Cc: linux-wireless
In-Reply-To: <9e4733910907161225m7322b5dcidf9271cb45c07657@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
On Thu, 2009-07-16 at 15:25 -0400, Jon Smirl wrote:
> On Thu, Jul 16, 2009 at 3:24 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> > On Thu, 2009-07-16 at 21:09 +0200, Johannes Berg wrote:
> >> On Thu, 2009-07-16 at 15:04 -0400, Jon Smirl wrote:
> >> > When cross compiling crda the Makefile asks the python system what the
> >> > word size is. This gets the word size from the host. Is there a way to
> >> > ask the word size using gcc? In my environment the Makefile is
> >> > automatically using the correct gcc cross compiler.
> >>
> >> Can you just use gnutls instead? it has no such issue :)
> >>
> >> Otherwise you can probably parse it out of "gcc -dumpspecs", but that
> >> format doesn't look too nice, especially with multilib gcc...
> >
> > C99 says this works, I think:
> >
> > echo -e '#include <limits.h>\n#if ULONG_MAX == 4294967295\n32\n#elif ULONG_MAX == 18446744073709551615U\n64\n#else\n0\n#endif' | gcc -E - | sed 's/^\(#.*\|\)$//;T;d'
>
> The problem test is in key2pub.py
>
> def print_ssl(output, name, val):
> import struct
> if len(struct.pack('@L', 0)) == 8:
> return print_ssl_64(output, name, val)
> else:
> return print_ssl_32(output, name, val)
>
I know, I wrote that code :)
You could make the makefile pass that in as a parameter to the script
instead.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Cross compiling crda and SSL word size
From: Jon Smirl @ 2009-07-16 19:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247772250.30529.42.camel@johannes.local>
On Thu, Jul 16, 2009 at 3:24 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-07-16 at 21:09 +0200, Johannes Berg wrote:
>> On Thu, 2009-07-16 at 15:04 -0400, Jon Smirl wrote:
>> > When cross compiling crda the Makefile asks the python system what the
>> > word size is. This gets the word size from the host. Is there a way to
>> > ask the word size using gcc? In my environment the Makefile is
>> > automatically using the correct gcc cross compiler.
>>
>> Can you just use gnutls instead? it has no such issue :)
>>
>> Otherwise you can probably parse it out of "gcc -dumpspecs", but that
>> format doesn't look too nice, especially with multilib gcc...
>
> C99 says this works, I think:
>
> echo -e '#include <limits.h>\n#if ULONG_MAX == 4294967295\n32\n#elif ULONG_MAX == 18446744073709551615U\n64\n#else\n0\n#endif' | gcc -E - | sed 's/^\(#.*\|\)$//;T;d'
The problem test is in key2pub.py
def print_ssl(output, name, val):
import struct
if len(struct.pack('@L', 0)) == 8:
return print_ssl_64(output, name, val)
else:
return print_ssl_32(output, name, val)
>
> johannes
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cross compiling crda and SSL word size
From: Johannes Berg @ 2009-07-16 19:24 UTC (permalink / raw)
To: Jon Smirl; +Cc: linux-wireless
In-Reply-To: <1247771344.30529.41.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
On Thu, 2009-07-16 at 21:09 +0200, Johannes Berg wrote:
> On Thu, 2009-07-16 at 15:04 -0400, Jon Smirl wrote:
> > When cross compiling crda the Makefile asks the python system what the
> > word size is. This gets the word size from the host. Is there a way to
> > ask the word size using gcc? In my environment the Makefile is
> > automatically using the correct gcc cross compiler.
>
> Can you just use gnutls instead? it has no such issue :)
>
> Otherwise you can probably parse it out of "gcc -dumpspecs", but that
> format doesn't look too nice, especially with multilib gcc...
C99 says this works, I think:
echo -e '#include <limits.h>\n#if ULONG_MAX == 4294967295\n32\n#elif ULONG_MAX == 18446744073709551615U\n64\n#else\n0\n#endif' | gcc -E - | sed 's/^\(#.*\|\)$//;T;d'
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Cross compiling crda and SSL word size
From: Johannes Berg @ 2009-07-16 19:09 UTC (permalink / raw)
To: Jon Smirl; +Cc: linux-wireless
In-Reply-To: <9e4733910907161204x441c21b9n22530800682d363@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Thu, 2009-07-16 at 15:04 -0400, Jon Smirl wrote:
> When cross compiling crda the Makefile asks the python system what the
> word size is. This gets the word size from the host. Is there a way to
> ask the word size using gcc? In my environment the Makefile is
> automatically using the correct gcc cross compiler.
Can you just use gnutls instead? it has no such issue :)
Otherwise you can probably parse it out of "gcc -dumpspecs", but that
format doesn't look too nice, especially with multilib gcc...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Cross compiling crda and SSL word size
From: Jon Smirl @ 2009-07-16 19:04 UTC (permalink / raw)
To: linux-wireless
When cross compiling crda the Makefile asks the python system what the
word size is. This gets the word size from the host. Is there a way to
ask the word size using gcc? In my environment the Makefile is
automatically using the correct gcc cross compiler.
My host is 64b and target is 32b.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] handle broken V4 fw region code shift
From: Marek Vasut @ 2009-07-16 18:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Dan Williams, libertas-dev
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]
Dne Čt 16. července 2009 20:21:30 Dan Williams napsal(a):
> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> > Hi,
> >
> > please consider applying/commenting on the following trivial fix. The
> > description is in the patch. Thanks.
>
> Please CC to linux-wireless@vger.kernel and I'll ack there so Linville
> will pick it up. Any patch that you consider appropriate for actual
> inclusion at the time you send it is better on linux-wireless.
> libertas-dev should really be only for hardware/firmware discussions and
> not-yet-ready patches.
>
> Thanks!
> Dan
Done, thanks! :-)
(sorry for sending it twice, I missed the address was incomplete in your mail)
[-- Attachment #2: 0003-Fix-problem-with-broken-V4-firmware-on-CF8381.patch --]
[-- Type: text/x-patch, Size: 2138 bytes --]
From d69e6db9d424e40dade6bbf107dbab2ff4d692d5 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marek.vasut@gmail.com>
Date: Thu, 16 Jul 2009 19:19:53 +0200
Subject: [PATCH] Fix problem with broken V4 firmware on CF8381
Firmware V4 on CF8381 reports region code shifted by 1 byte to left.
The following patch checks for this and handles it properly.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
---
drivers/net/wireless/libertas/cmd.c | 8 +++++++-
drivers/net/wireless/libertas/defs.h | 2 ++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c
index 01db705..445288d 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -135,8 +135,14 @@ int lbs_update_hw_spec(struct lbs_private *priv)
/* Clamp region code to 8-bit since FW spec indicates that it should
* only ever be 8-bit, even though the field size is 16-bit. Some firmware
* returns non-zero high 8 bits here.
+ *
+ * Firmware version 4.0.102 used in CF8381 has region code shifted. We
+ * need to check for this problem and handle it properly.
*/
- priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
+ if (MRVL_FW_MAJOR_REV(priv->fwrelease) == MRVL_FW_V4)
+ priv->regioncode = (le16_to_cpu(cmd.regioncode) >> 8) & 0xFF;
+ else
+ priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
for (i = 0; i < MRVDRV_MAX_REGION_CODE; i++) {
/* use the region code to search for the index */
diff --git a/drivers/net/wireless/libertas/defs.h b/drivers/net/wireless/libertas/defs.h
index 48da157..72f3479 100644
--- a/drivers/net/wireless/libertas/defs.h
+++ b/drivers/net/wireless/libertas/defs.h
@@ -234,6 +234,8 @@ static inline void lbs_deb_hex(unsigned int grp, const char *prompt, u8 *buf, in
/** Mesh enable bit in FW capability */
#define MESH_CAPINFO_ENABLE_MASK (1<<16)
+/** FW definition from Marvell v4 */
+#define MRVL_FW_V4 (0x04)
/** FW definition from Marvell v5 */
#define MRVL_FW_V5 (0x05)
/** FW definition from Marvell v10 */
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/3] p54: fix a fw crash caused by statistic feedback
From: Christian Lamparter @ 2009-07-16 18:05 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Larry Finger
This patch fixes a bug which crawled into the tree with the split-up
changes.
The memory-manager wasn't aware of the statistic feedback
extra_len space requirements and happily placed following frames
into the allegedly free spots.
Thanks fly out to Larry Finger for taking the time to
test all (permutations of) patches and theories all day long.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
---
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 349375f..efe47ec 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -686,6 +686,8 @@ int p54_upload_key(struct p54_common *priv, u8 algo, int slot, u8 idx, u8 len,
int p54_fetch_statistics(struct p54_common *priv)
{
+ struct ieee80211_tx_info *txinfo;
+ struct p54_tx_info *p54info;
struct sk_buff *skb;
skb = p54_alloc_skb(priv, P54_HDR_FLAG_CONTROL,
@@ -694,6 +696,20 @@ int p54_fetch_statistics(struct p54_common *priv)
if (!skb)
return -ENOMEM;
+ /*
+ * The statistic feedback causes some extra headaches here, if it
+ * is not to crash/corrupt the firmware data structures.
+ *
+ * Unlike all other Control Get OIDs we can not use helpers like
+ * skb_put to reserve the space for the data we're requesting.
+ * Instead the extra frame length -which will hold the results later-
+ * will only be told to the p54_assign_address, so that following
+ * frames won't be placed into the allegedly empty area.
+ */
+ txinfo = IEEE80211_SKB_CB(skb);
+ p54info = (void *) txinfo->rate_driver_data;
+ p54info->extra_len = sizeof(struct p54_statistics);
+
p54_tx(priv, skb);
return 0;
}
^ permalink raw reply related
* [PATCH 2/3] p54: fix beaconing related firmware crash
From: Christian Lamparter @ 2009-07-16 18:03 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Larry.Finger
This patch fixes a firmware crash which can be provoked by changing
operation mode.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
---
diff --git a/drivers/net/wireless/p54/lmac.h b/drivers/net/wireless/p54/lmac.h
index af35cfc..04b63ec 100644
--- a/drivers/net/wireless/p54/lmac.h
+++ b/drivers/net/wireless/p54/lmac.h
@@ -98,6 +98,10 @@ struct p54_hdr {
(!((((struct p54_hdr *) ((struct sk_buff *) skb)->data)-> \
flags) & cpu_to_le16(P54_HDR_FLAG_CONTROL)))
+#define GET_HW_QUEUE(skb) \
+ (((struct p54_tx_data *)((struct p54_hdr *) \
+ skb->data)->data)->hw_queue)
+
/*
* shared interface ID definitions
* The interface ID is a unique identification of a specific interface.
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index f19add2..955f6d7 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -130,7 +130,6 @@ static int p54_beacon_update(struct p54_common *priv,
struct ieee80211_vif *vif)
{
struct sk_buff *beacon;
- __le32 old_beacon_req_id;
int ret;
beacon = ieee80211_beacon_get(priv->hw, vif);
@@ -140,15 +139,16 @@ static int p54_beacon_update(struct p54_common *priv,
if (ret)
return ret;
- old_beacon_req_id = priv->beacon_req_id;
- priv->beacon_req_id = GET_REQ_ID(beacon);
-
- ret = p54_tx_80211(priv->hw, beacon);
- if (ret) {
- priv->beacon_req_id = old_beacon_req_id;
- return -ENOSPC;
- }
-
+ /*
+ * During operation, the firmware takes care of beaconing.
+ * The driver only needs to upload a new beacon template, once
+ * the template was changed by the stack or userspace.
+ *
+ * LMAC API 3.2.2 also specifies that the driver does not need
+ * to cancel the old beacon template by hand, instead the firmware
+ * will release the previous one through the feedback mechanism.
+ */
+ WARN_ON(p54_tx_80211(priv->hw, beacon));
priv->tsf_high32 = 0;
priv->tsf_low32 = 0;
@@ -253,9 +253,14 @@ static void p54_remove_interface(struct ieee80211_hw *dev,
mutex_lock(&priv->conf_mutex);
priv->vif = NULL;
- if (priv->beacon_req_id) {
+
+ /*
+ * LMAC API 3.2.2 states that any active beacon template must be
+ * canceled by the driver before attempting a mode transition.
+ */
+ if (le32_to_cpu(priv->beacon_req_id) != 0) {
p54_tx_cancel(priv, priv->beacon_req_id);
- priv->beacon_req_id = cpu_to_le32(0);
+ wait_for_completion_interruptible_timeout(&priv->beacon_comp, HZ);
}
priv->mode = NL80211_IFTYPE_MONITOR;
memset(priv->mac_addr, 0, ETH_ALEN);
@@ -544,6 +549,7 @@ struct ieee80211_hw *p54_init_common(size_t priv_data_len)
BIT(NL80211_IFTYPE_MESH_POINT);
dev->channel_change_time = 1000; /* TODO: find actual value */
+ priv->beacon_req_id = cpu_to_le32(0);
priv->tx_stats[P54_QUEUE_BEACON].limit = 1;
priv->tx_stats[P54_QUEUE_FWSCAN].limit = 1;
priv->tx_stats[P54_QUEUE_MGMT].limit = 3;
@@ -567,6 +573,7 @@ struct ieee80211_hw *p54_init_common(size_t priv_data_len)
mutex_init(&priv->conf_mutex);
mutex_init(&priv->eeprom_mutex);
init_completion(&priv->eeprom_comp);
+ init_completion(&priv->beacon_comp);
INIT_DELAYED_WORK(&priv->work, p54_work);
return dev;
diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
index 584b156..1afc394 100644
--- a/drivers/net/wireless/p54/p54.h
+++ b/drivers/net/wireless/p54/p54.h
@@ -211,6 +211,7 @@ struct p54_common {
u16 aid;
bool powersave_override;
__le32 beacon_req_id;
+ struct completion beacon_comp;
/* cryptographic engine information */
u8 privacy_caps;
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index 416400c..0d589d6 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -134,9 +134,13 @@ static int p54_assign_address(struct p54_common *priv, struct sk_buff *skb)
range = (void *) info->rate_driver_data;
range->start_addr = target_addr;
range->end_addr = target_addr + len;
+ data->req_id = cpu_to_le32(target_addr + priv->headroom);
+ if (IS_DATA_FRAME(skb) &&
+ unlikely(GET_HW_QUEUE(skb) == P54_QUEUE_BEACON))
+ priv->beacon_req_id = data->req_id;
+
__skb_queue_after(&priv->tx_queue, target_skb, skb);
spin_unlock_irqrestore(&priv->tx_queue.lock, flags);
- data->req_id = cpu_to_le32(target_addr + priv->headroom);
return 0;
}
@@ -209,13 +213,19 @@ static void p54_tx_qos_accounting_free(struct p54_common *priv,
struct sk_buff *skb)
{
if (IS_DATA_FRAME(skb)) {
- struct p54_hdr *hdr = (void *) skb->data;
- struct p54_tx_data *data = (void *) hdr->data;
unsigned long flags;
spin_lock_irqsave(&priv->tx_stats_lock, flags);
- priv->tx_stats[data->hw_queue].len--;
+ priv->tx_stats[GET_HW_QUEUE(skb)].len--;
spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
+
+ if (unlikely(GET_HW_QUEUE(skb) == P54_QUEUE_BEACON)) {
+ if (priv->beacon_req_id == GET_REQ_ID(skb)) {
+ /* this is the active beacon set anymore */
+ priv->beacon_req_id = 0;
+ }
+ complete(&priv->beacon_comp);
+ }
}
p54_wake_queues(priv);
}
@@ -403,10 +413,6 @@ static void p54_rx_frame_sent(struct p54_common *priv, struct sk_buff *skb)
* and we don't want to confuse the mac80211 stack.
*/
if (unlikely(entry_data->hw_queue < P54_QUEUE_FWSCAN)) {
- if (entry_data->hw_queue == P54_QUEUE_BEACON &&
- hdr->req_id == priv->beacon_req_id)
- priv->beacon_req_id = cpu_to_le32(0);
-
dev_kfree_skb_any(entry);
return ;
}
^ permalink raw reply related
* [PATCH 1/3] p54: remove useless code
From: Christian Lamparter @ 2009-07-16 18:03 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Larry Finger
This patch removes some useless checks in recv/xmit code.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index 01eadb1..416400c 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -87,9 +87,6 @@ static int p54_assign_address(struct p54_common *priv, struct sk_buff *skb)
u32 target_addr = priv->rx_start;
u16 len = priv->headroom + skb->len + priv->tailroom + 3;
- if (unlikely(WARN_ON(!skb || !priv)))
- return -EINVAL;
-
info = IEEE80211_SKB_CB(skb);
range = (void *) info->rate_driver_data;
len = (range->extra_len + len) & ~0x3;
@@ -111,11 +108,6 @@ static int p54_assign_address(struct p54_common *priv, struct sk_buff *skb)
range = (void *) info->rate_driver_data;
hole_size = range->start_addr - last_addr;
- if (!entry->next) {
- spin_unlock_irqrestore(&priv->tx_queue.lock, flags);
- return -ENOSPC;
- }
-
if (!target_skb && hole_size >= len) {
target_skb = entry->prev;
hole_size -= len;
@@ -153,9 +145,6 @@ static void p54_tx_pending(struct p54_common *priv)
struct sk_buff *skb;
int ret;
- if (unlikely(WARN_ON(!priv)))
- return ;
-
skb = skb_dequeue(&priv->tx_pending);
if (unlikely(!skb))
return ;
@@ -219,7 +208,7 @@ static int p54_tx_qos_accounting_alloc(struct p54_common *priv,
static void p54_tx_qos_accounting_free(struct p54_common *priv,
struct sk_buff *skb)
{
- if (skb && IS_DATA_FRAME(skb)) {
+ if (IS_DATA_FRAME(skb)) {
struct p54_hdr *hdr = (void *) skb->data;
struct p54_tx_data *data = (void *) hdr->data;
unsigned long flags;
@@ -266,9 +255,6 @@ static struct sk_buff *p54_find_and_unlink_skb(struct p54_common *priv,
void p54_tx(struct p54_common *priv, struct sk_buff *skb)
{
- if (unlikely(WARN_ON(!priv)))
- return ;
-
skb_queue_tail(&priv->tx_pending, skb);
p54_tx_pending(priv);
}
^ permalink raw reply related
* rfkill backport? crash on suspend on compat-wireless?
From: Hin-Tak Leung @ 2009-07-16 17:46 UTC (permalink / raw)
To: linux-wireless
Hi,
compat-wireless hasn't been working for a week or two and it was only
a day or two ago it started building again (on an up to date fedora 11
x86_64). Anyway, I have rtl8187 unload on suspend and it has been
working fine for some months (and still do after I removed
<kernel>/update/*). But I had two crashes on suspend while with the
latest compat-wireless, and that's two out of two occasions. I noticed
that now loading rtl8187 (and mac80211, etc) brings in rfkill_backport
- AFAIK it isn't need on my hardware, but... so I guess my question
is, is anybody experiencing crashes on suspend, newly in the last day
or two?
compat-release - master-2009-07-08-3-g3615cdf
master-tag - master-2009-07-10
git-describe - wireless-testing.git - v2.6.31-rc2-27901-ge59c61b
Also crashes on suspend/resume are rather difficult to diagnose (no
display, no log). How do people normally do anything about this kind
of problem?
Hin-Tak
^ permalink raw reply
* Re: [PATCH v2 16/21] mac80211: add helper for management / no-ack frame rate decision
From: Gábor Stefanik @ 2009-07-16 17:33 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: johannes, linville, linux-wireless, ath9k-devel, Zhu Yi,
Reinette Chatre, ipw3945-devel, Gabor Juhos, Felix Fietkau,
Derek Smithies, Chittajit Mitra
In-Reply-To: <1247763941-21396-1-git-send-email-lrodriguez@atheros.com>
On Thu, Jul 16, 2009 at 7:05 PM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> All current rate control algorithms agree to send management and no-ack
> frames at the lowest rate. They also agree to do this when sta
> and the private rate control data is NULL. We add a hlper to mac80211
> for this and simplify the rate control algorithm code.
>
> Developers wishing to make enhancements to rate control algorithms
> are for broadcast/multicast can opt to not use this in their
> gate_rate() mac80211 callback.
>
> Cc: Zhu Yi <yi.zhu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: ipw3945-devel@lists.sourceforge.net
> Cc: Gabor Juhos <juhosg@openwrt.org>
> Cc: Felix Fietkau <nbd@openwrt.org>
> Cc: Derek Smithies <derek@indranet.co.nz>
> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
ACK.
This will hopefully stop buggy algorithms from cropping up in the future.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH v2 16/21] mac80211: add helper for management / no-ack frame rate decision
From: reinette chatre @ 2009-07-16 17:25 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: johannes@sipsolutions.net, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Zhu, Yi, ipw3945-devel@lists.sourceforge.net, Gabor Juhos,
Felix Fietkau, Derek Smithies, Chittajit Mitra
In-Reply-To: <1247763941-21396-1-git-send-email-lrodriguez@atheros.com>
On Thu, 2009-07-16 at 10:05 -0700, Luis R. Rodriguez wrote:
> All current rate control algorithms agree to send management and no-ack
> frames at the lowest rate. They also agree to do this when sta
> and the private rate control data is NULL. We add a hlper to mac80211
> for this and simplify the rate control algorithm code.
>
> Developers wishing to make enhancements to rate control algorithms
> are for broadcast/multicast can opt to not use this in their
> gate_rate() mac80211 callback.
>
> Cc: Zhu Yi <yi.zhu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: ipw3945-devel@lists.sourceforge.net
> Cc: Gabor Juhos <juhosg@openwrt.org>
> Cc: Felix Fietkau <nbd@openwrt.org>
> Cc: Derek Smithies <derek@indranet.co.nz>
> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
For the iwlwifi bits ...
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Thank you
Reinette
^ permalink raw reply
* [PATCH v2] ath9k: Tune ANI function processing on AP mode during ANI reset
From: Luis R. Rodriguez @ 2009-07-16 17:17 UTC (permalink / raw)
To: johannes, linville
Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez, Bennyam Malavazi,
Jouni Malinen
For AP mode we must tune ANI specially for 2 GHz and
for 5 GHz. We mask in only the flags we want to toggle
on ath9k_hw_ani_control() through the ah->ani_function
bitmask, this will take care of ignoring changes during
ANI reset which we were disabling before.
Testedy-by: Steven Luo <steven@steven676.net>
Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com>
Cc: Jouni Malinen <jouni.malinen@Atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
I had messed up an e-mail address on the commit log, here its fixed.
The actual patch is the same. Seems that shiny new ergonomic keyboard
helps with the hands but won't actually type for you.
drivers/net/wireless/ath/ath9k/ani.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ani.c b/drivers/net/wireless/ath/ath9k/ani.c
index 1aeafb5..aad259b 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -478,6 +478,18 @@ void ath9k_ani_reset(struct ath_hw *ah)
"Reset ANI state opmode %u\n", ah->opmode);
ah->stats.ast_ani_reset++;
+ if (ah->opmode == NL80211_IFTYPE_AP) {
+ /*
+ * ath9k_hw_ani_control() will only process items set on
+ * ah->ani_function
+ */
+ if (IS_CHAN_2GHZ(chan))
+ ah->ani_function = (ATH9K_ANI_SPUR_IMMUNITY_LEVEL |
+ ATH9K_ANI_FIRSTEP_LEVEL);
+ else
+ ah->ani_function = 0;
+ }
+
ath9k_hw_ani_control(ah, ATH9K_ANI_NOISE_IMMUNITY_LEVEL, 0);
ath9k_hw_ani_control(ah, ATH9K_ANI_SPUR_IMMUNITY_LEVEL, 0);
ath9k_hw_ani_control(ah, ATH9K_ANI_FIRSTEP_LEVEL, 0);
--
1.6.3.3
^ permalink raw reply related
* [PATCH v4 01/21] mac80211: drop frames for sta with no valid rate
From: Luis R. Rodriguez @ 2009-07-16 17:15 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez
When we're associated we should be able to send data to
target sta. If we cannot we may be trying to use the incorrect
band to talk to the sta. Lets catch any such cases, warn, and
drop the frames to not invalidate assumptions being made on
rate control algorithms when they have a valid sta to
communicate with. Any such cases should be handled and fixed.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
Fixes a typo on the printk s/from/frame.
include/net/mac80211.h | 11 +++++++++++
net/mac80211/tx.c | 20 ++++++++++++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 14ef478..9428258 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2113,6 +2113,17 @@ rate_lowest_index(struct ieee80211_supported_band *sband,
return 0;
}
+static inline
+bool rate_usable_index_exists(struct ieee80211_supported_band *sband,
+ struct ieee80211_sta *sta)
+{
+ unsigned int i;
+
+ for (i = 0; i < sband->n_bitrates; i++)
+ if (rate_supported(sta, sband->band, i))
+ return true;
+ return false;
+}
int ieee80211_rate_control_register(struct rate_control_ops *ops);
void ieee80211_rate_control_unregister(struct rate_control_ops *ops);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 969a4b2..1d641c1 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -512,6 +512,7 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
int i, len;
bool inval = false, rts = false, short_preamble = false;
struct ieee80211_tx_rate_control txrc;
+ u32 sta_flags;
memset(&txrc, 0, sizeof(txrc));
@@ -544,7 +545,26 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
(tx->sta && test_sta_flags(tx->sta, WLAN_STA_SHORT_PREAMBLE))))
txrc.short_preamble = short_preamble = true;
+ sta_flags = tx->sta ? get_sta_flags(tx->sta) : 0;
+
+ /*
+ * Lets not bother rate control if we're associated and cannot
+ * talk to the sta. This should not happen.
+ */
+ if (WARN((tx->local->sw_scanning) &&
+ (sta_flags & WLAN_STA_ASSOC) &&
+ !rate_usable_index_exists(sband, &tx->sta->sta),
+ "%s: Dropped data frame as no usable bitrate found while "
+ "scanning and associated. Target station: "
+ "%pM on %d GHz band\n",
+ tx->dev->name, hdr->addr1,
+ tx->channel->band ? 5 : 2))
+ return TX_DROP;
+ /*
+ * If we're associated with the sta at this point we know we can at
+ * least send the frame at the lowest bit rate.
+ */
rate_control_get_rate(tx->sdata, tx->sta, &txrc);
if (unlikely(info->control.rates[0].idx < 0))
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2 16/21] mac80211: add helper for management / no-ack frame rate decision
From: Luis R. Rodriguez @ 2009-07-16 17:05 UTC (permalink / raw)
To: johannes, linville
Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez, Zhu Yi,
Reinette Chatre, ipw3945-devel, Gabor Juhos, Felix Fietkau,
Derek Smithies, Chittajit Mitra
All current rate control algorithms agree to send management and no-ack
frames at the lowest rate. They also agree to do this when sta
and the private rate control data is NULL. We add a hlper to mac80211
for this and simplify the rate control algorithm code.
Developers wishing to make enhancements to rate control algorithms
are for broadcast/multicast can opt to not use this in their
gate_rate() mac80211 callback.
Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: ipw3945-devel@lists.sourceforge.net
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/rc.c | 14 +------------
drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 13 ++---------
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 7 +-----
include/net/mac80211.h | 23 ++++++++++++++++++++++
net/mac80211/rate.c | 29 ++++++++++++++++++++++++++++
net/mac80211/rc80211_minstrel.c | 22 +--------------------
net/mac80211/rc80211_pid_algo.c | 11 +---------
7 files changed, 59 insertions(+), 60 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index 2c72901..630fcf4 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -1518,23 +1518,11 @@ exit:
static void ath_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
struct ieee80211_tx_rate_control *txrc)
{
- struct ieee80211_supported_band *sband = txrc->sband;
- struct sk_buff *skb = txrc->skb;
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ath_softc *sc = priv;
struct ath_rate_priv *ath_rc_priv = priv_sta;
- __le16 fc = hdr->frame_control;
- /* lowest rate for management and NO_ACK frames */
- if (!ieee80211_is_data(fc) ||
- tx_info->flags & IEEE80211_TX_CTL_NO_ACK || !sta) {
- tx_info->control.rates[0].idx = rate_lowest_index(sband, sta);
- tx_info->control.rates[0].count =
- (tx_info->flags & IEEE80211_TX_CTL_NO_ACK) ?
- 1 : ATH_MGT_TXMAXTRY;
+ if (rate_control_send_low(sta, priv_sta, txrc))
return;
- }
/* Find tx rate for unicast frames */
ath_rc_ratefind(sc, ath_rc_priv, txrc);
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
index 2b77692..a16bd41 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
@@ -673,7 +673,6 @@ static void rs_get_rate(void *priv_r, struct ieee80211_sta *sta,
s8 scale_action = 0;
unsigned long flags;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- __le16 fc;
u16 rate_mask = sta ? sta->supp_rates[sband->band] : 0;
s8 max_rate_idx = -1;
struct iwl_priv *priv = (struct iwl_priv *)priv_r;
@@ -681,16 +680,10 @@ static void rs_get_rate(void *priv_r, struct ieee80211_sta *sta,
IWL_DEBUG_RATE(priv, "enter\n");
- /* Send management frames and NO_ACK data using lowest rate. */
- fc = hdr->frame_control;
- if (!ieee80211_is_data(fc) || info->flags & IEEE80211_TX_CTL_NO_ACK ||
- !sta || !priv_sta) {
- IWL_DEBUG_RATE(priv, "leave: No STA priv data to update!\n");
- info->control.rates[0].idx = rate_lowest_index(sband, sta);
- if (info->flags & IEEE80211_TX_CTL_NO_ACK)
- info->control.rates[0].count = 1;
+ if (rate_control_send_low(sta, priv_sta, txrc))
return;
- }
+
+ rate_mask = sta->supp_rates[sband->band];
/* get user max rate if set */
max_rate_idx = txrc->max_rate_idx;
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 3fea027..6328041 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -2481,13 +2481,8 @@ static void rs_get_rate(void *priv_r, struct ieee80211_sta *sta, void *priv_sta,
}
/* Send management frames and NO_ACK data using lowest rate. */
- if (!ieee80211_is_data(hdr->frame_control) ||
- info->flags & IEEE80211_TX_CTL_NO_ACK || !sta || !lq_sta) {
- info->control.rates[0].idx = rate_lowest_index(sband, sta);
- if (info->flags & IEEE80211_TX_CTL_NO_ACK)
- info->control.rates[0].count = 1;
+ if (rate_control_send_low(sta, priv_sta, txrc))
return;
- }
rate_idx = lq_sta->last_txrate_idx;
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 9428258..7dd67a1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2097,6 +2097,29 @@ static inline int rate_supported(struct ieee80211_sta *sta,
return (sta == NULL || sta->supp_rates[band] & BIT(index));
}
+/**
+ * rate_control_send_low - helper for drivers for management/no-ack frames
+ *
+ * Rate control algorithms that agree to use the lowest rate to
+ * send management frames and NO_ACK data with the respective hw
+ * retries should use this in the beginning of their mac80211 get_rate
+ * callback. If true is returned the rate control can simply return.
+ * If false is returned we guarantee that sta and sta and priv_sta is
+ * not null.
+ *
+ * Rate control algorithms wishing to do more intelligent selection of
+ * rate for multicast/broadcast frames may choose to not use this.
+ *
+ * @sta: &struct ieee80211_sta pointer to the target destination. Note
+ * that this may be null.
+ * @priv_sta: private rate control structure. This may be null.
+ * @txrc: rate control information we sholud populate for mac80211.
+ */
+bool rate_control_send_low(struct ieee80211_sta *sta,
+ void *priv_sta,
+ struct ieee80211_tx_rate_control *txrc);
+
+
static inline s8
rate_lowest_index(struct ieee80211_supported_band *sband,
struct ieee80211_sta *sta)
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index ac5c8e9..b33efc4 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -198,6 +198,35 @@ static void rate_control_release(struct kref *kref)
kfree(ctrl_ref);
}
+static bool rc_no_data_or_no_ack(struct ieee80211_tx_rate_control *txrc)
+{
+ struct sk_buff *skb = txrc->skb;
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ __le16 fc;
+
+ fc = hdr->frame_control;
+
+ return ((info->flags & IEEE80211_TX_CTL_NO_ACK) || !ieee80211_is_data(fc));
+}
+
+bool rate_control_send_low(struct ieee80211_sta *sta,
+ void *priv_sta,
+ struct ieee80211_tx_rate_control *txrc)
+{
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(txrc->skb);
+
+ if (!sta || !priv_sta || rc_no_data_or_no_ack(txrc)) {
+ info->control.rates[0].idx = rate_lowest_index(txrc->sband, sta);
+ info->control.rates[0].count =
+ (info->flags & IEEE80211_TX_CTL_NO_ACK) ?
+ 1 : txrc->hw->max_rate_tries;
+ return true;
+ }
+ return false;
+}
+EXPORT_SYMBOL(rate_control_send_low);
+
void rate_control_get_rate(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta,
struct ieee80211_tx_rate_control *txrc)
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index 5bdce0c..7c51429 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -70,19 +70,6 @@ rix_to_ndx(struct minstrel_sta_info *mi, int rix)
return i;
}
-static inline bool
-use_low_rate(struct sk_buff *skb)
-{
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
- __le16 fc;
-
- fc = hdr->frame_control;
-
- return ((info->flags & IEEE80211_TX_CTL_NO_ACK) || !ieee80211_is_data(fc));
-}
-
-
static void
minstrel_update_stats(struct minstrel_priv *mp, struct minstrel_sta_info *mi)
{
@@ -231,7 +218,6 @@ minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
void *priv_sta, struct ieee80211_tx_rate_control *txrc)
{
struct sk_buff *skb = txrc->skb;
- struct ieee80211_supported_band *sband = txrc->sband;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct minstrel_sta_info *mi = priv_sta;
struct minstrel_priv *mp = priv;
@@ -244,14 +230,8 @@ minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
int mrr_ndx[3];
int sample_rate;
- if (!sta || !mi || use_low_rate(skb)) {
- ar[0].idx = rate_lowest_index(sband, sta);
- if (info->flags & IEEE80211_TX_CTL_NO_ACK)
- ar[0].count = 1;
- else
- ar[0].count = mp->max_retry;
+ if (rate_control_send_low(sta, priv_sta, txrc))
return;
- }
mrr = mp->has_mrr && !txrc->rts && !txrc->bss_conf->use_cts_prot;
diff --git a/net/mac80211/rc80211_pid_algo.c b/net/mac80211/rc80211_pid_algo.c
index 5496077..8c053be 100644
--- a/net/mac80211/rc80211_pid_algo.c
+++ b/net/mac80211/rc80211_pid_algo.c
@@ -276,11 +276,9 @@ rate_control_pid_get_rate(void *priv, struct ieee80211_sta *sta,
{
struct sk_buff *skb = txrc->skb;
struct ieee80211_supported_band *sband = txrc->sband;
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rc_pid_sta_info *spinfo = priv_sta;
int rateidx;
- __le16 fc;
if (txrc->rts)
info->control.rates[0].count =
@@ -290,15 +288,8 @@ rate_control_pid_get_rate(void *priv, struct ieee80211_sta *sta,
txrc->hw->conf.short_frame_max_tx_count;
/* Send management frames and NO_ACK data using lowest rate. */
- fc = hdr->frame_control;
- if (!sta || !spinfo || !ieee80211_is_data(fc) ||
- info->flags & IEEE80211_TX_CTL_NO_ACK) {
- info->control.rates[0].idx = rate_lowest_index(sband, sta);
- if (info->flags & IEEE80211_TX_CTL_NO_ACK)
- info->control.rates[0].count = 1;
-
+ if (rate_control_send_low(sta, priv_sta, txrc))
return;
- }
rateidx = spinfo->txrate_idx;
--
1.6.3.3
^ permalink raw reply related
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Gábor Stefanik @ 2009-07-16 17:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Jon Fairbairn, Pen Li, linux-wireless
In-Reply-To: <43e72e890907160948o507a3bbbv2f08298c5dcdcee6@mail.gmail.com>
On Thu, Jul 16, 2009 at 6:48 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Thu, Jul 16, 2009 at 9:39 AM, Jon
> Fairbairn<jon.fairbairn@cl.cam.ac.uk> wrote:
>> "Luis R. Rodriguez" <mcgrof@gmail.com>
>> writes:
>>
>>> On Thu, Jul 16, 2009 at 1:02 AM, Jon
>>> Fairbairn<jon.fairbairn@cl.cam.ac.uk> wrote:
>>>>
>>>> A machine I want to set up as an AP has only PCI express slots free...
>>>
>>> I'd recommend ath9k.
>>
>>> http://wireless.kernel.org/en/users/Drivers/ath9k
>>
>> Thanks, but I've seen that page and "products with supported ath9k
>> cards" points to a page that lists "Laptops with ath9k cards" (I'm
>> looking for PCIe, not mini-PCIe) and "APs with ath9k cards", not "ath9k
>> cards". Before I can buy a card, I need to know what it is called in the
>> shops (on-line or otherwise), not what chipset it has.
>
> The page lists all products and the manufacturer names of the products.
>
> But yeah, I am not aware of PCI-Express devices sold in the market
> with separately. Adding Pen Li in case he is aware.
>
> Pen, this e-mail is in a public mailing list.
>
> Luis
> --
> 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
>
A possible solution to the PCIE vs. MiniPCIE problem:
http://www.hwtools.net/Adapter/MP2W.html
http://shop.ebay.com/?_from=R40&_trksid=m38&_nkw=MP2W
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jon Fairbairn @ 2009-07-16 17:01 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1247762215.4235.21.camel@mj>
Pavel Roskin <proski@gnu.org> writes:
> On Thu, 2009-07-16 at 09:02 +0100, Jon Fairbairn wrote:
>
>> I've seen adverts for the Abit WLP-01, and elsewhere on the net seen
>> implications that it's 168c:001c, which isn't listed at
>> <http://wireless.kernel.org/en/users/Devices/PCI>, but
>> <http://wireless.kernel.org/en/users/Drivers/ath5k> does list it and
>> says AP mode not working, but mentions
>> <http://madwifi-project.org/wiki/Compatibility/Abit>, which suggest AP
>> mode works with madwifi. What's the current status?
>
> ath5k will support the AP mode in Linux 2.6.31. It's already in Linux
> 2.6.31-rc3.
Ah, thanks for that. Three questions arise:
Are the pci ids quoted above recognised as needing ath5k?
Is the WLP-01 really ath5k/really have those ids?
The distro I'm using (fedora 11) has 2.6.29 -- will the relevant modules
build for that, or would I have to build a whole 2.6.31?
Thanks.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 16/21] mac80211: add helper for management / no-ack frame rate decision
From: Luis R. Rodriguez @ 2009-07-16 17:00 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu, Yi, Chittajit Mitra, linux-wireless@vger.kernel.org,
linville@tuxdriver.com, ipw3945-devel@lists.sourceforge.net,
Derek Smithies, ath9k-devel@lists.ath9k.org,
johannes@sipsolutions.net
In-Reply-To: <1247690000.17896.2205.camel@rc-desk>
On Wed, Jul 15, 2009 at 1:33 PM, reinette
chatre<reinette.chatre@intel.com> wrote:
> Hi Luis,
>
> On Tue, 2009-07-14 at 17:14 -0700, Luis R. Rodriguez wrote:
>> All current rate control algorithms agree to send management and no-ack
>> frames at the lowest rate. They also agree to do this when sta
>> and the private rate control data is NULL. We add a hlper to mac80211
>> for this and simplify the rate control algorithm code.
>>
>> Developers wishing to make enhancements to rate control algorithms
>> are for broadcast/multicast can opt to not use this in their
>> gate_rate() mac80211 callback.
>>
>> Cc: Zhu Yi <yi.zhu@intel.com>
>> Cc: Reinette Chatre <reinette.chatre@intel.com>
>> Cc: ipw3945-devel@lists.sourceforge.net
>> Cc: Gabor Juhos <juhosg@openwrt.org>
>> Cc: Felix Fietkau <nbd@openwrt.org>
>> Cc: Derek Smithies <derek@indranet.co.nz>
>> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> drivers/net/wireless/ath/ath9k/rc.c | 14 +------------
>> drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 13 ++---------
>> drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 7 +-----
>> include/net/mac80211.h | 23 ++++++++++++++++++++++
>> net/mac80211/rate.c | 29 ++++++++++++++++++++++++++++
>> net/mac80211/rc80211_minstrel.c | 22 +--------------------
>> net/mac80211/rc80211_pid_algo.c | 11 +---------
>> 7 files changed, 59 insertions(+), 60 deletions(-)
>>
>
>> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
>> index 3fea027..695a841 100644
>> --- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
>> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
>> @@ -2481,13 +2481,8 @@ static void rs_get_rate(void *priv_r, struct ieee80211_sta *sta, void *priv_sta,
>> }
>>
>> /* Send management frames and NO_ACK data using lowest rate. */
>> - if (!ieee80211_is_data(hdr->frame_control) ||
>> - info->flags & IEEE80211_TX_CTL_NO_ACK || !sta || !lq_sta) {
>> - info->control.rates[0].idx = rate_lowest_index(sband, sta);
>> - if (info->flags & IEEE80211_TX_CTL_NO_ACK)
>> - info->control.rates[0].count = 1;
>> + if (rate_control_send_low(sta, priv_r, txrc))
>
> I think it should be priv_sta instead of priv_r here.
>
> The rest looks good for iwlwifi.
Good catch, thanks for testing and reviewing, will post a v2 for this.
Luis
^ permalink raw reply
* Re: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: Marcel Holtmann @ 2009-07-16 16:57 UTC (permalink / raw)
To: Tomas Winkler
Cc: Zhu, Yi, drzeus-list@drzeus.cx, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1ba2fa240907160804g18b1a215w3161c9682db7b35@mail.gmail.com>
Hi Dave,
> > > Subject: RE: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
> >
> > BTW, subject should be "iwmc3200".
>
> Thanks. I'll address all comments although I'm not sure how to split
> the patch since adding SDIO_VENDOR_ID_INTEL to sdio_ids.h it affects
> all the drivers anyhow, so I'm suggesting to route it through netdev.
I think it is best that you take the whole patch via net-next-2.6 to
avoid breakage during the next merge window.
Regards
Marcel
^ permalink raw reply
* Re: prism54 firmware cannot initialize pcmcia card
From: Luis R. Rodriguez @ 2009-07-16 16:51 UTC (permalink / raw)
To: Dave; +Cc: linux-wireless
In-Reply-To: <loom.20090716T120033-657@post.gmane.org>
On Thu, Jul 16, 2009 at 5:09 AM, Dave<dave.mulford@gmail.com> wrote:
> First, some generic info about the laptop I'm using
>
> gentoo kernel-2.6.29
> prism54-firmware-2.13.2 (listed as working with in-kernel >=2.6.29 driver)
> yenta_cardbus driver
>
> Everything seems to work. The driver is loaded, the card is recognized, the
> driver requests the correct firmware name, then the firmware seems to have
> issues initializing the card. I have posted the relevant entries in dmesg to
> http://pastebin.com/f7514c9c0
>
> Any help is appreciated. Thanks!
You are using p54 softmac firmware with the old fullmac prism54
driver. You can now use the p54 softmac driver. See:
http://wireless.kernel.org/en/users/Drivers/p54
Luis
^ permalink raw reply
* Re: [RFC/RFT 4/5] mac80211: Replace {sw,hw}_scanning variables with a bitfield
From: Luis R. Rodriguez @ 2009-07-16 16:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: Helmut Schaa, linux-wireless
In-Reply-To: <1247762613.30529.33.camel@johannes.local>
On Thu, Jul 16, 2009 at 9:43 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Thu, 2009-07-16 at 09:30 -0700, Luis R. Rodriguez wrote:
>> On Thu, Jul 16, 2009 at 2:08 AM, Helmut
>> Schaa<helmut.schaa@googlemail.com> wrote:
>> > Use a bitfield to store the current scan mode instead of two boolean
>> > variables {sw,hw}_scanning. This patch does not introduce functional
>> > changes.
>> >
>>
>> > +enum mac80211_scan_flag {
>> > + SCAN_SW_SCANNING = 1,
>> > + SCAN_HW_SCANNING = 2,
>> > +};
>> > +
>>
>> But why is that needed? The commit log doesn't state that. We won't
>> use both at the same time.
>
> You're nitpicking ;)
> We currently have two variables, and this just changes them into two
> bits instead, so he can extend the sw-scanning case with another bit :)
I didn't realize that until reading the next patch.
Luis
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Luis R. Rodriguez @ 2009-07-16 16:48 UTC (permalink / raw)
To: Jon Fairbairn, Pen Li; +Cc: linux-wireless
In-Reply-To: <wf63dsmvjg.fsf@calligramme.charmers>
On Thu, Jul 16, 2009 at 9:39 AM, Jon
Fairbairn<jon.fairbairn@cl.cam.ac.uk> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com>
> writes:
>
>> On Thu, Jul 16, 2009 at 1:02 AM, Jon
>> Fairbairn<jon.fairbairn@cl.cam.ac.uk> wrote:
>>>
>>> A machine I want to set up as an AP has only PCI express slots free...
>>
>> I'd recommend ath9k.
>
>> http://wireless.kernel.org/en/users/Drivers/ath9k
>
> Thanks, but I've seen that page and "products with supported ath9k
> cards" points to a page that lists "Laptops with ath9k cards" (I'm
> looking for PCIe, not mini-PCIe) and "APs with ath9k cards", not "ath9k
> cards". Before I can buy a card, I need to know what it is called in the
> shops (on-line or otherwise), not what chipset it has.
The page lists all products and the manufacturer names of the products.
But yeah, I am not aware of PCI-Express devices sold in the market
with separately. Adding Pen Li in case he is aware.
Pen, this e-mail is in a public mailing list.
Luis
^ 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