* ath6kl ar6004 usb adapter
From: Lorenzo Nava @ 2013-08-28 6:31 UTC (permalink / raw)
To: linux-wireless
Hi everybosy,
I'm looking for a ar6004 based chip wireless usb adapter.
Anybody knows any available wifi usb adapter with that chip?
Thank you.
Cheers.
^ permalink raw reply
* Re: [PATCH v2 1/6] ath10k: use inline ce_state structure
From: Michal Kazior @ 2013-08-28 5:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87y57mjvwu.fsf@kamboji.qca.qualcomm.com>
On 28 August 2013 06:12, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> Simplifies memory managament of ce_state.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Sorry, I noticed this only in my second review round:
>
>> --- a/drivers/net/wireless/ath/ath10k/pci.h
>> +++ b/drivers/net/wireless/ath/ath10k/pci.h
>> @@ -233,7 +233,10 @@ struct ath10k_pci {
>> spinlock_t ce_lock;
>>
>> /* Map CE id to ce_state */
>> - struct ce_state *ce_id_to_state[CE_COUNT_MAX];
>> + struct ce_state ce_states[CE_COUNT_MAX];
>> +
>> + /* makes sure that dummy reads are atomic */
>> + spinlock_t hw_v1_workaround_lock;
>> };
>
> That lock doesn't look right. Is it a leftover from a rebase?
Oh, good catch. I wonder how it got there..
Michał.
^ permalink raw reply
* NGFF based WLAN module
From: Matt Chen @ 2013-08-28 5:27 UTC (permalink / raw)
To: linux-wireless
Hi,
I have a NGFF WLAN module, Intel Wilkins Peak 2, I am wondering how to =
enable it. I found there is nothing from the lspci result. Is there any =
way to enable it in Linux ?
Thanks.
^ permalink raw reply
* Re: Update e-mail address for Andrea Merello
From: Greg KH @ 2013-08-28 5:05 UTC (permalink / raw)
To: Andrea Merello; +Cc: linville, linux-wireless, linux-kernel
In-Reply-To: <1377518010-14767-1-git-send-email-andrea.merello@gmail.com>
On Mon, Aug 26, 2013 at 01:53:30PM +0200, Andrea Merello wrote:
> A lot of files contain reference to my old e-mail address.
> Now I'm going not to read mail from it anymore, so update it
> with my current address everywhere.
>
> Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
I stripped out and took only the drivers/staging/* changes in this
patch. I'd recommend resending all the drivers/net/wireless/ changes to
the linux-wireless@ group again, so they can apply just those changes.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/4] ath10k: synchronize tx/rx reporting to mac80211
From: Kalle Valo @ 2013-08-28 4:23 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1377507205-5386-2-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> According to mac80211 docs tx and rx reporting
> routines must not run concurrently unless they are
> _irqsafe variants.
>
> This doesn't fix any visible bug but is apparently
> the right thing to do as per the documentation.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
I had a quick chat with Johannes and Sujith about this. The concurrency
requirements are for the STA PS race in AP mode (see
ieee80211_handle_filtered_frame()).
I think we should drop this frame, revisit later and properly analyse
how to fix the race. But it would be good add this to the todo list:
http://wireless.kernel.org/en/users/Drivers/ath10k#TODO
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 1/6] ath10k: use inline ce_state structure
From: Kalle Valo @ 2013-08-28 4:12 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1377601683-12072-2-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Simplifies memory managament of ce_state.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Sorry, I noticed this only in my second review round:
> --- a/drivers/net/wireless/ath/ath10k/pci.h
> +++ b/drivers/net/wireless/ath/ath10k/pci.h
> @@ -233,7 +233,10 @@ struct ath10k_pci {
> spinlock_t ce_lock;
>
> /* Map CE id to ce_state */
> - struct ce_state *ce_id_to_state[CE_COUNT_MAX];
> + struct ce_state ce_states[CE_COUNT_MAX];
> +
> + /* makes sure that dummy reads are atomic */
> + spinlock_t hw_v1_workaround_lock;
> };
That lock doesn't look right. Is it a leftover from a rebase?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: Fix mutex unlock balance
From: Kalle Valo @ 2013-08-28 4:09 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan; +Cc: linux-wireless, ath10k
In-Reply-To: <1377102404-14742-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
>
> ath10k_debug_read_target_stats is properly
> protected by data_lock (spinlock). Remove
> the unwanted mutex_unlock(&ar->conf_mutex)
[...]
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 4/4] ath10k: fix issues on non-preemptible systems
From: Kalle Valo @ 2013-08-28 4:02 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQ=ycKd0Z60wHTWHoq7hBz1W2iW+ahjVmc_nFLQmU7-1Bg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 27 August 2013 09:06, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>
>> I consider this more as a workaround as a real fix. Would NAPI be a
>> proper fix for issues like this?
>>
>> NAPI support was removed from mac80211 six months ago, but I guess we
>> could try to get it back if we have a good reason:
>>
>> http://marc.info/?l=linux-wireless&m=136204135907491
>
> Hmm. From what I understand NAPI is used for RX polling. My patch
> addresses mainly WMI/HTT TX starvation.
I thought I saw something related to NAPI on TX as well, but I can't
find it anymore.
> There's another solution that I had in mind. Instead of:
>
> for (;;) { dequeue(z); process; }
>
> I did:
>
> q = dequeue_all(z); for (;;) { dequeue(q); process; }
>
> I.e. move all queued stuff at the worker entry and move it out of the
> global queue, that can, and will be, having more stuff queued while
> the worker does its job).
>
> This way workers would exit/restart more often, but from what I tested
> it didn't really solve the problem. Given enough traffic HTC worker
> responsible for HTT TX gets overwhelmed eventually. You could try
> limit how many frames a worker can process during one execution, but
> how do you guess that? This starvation depends on how fast your CPU
> is.
I think we should come up with better ways to handle this. To have a
quota (like you mention above) would be one option. Other option would
be to have multiple queues and some sort of priorisation or fair
queueing.
And most importantly of all, we should minimise the lenght of queue we
have inside ath10k. I'm worried that we queue way too many packets
within ath10k right now.
> Thus I opted for sole cond_resched().
Yeah, this is a good workaround for the problem. But it would be good to
get bottom of this as well.
>>> +#ifndef CONFIG_PREEMPT
>>> + cond_resched();
>>> +#endif
>>
>> Why the #ifndef? Why should we not call cond_resched() when PREEMPT is
>> enabled? Does something negative happen then?
>
> I think it should be okay. I saw the #ifndef thing in b43legacy and
> thought it simply makes sense (although it's unsightly).
For various reasons I would prefer to have cond_resched() without the
#ifndef, if possible.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/4] ath10k: fixes
From: Kalle Valo @ 2013-08-28 3:53 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Michal Kazior, ath10k
In-Reply-To: <20130827080144.GB29102@pogo>
"Luis R. Rodriguez" <rodrigue@qca.qualcomm.com> writes:
>> I disagree. The point of linux-stable is _not_ that we send all possible
>> fixes to stable. Instead we should send fixes only which really matter
>> to users and for which we have received bug reports. I haven't yet seen
>> any fix for ath10k which should be a candidate for stable releases.
>
> You don't need to wait for an issue to happen to consider it serious,
> the description of the symptoms seem pretty bad to me, but its your
> call in the end.
>
>> If we start sending all ath10k fixes to stable it's just extra churn for
>> both Greg and people working on ath10k.
>
> I'm not asking for anything that has the word "fix" to be sent, I'm
> asking them to be reviewed for stable consideration.
I think a good rule is that we should send fixes to stable only if a
user (!= developer) has reported the problem.
--
Kalle Valo
^ permalink raw reply
* Re: [E1000-devel] [PATCH net-next] drivers:net: Convert dma_alloc_coherent(...__GFP_ZERO) to dma_zalloc_coherent
From: Jeff Kirsher @ 2013-08-28 1:44 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, e1000-devel, users, linux-wireless, linux-kernel, b43-dev
In-Reply-To: <1377582323.2658.10.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
On Mon, 2013-08-26 at 22:45 -0700, Joe Perches wrote:
> __GFP_ZERO is an uncommon flag and perhaps is better
> not used. static inline dma_zalloc_coherent exists
> so convert the uses of dma_alloc_coherent with __GFP_ZERO
> to the more common kernel style with zalloc.
>
> Remove memset from the static inline dma_zalloc_coherent
> and add just one use of __GFP_ZERO instead.
>
> Trivially reduces the size of the existing uses of
> dma_zalloc_coherent.
>
> Realign arguments as appropriate.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 2/2] cw1200: Prevent a lock-related hang in the cw1200_spi driver
From: Solomon Peachy @ 2013-08-28 0:29 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1377649787-2817-1-git-send-email-pizza@shaftnet.org>
The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock
API, which relies on sdio_claim_host/sdio_release_host to serialize
hardware operations across multiple threads.
Unfortunately the implementation was flawed, as it lacked a way to wake
up the lock requestor when there was contention, often resulting in a
hang.
This problem was uncovered while trying to fix the
spi-transfers-in-interrupt-context BUG() corrected in the previous
patch. Many thanks to Dave Sizeburns for his assistance in fixing this.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
Please consider this for 3.11-rc; without this patch SPI users are all
but guaranteed to deadlock while running this driver.
drivers/net/wireless/cw1200/cw1200_spi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index c31580b..f5e6b48 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -40,6 +40,7 @@ struct hwbus_priv {
struct cw1200_common *core;
const struct cw1200_platform_data_spi *pdata;
spinlock_t lock; /* Serialize all bus operations */
+ wait_queue_head_t wq;
int claimed;
int irq_disabled;
};
@@ -198,8 +199,11 @@ static void cw1200_spi_lock(struct hwbus_priv *self)
{
unsigned long flags;
+ DECLARE_WAITQUEUE(wait, current);
+
might_sleep();
+ add_wait_queue(&self->wq, &wait);
spin_lock_irqsave(&self->lock, flags);
while (1) {
set_current_state(TASK_UNINTERRUPTIBLE);
@@ -212,6 +216,7 @@ static void cw1200_spi_lock(struct hwbus_priv *self)
set_current_state(TASK_RUNNING);
self->claimed = 1;
spin_unlock_irqrestore(&self->lock, flags);
+ remove_wait_queue(&self->wq, &wait);
return;
}
@@ -223,6 +228,8 @@ static void cw1200_spi_unlock(struct hwbus_priv *self)
spin_lock_irqsave(&self->lock, flags);
self->claimed = 0;
spin_unlock_irqrestore(&self->lock, flags);
+ wake_up(&self->wq);
+
return;
}
@@ -413,6 +420,8 @@ static int cw1200_spi_probe(struct spi_device *func)
spi_set_drvdata(func, self);
+ init_waitqueue_head(&self->wq);
+
status = cw1200_spi_irq_subscribe(self);
status = cw1200_core_probe(&cw1200_spi_hwbus_ops,
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] cw1200: Don't perform SPI transfers in interrupt context
From: Solomon Peachy @ 2013-08-28 0:29 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the interrupt line. Unfortunately this
involves a SPI transaction in interrupt context. Some (most?) SPI
controllers perform the transfer asynchronously and try to sleep.
This is bad, and triggers a BUG().
So, work around this by using adding a hwbus hook for the cw1200 driver
core to call. The cw1200_spi driver translates this into
irq_disable()/irq_enable() calls instead, which can safely be called in
interrupt context.
Apparently the platforms I used to develop the cw1200_spi driver used
synchronous spi_sync() implementations, which is why this didn't surface
until now.
Many thanks to Dave Sizeburns for the inital bug report and his services
as a tester.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
Please consider this for 3.11-rc; without this patch many SPI users
will immediately trigger a BUG().
drivers/net/wireless/cw1200/cw1200_spi.c | 19 ++++++++++++++++---
drivers/net/wireless/cw1200/fwio.c | 2 +-
drivers/net/wireless/cw1200/hwbus.h | 1 +
drivers/net/wireless/cw1200/hwio.c | 15 +++++++++++++++
4 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index d063760..c31580b 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -41,6 +41,7 @@ struct hwbus_priv {
const struct cw1200_platform_data_spi *pdata;
spinlock_t lock; /* Serialize all bus operations */
int claimed;
+ int irq_disabled;
};
#define SDIO_TO_SPI_ADDR(addr) ((addr & 0x1f)>>2)
@@ -230,6 +231,8 @@ static irqreturn_t cw1200_spi_irq_handler(int irq, void *dev_id)
struct hwbus_priv *self = dev_id;
if (self->core) {
+ disable_irq_nosync(self->func->irq);
+ self->irq_disabled = 1;
cw1200_irq_handler(self->core);
return IRQ_HANDLED;
} else {
@@ -263,13 +266,22 @@ exit:
static int cw1200_spi_irq_unsubscribe(struct hwbus_priv *self)
{
- int ret = 0;
-
pr_debug("SW IRQ unsubscribe\n");
disable_irq_wake(self->func->irq);
free_irq(self->func->irq, self);
- return ret;
+ return 0;
+}
+
+static int cw1200_spi_irq_enable(struct hwbus_priv *self, int enable)
+{
+ /* Disables are handled by the interrupt handler */
+ if (enable && self->irq_disabled) {
+ enable_irq(self->func->irq);
+ self->irq_disabled = 0;
+ }
+
+ return 0;
}
static int cw1200_spi_off(const struct cw1200_platform_data_spi *pdata)
@@ -349,6 +361,7 @@ static struct hwbus_ops cw1200_spi_hwbus_ops = {
.unlock = cw1200_spi_unlock,
.align_size = cw1200_spi_align_size,
.power_mgmt = cw1200_spi_pm,
+ .irq_enable = cw1200_spi_irq_enable,
};
/* Probe Function to be called by SPI stack when device is discovered */
diff --git a/drivers/net/wireless/cw1200/fwio.c b/drivers/net/wireless/cw1200/fwio.c
index acdff0f..0b2061b 100644
--- a/drivers/net/wireless/cw1200/fwio.c
+++ b/drivers/net/wireless/cw1200/fwio.c
@@ -485,7 +485,7 @@ int cw1200_load_firmware(struct cw1200_common *priv)
/* Enable interrupt signalling */
priv->hwbus_ops->lock(priv->hwbus_priv);
- ret = __cw1200_irq_enable(priv, 1);
+ ret = __cw1200_irq_enable(priv, 2);
priv->hwbus_ops->unlock(priv->hwbus_priv);
if (ret < 0)
goto unsubscribe;
diff --git a/drivers/net/wireless/cw1200/hwbus.h b/drivers/net/wireless/cw1200/hwbus.h
index 8b2fc83..51dfb3a 100644
--- a/drivers/net/wireless/cw1200/hwbus.h
+++ b/drivers/net/wireless/cw1200/hwbus.h
@@ -28,6 +28,7 @@ struct hwbus_ops {
void (*unlock)(struct hwbus_priv *self);
size_t (*align_size)(struct hwbus_priv *self, size_t size);
int (*power_mgmt)(struct hwbus_priv *self, bool suspend);
+ int (*irq_enable)(struct hwbus_priv *self, int enable);
};
#endif /* CW1200_HWBUS_H */
diff --git a/drivers/net/wireless/cw1200/hwio.c b/drivers/net/wireless/cw1200/hwio.c
index ff230b7..41bd761 100644
--- a/drivers/net/wireless/cw1200/hwio.c
+++ b/drivers/net/wireless/cw1200/hwio.c
@@ -273,6 +273,21 @@ int __cw1200_irq_enable(struct cw1200_common *priv, int enable)
u16 val16;
int ret;
+ /* We need to do this hack because the SPI layer can sleep on I/O
+ and the general path involves I/O to the device in interrupt
+ context.
+
+ However, the initial enable call needs to go to the hardware.
+
+ We don't worry about shutdown because we do a full reset which
+ clears the interrupt enabled bits.
+ */
+ if (priv->hwbus_ops->irq_enable) {
+ ret = priv->hwbus_ops->irq_enable(priv->hwbus_priv, enable);
+ if (ret || enable < 2)
+ return ret;
+ }
+
if (HIF_8601_SILICON == priv->hw_type) {
ret = __cw1200_reg_read_32(priv, ST90TDS_CONFIG_REG_ID, &val32);
if (ret < 0) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] cw1200: When debug is enabled, display all wakeup conditions for the wait_event_interruptible_timeout() call.
From: Solomon Peachy @ 2013-08-28 0:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1377649033-2091-1-git-send-email-pizza@shaftnet.org>
When trying to debug an interrupt delivery problem I noticed that not
all of the wakeup conditions on the worker thread were included in the
debug message. This patch rectifies that.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/bh.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cw1200/bh.c b/drivers/net/wireless/cw1200/bh.c
index c1ec2a4..92d299a 100644
--- a/drivers/net/wireless/cw1200/bh.c
+++ b/drivers/net/wireless/cw1200/bh.c
@@ -465,8 +465,8 @@ static int cw1200_bh(void *arg)
(rx || tx || term || suspend || priv->bh_error);
}), status);
- pr_debug("[BH] - rx: %d, tx: %d, term: %d, suspend: %d, status: %ld\n",
- rx, tx, term, suspend, status);
+ pr_debug("[BH] - rx: %d, tx: %d, term: %d, bh_err: %d, suspend: %d, status: %ld\n",
+ rx, tx, term, suspend, priv->bh_error, status);
/* Did an error occur? */
if ((status < 0 && status != -ERESTARTSYS) ||
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] cw1200: Display the correct default reference clock.
From: Solomon Peachy @ 2013-08-28 0:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
This is purely a cosmetic bug.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/cw1200/main.c b/drivers/net/wireless/cw1200/main.c
index 3724e73..090f015 100644
--- a/drivers/net/wireless/cw1200/main.c
+++ b/drivers/net/wireless/cw1200/main.c
@@ -507,7 +507,7 @@ u32 cw1200_dpll_from_clk(u16 clk_khz)
case 0xCB20: /* 52000 KHz */
return 0x07627091;
default:
- pr_err("Unknown Refclk freq (0x%04x), using 2600KHz\n",
+ pr_err("Unknown Refclk freq (0x%04x), using 26000KHz\n",
clk_khz);
return 0x0EC4F121;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 2/2] staging: vt6656: device.h Replace typedef struct _RCB
From: Greg KH @ 2013-08-27 23:57 UTC (permalink / raw)
To: Malcolm Priestley; +Cc: linux-wireless
In-Reply-To: <1377603883.3320.93.camel@canaries32-MCP7A>
On Tue, Aug 27, 2013 at 12:44:43PM +0100, Malcolm Priestley wrote:
> Replace with struct vnt_rcb
>
> Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
> ---
> drivers/staging/vt6656/device.h | 20 +++++++++-----------
> drivers/staging/vt6656/dpc.c | 10 +++++-----
> drivers/staging/vt6656/dpc.h | 4 ++--
> drivers/staging/vt6656/main_usb.c | 14 ++++++++------
> drivers/staging/vt6656/usbpipe.c | 4 ++--
> drivers/staging/vt6656/usbpipe.h | 2 +-
> 6 files changed, 27 insertions(+), 27 deletions(-)
This patch only applies with fuzz, which means we are starting to get
out of sync. Can you refresh this one against my staging-next tree,
which I've applied all of your other patches to, and resend it?
thanks,
greg k-h
^ permalink raw reply
* RE: sd8787 (mwifiex) on big endian system
From: Bing Zhao @ 2013-08-27 23:42 UTC (permalink / raw)
To: Tobias Waldekranz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20130827061745.GA19431@gmail.com>
Hi Tobias,
> Hi Bing,
>
> Here is the log output without the added udelay. It is always the 0xd9
> command that fails, but not always with these sdio_ireg/wr_bitmask
> values. I have seen these combinations:
>
> - sdio_ireg incorrect(2), wr_bitmask incorrect(fffe)
> - sdio_ireg correct(3), wr_bitmask incorrect(fffe)
> - sdio_ireg incorrect(2), wr_bitmask correct(ffff)
>
> Waiting 50 us before reading the mp_regs always returns the correct
> response.
Thanks for the logs.
Could you try the following change to bypass 0xd9 command?
diff --git a/drivers/net/wireless/mwifiex/sta_cmd.c b/drivers/net/wireless/mwifi
index c0268b5..3cecc86 100644
--- a/drivers/net/wireless/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/mwifiex/sta_cmd.c
@@ -1541,6 +1541,7 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8
if (ret)
return -1;
+#if 0
/* Reconfigure tx buf size */
ret = mwifiex_send_cmd_sync(priv,
HostCmd_CMD_RECONFIGURE_TX_BUFF,
@@ -1548,6 +1549,7 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8
&priv->adapter->tx_buf_size);
if (ret)
return -1;
+#endif
if (priv->bss_type != MWIFIEX_BSS_TYPE_UAP) {
/* Enable IEEE PS by default */
Thanks,
Bing
^ permalink raw reply related
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Larry Finger @ 2013-08-27 23:17 UTC (permalink / raw)
To: Colleen Josephson; +Cc: linux-wireless
In-Reply-To: <CAN3-2D6Cf6Ew2Ar5ZD5ZCamhKF92wnKjgP=dEk15UF1YDXJS5g@mail.gmail.com>
On 08/27/2013 06:09 PM, Colleen Josephson wrote:
> Any updates? Or addition information that would be useful? I will be
> relocating to the other side of the US next week, so I will be unable
> to collect more information or traces on this specific network after
> then.
I have been busy getting a new driver into the kernel before 3.12 comes out. I
am now looking into both rtl8192ce and rtl8192cu. I think I have what I need
from you.
Larry
^ permalink raw reply
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Colleen Josephson @ 2013-08-27 23:09 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <CAN3-2D5+tvQyZKBP3vUwGWdctCcfCeBxAhPsZs+DCLDdr4dyCw@mail.gmail.com>
Any updates? Or addition information that would be useful? I will be
relocating to the other side of the US next week, so I will be unable
to collect more information or traces on this specific network after
then.
^ permalink raw reply
* Re: Problems associating to AP with rtl8192cu driver
From: Mark Cave-Ayland @ 2013-08-27 22:05 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <521D17C7.2070105@lwfinger.net>
On 27/08/13 22:19, Larry Finger wrote:
Hi Larry,
>> The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP
>> firmware should also be reasonably up-to-date. Access to all APs is
>> fine using
>> an Android phone, the zd1211rw desktop PC and a laptop with an iwlwifi
>> driver.
>> The APs are set to advertise both WPA and WPA2 encryption.
>
> The accepted firmware has an md5sum of 943e9b714a926e630b8152d7aad91d2e
> for /lib/firmware/rtlwifi/rtl8192cufw.bin.
Yes - that agrees with what I have here:
mca@kentang:~$ md5sum /lib/firmware/rtlwifi/rtl8192cufw.bin
943e9b714a926e630b8152d7aad91d2e /lib/firmware/rtlwifi/rtl8192cufw.bin
>>> Do you still have the wireshark file from the failed attempt? If so,
>>> could you filter out the traffic from APs and stations other than the
>>> units trying to make the connection, and send me (privately) the trimmed
>>> file?
>>
>> Yes - I'm not sure if it's exactly that attempt, but I do have a
>> representative
>> wireshark trace of this which I will send to you privately.
>>
>>> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
>>> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
>>> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.
>>
>> Okay. So perhaps there is something slightly different about this
>> particular
>> WiFi dongle...
>
> Neither rtl8192cu nor 8192cu (the vendor driver) work with the 2x2
> configuration such as found in a TP-Link TL-WN8200ND V1.0. That was
> reported to Realtek, but I have had no response from them.
Understood. All of the O2 wireless box, desktop PC and Netgear AP I used
in my tests here are b/g only, so I'm guessing that shouldn't be an issue?
ATB,
Mark.
^ permalink raw reply
* Re: Problems associating to AP with rtl8192cu driver
From: Larry Finger @ 2013-08-27 21:19 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: linux-wireless
In-Reply-To: <521D0EA2.2070105@ilande.co.uk>
On 08/27/2013 03:40 PM, Mark Cave-Ayland wrote:
> On 27/08/13 17:23, Larry Finger wrote:
>
> Hi Larry,
>
>> I just retested and this message was posted from what lsusb says is a
>> "Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
>> 802.11n Wireless Adapter [Realtek RTL8188CUS]" connected to an AP using
>> WPA(1).
>
> I'm actually testing a dongle from a Raspberry Pi that I've been experiencing
> issues with under load with the Realtek-written 8192cu driver. My understanding
> is that it is an OEM RTL8188CUS adapter from here:
> http://thepihut.com/products/usb-wifi-adapter-for-the-raspberry-pi.
>
>> My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built
>> 3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I
>> will build and test the mainline kernel, but it should not make a
>> difference as the only code differences between wireless-testing and the
>> mainline trees deal with cleaning up some sparse endian issues.
>>
>> What is the make/model of the AP that fails? Is its firmware the latest
>> available? Just to confirm, you are running WPA1 encryption.
>
> It seems to be all of the ones I'm testing :/ Currently that's an old Netgear
> DG834G, a desktop PC running Debian Wheezy/hostapd using a zd1211rw-based WiFi
> dongle, and an O2 Wireless box (rebadged Thomson). The problem seems to be that
> association is difficult, and even when it does associate then the AP appears to
> drop out every minute or so.
>
> The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP
> firmware should also be reasonably up-to-date. Access to all APs is fine using
> an Android phone, the zd1211rw desktop PC and a laptop with an iwlwifi driver.
> The APs are set to advertise both WPA and WPA2 encryption.
The accepted firmware has an md5sum of 943e9b714a926e630b8152d7aad91d2e for
/lib/firmware/rtlwifi/rtl8192cufw.bin.
>> Do you still have the wireshark file from the failed attempt? If so,
>> could you filter out the traffic from APs and stations other than the
>> units trying to make the connection, and send me (privately) the trimmed
>> file?
>
> Yes - I'm not sure if it's exactly that attempt, but I do have a representative
> wireshark trace of this which I will send to you privately.
>
>> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
>> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
>> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.
>
> Okay. So perhaps there is something slightly different about this particular
> WiFi dongle...
Neither rtl8192cu nor 8192cu (the vendor driver) work with the 2x2 configuration
such as found in a TP-Link TL-WN8200ND V1.0. That was reported to Realtek, but I
have had no response from them.
Larry
^ permalink raw reply
* Re: Problems associating to AP with rtl8192cu driver
From: Mark Cave-Ayland @ 2013-08-27 20:40 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <521CD266.5010801@lwfinger.net>
On 27/08/13 17:23, Larry Finger wrote:
Hi Larry,
> I just retested and this message was posted from what lsusb says is a
> "Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
> 802.11n Wireless Adapter [Realtek RTL8188CUS]" connected to an AP using
> WPA(1).
I'm actually testing a dongle from a Raspberry Pi that I've been
experiencing issues with under load with the Realtek-written 8192cu
driver. My understanding is that it is an OEM RTL8188CUS adapter from
here: http://thepihut.com/products/usb-wifi-adapter-for-the-raspberry-pi.
> My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built
> 3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I
> will build and test the mainline kernel, but it should not make a
> difference as the only code differences between wireless-testing and the
> mainline trees deal with cleaning up some sparse endian issues.
>
> What is the make/model of the AP that fails? Is its firmware the latest
> available? Just to confirm, you are running WPA1 encryption.
It seems to be all of the ones I'm testing :/ Currently that's an old
Netgear DG834G, a desktop PC running Debian Wheezy/hostapd using a
zd1211rw-based WiFi dongle, and an O2 Wireless box (rebadged Thomson).
The problem seems to be that association is difficult, and even when it
does associate then the AP appears to drop out every minute or so.
The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP
firmware should also be reasonably up-to-date. Access to all APs is fine
using an Android phone, the zd1211rw desktop PC and a laptop with an
iwlwifi driver. The APs are set to advertise both WPA and WPA2 encryption.
> Do you still have the wireshark file from the failed attempt? If so,
> could you filter out the traffic from APs and stations other than the
> units trying to make the connection, and send me (privately) the trimmed
> file?
Yes - I'm not sure if it's exactly that attempt, but I do have a
representative wireshark trace of this which I will send to you privately.
> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.
Okay. So perhaps there is something slightly different about this
particular WiFi dongle...
Many thanks,
Mark.
^ permalink raw reply
* Re: pull request: wireless 2013-08-23
From: David Miller @ 2013-08-27 19:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130823162044.GD15114@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 23 Aug 2013 12:20:44 -0400
> This is one more set of fixes intended for the 3.11 stream...
>
> For the mac80211 bits, Johannes says:
>
> "I have three more patches for the 3.11 stream: Felix's fix for the
> fairly visible brcmsmac crash, a fix from Simon for an IBSS join bug I
> found and a fix for a channel context bug in IBSS I'd introduced."
>
> Along with those...
>
> Sujith Manoharan makes a minor change to not use a PLL hang workaroun
> for AR9550. This one-liner fixes a couple of bugs reported in the Red Hat
> bugzilla.
>
> Helmut Schaa addresses an ath9k_htc bug that mangles frame headers
> during Tx. This fix is small, tested by the bug reported and isolated
> to ath9k_htc.
>
> Stanislaw Gruszka reverts a recent iwl4965 change that broke rfkill
> notification to user space.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net-next] drivers:net: Convert dma_alloc_coherent(...__GFP_ZERO) to dma_zalloc_coherent
From: Jesse Brandeburg @ 2013-08-27 19:34 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, linux-kernel, e1000-devel, linux-wireless, b43-dev, users,
jesse.brandeburg
In-Reply-To: <1377582323.2658.10.camel@joe-AO722>
On Mon, 26 Aug 2013 22:45:23 -0700
Joe Perches <joe@perches.com> wrote:
> __GFP_ZERO is an uncommon flag and perhaps is better
> not used. static inline dma_zalloc_coherent exists
> so convert the uses of dma_alloc_coherent with __GFP_ZERO
> to the more common kernel style with zalloc.
>
> Remove memset from the static inline dma_zalloc_coherent
> and add just one use of __GFP_ZERO instead.
>
> Trivially reduces the size of the existing uses of
> dma_zalloc_coherent.
>
> Realign arguments as appropriate.
>
> Signed-off-by: Joe Perches <joe@perches.com>
e1000 and ixgb bits:
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
^ permalink raw reply
* [PATCH] iw: Print out HotSpot2 IE information.
From: greearb @ 2013-08-27 19:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Example:
HotSpot 2.0 Indication:
DGAF: 0
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 1a48509... c20c386... M scan.c
scan.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/scan.c b/scan.c
index 1a48509..c20c386 100644
--- a/scan.c
+++ b/scan.c
@@ -1388,8 +1388,21 @@ static inline void print_p2p(const uint8_t type, uint8_t len, const uint8_t *dat
}
}
+static inline void print_hs20_ind(const uint8_t type, uint8_t len, const uint8_t *data)
+{
+ /* I can't find the spec for this...just going off what wireshark uses. */
+ printf("\n");
+ if (len > 0) {
+ printf("\t\tDGAF: %i\n", (int)(data[0] & 0x1));
+ }
+ else {
+ printf("\t\tUnexpected length: %i\n", len);
+ }
+}
+
static const struct ie_print wfa_printers[] = {
[9] = { "P2P", print_p2p, 2, 255, BIT(PRINT_SCAN), },
+ [16] = { "HotSpot 2.0 Indication", print_hs20_ind, 1, 255, BIT(PRINT_SCAN), },
};
static void print_vendor(unsigned char len, unsigned char *data,
--
1.7.3.4
^ permalink raw reply related
* [PATCH] iw: Print 802.11u roaming consortium IE in scan results.
From: greearb @ 2013-08-27 17:26 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Example output:
802.11u Roaming Consortium:
ANQP OIs: 0
OI 1: 01010101
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 b1917b0... 1a48509... M scan.c
scan.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/scan.c b/scan.c
index b1917b0..1a48509 100644
--- a/scan.c
+++ b/scan.c
@@ -709,6 +709,58 @@ static void print_11u_advert(const uint8_t type, uint8_t len, const uint8_t *dat
}
}
+static void print_11u_rcon(const uint8_t type, uint8_t len, const uint8_t *data)
+{
+ /* See Section 7.3.2.96 in the 802.11u spec. */
+ int idx = 0;
+ int ln0 = data[1] & 0xf;
+ int ln1 = ((data[1] & 0xf0) >> 4);
+ int ln2 = 0;
+ printf("\n");
+
+ if (ln1) {
+ ln2 = len - 2 - ln0 - ln1;
+ }
+ printf("\t\tANQP OIs: %i\n", data[0]);
+
+ if (ln0 > 0) {
+ printf("\t\tOI 1: ");
+ if (2 + ln0 > len) {
+ printf("Invalid IE length.\n");
+ }
+ else {
+ for (idx = 0; idx < ln0; idx++) {
+ printf("%02hx", data[2 + idx]);
+ }
+ printf("\n");
+ }
+ }
+ if (ln1 > 0) {
+ printf("\t\tOI 2: ");
+ if (2 + ln0 + ln1 > len) {
+ printf("Invalid IE length.\n");
+ }
+ else {
+ for (idx = 0; idx < ln1; idx++) {
+ printf("%02hx", data[2 + ln0 + idx]);
+ }
+ printf("\n");
+ }
+ }
+ if (ln2 > 0) {
+ printf("\t\tOI 3: ");
+ if (2 + ln0 + ln1 + ln2 > len) {
+ printf("Invalid IE length.\n");
+ }
+ else {
+ for (idx = 0; idx < ln2; idx++) {
+ printf("%02hx", data[2 + ln0 + ln1 + idx]);
+ }
+ printf("\n");
+ }
+ }
+}
+
static const char *ht_secondary_offset[4] = {
"no secondary",
"above",
@@ -988,6 +1040,7 @@ static const struct ie_print ieprinters[] = {
[127] = { "Extended capabilities", print_capabilities, 0, 255, BIT(PRINT_SCAN), },
[107] = { "802.11u Interworking", print_interworking, 0, 255, BIT(PRINT_SCAN), },
[108] = { "802.11u Advertisement", print_11u_advert, 0, 255, BIT(PRINT_SCAN), },
+ [111] = { "802.11u Roaming Consortium", print_11u_rcon, 0, 255, BIT(PRINT_SCAN), },
};
static void print_wifi_wpa(const uint8_t type, uint8_t len, const uint8_t *data)
--
1.7.3.4
^ 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