* Re: [PATCH] wl1251: halt the embedded CPU before loading firmware
From: Kalle Valo @ 2009-09-10 19:25 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20090818033356.GB524@hash.localnet>
Bob Copeland <me@bobcopeland.com> writes:
> After initial power-up, the embedded cpu is usually halted. However,
> if we down the interface and only do a soft reset before bringing
> the interface back up, it will still be running and the firmware
> loading code will bail out. This change halts the CPU before loading
> the firmware, enabling a second call to wl1251_boot() to succeed
> without a hard reset.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Kalle Valo <kalle.valo@nokia.com>
(Even though the patch is already in wireless-testing.)
> Hi Kalle,
Hi Bob,
sorry for the long delay. Last few weeks has been crazy :)
> Thoughts on this? It fixes my remaining issue with warm card reset.
> I think Android code does this in the firmware loader:
I'm fine with this. I tested the patch with spi and it works fine.
Thanks again.
--
Kalle Valo
^ permalink raw reply
* Re: AP: ath5k + hostapd occasionally sulks
From: Philip A. Prindeville @ 2009-09-10 18:55 UTC (permalink / raw)
To: Bob Copeland; +Cc: jon.fairbairn, linux-wireless
In-Reply-To: <4AA7DB6C.9060207@redfish-solutions.com>
Philip Prindeville wrote:
> Bob Copeland wrote:
>
>> On Tue, Sep 8, 2009 at 1:53 PM, Philip Prindeville
>> <philipp_subx@redfish-solutions.com> wrote:
>>
>>
>>> I pulled compat-wireless from GIT last night (or about 1:30am mountain,
>>> really) and rebuilt a 2.6.27.29 kernel.
>>>
>>> I'm seeing a lot of:
>>>
>>> Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packet
>>>
>>>
>>> one every 10 seconds, in fact. This is with an Engenius EMP-8062+ card:
>>>
>>>
>> Ok, the timing information is useful. This is probably something (beacon
>> sending?) racing with the periodic calibration, which temporarily stops
>> all of the tx traffic and frees the tx buffers, then starts it all up
>> again. In short, apart from the logging this shouldn't cause any
>> problems, but we should probably disable the beacon tasklet during this
>> time.
>>
>>
>
> Alas it is causing problems. I have a Windows 7 client with an Atheros
> card (I forget which... it's the mini-PCIe card that comes with Zotac
> ION mini-itx motherboards).
>
> I either can't associate, or associate but don't get a DHCP address or
> don't pass traffic... I forget which.
>
> I can do more testing tomorrow...
>
>> If this only appeared all of a sudden in recent compat snapshots, it
>> would be useful to know the last one that worked normally.
>>
>>
>
> I could walk it backwards, I suppose... 2009-08-23 was definitely
> working with an 9K board.
>
> I've not tried it with a 5K board (I'm not at this location very often).
>
FYI: The Windows 7 box associates and runs just fine with 9K driver
with 2009-09-07. So it seems to be an issue with the 5K driver.
I'll set up a second WAP with a 5K card...
-Philip
>
>
>>> I'll probably have to reboot regularly, since this is on an embedded box
>>> with limited CF filesystem, and I can't overflow my /var partition...
>>>
>>>
>> Ouch. For now, just take it out or demote it to debug.
>>
>> As for the original problem, I don't know offhand why a large download
>> would trigger a cascade of these errors. The best way to track it down
>> is to try to come up with a case that reproduces it and sprinkle printks
>> throughout the driver, especially when we free and allocate the tx
>> buffers.
>>
>>
>>
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: reinette chatre @ 2009-09-10 18:50 UTC (permalink / raw)
To: Frans Pop
Cc: Mel Gorman, Larry Finger, John W. Linville, Pekka Enberg,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton,
cl@linux-foundation.org, Krauss, Assaf, Johannes Berg,
Abbas, Mohamed
In-Reply-To: <200909102043.17883.elendil@planet.nl>
On Thu, 2009-09-10 at 11:43 -0700, Frans Pop wrote:
> Looks good to me (from a user's perspective).
Thank you very much for looking at it.
> IIUC the first message is now only displayed if IWL debugging is
> explicitly enabled,
Correct. User will have to enable debug flag of 0x1.
> It seems to me that, with debugging enabled, the "Failed to allocate SKB
> buffer." message may get repeated, but I guess that's minor.
Yes, it will be repeated. I did add a "net_ratelimit()" to it so it
should not be too overwhelming. I did not care to limit it even more
since we are now talking about a debug message as opposed to an error
message on the console.
> One nitpick. As you've made the message into sentences, "Only %u free
> buffers remaining" should IMO also end with a period.
Sorry - will fix. I will not post a new version to this thread for this
issue, but it will be fixed in the next version I send out.
Reinette
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Frans Pop @ 2009-09-10 18:43 UTC (permalink / raw)
To: reinette chatre
Cc: Mel Gorman, Larry Finger, John W. Linville, Pekka Enberg,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton,
cl@linux-foundation.org, Krauss, Assaf, Johannes Berg,
Abbas, Mohamed
In-Reply-To: <1252606547.30150.304.camel@rc-desk>
On Thursday 10 September 2009, reinette chatre wrote:
> From: Reinette Chatre <reinette.chatre@intel.com>
> Date: Wed, 9 Sep 2009 15:41:00 -0700
> Subject: [PATCH] iwlwifi: reduce noise when skb allocation fails
Looks good to me (from a user's perspective).
IIUC the first message is now only displayed if IWL debugging is
explicitly enabled, and the second only if there really is danger of it
affecting data transfer and has been made more informative too.
It seems to me that, with debugging enabled, the "Failed to allocate SKB
buffer." message may get repeated, but I guess that's minor.
One nitpick. As you've made the message into sentences, "Only %u free
buffers remaining" should IMO also end with a period.
Thanks,
FJP
^ permalink raw reply
* Re: [PATCH] b43: Force-wake queues on init
From: Michael Buesch @ 2009-09-10 18:38 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Albert Herranz, linux-wireless,
Broadcom Wireless
In-Reply-To: <43e72e890909101134j64bf22eai1c282cc1738cd968@mail.gmail.com>
On Thursday 10 September 2009 20:34:36 Luis R. Rodriguez wrote:
> On Thu, Sep 10, 2009 at 11:31 AM, Michael Buesch <mb@bu3sch.de> wrote:
> > Force wake the mac80211 queues on init.
> > Under rare circumstances they may be stopped, if a DMA error or
> > something else causes a device reset while a queue was stopped.
>
> So this is a work around for some unknown issue on the driver?
No, it's a fix for a bug that should not trigger in practice very often.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: Force-wake queues on init
From: Luis R. Rodriguez @ 2009-09-10 18:34 UTC (permalink / raw)
To: Michael Buesch
Cc: John W. Linville, Albert Herranz, linux-wireless,
Broadcom Wireless
In-Reply-To: <200909102031.47103.mb@bu3sch.de>
On Thu, Sep 10, 2009 at 11:31 AM, Michael Buesch <mb@bu3sch.de> wrote:
> Force wake the mac80211 queues on init.
> Under rare circumstances they may be stopped, if a DMA error or
> something else causes a device reset while a queue was stopped.
So this is a work around for some unknown issue on the driver?
Luis
^ permalink raw reply
* [PATCH] b43: Force-wake queues on init
From: Michael Buesch @ 2009-09-10 18:31 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless, Albert Herranz
Force wake the mac80211 queues on init.
Under rare circumstances they may be stopped, if a DMA error or
something else causes a device reset while a queue was stopped.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-09-10 20:13:54.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-09-10 20:26:43.000000000 +0200
@@ -4326,6 +4326,8 @@ static int b43_wireless_core_init(struct
b43_upload_card_macaddress(dev);
b43_security_init(dev);
+ ieee80211_wake_queues(dev->wl->hw);
+
b43_set_status(dev, B43_STAT_INITIALIZED);
out:
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43: Do not use _irqsafe callbacks
From: Michael Buesch @ 2009-09-10 18:22 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless, Albert Herranz
We don't need to call the irqsafe callbacks.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Apply on top the other patches.
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c 2009-09-05 12:31:01.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/dma.c 2009-09-10 20:14:25.000000000 +0200
@@ -1428,9 +1428,9 @@ void b43_dma_handle_txstatus(struct b43_
ring->nr_failed_tx_packets++;
ring->nr_total_packet_tries += status->frame_count;
#endif /* DEBUG */
- ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb);
+ ieee80211_tx_status(dev->wl->hw, meta->skb);
- /* skb is freed by ieee80211_tx_status_irqsafe() */
+ /* skb is freed by ieee80211_tx_status() */
meta->skb = NULL;
} else {
/* No need to call free_descriptor_buffer here, as
Index: wireless-testing/drivers/net/wireless/b43/pio.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/pio.c 2009-09-05 12:31:02.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/pio.c 2009-09-10 20:14:37.000000000 +0200
@@ -574,7 +574,7 @@ void b43_pio_handle_txstatus(struct b43_
q->buffer_used -= total_len;
q->free_packet_slots += 1;
- ieee80211_tx_status_irqsafe(dev->wl->hw, pack->skb);
+ ieee80211_tx_status(dev->wl->hw, pack->skb);
pack->skb = NULL;
list_add(&pack->list, &q->packets_list);
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/xmit.c 2009-09-06 16:17:08.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/xmit.c 2009-09-10 20:13:29.000000000 +0200
@@ -690,7 +690,7 @@ void b43_rx(struct b43_wldev *dev, struc
}
memcpy(IEEE80211_SKB_RXCB(skb), &status, sizeof(status));
- ieee80211_rx_irqsafe(dev->wl->hw, skb);
+ ieee80211_rx(dev->wl->hw, skb);
return;
drop:
--
Greetings, Michael.
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: reinette chatre @ 2009-09-10 18:15 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton,
cl@linux-foundation.org, Krauss, Assaf, Johannes Berg,
Abbas, Mohamed
In-Reply-To: <20090910090206.GA22276@csn.ul.ie>
On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote:
> > We can thus use ___GFP_NOWARN for the allocations in
> > iwl_rx_allocate and leave it to the restocking to find the needed memory
> > when it tried its allocations using GFP_KERNEL.
> >
>
> Would it be possible to use __GFP_NOWARN *unless* this allocation is
> necessary to receive the packet?
I think so.
> > I do think it is useful to let user know about these allocation
> > failures, even if it does not result in packet loss. Wrapping it in
> > net_ratelimit() will help though.
> >
>
> If it does not distinguish between failures causing packet loss and just a
> temporary issue, I'd be worried the messages would generate bug reports and
> we genuinely won't know if it's a real problem or not.
Good point.
>
> As a total aside, there is still the problem that the driver is depending on
> order-2 allocations. On systems without swap, the allocation problem could be
> more severe as there are fewer pages the system can use to regain contiguity.
It seems that somebody did think about this in the initialization of
max_pkt_size (which is priv->hw_params.rx_buf_size - 256). If we use
max_pkt_size in the code that allocates the skb then the 256 added for
alignment will not cause it to go to an order-2 allocation. I do not
know why max_pkt_size is not used at the moment and will have to do some
digging to find out.
>
> > How about the patch below?
> >
> > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c
> > index b90adcb..f0ee72e 100644
> > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c
> > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
> > @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority)
> >
> > /* Alloc a new receive buffer */
> > skb = alloc_skb(priv->hw_params.rx_buf_size + 256,
> > - priority);
> > + priority | __GFP_NOWARN);
> >
>
> So, would it be possible here to only remove __GFP_NOWARN if this is GFP_ATOMIC
> (implying we have to refill now) and the rxq->free_count is really small
> e.g. <= 2?
I like your suggestion. Considering the issue I would like to remove
__GFP_NOWARN even if it is GFP_KERNEL ... I think it is actually even
more of a problem if we are in GFP_KERNEL and not able to allocate
memory when running low on buffers. Also, with the queue size of 256 I
think we can use RX_LOW_WATERMARK here, which is 8.
>
> > if (!skb) {
> > - IWL_CRIT(priv, "Can not allocate SKB buffers\n");
> > + if (net_ratelimit())
> > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n");
>
> Similarly, could the message either be supressed when there is enough
> buffers in the RX queue or differenciate between enough buffers and
> things getting tight possibly causing packet loss?
Frans also had comments in this regard. Will do.
>
> The IWL_CRIT() part even is a hint - there is no guarantee that the allocation
> failure is really a critical problem.
Right.
How about this:
>From bd2153dd9e4a0ad588adec38c580d67023d5587e Mon Sep 17 00:00:00 2001
From: Reinette Chatre <reinette.chatre@intel.com>
Date: Wed, 9 Sep 2009 15:41:00 -0700
Subject: [PATCH] iwlwifi: reduce noise when skb allocation fails
Replenishment of receive buffers is done in the tasklet handling
received frames as well as in a workqueue. When we are in the tasklet
we cannot sleep and thus attempt atomic skb allocations. It is generally
not a big problem if this fails since iwl_rx_allocate is always followed
by a call to iwl_rx_queue_restock which will queue the work to replenish
the buffers at a time when sleeping is allowed.
We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to
reduce the noise if such an allocation fails while we still have enough
buffers. We do maintain the warning and the error message when we are low
on buffers to communicate to the user that there is a potential problem with
memory availability on system
This addresses issue reported upstream in thread "iwlagn: order 2 page
allocation failures" in
http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-rx.c | 12 +++++++++---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 8 +++++++-
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c
index b90adcb..cb50cc7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
@@ -250,12 +250,18 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority)
}
spin_unlock_irqrestore(&rxq->lock, flags);
+ if (rxq->free_count > RX_LOW_WATERMARK)
+ priority |= __GFP_NOWARN;
/* Alloc a new receive buffer */
- skb = alloc_skb(priv->hw_params.rx_buf_size + 256,
- priority);
+ skb = alloc_skb(priv->hw_params.rx_buf_size + 256, priority);
if (!skb) {
- IWL_CRIT(priv, "Can not allocate SKB buffers\n");
+ if (net_ratelimit())
+ IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n");
+ if ((rxq->free_count <= RX_LOW_WATERMARK) &&
+ net_ratelimit())
+ IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n",
+ rxq->free_count);
/* We don't reschedule replenish work here -- we will
* call the restock method and if it still needs
* more buffers it will schedule replenish */
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 0909668..0d96b17 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1146,11 +1146,17 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority)
}
spin_unlock_irqrestore(&rxq->lock, flags);
+ if (rxq->free_count > RX_LOW_WATERMARK)
+ priority |= __GFP_NOWARN;
/* Alloc a new receive buffer */
skb = alloc_skb(priv->hw_params.rx_buf_size, priority);
if (!skb) {
if (net_ratelimit())
- IWL_CRIT(priv, ": Can not allocate SKB buffers\n");
+ IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n");
+ if ((rxq->free_count <= RX_LOW_WATERMARK) &&
+ net_ratelimit())
+ IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n",
+ rxq->free_count);
/* We don't reschedule replenish work here -- we will
* call the restock method and if it still needs
* more buffers it will schedule replenish */
--
1.5.6.3
^ permalink raw reply related
* [PATCH] b43: Add Soft-MAC SDIO device support
From: Michael Buesch @ 2009-09-10 17:34 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless, Albert Herranz
From: Albert Herranz <albert_herranz@yahoo.es>
This adds support for Soft-MAC SDIO devices to b43.
The driver still lacks some fixes for SDIO devices, so it's currently
marked as BROKEN.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Depends on the SSB SDIO patch.
Index: wireless-testing/drivers/net/wireless/b43/Kconfig
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/Kconfig 2009-09-10 19:23:09.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/Kconfig 2009-09-10 19:33:24.000000000 +0200
@@ -61,11 +61,28 @@ config B43_PCMCIA
If unsure, say N.
+config B43_SDIO
+ bool "Broadcom 43xx SDIO device support (EXPERIMENTAL)"
+ depends on B43 && SSB_SDIOHOST_POSSIBLE && EXPERIMENTAL && BROKEN
+ select SSB_SDIOHOST
+ ---help---
+ Broadcom 43xx device support for Soft-MAC SDIO devices.
+
+ With this config option you can drive Soft-MAC b43 cards with a
+ Secure Digital I/O interface.
+ This includes the WLAN daughter card found on the Nintendo Wii
+ video game console.
+ Note that this does not support Broadcom 43xx Full-MAC devices.
+
+ It's safe to select Y here, even if you don't have a B43 SDIO device.
+
+ If unsure, say N.
+
# Data transfers to the device via PIO
-# This is only needed on PCMCIA devices. All others can do DMA properly.
+# This is only needed on PCMCIA and SDIO devices. All others can do DMA properly.
config B43_PIO
bool
- depends on B43 && (B43_PCMCIA || B43_FORCE_PIO)
+ depends on B43 && (B43_SDIO || B43_PCMCIA || B43_FORCE_PIO)
select SSB_BLOCKIO
default y
Index: wireless-testing/drivers/net/wireless/b43/Makefile
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/Makefile 2009-09-10 19:23:09.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/Makefile 2009-09-10 19:23:20.000000000 +0200
@@ -16,6 +16,7 @@ b43-$(CONFIG_B43_PIO) += pio.o
b43-y += rfkill.o
b43-$(CONFIG_B43_LEDS) += leds.o
b43-$(CONFIG_B43_PCMCIA) += pcmcia.o
+b43-$(CONFIG_B43_SDIO) += sdio.o
b43-$(CONFIG_B43_DEBUG) += debugfs.o
obj-$(CONFIG_B43) += b43.o
Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-09-10 19:23:09.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-09-10 19:23:20.000000000 +0200
@@ -8,6 +8,9 @@
Copyright (c) 2005 Danny van Dyk <kugelfang@gentoo.org>
Copyright (c) 2005 Andreas Jaggi <andreas.jaggi@waterwave.ch>
+ SDIO support
+ Copyright (c) 2009 Albert Herranz <albert_herranz@yahoo.es>
+
Some parts of the code in this file are derived from the ipw2200
driver Copyright(c) 2003 - 2004 Intel Corporation.
@@ -53,6 +56,8 @@
#include "xmit.h"
#include "lo.h"
#include "pcmcia.h"
+#include "sdio.h"
+#include <linux/mmc/sdio_func.h>
MODULE_DESCRIPTION("Broadcom B43 wireless driver");
MODULE_AUTHOR("Martin Langer");
@@ -1587,7 +1592,7 @@ static void b43_beacon_update_trigger_wo
mutex_lock(&wl->mutex);
dev = wl->current_dev;
if (likely(dev && (b43_status(dev) >= B43_STAT_INITIALIZED))) {
- if (0 /*FIXME dev->dev->bus->bustype == SSB_BUSTYPE_SDIO*/) {
+ if (dev->dev->bus->bustype == SSB_BUSTYPE_SDIO) {
/* wl->mutex is enough. */
b43_do_beacon_update_trigger_work(dev);
mmiowb();
@@ -1905,6 +1910,27 @@ static irqreturn_t b43_interrupt_handler
return ret;
}
+/* SDIO interrupt handler. This runs in process context. */
+static void b43_sdio_interrupt_handler(struct b43_wldev *dev)
+{
+ struct b43_wl *wl = dev->wl;
+ struct sdio_func *func = dev->dev->bus->host_sdio;
+ irqreturn_t ret;
+
+ if (unlikely(b43_status(dev) < B43_STAT_STARTED))
+ return;
+
+ mutex_lock(&wl->mutex);
+ sdio_release_host(func);
+
+ ret = b43_do_interrupt(dev);
+ if (ret == IRQ_WAKE_THREAD)
+ b43_do_interrupt_thread(dev);
+
+ sdio_claim_host(func);
+ mutex_unlock(&wl->mutex);
+}
+
void b43_do_release_fw(struct b43_firmware_file *fw)
{
release_firmware(fw->data);
@@ -3828,7 +3854,7 @@ redo:
/* Disable interrupts on the device. */
b43_set_status(dev, B43_STAT_INITIALIZED);
- if (0 /*FIXME dev->dev->bus->bustype == SSB_BUSTYPE_SDIO*/) {
+ if (dev->dev->bus->bustype == SSB_BUSTYPE_SDIO) {
/* wl->mutex is locked. That is enough. */
b43_write32(dev, B43_MMIO_GEN_IRQ_MASK, 0);
b43_read32(dev, B43_MMIO_GEN_IRQ_MASK); /* Flush */
@@ -3858,7 +3884,10 @@ redo:
dev_kfree_skb(skb_dequeue(&wl->tx_queue));
b43_mac_suspend(dev);
- free_irq(dev->dev->irq, dev);
+ if (dev->dev->bus->bustype == SSB_BUSTYPE_SDIO)
+ b43_sdio_free_irq(dev);
+ else
+ free_irq(dev->dev->irq, dev);
b43_leds_exit(dev);
b43dbg(wl, "Wireless interface stopped\n");
@@ -3873,12 +3902,20 @@ static int b43_wireless_core_start(struc
B43_WARN_ON(b43_status(dev) != B43_STAT_INITIALIZED);
drain_txstatus_queue(dev);
- err = request_threaded_irq(dev->dev->irq, b43_interrupt_handler,
- b43_interrupt_thread_handler,
- IRQF_SHARED, KBUILD_MODNAME, dev);
- if (err) {
- b43err(dev->wl, "Cannot request IRQ-%d\n", dev->dev->irq);
- goto out;
+ if (dev->dev->bus->bustype == SSB_BUSTYPE_SDIO) {
+ err = b43_sdio_request_irq(dev, b43_sdio_interrupt_handler);
+ if (err) {
+ b43err(dev->wl, "Cannot request SDIO IRQ\n");
+ goto out;
+ }
+ } else {
+ err = request_threaded_irq(dev->dev->irq, b43_interrupt_handler,
+ b43_interrupt_thread_handler,
+ IRQF_SHARED, KBUILD_MODNAME, dev);
+ if (err) {
+ b43err(dev->wl, "Cannot request IRQ-%d\n", dev->dev->irq);
+ goto out;
+ }
}
/* We are ready to run. */
@@ -4270,7 +4307,9 @@ static int b43_wireless_core_init(struct
/* Maximum Contention Window */
b43_shm_write16(dev, B43_SHM_SCRATCH, B43_SHM_SC_MAXCONT, 0x3FF);
- if ((dev->dev->bus->bustype == SSB_BUSTYPE_PCMCIA) || B43_FORCE_PIO) {
+ if ((dev->dev->bus->bustype == SSB_BUSTYPE_PCMCIA) ||
+ (dev->dev->bus->bustype == SSB_BUSTYPE_SDIO) ||
+ B43_FORCE_PIO) {
dev->__using_pio_transfers = 1;
err = b43_pio_init(dev);
} else {
@@ -4944,7 +4983,7 @@ static struct ssb_driver b43_ssb_driver
static void b43_print_driverinfo(void)
{
const char *feat_pci = "", *feat_pcmcia = "", *feat_nphy = "",
- *feat_leds = "";
+ *feat_leds = "", *feat_sdio = "";
#ifdef CONFIG_B43_PCI_AUTOSELECT
feat_pci = "P";
@@ -4958,11 +4997,14 @@ static void b43_print_driverinfo(void)
#ifdef CONFIG_B43_LEDS
feat_leds = "L";
#endif
+#ifdef CONFIG_B43_SDIO
+ feat_sdio = "S";
+#endif
printk(KERN_INFO "Broadcom 43xx driver loaded "
- "[ Features: %s%s%s%s, Firmware-ID: "
+ "[ Features: %s%s%s%s%s, Firmware-ID: "
B43_SUPPORTED_FIRMWARE_ID " ]\n",
feat_pci, feat_pcmcia, feat_nphy,
- feat_leds);
+ feat_leds, feat_sdio);
}
static int __init b43_init(void)
@@ -4973,13 +5015,18 @@ static int __init b43_init(void)
err = b43_pcmcia_init();
if (err)
goto err_dfs_exit;
- err = ssb_driver_register(&b43_ssb_driver);
+ err = b43_sdio_init();
if (err)
goto err_pcmcia_exit;
+ err = ssb_driver_register(&b43_ssb_driver);
+ if (err)
+ goto err_sdio_exit;
b43_print_driverinfo();
return err;
+err_sdio_exit:
+ b43_sdio_exit();
err_pcmcia_exit:
b43_pcmcia_exit();
err_dfs_exit:
@@ -4990,6 +5037,7 @@ err_dfs_exit:
static void __exit b43_exit(void)
{
ssb_driver_unregister(&b43_ssb_driver);
+ b43_sdio_exit();
b43_pcmcia_exit();
b43_debugfs_exit();
}
Index: wireless-testing/drivers/net/wireless/b43/sdio.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ wireless-testing/drivers/net/wireless/b43/sdio.c 2009-09-10 19:23:20.000000000 +0200
@@ -0,0 +1,197 @@
+/*
+ * Broadcom B43 wireless driver
+ *
+ * SDIO over Sonics Silicon Backplane bus glue for b43.
+ *
+ * Copyright (C) 2009 Albert Herranz
+ * Copyright (C) 2009 Michael Buesch <mb@bu3sch.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/mmc/card.h>
+#include <linux/mmc/sdio_func.h>
+#include <linux/mmc/sdio_ids.h>
+#include <linux/ssb/ssb.h>
+
+#include "sdio.h"
+#include "b43.h"
+
+
+#define HNBU_CHIPID 0x01 /* vendor & device id */
+
+#define B43_SDIO_BLOCK_SIZE 64 /* rx fifo max size in bytes */
+
+
+static const struct b43_sdio_quirk {
+ u16 vendor;
+ u16 device;
+ unsigned int quirks;
+} b43_sdio_quirks[] = {
+ { 0x14E4, 0x4318, SSB_QUIRK_SDIO_READ_AFTER_WRITE32, },
+ { },
+};
+
+
+static unsigned int b43_sdio_get_quirks(u16 vendor, u16 device)
+{
+ const struct b43_sdio_quirk *q;
+
+ for (q = b43_sdio_quirks; q->quirks; q++) {
+ if (vendor == q->vendor && device == q->device)
+ return q->quirks;
+ }
+
+ return 0;
+}
+
+static void b43_sdio_interrupt_dispatcher(struct sdio_func *func)
+{
+ struct b43_sdio *sdio = sdio_get_drvdata(func);
+ struct b43_wldev *dev = sdio->irq_handler_opaque;
+
+ sdio->irq_handler(dev);
+}
+
+int b43_sdio_request_irq(struct b43_wldev *dev,
+ void (*handler)(struct b43_wldev *dev))
+{
+ struct ssb_bus *bus = dev->dev->bus;
+ struct sdio_func *func = bus->host_sdio;
+ struct b43_sdio *sdio = sdio_get_drvdata(func);
+ int err;
+
+ sdio->irq_handler_opaque = dev;
+ sdio->irq_handler = handler;
+ sdio_claim_host(func);
+ err = sdio_claim_irq(func, b43_sdio_interrupt_dispatcher);
+ sdio_release_host(func);
+
+ return err;
+}
+
+void b43_sdio_free_irq(struct b43_wldev *dev)
+{
+ struct ssb_bus *bus = dev->dev->bus;
+ struct sdio_func *func = bus->host_sdio;
+ struct b43_sdio *sdio = sdio_get_drvdata(func);
+
+ sdio_claim_host(func);
+ sdio_release_irq(func);
+ sdio_release_host(func);
+ sdio->irq_handler_opaque = NULL;
+ sdio->irq_handler = NULL;
+}
+
+static int b43_sdio_probe(struct sdio_func *func,
+ const struct sdio_device_id *id)
+{
+ struct b43_sdio *sdio;
+ struct sdio_func_tuple *tuple;
+ u16 vendor = 0, device = 0;
+ int error;
+
+ /* Look for the card chip identifier. */
+ tuple = func->tuples;
+ while (tuple) {
+ switch (tuple->code) {
+ case 0x80:
+ switch (tuple->data[0]) {
+ case HNBU_CHIPID:
+ if (tuple->size != 5)
+ break;
+ vendor = tuple->data[1] | (tuple->data[2]<<8);
+ device = tuple->data[3] | (tuple->data[4]<<8);
+ dev_info(&func->dev, "Chip ID %04x:%04x\n",
+ vendor, device);
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+ tuple = tuple->next;
+ }
+ if (!vendor || !device) {
+ error = -ENODEV;
+ goto out;
+ }
+
+ sdio_claim_host(func);
+ error = sdio_set_block_size(func, B43_SDIO_BLOCK_SIZE);
+ if (error) {
+ dev_err(&func->dev, "failed to set block size to %u bytes,"
+ " error %d\n", B43_SDIO_BLOCK_SIZE, error);
+ goto err_release_host;
+ }
+ error = sdio_enable_func(func);
+ if (error) {
+ dev_err(&func->dev, "failed to enable func, error %d\n", error);
+ goto err_release_host;
+ }
+ sdio_release_host(func);
+
+ sdio = kzalloc(sizeof(*sdio), GFP_KERNEL);
+ if (!sdio) {
+ error = -ENOMEM;
+ dev_err(&func->dev, "failed to allocate ssb bus\n");
+ goto err_disable_func;
+ }
+ error = ssb_bus_sdiobus_register(&sdio->ssb, func,
+ b43_sdio_get_quirks(vendor, device));
+ if (error) {
+ dev_err(&func->dev, "failed to register ssb sdio bus,"
+ " error %d\n", error);
+ goto err_free_ssb;
+ }
+ sdio_set_drvdata(func, sdio);
+
+ return 0;
+
+err_free_ssb:
+ kfree(sdio);
+err_disable_func:
+ sdio_disable_func(func);
+err_release_host:
+ sdio_release_host(func);
+out:
+ return error;
+}
+
+static void b43_sdio_remove(struct sdio_func *func)
+{
+ struct b43_sdio *sdio = sdio_get_drvdata(func);
+
+ ssb_bus_unregister(&sdio->ssb);
+ sdio_disable_func(func);
+ kfree(sdio);
+ sdio_set_drvdata(func, NULL);
+}
+
+static const struct sdio_device_id b43_sdio_ids[] = {
+ { SDIO_DEVICE(0x02d0, 0x044b) }, /* Nintendo Wii WLAN daughter card */
+ { },
+};
+
+static struct sdio_driver b43_sdio_driver = {
+ .name = "b43-sdio",
+ .id_table = b43_sdio_ids,
+ .probe = b43_sdio_probe,
+ .remove = b43_sdio_remove,
+};
+
+int b43_sdio_init(void)
+{
+ return sdio_register_driver(&b43_sdio_driver);
+}
+
+void b43_sdio_exit(void)
+{
+ sdio_unregister_driver(&b43_sdio_driver);
+}
Index: wireless-testing/drivers/net/wireless/b43/sdio.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ wireless-testing/drivers/net/wireless/b43/sdio.h 2009-09-10 19:23:20.000000000 +0200
@@ -0,0 +1,45 @@
+#ifndef B43_SDIO_H_
+#define B43_SDIO_H_
+
+#include <linux/ssb/ssb.h>
+
+struct b43_wldev;
+
+
+#ifdef CONFIG_B43_SDIO
+
+struct b43_sdio {
+ struct ssb_bus ssb;
+ void *irq_handler_opaque;
+ void (*irq_handler)(struct b43_wldev *dev);
+};
+
+int b43_sdio_request_irq(struct b43_wldev *dev,
+ void (*handler)(struct b43_wldev *dev));
+void b43_sdio_free_irq(struct b43_wldev *dev);
+
+int b43_sdio_init(void);
+void b43_sdio_exit(void);
+
+
+#else /* CONFIG_B43_SDIO */
+
+
+int b43_sdio_request_irq(struct b43_wldev *dev,
+ void (*handler)(struct b43_wldev *dev))
+{
+ return -ENODEV;
+}
+void b43_sdio_free_irq(struct b43_wldev *dev)
+{
+}
+static inline int b43_sdio_init(void)
+{
+ return 0;
+}
+static inline void b43_sdio_exit(void)
+{
+}
+
+#endif /* CONFIG_B43_SDIO */
+#endif /* B43_SDIO_H_ */
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL
From: Matthew Garrett @ 2009-09-10 17:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-input, linux-wireless, marcel
In-Reply-To: <43e72e890909101027saf1ed35u23936729eccf3f92@mail.gmail.com>
On Thu, Sep 10, 2009 at 10:27:01AM -0700, Luis R. Rodriguez wrote:
> On Thu, Sep 10, 2009 at 10:21 AM, Matthew Garrett <mjg@redhat.com> wrote:
>
> > This patch adds a new keycode, KEY_RFKILL_ALL.
>
> > include/linux/input.h | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
>
> > +#define KEY_RFKILL 0x20c /* Key that controls all radios */
>
> But this above is KEY_RFKILL, not KEY_RKILL_ALL. Typo?
Sorry, yes - forgot to update the commit message to match the change in
the patch and subject.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL
From: Luis R. Rodriguez @ 2009-09-10 17:27 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-input, linux-wireless, marcel
In-Reply-To: <1252603292-20830-1-git-send-email-mjg@redhat.com>
On Thu, Sep 10, 2009 at 10:21 AM, Matthew Garrett <mjg@redhat.com> wrote:
> This patch adds a new keycode, KEY_RFKILL_ALL.
> include/linux/input.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
> +#define KEY_RFKILL 0x20c /* Key that controls all radios */
But this above is KEY_RFKILL, not KEY_RKILL_ALL. Typo?
Luis
^ permalink raw reply
* [PATCH 1/2] input: Add KEY_RFKILL
From: Matthew Garrett @ 2009-09-10 17:21 UTC (permalink / raw)
To: linux-input; +Cc: linux-wireless, marcel, Matthew Garrett
Most laptops have keys that are intended to toggle all device state, not
just wifi. These are currently generally mapped to KEY_WLAN. As a result,
rfkill will only kill or enable wifi in response to the key press. This
confuses users and can make it difficult for them to enable bluetooth
and wwan devices.
This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
system should toggle the state of all rfkillable devices.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
include/linux/input.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index 8b3bc3e..20a622e 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -595,6 +595,8 @@ struct input_absinfo {
#define KEY_NUMERIC_STAR 0x20a
#define KEY_NUMERIC_POUND 0x20b
+#define KEY_RFKILL 0x20c /* Key that controls all radios */
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
#define KEY_MAX 0x2ff
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/2] rfkill: Add support for KEY_RFKILL
From: Matthew Garrett @ 2009-09-10 17:21 UTC (permalink / raw)
To: linux-input; +Cc: linux-wireless, marcel, Matthew Garrett
In-Reply-To: <1252603292-20830-1-git-send-email-mjg@redhat.com>
Add support for handling KEY_RFKILL in the rfkill input module. This
simply toggles the state of all rfkill devices. The comment in rfkill.h
is also updated to reflect that RFKILL_TYPE_ALL may be used inside the
kernel.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
include/linux/rfkill.h | 2 +-
net/rfkill/input.c | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index 278777f..4c39f7e 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -32,7 +32,7 @@
/**
* enum rfkill_type - type of rfkill switch.
*
- * @RFKILL_TYPE_ALL: toggles all switches (userspace only)
+ * @RFKILL_TYPE_ALL: toggles all switches (requests only - not a switch type)
* @RFKILL_TYPE_WLAN: switch is on a 802.11 wireless network device.
* @RFKILL_TYPE_BLUETOOTH: switch is on a bluetooth device.
* @RFKILL_TYPE_UWB: switch is on a ultra wideband device.
diff --git a/net/rfkill/input.c b/net/rfkill/input.c
index a7295ad..3713d7e 100644
--- a/net/rfkill/input.c
+++ b/net/rfkill/input.c
@@ -212,6 +212,9 @@ static void rfkill_event(struct input_handle *handle, unsigned int type,
case KEY_WIMAX:
rfkill_schedule_toggle(RFKILL_TYPE_WIMAX);
break;
+ case KEY_RFKILL:
+ rfkill_schedule_toggle(RFKILL_TYPE_ALL);
+ break;
}
} else if (type == EV_SW && code == SW_RFKILL_ALL)
rfkill_schedule_evsw_rfkillall(data);
@@ -295,6 +298,11 @@ static const struct input_device_id rfkill_ids[] = {
.keybit = { [BIT_WORD(KEY_WIMAX)] = BIT_MASK(KEY_WIMAX) },
},
{
+ .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
+ .evbit = { BIT_MASK(EV_KEY) },
+ .keybit = { [BIT_WORD(KEY_RFKILL)] = BIT_MASK(KEY_RFKILL) },
+ },
+ {
.flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_SWBIT,
.evbit = { BIT(EV_SW) },
.swbit = { [BIT_WORD(SW_RFKILL_ALL)] = BIT_MASK(SW_RFKILL_ALL) },
--
1.6.2.5
^ permalink raw reply related
* Re: anything
From: Gabor Juhos @ 2009-09-10 15:58 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Jon Nettleton, linux-wireless
In-Reply-To: <43e72e890909100854i8d16de8g9501630ce5c64787@mail.gmail.com>
Luis R. Rodriguez írta:
> On Thu, Sep 10, 2009 at 8:36 AM, Jon Nettleton <jon.nettleton@gmail.com> wrote:
>> subscribe linux-wireless
>
> -EWRONG_REQUREST
-ETYPO :)
^ permalink raw reply
* Re: anything
From: Luis R. Rodriguez @ 2009-09-10 15:54 UTC (permalink / raw)
To: Jon Nettleton; +Cc: linux-wireless
In-Reply-To: <1252597007.4544.0.camel@localhost.localdomain>
On Thu, Sep 10, 2009 at 8:36 AM, Jon Nettleton <jon.nettleton@gmail.com> wrote:
> subscribe linux-wireless
-EWRONG_REQUREST
^ permalink raw reply
* anything
From: Jon Nettleton @ 2009-09-10 15:36 UTC (permalink / raw)
To: linux-wireless
subscribe linux-wireless
^ permalink raw reply
* unibomb pending patches - 2009-09-09
From: Luis R. Rodriguez @ 2009-09-10 15:16 UTC (permalink / raw)
To: linux-wireless, Sujith; +Cc: devel
Here's an all-in-one patch file for my pending 2 series of patches:
http://bombadil.infradead.org/~mcgrof/patches/ath/2009/09/all-2009-09-09.patch
Luis
^ permalink raw reply
* [PATCH] sdio: pass unknown cis tuples to sdio drivers
From: Albert Herranz @ 2009-09-10 12:56 UTC (permalink / raw)
To: akpm, linux-mmc; +Cc: bcm43xx-dev, linux-wireless, Albert Herranz
In-Reply-To: <1252587402-7382-1-git-send-email-albert_herranz@yahoo.es>
Some manufacturers provide vendor information in non-vendor specific CIS
tuples. For example, Broadcom uses an Extended Function tuple to provide
the MAC address on some of their network cards, as in the case of the
Nintendo Wii WLAN daughter card.
This patch allows passing correct tuples unknown to the SDIO core to
a matching SDIO driver instead of rejecting them and failing.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
---
v1
- fixed typo in commit message
- CC'd akpm as suggested by mb
- required by commit 4ea602e183ca20a7577ebe253323d0e5d0f9847 in net-next-2.6
drivers/mmc/core/sdio_cis.c | 46 +++++++++++++++++++++++-------------------
1 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/core/sdio_cis.c b/drivers/mmc/core/sdio_cis.c
index 963f293..87934ac 100644
--- a/drivers/mmc/core/sdio_cis.c
+++ b/drivers/mmc/core/sdio_cis.c
@@ -123,8 +123,9 @@ static int cistpl_funce_func(struct sdio_func *func,
vsn = func->card->cccr.sdio_vsn;
min_size = (vsn == SDIO_SDIO_REV_1_00) ? 28 : 42;
+ /* let the SDIO driver take care of unknown tuples */
if (size < min_size || buf[0] != 1)
- return -EINVAL;
+ return -EILSEQ;
/* TPLFE_MAX_BLK_SIZE */
func->max_blksize = buf[12] | (buf[13] << 8);
@@ -154,13 +155,7 @@ static int cistpl_funce(struct mmc_card *card, struct sdio_func *func,
else
ret = cistpl_funce_common(card, buf, size);
- if (ret) {
- printk(KERN_ERR "%s: bad CISTPL_FUNCE size %u "
- "type %u\n", mmc_hostname(card->host), size, buf[0]);
- return ret;
- }
-
- return 0;
+ return ret;
}
typedef int (tpl_parse_t)(struct mmc_card *, struct sdio_func *,
@@ -253,21 +248,12 @@ static int sdio_read_cis(struct mmc_card *card, struct sdio_func *func)
for (i = 0; i < ARRAY_SIZE(cis_tpl_list); i++)
if (cis_tpl_list[i].code == tpl_code)
break;
- if (i >= ARRAY_SIZE(cis_tpl_list)) {
- /* this tuple is unknown to the core */
- this->next = NULL;
- this->code = tpl_code;
- this->size = tpl_link;
- *prev = this;
- prev = &this->next;
- printk(KERN_DEBUG
- "%s: queuing CIS tuple 0x%02x length %u\n",
- mmc_hostname(card->host), tpl_code, tpl_link);
- } else {
+ if (i < ARRAY_SIZE(cis_tpl_list)) {
const struct cis_tpl *tpl = cis_tpl_list + i;
if (tpl_link < tpl->min_size) {
printk(KERN_ERR
- "%s: bad CIS tuple 0x%02x (length = %u, expected >= %u)\n",
+ "%s: bad CIS tuple 0x%02x"
+ " (length = %u, expected >= %u)\n",
mmc_hostname(card->host),
tpl_code, tpl_link, tpl->min_size);
ret = -EINVAL;
@@ -275,7 +261,25 @@ static int sdio_read_cis(struct mmc_card *card, struct sdio_func *func)
ret = tpl->parse(card, func,
this->data, tpl_link);
}
- kfree(this);
+ /* already successfully parsed, not needed anymore */
+ if (!ret)
+ kfree(this);
+ } else {
+ /* unknown tuple */
+ ret = -EILSEQ;
+ }
+
+ if (ret == -EILSEQ) {
+ /* this tuple is unknown to the core */
+ this->next = NULL;
+ this->code = tpl_code;
+ this->size = tpl_link;
+ *prev = this;
+ prev = &this->next;
+ pr_debug("%s: queuing CIS tuple 0x%02x length %u\n",
+ mmc_hostname(card->host), tpl_code, tpl_link);
+ /* keep on analyzing tuples */
+ ret = 0;
}
ptr += tpl_link;
--
1.6.0.4
^ permalink raw reply related
* [PATCH] sdio: recognize io card without powercycle
From: Albert Herranz @ 2009-09-10 12:56 UTC (permalink / raw)
To: akpm, linux-mmc; +Cc: bcm43xx-dev, linux-wireless, Albert Herranz
SDIO Simplified Specification V2.00 states that it is strongly recommended
that the host executes either a power reset or issues a CMD52 (I/O Reset) to
re-initialize an I/O only card or the I/O portion of a combo card.
Additionally, the CMD52 must be issued first because it cannot be issued
after a CMD0.
With this patch the Nintendo Wii SDIO-based WLAN card is detected after a
system reset, without requiring a complete system powercycle.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
---
v1
- reworded commit message
- CC'd akpm as suggested by mb
drivers/mmc/core/core.c | 1 +
drivers/mmc/core/sdio_ops.c | 36 ++++++++++++++++++++++++++++++------
drivers/mmc/core/sdio_ops.h | 1 +
3 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index d84c880..c768f70 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -890,6 +890,7 @@ void mmc_rescan(struct work_struct *work)
mmc_claim_host(host);
mmc_power_up(host);
+ sdio_go_idle(host);
mmc_go_idle(host);
mmc_send_if_cond(host, host->ocr_avail);
diff --git a/drivers/mmc/core/sdio_ops.c b/drivers/mmc/core/sdio_ops.c
index 4eb7825..14d3204 100644
--- a/drivers/mmc/core/sdio_ops.c
+++ b/drivers/mmc/core/sdio_ops.c
@@ -67,13 +67,13 @@ int mmc_send_io_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
return err;
}
-int mmc_io_rw_direct(struct mmc_card *card, int write, unsigned fn,
- unsigned addr, u8 in, u8* out)
+static int mmc_io_rw_direct_host(struct mmc_host *host, int write, unsigned fn,
+ unsigned addr, u8 in, u8 *out)
{
struct mmc_command cmd;
int err;
- BUG_ON(!card);
+ BUG_ON(!host);
BUG_ON(fn > 7);
/* sanity check */
@@ -90,11 +90,11 @@ int mmc_io_rw_direct(struct mmc_card *card, int write, unsigned fn,
cmd.arg |= in;
cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_AC;
- err = mmc_wait_for_cmd(card->host, &cmd, 0);
+ err = mmc_wait_for_cmd(host, &cmd, 0);
if (err)
return err;
- if (mmc_host_is_spi(card->host)) {
+ if (mmc_host_is_spi(host)) {
/* host driver already reported errors */
} else {
if (cmd.resp[0] & R5_ERROR)
@@ -106,7 +106,7 @@ int mmc_io_rw_direct(struct mmc_card *card, int write, unsigned fn,
}
if (out) {
- if (mmc_host_is_spi(card->host))
+ if (mmc_host_is_spi(host))
*out = (cmd.resp[0] >> 8) & 0xFF;
else
*out = cmd.resp[0] & 0xFF;
@@ -115,6 +115,13 @@ int mmc_io_rw_direct(struct mmc_card *card, int write, unsigned fn,
return 0;
}
+int mmc_io_rw_direct(struct mmc_card *card, int write, unsigned fn,
+ unsigned addr, u8 in, u8 *out)
+{
+ BUG_ON(!card);
+ return mmc_io_rw_direct_host(card->host, write, fn, addr, in, out);
+}
+
int mmc_io_rw_extended(struct mmc_card *card, int write, unsigned fn,
unsigned addr, int incr_addr, u8 *buf, unsigned blocks, unsigned blksz)
{
@@ -182,3 +189,20 @@ int mmc_io_rw_extended(struct mmc_card *card, int write, unsigned fn,
return 0;
}
+int sdio_go_idle(struct mmc_host *host)
+{
+ int ret;
+ u8 abort;
+
+ /* SDIO Simplified Specification V2.0, 4.4 Reset for SDIO */
+
+ ret = mmc_io_rw_direct_host(host, 0, 0, SDIO_CCCR_ABORT, 0, &abort);
+ if (ret)
+ abort = 0x08;
+ else
+ abort |= 0x08;
+
+ ret = mmc_io_rw_direct_host(host, 1, 0, SDIO_CCCR_ABORT, abort, NULL);
+ return ret;
+}
+
diff --git a/drivers/mmc/core/sdio_ops.h b/drivers/mmc/core/sdio_ops.h
index e2e74b0..9b546c7 100644
--- a/drivers/mmc/core/sdio_ops.h
+++ b/drivers/mmc/core/sdio_ops.h
@@ -17,6 +17,7 @@ int mmc_io_rw_direct(struct mmc_card *card, int write, unsigned fn,
unsigned addr, u8 in, u8* out);
int mmc_io_rw_extended(struct mmc_card *card, int write, unsigned fn,
unsigned addr, int incr_addr, u8 *buf, unsigned blocks, unsigned blksz);
+int sdio_go_idle(struct mmc_host *host);
#endif
--
1.6.0.4
^ permalink raw reply related
* Re: iwlagn: order 2 page allocation failures
From: Mel Gorman @ 2009-09-10 12:58 UTC (permalink / raw)
To: Pekka Enberg
Cc: Frans Pop, Larry Finger, John W. Linville, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <1252586376.4876.29.camel@penberg-laptop>
On Thu, Sep 10, 2009 at 03:39:36PM +0300, Pekka Enberg wrote:
> Hi Mel,
>
> On Thu, 2009-09-10 at 13:34 +0100, Mel Gorman wrote:
> > > That's because it's a large allocation that's passed directly to the
> > > page allocator. See kmalloc_large_node(), for example.
> >
> > Pants. Is there any chance that could be fixed so that allocation
> > failures within SLUB get consistently reported?
>
> Did you have something specific in mind? I am not sure it's worth it,
> really.
>
> The kmalloc_large() function is a static inline in
> include/linux/slub_def.h that gets inlined nicely to a get_order() +
> __get_free_pages() pair in the caller for production configs. I'm not
> sure what we should print either. There's no known "object size" or
> "buffer size" nor do we any of the variable order things or backing
> struct kmem_cache_nodes.
>
All I had in mind really was to grab the size of the buffer that was
passed into kmalloc such as here;
void *__kmalloc(size_t size, gfp_t flags)
{
struct kmem_cache *s;
void *ret;
if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, flags);
and to have consistent reporting of slub-allocation failures but if you
reckon it's not worth it, I wouldn't push strongly on it.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Pekka Enberg @ 2009-09-10 12:39 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Larry Finger, John W. Linville, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <20090910123445.GC31153@csn.ul.ie>
Hi Mel,
On Thu, 2009-09-10 at 13:34 +0100, Mel Gorman wrote:
> > That's because it's a large allocation that's passed directly to the
> > page allocator. See kmalloc_large_node(), for example.
>
> Pants. Is there any chance that could be fixed so that allocation
> failures within SLUB get consistently reported?
Did you have something specific in mind? I am not sure it's worth it,
really.
The kmalloc_large() function is a static inline in
include/linux/slub_def.h that gets inlined nicely to a get_order() +
__get_free_pages() pair in the caller for production configs. I'm not
sure what we should print either. There's no known "object size" or
"buffer size" nor do we any of the variable order things or backing
struct kmem_cache_nodes.
Pekka
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Mel Gorman @ 2009-09-10 12:34 UTC (permalink / raw)
To: Pekka Enberg
Cc: Frans Pop, Larry Finger, John W. Linville, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <1252570722.4876.23.camel@penberg-laptop>
On Thu, Sep 10, 2009 at 11:18:42AM +0300, Pekka Enberg wrote:
> On Wed, 2009-09-09 at 17:55 +0100, Mel Gorman wrote:
> > On Wed, Sep 09, 2009 at 05:59:30PM +0200, Frans Pop wrote:
> > > On Wednesday 09 September 2009, Mel Gorman wrote:
> > > > Franz, in the full dmesg was there any mention of "SLUB: Unable to
> > > > allocate memory on node"?
> > >
> > > No, nothing at all. I double checked the kernel log, but it was completely
> > > quiet in the hours before and after the messages I already posted.
> > >
> >
> > Ok, that in itself is unexpected.
> >
> > Pekka, it looks from the stack trace that the failure is from
> > __alloc_skb and I am guessing the failure path is around here
> >
> > size = SKB_DATA_ALIGN(size);
> > data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info),
> > gfp_mask, node);
> > if (!data)
> > goto nodata;
> >
> > Why would the SLUB out-of-memory message not appear? It's hardly
> > tripping up on printk_ratelimit() is it?
>
> That's because it's a large allocation that's passed directly to the
> page allocator. See kmalloc_large_node(), for example.
>
Pants. Is there any chance that could be fixed so that allocation
failures within SLUB get consistently reported?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* First Data (EAPOL) frame goes missing
From: Paresh Sawant @ 2009-09-10 12:03 UTC (permalink / raw)
To: linux-wireless
Hi,
I am running wpa_supplicant on Linux (Kernel 2.6.30.5) with iwl3945
and mac80211. I am working in WPA2 Enterprise mode.
It came to my notice that after a successful association, first EAPOL
packet sent by the access point is missing and never reached the
mac80211. The wireless sniffer shows the frame shipped from the access
point.
I have put printk to dump the inbound frames in function
"__ieee80211_rx" in net/mac80211/rx.c. I see that though the frame is
shown on wireless sniffer but the dump for the same is missing.
Thanks
- Paresh
^ permalink raw reply
* Re: [PATCH 7/7] atheros: use get_unaligned_le*() for bssid mask setting
From: Bob Copeland @ 2009-09-10 11:04 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville, linux-wireless, ath9k-devel, devel, Nick Kossifidis,
Christian Lamparter
In-Reply-To: <1252566619-30390-8-git-send-email-lrodriguez@atheros.com>
On Thu, Sep 10, 2009 at 3:10 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> - /* MAC may be NULL if it's a broadcast key. In this case no need to
> - * to compute AR5K_LOW_ID and AR5K_HIGH_ID as we already know it. */
> + /*
> + * MAC may be NULL if it's a broadcast key. In this case no need to
> + * to compute get_unaligned_le32 and get_unaligned_le16 as we
> + * already know it.
> + */
Maybe not this one... but otherwise ACK :)
--
Bob Copeland %% www.bobcopeland.com
^ 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