* [PATCH 03/13] iwlwifi: remove un-supported eeprom parameters
From: Reinette Chatre @ 2009-09-11 17:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy, Reinette Chatre
In-Reply-To: <1252690699-25796-1-git-send-email-reinette.chatre@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Remove few of the parameters not used and no longer valid in EEPROM.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index 6b68db7..90e2b4e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -370,12 +370,10 @@ struct iwl_eeprom_calib_info {
#define EEPROM_BOARD_PBA_NUMBER (2*0x3B+1) /* 9 bytes */
#define EEPROM_VERSION (2*0x44) /* 2 bytes */
#define EEPROM_SKU_CAP (2*0x45) /* 1 bytes */
-#define EEPROM_LEDS_MODE (2*0x45+1) /* 1 bytes */
#define EEPROM_OEM_MODE (2*0x46) /* 2 bytes */
#define EEPROM_WOWLAN_MODE (2*0x47) /* 2 bytes */
#define EEPROM_RADIO_CONFIG (2*0x48) /* 2 bytes */
#define EEPROM_3945_M_VERSION (2*0x4A) /* 1 bytes */
-#define EEPROM_ANTENNA_SWITCH_TYPE (2*0x4A+1) /* 1 bytes */
/* The following masks are to be applied on EEPROM_RADIO_CONFIG */
#define EEPROM_RF_CFG_TYPE_MSK(x) (x & 0x3) /* bits 0-1 */
--
1.5.6.3
^ permalink raw reply related
* [PATCH 04/13] iwlwifi: separate nic_config for different NIC
From: Reinette Chatre @ 2009-09-11 17:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy, Reinette Chatre
In-Reply-To: <1252690699-25796-1-git-send-email-reinette.chatre@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Different NIC has different requirements for configuration. Currently all
5000 series hardware and later share the same configuration function even
though they do not need the same configurations. Fix this by separating the
needed configuration actions for each hardware model.
.5000 series: L1-ASPM H/W bug work-around
configure radio
write CSR_HW_IF_CONFIG_REG for uCode use
work-around for NIC get stuck after early PCIe power off
.1000 series: write CSR_HW_IF_CONFIG_REG for uCode use
setting digital SVR for 1000 card to 1.32V
.6000 series: configure radio
write CSR_HW_IF_CONFIG_REG for uCode use
write CSR_GP_DRIVER_REG to indicate radio sku
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-1000.c | 5 ++++-
drivers/net/wireless/iwlwifi/iwl-5000.c | 4 ++--
drivers/net/wireless/iwlwifi/iwl-6000.c | 16 +++++++++++++++-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 7 ++++++-
4 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index a95caa0..b6d2abe 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -76,7 +76,10 @@ static void iwl1000_set_ct_threshold(struct iwl_priv *priv)
/* NIC configuration for 1000 series */
static void iwl1000_nic_config(struct iwl_priv *priv)
{
- iwl5000_nic_config(priv);
+ /* set CSR_HW_CONFIG_REG for uCode use */
+ iwl_set_bit(priv, CSR_HW_IF_CONFIG_REG,
+ CSR_HW_IF_CONFIG_REG_BIT_RADIO_SI |
+ CSR_HW_IF_CONFIG_REG_BIT_MAC_SI);
/* Setting digital SVR for 1000 card to 1.32V */
/* locking is acquired in iwl_set_bits_mask_prph() function */
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index 1d539e3..ea215bb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -198,7 +198,7 @@ out:
}
-/* NIC configuration for 5000 series and up */
+/* NIC configuration for 5000 series */
void iwl5000_nic_config(struct iwl_priv *priv)
{
unsigned long flags;
@@ -221,7 +221,7 @@ void iwl5000_nic_config(struct iwl_priv *priv)
radio_cfg = iwl_eeprom_query16(priv, EEPROM_RADIO_CONFIG);
/* write radio config values to register */
- if (EEPROM_RF_CFG_TYPE_MSK(radio_cfg) < EEPROM_5000_RF_CFG_TYPE_MAX)
+ if (EEPROM_RF_CFG_TYPE_MSK(radio_cfg) < EEPROM_RF_CONFIG_TYPE_MAX)
iwl_set_bit(priv, CSR_HW_IF_CONFIG_REG,
EEPROM_RF_CFG_TYPE_MSK(radio_cfg) |
EEPROM_RF_CFG_STEP_MSK(radio_cfg) |
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index 82b9c93..36655c2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -71,7 +71,21 @@ static void iwl6000_set_ct_threshold(struct iwl_priv *priv)
/* NIC configuration for 6000 series */
static void iwl6000_nic_config(struct iwl_priv *priv)
{
- iwl5000_nic_config(priv);
+ u16 radio_cfg;
+
+ radio_cfg = iwl_eeprom_query16(priv, EEPROM_RADIO_CONFIG);
+
+ /* write radio config values to register */
+ if (EEPROM_RF_CFG_TYPE_MSK(radio_cfg) <= EEPROM_RF_CONFIG_TYPE_MAX)
+ iwl_set_bit(priv, CSR_HW_IF_CONFIG_REG,
+ EEPROM_RF_CFG_TYPE_MSK(radio_cfg) |
+ EEPROM_RF_CFG_STEP_MSK(radio_cfg) |
+ EEPROM_RF_CFG_DASH_MSK(radio_cfg));
+
+ /* set CSR_HW_CONFIG_REG for uCode use */
+ iwl_set_bit(priv, CSR_HW_IF_CONFIG_REG,
+ CSR_HW_IF_CONFIG_REG_BIT_RADIO_SI |
+ CSR_HW_IF_CONFIG_REG_BIT_MAC_SI);
/* no locking required for register write */
if (priv->cfg->pa_type == IWL_PA_HYBRID) {
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom.h b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
index 90e2b4e..61794eb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -385,7 +385,12 @@ struct iwl_eeprom_calib_info {
#define EEPROM_3945_RF_CFG_TYPE_MAX 0x0
#define EEPROM_4965_RF_CFG_TYPE_MAX 0x1
-#define EEPROM_5000_RF_CFG_TYPE_MAX 0x3
+
+/* Radio Config for 5000 and up */
+#define EEPROM_RF_CONFIG_TYPE_R3x3 0x0
+#define EEPROM_RF_CONFIG_TYPE_R2x2 0x1
+#define EEPROM_RF_CONFIG_TYPE_R1x2 0x2
+#define EEPROM_RF_CONFIG_TYPE_MAX 0x3
/*
* Per-channel regulatory data.
--
1.5.6.3
^ permalink raw reply related
* [PATCH 0/13] iwlwifi driver updates 09/11/2009
From: Reinette Chatre @ 2009-09-11 17:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In this series we include a few fixes for 2.6.32. It also contains some
cleanup and preparation work for new hardware.
The fixes for 2.6.32 are:
- patch 2/13 fixes the problem where stations are not able to use HT rates
and keep using legacy rates
- patch 6/13 fixes buffer loss that occur when system is not able to
allocate an skb. This can happen more often than expected since the driver
attempts skb allocation while in tasklet and thus with GFP_ATOMIC that is
more likely to fail.
- patch 12/13 fixes the problem where we transmit on incorrect antenna
- patch 13/13 even though powersave is default disabled for iwlwifi users
are still able to enable it using iwconfig. We need to prevent this for
4965 since it cannot handle the powersave requests well.
[PATCH 01/13] iwlwifi: modify LED blink index table
[PATCH 02/13 v2.6.32 and w-t] iwlwifi: fix HT operation in 2.4 GHz band
[PATCH 03/13] iwlwifi: remove un-supported eeprom parameters
[PATCH 04/13] iwlwifi: separate nic_config for different NIC
[PATCH 05/13] iwlwifi: separate set_hw_params function for 6000 series
[PATCH 06/13 v2.6.32 and w-t] iwlwifi: fix potential rx buffer loss
[PATCH 07/13] iwlwifi: clean up ht config a little
[PATCH 08/13] iwlwifi: Adjust blink rate to compensate Clock difference
[PATCH 09/13] iwlwifi: clean up ht config naming
[PATCH 10/13] iwlwifi: show NVM version in debugfs
[PATCH 11/13] iwlwifi: clarify and clean up chain settings
[PATCH 12/13 v2.6.32 and w-t] iwlwifi: find the correct first antenna
[PATCH 13/13 v2.6.32 and w-t] iwlwifi: disable powersave for 4965
Thank you
Reinette
^ permalink raw reply
* [PATCH 02/13 v2.6.32 and w-t] iwlwifi: fix HT operation in 2.4 GHz band
From: Reinette Chatre @ 2009-09-11 17:38 UTC (permalink / raw)
To: linville
Cc: linux-wireless, ipw3945-devel, Daniel C Halperin, Reinette Chatre
In-Reply-To: <1252690699-25796-1-git-send-email-reinette.chatre@intel.com>
From: Daniel C Halperin <daniel.c.halperin@intel.com>
When we cleaned up the driver to properly tell mac80211 about HT rates
("iwlwifi: use iwl_hwrate_get_mac80211_idx where appropriate"), we broke
internal rate indexing in 2.4 GHz band.
Signed-off-by: Daniel C Halperin <daniel.c.halperin@intel.com>
Tested-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 40b207a..fd73153 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -883,6 +883,12 @@ static void rs_tx_status(void *priv_r, struct ieee80211_supported_band *sband,
mac_index &= RATE_MCS_CODE_MSK; /* Remove # of streams */
if (mac_index >= (IWL_RATE_9M_INDEX - IWL_FIRST_OFDM_RATE))
mac_index++;
+ /*
+ * mac80211 HT index is always zero-indexed; we need to move
+ * HT OFDM rates after CCK rates in 2.4 GHz band
+ */
+ if (priv->band == IEEE80211_BAND_2GHZ)
+ mac_index += IWL_FIRST_OFDM_RATE;
}
if ((mac_index < 0) ||
--
1.5.6.3
^ permalink raw reply related
* [PATCH 01/13] iwlwifi: modify LED blink index table
From: Reinette Chatre @ 2009-09-11 17:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy, Reinette Chatre
In-Reply-To: <1252690699-25796-1-git-send-email-reinette.chatre@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Modify LED blink index table to include 1Mbps.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-led.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-led.c b/drivers/net/wireless/iwlwifi/iwl-led.c
index f420c99..41addd1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-led.c
+++ b/drivers/net/wireless/iwlwifi/iwl-led.c
@@ -65,9 +65,9 @@ static const struct {
{70, 65, 65},
{50, 75, 75},
{20, 85, 85},
- {15, 95, 95 },
- {10, 110, 110},
- {5, 130, 130},
+ {10, 95, 95},
+ {5, 110, 110},
+ {1, 130, 130},
{0, 167, 167},
/* SOLID_ON */
{-1, IWL_LED_SOLID, 0}
--
1.5.6.3
^ permalink raw reply related
* [PATCH] b43: Fix resume failure
From: Michael Buesch @ 2009-09-11 16:31 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless
This fixes a resume failure where a signal is pending on resume
so the firmware upload fails.
This removes the interruptible sleep, because we don't really need it.
In the worst case (with broken firmware) the sleep loop will take 1 second.
In the common case (working firmware), it will only take a few milliseconds.
So we don't really need to be interruptible.
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-11 18:24:59.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-09-11 18:25:13.000000000 +0200
@@ -2309,11 +2309,7 @@ static int b43_upload_microcode(struct b
err = -ENODEV;
goto error;
}
- msleep_interruptible(50);
- if (signal_pending(current)) {
- err = -EINTR;
- goto error;
- }
+ msleep(50);
}
b43_read32(dev, B43_MMIO_GEN_IRQ_REASON); /* dummy read */
--
Greetings, Michael.
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: reinette chatre @ 2009-09-11 16:14 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: <20090911084542.GA32497@csn.ul.ie>
On Fri, 2009-09-11 at 01:45 -0700, Mel Gorman wrote:
> Otherwise, it looks just the finest and I think it will address the
> problem to some extent - in that it won't print alarming messages when
> they are not needed.
>
> The additional changes with respect to GFP_ATOMIC are optional. Whether
> you do it or not.
>
> Acked-by: Mel Gorman <mel@csn.ul.ie>
Thank you very much. I'll make the changes you suggested.
Reinette
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-09-11 16:13 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Kalle Valo, linux-wireless, netdev, Johannes Berg,
John W. Linville
In-Reply-To: <4AAA75CB.6040803@hartkopp.net>
On Friday 11 September 2009 18:07:39 Oliver Hartkopp wrote:
> Michael Buesch wrote:
> > On Friday 11 September 2009 16:57:54 Kalle Valo wrote:
> >> Michael Buesch <mb@bu3sch.de> writes:
> >>
> >>> Hi,
> >> Hallo,
> >>
> >>> mac80211 (or some other part of the networking stack) triggers this
> >>> warning in the NOHZ code: NOHZ: local_softirq_pending 08
> >>>
> >>> 08 seems to be NET_RX_SOFTIRQ.
> >>>
> >>> It happens, because my test driver b43 handles all RX and TX-status
> >>> callbacks in process context. I guess some part of the networking
> >>> stack expects RX to be in tasklet and/or softirq context.
> >>>
> >>> We also have a report of this warning in wl1251, so it's probably not
> >>> a b43 problem.
> >> Yes, I see this with wl1251. It uses workqueues everywhere.
> >>
> >
> > This patch seems to fix it.
> >
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
> >
> > Index: wireless-testing/net/mac80211/cfg.c
> > ===================================================================
> > --- wireless-testing.orig/net/mac80211/cfg.c 2009-08-09 18:47:11.000000000 +0200
> > +++ wireless-testing/net/mac80211/cfg.c 2009-09-11 16:59:12.000000000 +0200
> > @@ -606,7 +606,7 @@ static void ieee80211_send_layer2_update
> > skb->dev = sta->sdata->dev;
> > skb->protocol = eth_type_trans(skb, sta->sdata->dev);
> > memset(skb->cb, 0, sizeof(skb->cb));
> > - netif_rx(skb);
> > + ieee80211_netif_rx(skb);
> > }
> >
> > static void sta_apply_parameters(struct ieee80211_local *local,
> > Index: wireless-testing/net/mac80211/ieee80211_i.h
> > ===================================================================
> > --- wireless-testing.orig/net/mac80211/ieee80211_i.h 2009-08-23 00:06:41.000000000 +0200
> > +++ wireless-testing/net/mac80211/ieee80211_i.h 2009-09-11 17:02:05.000000000 +0200
> > @@ -1053,6 +1053,14 @@ void ieee80211_tx_pending(unsigned long
> > int ieee80211_monitor_start_xmit(struct sk_buff *skb, struct net_device *dev);
> > int ieee80211_subif_start_xmit(struct sk_buff *skb, struct net_device *dev);
> >
> > +/* rx handling */
> > +static inline int ieee80211_netif_rx(struct sk_buff *skb)
> > +{
> > + if (in_interrupt())
> > + return netif_rx(skb);
> > + return netif_rx_ni(skb);
> > +}
> > +
>
> Hello Michael,
>
> i know this NOHZ warning from the CAN stack also - but now, i know what caused
> this warning. I fixed it in my local tree and it works. Thanks!
>
> As there are several users in the kernel do exact this test and call the
> appropriate netif_rx() function, i would suggest to create a static inline
> function:
>
> static inline int netif_rx_ti(struct sk_buff *skb)
> {
> if (in_interrupt())
> return netif_rx(skb);
> return netif_rx_ni(skb);
> }
>
> ('ti' for test in_interrupt())
>
> in include/linux/netdevice.h
>
> What do you think about that?
Yeah, I'm fine with that.
--
Greetings, Michael.
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Oliver Hartkopp @ 2009-09-11 16:07 UTC (permalink / raw)
To: Michael Buesch
Cc: Kalle Valo, linux-wireless, netdev, Johannes Berg,
John W. Linville
In-Reply-To: <200909111707.23971.mb@bu3sch.de>
Michael Buesch wrote:
> On Friday 11 September 2009 16:57:54 Kalle Valo wrote:
>> Michael Buesch <mb@bu3sch.de> writes:
>>
>>> Hi,
>> Hallo,
>>
>>> mac80211 (or some other part of the networking stack) triggers this
>>> warning in the NOHZ code: NOHZ: local_softirq_pending 08
>>>
>>> 08 seems to be NET_RX_SOFTIRQ.
>>>
>>> It happens, because my test driver b43 handles all RX and TX-status
>>> callbacks in process context. I guess some part of the networking
>>> stack expects RX to be in tasklet and/or softirq context.
>>>
>>> We also have a report of this warning in wl1251, so it's probably not
>>> a b43 problem.
>> Yes, I see this with wl1251. It uses workqueues everywhere.
>>
>
> This patch seems to fix it.
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
>
> Index: wireless-testing/net/mac80211/cfg.c
> ===================================================================
> --- wireless-testing.orig/net/mac80211/cfg.c 2009-08-09 18:47:11.000000000 +0200
> +++ wireless-testing/net/mac80211/cfg.c 2009-09-11 16:59:12.000000000 +0200
> @@ -606,7 +606,7 @@ static void ieee80211_send_layer2_update
> skb->dev = sta->sdata->dev;
> skb->protocol = eth_type_trans(skb, sta->sdata->dev);
> memset(skb->cb, 0, sizeof(skb->cb));
> - netif_rx(skb);
> + ieee80211_netif_rx(skb);
> }
>
> static void sta_apply_parameters(struct ieee80211_local *local,
> Index: wireless-testing/net/mac80211/ieee80211_i.h
> ===================================================================
> --- wireless-testing.orig/net/mac80211/ieee80211_i.h 2009-08-23 00:06:41.000000000 +0200
> +++ wireless-testing/net/mac80211/ieee80211_i.h 2009-09-11 17:02:05.000000000 +0200
> @@ -1053,6 +1053,14 @@ void ieee80211_tx_pending(unsigned long
> int ieee80211_monitor_start_xmit(struct sk_buff *skb, struct net_device *dev);
> int ieee80211_subif_start_xmit(struct sk_buff *skb, struct net_device *dev);
>
> +/* rx handling */
> +static inline int ieee80211_netif_rx(struct sk_buff *skb)
> +{
> + if (in_interrupt())
> + return netif_rx(skb);
> + return netif_rx_ni(skb);
> +}
> +
Hello Michael,
i know this NOHZ warning from the CAN stack also - but now, i know what caused
this warning. I fixed it in my local tree and it works. Thanks!
As there are several users in the kernel do exact this test and call the
appropriate netif_rx() function, i would suggest to create a static inline
function:
static inline int netif_rx_ti(struct sk_buff *skb)
{
if (in_interrupt())
return netif_rx(skb);
return netif_rx_ni(skb);
}
('ti' for test in_interrupt())
in include/linux/netdevice.h
What do you think about that?
Regards,
Oliver
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Kalle Valo @ 2009-09-11 16:07 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-wireless, netdev, Johannes Berg, John W. Linville
In-Reply-To: <200909111707.23971.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
>> > mac80211 (or some other part of the networking stack) triggers this
>> > warning in the NOHZ code: NOHZ: local_softirq_pending 08
>> >
>> > 08 seems to be NET_RX_SOFTIRQ.
>> >
>> > It happens, because my test driver b43 handles all RX and TX-status
>> > callbacks in process context. I guess some part of the networking
>> > stack expects RX to be in tasklet and/or softirq context.
>> >
>> > We also have a report of this warning in wl1251, so it's probably not
>> > a b43 problem.
>>
>> Yes, I see this with wl1251. It uses workqueues everywhere.
>>
>
> This patch seems to fix it.
Yes, it does. Thanks.
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
Tested-by: Kalle Valo <kalle.valo@nokia.com>
--
Kalle Valo
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-09-11 15:07 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, netdev, Johannes Berg, John W. Linville
In-Reply-To: <877hw534wd.fsf@litku.valot.fi>
On Friday 11 September 2009 16:57:54 Kalle Valo wrote:
> Michael Buesch <mb@bu3sch.de> writes:
>
> > Hi,
>
> Hallo,
>
> > mac80211 (or some other part of the networking stack) triggers this
> > warning in the NOHZ code: NOHZ: local_softirq_pending 08
> >
> > 08 seems to be NET_RX_SOFTIRQ.
> >
> > It happens, because my test driver b43 handles all RX and TX-status
> > callbacks in process context. I guess some part of the networking
> > stack expects RX to be in tasklet and/or softirq context.
> >
> > We also have a report of this warning in wl1251, so it's probably not
> > a b43 problem.
>
> Yes, I see this with wl1251. It uses workqueues everywhere.
>
This patch seems to fix it.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-testing/net/mac80211/cfg.c
===================================================================
--- wireless-testing.orig/net/mac80211/cfg.c 2009-08-09 18:47:11.000000000 +0200
+++ wireless-testing/net/mac80211/cfg.c 2009-09-11 16:59:12.000000000 +0200
@@ -606,7 +606,7 @@ static void ieee80211_send_layer2_update
skb->dev = sta->sdata->dev;
skb->protocol = eth_type_trans(skb, sta->sdata->dev);
memset(skb->cb, 0, sizeof(skb->cb));
- netif_rx(skb);
+ ieee80211_netif_rx(skb);
}
static void sta_apply_parameters(struct ieee80211_local *local,
Index: wireless-testing/net/mac80211/ieee80211_i.h
===================================================================
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2009-08-23 00:06:41.000000000 +0200
+++ wireless-testing/net/mac80211/ieee80211_i.h 2009-09-11 17:02:05.000000000 +0200
@@ -1053,6 +1053,14 @@ void ieee80211_tx_pending(unsigned long
int ieee80211_monitor_start_xmit(struct sk_buff *skb, struct net_device *dev);
int ieee80211_subif_start_xmit(struct sk_buff *skb, struct net_device *dev);
+/* rx handling */
+static inline int ieee80211_netif_rx(struct sk_buff *skb)
+{
+ if (in_interrupt())
+ return netif_rx(skb);
+ return netif_rx_ni(skb);
+}
+
/* HT */
void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
struct ieee80211_ht_cap *ht_cap_ie,
Index: wireless-testing/net/mac80211/main.c
===================================================================
--- wireless-testing.orig/net/mac80211/main.c 2009-08-23 00:06:41.000000000 +0200
+++ wireless-testing/net/mac80211/main.c 2009-09-11 16:59:35.000000000 +0200
@@ -591,7 +591,7 @@ void ieee80211_tx_status(struct ieee8021
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ ieee80211_netif_rx(skb2);
}
}
@@ -600,7 +600,7 @@ void ieee80211_tx_status(struct ieee8021
}
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ ieee80211_netif_rx(skb);
skb = NULL;
}
rcu_read_unlock();
Index: wireless-testing/net/mac80211/rx.c
===================================================================
--- wireless-testing.orig/net/mac80211/rx.c 2009-09-04 19:08:05.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-09-11 17:00:08.000000000 +0200
@@ -309,7 +309,7 @@ ieee80211_rx_monitor(struct ieee80211_lo
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ ieee80211_netif_rx(skb2);
}
}
@@ -320,7 +320,7 @@ ieee80211_rx_monitor(struct ieee80211_lo
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ ieee80211_netif_rx(skb);
} else
dev_kfree_skb(skb);
@@ -1349,7 +1349,7 @@ ieee80211_deliver_skb(struct ieee80211_r
/* deliver to local stack */
skb->protocol = eth_type_trans(skb, dev);
memset(skb->cb, 0, sizeof(skb->cb));
- netif_rx(skb);
+ ieee80211_netif_rx(skb);
}
}
@@ -1943,7 +1943,7 @@ static void ieee80211_rx_cooked_monitor(
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ ieee80211_netif_rx(skb2);
}
}
@@ -1954,7 +1954,7 @@ static void ieee80211_rx_cooked_monitor(
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ ieee80211_netif_rx(skb);
skb = NULL;
} else
goto out_free_skb;
--
Greetings, Michael.
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Kalle Valo @ 2009-09-11 14:57 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-wireless, netdev, Johannes Berg
In-Reply-To: <200909111648.50902.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> Hi,
Hallo,
> mac80211 (or some other part of the networking stack) triggers this
> warning in the NOHZ code: NOHZ: local_softirq_pending 08
>
> 08 seems to be NET_RX_SOFTIRQ.
>
> It happens, because my test driver b43 handles all RX and TX-status
> callbacks in process context. I guess some part of the networking
> stack expects RX to be in tasklet and/or softirq context.
>
> We also have a report of this warning in wl1251, so it's probably not
> a b43 problem.
Yes, I see this with wl1251. It uses workqueues everywhere.
--
Kalle Valo
^ permalink raw reply
* mac80211: NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-09-11 14:48 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, Kalle.Valo, Johannes Berg
Hi,
mac80211 (or some other part of the networking stack) triggers this warning
in the NOHZ code:
NOHZ: local_softirq_pending 08
08 seems to be NET_RX_SOFTIRQ.
It happens, because my test driver b43 handles all RX and TX-status callbacks in
process context. I guess some part of the networking stack expects RX to be in
tasklet and/or softirq context.
We also have a report of this warning in wl1251, so it's probably not a b43 problem.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 3/4] ath5k: define ath_common ops
From: Linus Torvalds @ 2009-09-11 14:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jiri Slaby, Nick Kossifidis, devel, ath9k-devel, linux-wireless,
Alan Cox, Jeff Garzik
In-Reply-To: <43e72e890909110023k62a512bejd712a3449cc8328d@mail.gmail.com>
On Fri, 11 Sep 2009, Luis R. Rodriguez wrote:
>
> That is the way I had it originally before submission, and I
> completely agree its reasonable to not incur additional cost at the
> expense of having two separate read/write paths, and perhaps we should
> only incur the extra cost on routines shared between
> ath9k/ath9k/ath9k_htc. But -- is there really is a measurable cost
> penalty?
There's a measurable size penalty, at least.
In fact, if you know what kind of IO op it is (ie "it's always MMIO"),
you'd be even better using "writel()" directly, in which case it turns
into just a single store on most architectures, and doesn't cause all the
register save/restore of a function call.
Linus
^ permalink raw reply
* [PATCH] ssb: Disable verbose SDIO coreswitch
From: Michael Buesch @ 2009-09-11 14:08 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless, Albert Herranz
Disable SDIO coreswitch debugging.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Index: wireless-testing/drivers/ssb/sdio.c
===================================================================
--- wireless-testing.orig/drivers/ssb/sdio.c 2009-09-08 19:29:16.000000000 +0200
+++ wireless-testing/drivers/ssb/sdio.c 2009-09-11 16:05:25.000000000 +0200
@@ -21,7 +21,7 @@
#include "ssb_private.h"
/* Define the following to 1 to enable a printk on each coreswitch. */
-#define SSB_VERBOSE_SDIOCORESWITCH_DEBUG 1
+#define SSB_VERBOSE_SDIOCORESWITCH_DEBUG 0
/* Hardware invariants CIS tuples */
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43: Fix SDIO interrupt handler deadlock
From: Michael Buesch @ 2009-09-11 14:00 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless, Albert Herranz
We need to release the SDIO host before locking the driver mutex.
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:26:43.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-09-11 15:55:19.000000000 +0200
@@ -1914,20 +1914,14 @@ static irqreturn_t b43_interrupt_handler
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);
}
Index: wireless-testing/drivers/net/wireless/b43/sdio.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/sdio.c 2009-09-10 19:23:20.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/sdio.c 2009-09-11 15:54:05.000000000 +0200
@@ -54,7 +54,12 @@ static void b43_sdio_interrupt_dispatche
struct b43_sdio *sdio = sdio_get_drvdata(func);
struct b43_wldev *dev = sdio->irq_handler_opaque;
+ if (unlikely(b43_status(dev) < B43_STAT_STARTED))
+ return;
+
+ sdio_release_host(func);
sdio->irq_handler(dev);
+ sdio_claim_host(func);
}
int b43_sdio_request_irq(struct b43_wldev *dev,
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: Add Soft-MAC SDIO device support
From: Michael Buesch @ 2009-09-11 13:44 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John W. Linville, Albert Herranz, linux-wireless,
Broadcom Wireless
In-Reply-To: <69e28c910909101423j535c9cffq5b1be1cb00877645@mail.gmail.com>
On Thursday 10 September 2009 23:23:19 Gábor Stefanik wrote:
> On Thu, Sep 10, 2009 at 7:34 PM, Michael Buesch <mb@bu3sch.de> wrote:
> > 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.
>
> Is it actually completely broken; or already testable, just incomplete?
incomplete
--
Greetings, Michael.
^ permalink raw reply
* Questions about regulatory domain & passive scanning
From: Holger Schurig @ 2009-09-11 12:27 UTC (permalink / raw)
To: linux-wireless, Luis R. Rodriguez
Hi !
I'm playing with regulatory domain using wireless-testing, iw,
crda and ath5 on Debian. Here are some observations:
1) Debian sucks here (while it's otherwise great!). No
wireless-regdb, wireless-crda packages, not even in
experimental. Maybe I need to add some Ubuntu repository
as "deb-src" to my apt sources.list, apt-get source that
stuff and recompile it manually.
2) I remove CONFIG_WIRELESS_OLD_REGULATORY. Then, after inserting
the card, I see in "iw list":
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm) (passive scanning)
* 2472 MHz [13] (20.0 dBm) (passive scanning)
* 2484 MHz [14] (20.0 dBm) (passive scanning)
I'd like to highlight the "passive scanning". Is this info
from the card EEPROM?
3) After "iw reg set DE" (for germany), it's now
2412 MHz [1] (20.0 dBm)
2417 MHz [2] (20.0 dBm)
2422 MHz [3] (20.0 dBm)
2427 MHz [4] (20.0 dBm)
2432 MHz [5] (20.0 dBm)
2437 MHz [6] (20.0 dBm)
2442 MHz [7] (20.0 dBm)
2447 MHz [8] (20.0 dBm)
2452 MHz [9] (20.0 dBm)
2457 MHz [10] (20.0 dBm)
2462 MHz [11] (20.0 dBm)
2467 MHz [12] (20.0 dBm) (passive scanning)
2472 MHz [13] (20.0 dBm) (passive scanning)
2484 MHz [14] (disabled)
Great, CRDA worked obviously: channel 14 has been disabled.
And, as I understand it, CRDA can just limit settings
further, not widening it. Therefore channels 12 and 13
are still marked as "passive scanning".
If I want to get them to "active scanning", would I need to
modify the EEPROM of the card? ath_info says "Reg. Domain:
0x60".
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 3/4] ath5k: define ath_common ops
From: Bob Copeland @ 2009-09-11 11:35 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jiri Slaby, Nick Kossifidis, devel, ath9k-devel, linux-wireless,
Alan Cox, Linus Torvalds, Jeff Garzik
In-Reply-To: <43e72e890909110023k62a512bejd712a3449cc8328d@mail.gmail.com>
On Fri, Sep 11, 2009 at 3:23 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> ath9k/ath9k/ath9k_htc. But -- is there really is a measurable cost
> penalty?
>
> This is why I asked if someone can test and give measurable
> differences over this. If there really isn't then that's not strong
> point against it.
Honestly, it probably won't matter in the grand scheme of things, but I
think if you are proposing a patch that touches every hotpath in two
drivers, then you need to do the work to say "by the way, this has benefit
X which outweighs the very small (or absent) performance regression Y,
and here are the numbers.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH v2] sdio: pass whitelisted cis funce tuples to sdio drivers
From: Albert Herranz @ 2009-09-11 9:54 UTC (permalink / raw)
To: akpm, pierre, linux-mmc; +Cc: bcm43xx-dev, linux-wireless, Albert Herranz
In-Reply-To: <1252662852-20548-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 whitelisted FUNCE 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
v2
- renamed from "sdio: pass unknown cis tuples to sdio drivers"
- added funce tuple whitelist concept
- fixed leak reported by akpm
drivers/mmc/core/sdio_cis.c | 65 ++++++++++++++++++++++++++++++++----------
1 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/core/sdio_cis.c b/drivers/mmc/core/sdio_cis.c
index 963f293..4e4fac1 100644
--- a/drivers/mmc/core/sdio_cis.c
+++ b/drivers/mmc/core/sdio_cis.c
@@ -98,6 +98,22 @@ static const unsigned char speed_val[16] =
static const unsigned int speed_unit[8] =
{ 10000, 100000, 1000000, 10000000, 0, 0, 0, 0 };
+/* FUNCE tuples with these types get passed to SDIO drivers */
+static const unsigned char funce_type_whitelist[] = {
+ 4 /* CISTPL_FUNCE_LAN_NODE_ID used in Broadcom cards */
+};
+
+static int cistpl_funce_whitelisted(unsigned char type)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(funce_type_whitelist); i++) {
+ if (funce_type_whitelist[i] == type)
+ return 1;
+ }
+ return 0;
+}
+
static int cistpl_funce_common(struct mmc_card *card,
const unsigned char *buf, unsigned size)
{
@@ -120,6 +136,10 @@ static int cistpl_funce_func(struct sdio_func *func,
unsigned vsn;
unsigned min_size;
+ /* let SDIO drivers take care of whitelisted FUNCE tuples */
+ if (cistpl_funce_whitelisted(buf[0]))
+ return -EILSEQ;
+
vsn = func->card->cccr.sdio_vsn;
min_size = (vsn == SDIO_SDIO_REV_1_00) ? 28 : 42;
@@ -154,13 +174,12 @@ static int cistpl_funce(struct mmc_card *card, struct sdio_func *func,
else
ret = cistpl_funce_common(card, buf, size);
- if (ret) {
+ if (ret && ret != -EILSEQ) {
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 +272,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 +285,30 @@ static int sdio_read_cis(struct mmc_card *card, struct sdio_func *func)
ret = tpl->parse(card, func,
this->data, tpl_link);
}
- kfree(this);
+ /*
+ * We don't need the tuple anymore if it was
+ * successfully parsed by the SDIO core or if it is
+ * not going to be parsed by SDIO drivers.
+ */
+ if (!ret || ret != -EILSEQ)
+ kfree(this);
+ } else {
+ /* unknown tuple */
+ ret = -EILSEQ;
+ }
+
+ if (ret == -EILSEQ) {
+ /* this tuple is unknown to the core or whitelisted */
+ 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);
+ /* keep on analyzing tuples */
+ ret = 0;
}
ptr += tpl_link;
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2] sdio: recognize io card without powercycle
From: Albert Herranz @ 2009-09-11 9:54 UTC (permalink / raw)
To: akpm, pierre, 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
v2
- renamed sdio_go_idle to sdio_reset as suggested by Pierre Ossman
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 2649117..dd746d9 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -868,6 +868,7 @@ void mmc_rescan(struct work_struct *work)
mmc_claim_host(host);
mmc_power_up(host);
+ sdio_reset(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..dea36d9 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_reset(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..12a4d3a 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_reset(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-11 8:47 UTC (permalink / raw)
To: reinette chatre
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: <1252617290.30150.321.camel@rc-desk>
On Thu, Sep 10, 2009 at 02:14:50PM -0700, reinette chatre wrote:
> On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote:
>
> >
> > 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.
>
> I looked more at the implementation and hardware interface but I do not
> see a way around this. We have to provide 8k buffer to device, and we
> have to make sure it is aligned.
>
That would imply an order-1 allocation instead of an order-2 though so
it would appear than we are being worse than we have to. It would appear
to be because of this +256 bytes that goes onto every buffer.
> Do you have any suggestions?
>
Nothing concrete. Finding an alternative to having the socket buffer
8192+256 to make it an order-1 allocation would be an improvement but I
don't know how that should be tackled. Lacking the hardware, I can't
experiment myself :(
--
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: Mel Gorman @ 2009-09-11 8:45 UTC (permalink / raw)
To: reinette chatre
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: <1252606547.30150.304.camel@rc-desk>
On Thu, Sep 10, 2009 at 11:15:47AM -0700, reinette chatre 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.
>
Thanks
> > > 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.
>
RX_LOW_WATERMARK sounds reasonable as if that watermark is reached, the
buffer count is pretty low. With order-2 allocations, I bet the system is
beginning to grind a bit to find contiguous pages at that point as well.
I agree that it's a greater problem if the system is unable to allocate
the pages as GFP_KERNEL - prehaps to the extent where it's worth
distinguishing between GFP_KERNEL and GFP_ATOMIC failures. If GFP_KERNEL
allocations are failure, packet loss is likely and the system may not
recover, particularly if there is no swap configured.
> >
>
> >
> > > 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;
Seems very reasonable.
> /* 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);
>
This change appears superflous. It don't change any functionality. Looks
like the style is just being made consistent with a similar code block
elsewhere.
> 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);
To get a good idea of how screwed we really are, how about?
IWL_CRIT(priv, "Failed to allocate SKB buffer with %s. Only %u free buffers remaining\n",
priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL",
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 */
Otherwise, it looks just the finest and I think it will address the
problem to some extent - in that it won't print alarming messages when
they are not needed.
The additional changes with respect to GFP_ATOMIC are optional. Whether
you do it or not.
Acked-by: Mel Gorman <mel@csn.ul.ie>
Thanks very much.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [PATCH] wireless: default CONFIG_WLAN to y
From: Luis R. Rodriguez @ 2009-09-11 8:43 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
When this was added no defaults were set and it seems
this implies n. Default this to y.
Reported-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index ad89d23..49ea9c9 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -5,6 +5,7 @@
menuconfig WLAN
bool "Wireless LAN"
depends on !S390
+ default y
---help---
This section contains all the pre 802.11 and 802.11 wireless
device drivers. For a complete list of drivers and documentation
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] sdio: pass unknown cis tuples to sdio drivers
From: Albert Herranz @ 2009-09-11 8:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mmc, bcm43xx-dev, linux-wireless
In-Reply-To: <20090911010102.4c7840b0.akpm@linux-foundation.org>
--- El vie, 11/9/09, Andrew Morton <akpm@linux-foundation.org> escribió:
> > >
> > > ret == -EINVAL
> > >
> >
> > At this point ret is not -EINVAL.
>
> Yes it is. We just did
>
> ret = -EINVAL;
>
>
> If that assignment happens, we leak `this'.
>
Hi Andrew,
I misunderstood you. I thought that you were trying to imply on your original comment that retval was _already_ -EINVAL at that point.
Now I see the issue. `this' should be freed if successfully parsed (!ret) or if invalid and not going to be passed to a SDIO driver (ret == -EINVAL).
Thanks for catching that. I'll send an updated patch.
Cheers,
Albert
^ 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