* Re: [PATCH 3/3] i2400m-sdio: select IWMC3200TOP in Kconfig
From: Tomas Winkler @ 2009-09-23 5:36 UTC (permalink / raw)
To: Marcel Holtmann
Cc: davem, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1253666644.2931.7.camel@localhost.localdomain>
On Wed, Sep 23, 2009 at 3:44 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Tomas,
>
>> i2400m-sdio requires iwmc3200top for its operation
>>
>> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>> ---
>> drivers/net/wimax/i2400m/Kconfig | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/wimax/i2400m/Kconfig b/drivers/net/wimax/i2400m/Kconfig
>> index d623b3d..7368ad5 100644
>> --- a/drivers/net/wimax/i2400m/Kconfig
>> +++ b/drivers/net/wimax/i2400m/Kconfig
>> @@ -25,6 +25,7 @@ config WIMAX_I2400M_SDIO
>> tristate "Intel Wireless WiMAX Connection 2400 over SDIO"
>> depends on WIMAX && MMC
>> select WIMAX_I2400M
>> + select IWMC3200TOP
>> help
>> Select if you have a device based on the Intel WiMAX
>> Connection 2400 over SDIO.
>
> this is not true actually. Since the WiMAX hardware in my laptop doesn't
> require the top driver.
>
SDIO?
Thanks
Tomas
^ permalink raw reply
* Re: [RFC] nl80211: introduce NL80211_ATTR_SCAN_EXPIRE
From: Johannes Berg @ 2009-09-22 18:50 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless@vger.kernel.org, John W Linville
In-Reply-To: <200909210946.19675.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Mon, 2009-09-21 at 09:46 +0200, Holger Schurig wrote:
> I hope this now makes more sense.
It does, but I disagree with the solution. IMO we should just add a
"last seen at" timestamp to each BSS so wpa_supplicant can make the
decision which ones to look at and which ones to ignore. They'll all be
used when you don't let wpa_supplicant roam, but that doesn't really
matter much.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: Johannes Berg @ 2009-09-23 6:57 UTC (permalink / raw)
To: Tomas Winkler
Cc: davem, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1253662724-16497-2-git-send-email-tomas.winkler@intel.com>
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
On Wed, 2009-09-23 at 02:38 +0300, Tomas Winkler wrote:
> +config IWMC3200TOP
> + tristate "Intel Wireless MultiCom Top Driver"
> + depends on MMC && EXPERIMENTAL
> + select FW_LOADER
> + ---help---
> + Intel Wireless MultiCom 3200 Top driver is responsible for
> + for firmware load and enabled coms enumeration
This seems like the wrong approach to me.
To me, it seems like you have a device that contains an internal bus and
allows bus enumeration. Typically, we would surface that bus in the
driver/device model and allow sub-drivers to bind to that by way of
exposing the internal bus, like e.g. drivers/ssb/.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Comparison of wpa_supplicant with -Dnl80211 and -Dwext, WEP and WPA
From: Johannes Berg @ 2009-09-23 6:59 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, hostap
In-Reply-To: <200909221118.04569.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]
On Tue, 2009-09-22 at 11:18 +0200, Holger Schurig wrote:
> wep_nl80211
> -----------
> 0.00000 0.00000: Initializing interface ...
> 0.03985 0.03985: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
Those are expected, and ok.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Comparison of wpa_supplicant with -Dnl80211 and -Dwext, WEP and WPA
From: Johannes Berg @ 2009-09-23 7:01 UTC (permalink / raw)
To: Holger Schurig; +Cc: hostap, linux-wireless
In-Reply-To: <200909221258.44921.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
On Tue, 2009-09-22 at 12:58 +0200, Holger Schurig wrote:
> > 0.00000 0.00000: Initializing interface ...
> > 0.08801 0.08801: Setting scan request: 0 sec 100000 usec
> > 0.25167 0.16365: ioctl[SIOCGIWSCAN]: Resource temporarily unavailable
>
> This is because wpa_supplicant very early - in
> wpa_driver_wext_finish_drv_init() - calls
> wpa_driver_wext_disconnect(). This in turn sets a random 32
> character long ESSID, as a desparate means to disconnect.
>
> Now that an essid is set, the calling chain in the kernel
>
> cfg80211_netdev_notifier_call(), case NETDEV_UP
> cfg80211_mgd_wext_connect()
> __cfg80211_connect()
> cfg80211_conn_scan(
>
> get's executed. This starts a scan.
>
> Later, when wpa_supplicant tries to get a scan result, it will
> only get an -EBUSY because of net/wireless/scan.c, function
> cfg80211_wext_siwscan():
>
> if (rdev->scan_req) {
> err = -EBUSY;
> goto out;
> }
>
>
>
> However, I'm wondering: if several scan commands are
> supposed to add up into the BSS list anyway (and each BSS list
> entry by default pruned after 15 seconds), why is it an error
> to access the current state of the BSS list while a scan is
> in progress?
Because the scan request contains info on how to do the scan.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: BUGLET? cfg80211: .dumpit methods called twice
From: Johannes Berg @ 2009-09-23 7:02 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200909220933.24443.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
On Tue, 2009-09-22 at 09:33 +0200, Holger Schurig wrote:
> I just noticed that all functions mentioned on .dumpit in
> net/wireless/nl80211.c are actually called twice.
>
> For example, I've added
>
> --- linux-wl.orig/net/wireless/nl80211.c 2009-09-18
> 14:44:28.000000000 +0200
> +++ linux-wl/net/wireless/nl80211.c 2009-09-18
> 14:45:41.000000000 +0200
> @@ -2919,6 +2919,8 @@ static int nl80211_trigger_scan(struct s
> enum ieee80211_band band;
> size_t ie_len;
>
> + printk("##HS %s:%d\n", __func__, __LINE__);
> +
> if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
> return -EINVAL;
>
> and when I now issue one "iw eth1 scan dump" I get two logs of
> this printk in my dmesg.
>
> AFAIK it doesn't cause any harm, but it's not that efficient and
> it might cause harm in the future if any of the .dumpit methods
> has the "right" side-effects.
Umm, that's expected since dumpit() effectively runs until it returns no
more data.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: getting "ath5k phy0: noise floor calibration timeout"
From: Holger Schurig @ 2009-09-23 7:05 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1253662161.2510.59.camel@localhost.localdomain>
> I get that all the time, and have since 2.6.27 or earlier. If it's a
> real bug, we should fix it, but if it's just an informational message,
> maybe we should silence it?
This is what I'd like to know: if it's a real but or not.
^ permalink raw reply
* Re: Comparison of wpa_supplicant with -Dnl80211 and -Dwext, WEP and WPA
From: Holger Schurig @ 2009-09-23 7:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, hostap
In-Reply-To: <1253689198.4458.24.camel@johannes.local>
> Those are expected, and ok.
Okay, then here is a patch to silence this in wpa_supplicant.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Index: wpasupplicant/src/drivers/driver_nl80211.c
===================================================================
--- wpasupplicant.orig/src/drivers/driver_nl80211.c 2009-09-22 12:28:58.000000000 +0200
+++ wpasupplicant/src/drivers/driver_nl80211.c 2009-09-22 12:30:29.000000000 +0200
@@ -1819,6 +1819,8 @@ static int nl_set_encr(int ifindex, stru
NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, ifindex);
ret = send_and_recv_msgs(drv, msg, NULL, NULL);
+ if (ret == -ENOLINK)
+ ret = 0;
if (ret == -ENOENT && alg == WPA_ALG_NONE)
ret = 0;
if (ret)
@@ -1850,7 +1852,7 @@ static int nl_set_encr(int ifindex, stru
NLA_PUT_FLAG(msg, NL80211_ATTR_KEY_DEFAULT);
ret = send_and_recv_msgs(drv, msg, NULL, NULL);
- if (ret == -ENOENT)
+ if (ret == -ENOENT || ret == -ENOLINK)
ret = 0;
if (ret)
wpa_printf(MSG_DEBUG, "nl80211: set_key default failed; "
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [RFC] nl80211: introduce NL80211_ATTR_SCAN_EXPIRE
From: Holger Schurig @ 2009-09-23 7:12 UTC (permalink / raw)
To: Dan Williams
Cc: Johannes Berg, linux-wireless@vger.kernel.org, John W Linville
In-Reply-To: <1253662172.2510.60.camel@localhost.localdomain>
On Wednesday 23 September 2009 01:29:32 Dan Williams wrote:
> So on the supplicant side, this weekend I was discussing with
> Jouni about making the supplicant *not* trigger a completely
> new scan when trying to associate if the scan list was current
> in the past 5 or 10 seconds. The issue here is that NM
> requests a scan, ...
I currently center around a setup without NM. Okay, for the
forklift terminals (they are x86-based), NM would be feasible.
But for the handheld terminals (Intel PXA based) I'm not keen
on NM. So I basically develop a simple program that monitors
signal and triggers a scan when signal level is below some
thresshold. This program happens to be linked into
wpa_supplicant, but it can also be a standalone program.
I'm relying on wpa_supplicant's feature to monitor scan-done
events and looking if there's something a better matching BSS
in the result.
But when you take wpa_supplicant, NM and whatever, then maybe the
timestamp idea from Johannes should be used. Any application
that wants to look if it should roam can quickly get the
scan results. By the timestamp of the entries it can then
see how old the entries are. Only if entries are outdated,
it can fire up a scan.
There's just one case: if there is no BSS in the scan list.
Then any app doing a "get scan results" call wouldn't know
if the last scan is ages ago or if there is really no AP
in the vincinity, doing an immediate re-scan. This can be
harmful for battery-driven devices. So maybe a timestamp
"last scan was at timestamp XXX" besides the individual
BSS timestamps would be helpful here.
This way apps can synchronize themselfes and, even if
different apps do scanning, they can say "We don't scan
more often than every N seconds".
> BTW, 10 years ago I did a forklift deployment too with pre-802.11
> Aironet equipment and Netware. Wasn't that fun to get up and running.
> This was at a paper company too, and guess what huge rolls of paper do?
> They absorb radio waves quite well. Suck. And forklifts can go *fast*.
Oh, and a wholesale company for drinks is even more demanding.
Water-based liquid has the nice property of absorbing microwaves
in the 2.4 MHz range extremely nicely, just see your next
microwave oven for a proof ...
The nice thing about this: when you have a working roaming
(and fast-enought handoff) in a warehouse/fork-lift scenary,
then your can forget about the WLAN problem in other scenarios,
because they are way less demanding. What happens to work in
the forklift case works everywhere else.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Comparison of wpa_supplicant with -Dnl80211 and -Dwext, WEP and WPA
From: Holger Schurig @ 2009-09-23 7:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: hostap, linux-wireless
In-Reply-To: <1253689291.4458.25.camel@johannes.local>
On Wednesday 23 September 2009 09:01:31 Johannes Berg wrote:
> Because the scan request contains info on how to do the scan.
I know. I sent another mail where I said the traceback
was correct, but not my conclusion: I confused
cfg80211_wext_siwscan() and cfg80211_wext_giwscan().
I thougth the return -EBUSY is in cfg80211_wext_giwscan().
That it is in cfg80211_wext_siwscan() makes perfect sense.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [RFC] nl80211: introduce NL80211_ATTR_SCAN_EXPIRE
From: Johannes Berg @ 2009-09-23 7:21 UTC (permalink / raw)
To: Holger Schurig
Cc: Dan Williams, linux-wireless@vger.kernel.org, John W Linville
In-Reply-To: <200909230912.57417.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
On Wed, 2009-09-23 at 09:12 +0200, Holger Schurig wrote:
> There's just one case: if there is no BSS in the scan list.
> Then any app doing a "get scan results" call wouldn't know
> if the last scan is ages ago or if there is really no AP
> in the vincinity, doing an immediate re-scan. This can be
> harmful for battery-driven devices. So maybe a timestamp
> "last scan was at timestamp XXX" besides the individual
> BSS timestamps would be helpful here.
>
> This way apps can synchronize themselfes and, even if
> different apps do scanning, they can say "We don't scan
> more often than every N seconds".
You can monitor nl80211 events for scan completion already, so this
isn't really an issue. In fact, adding a "last scan" thing would not be
a good idea since the scan might have been different, only contained a
subset of channels, etc.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: Tomas Winkler @ 2009-09-23 7:23 UTC (permalink / raw)
To: Johannes Berg
Cc: davem, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1253689036.4458.22.camel@johannes.local>
On Wed, Sep 23, 2009 at 9:57 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-09-23 at 02:38 +0300, Tomas Winkler wrote:
>
>> +config IWMC3200TOP
>> + tristate "Intel Wireless MultiCom Top Driver"
>> + depends on MMC && EXPERIMENTAL
>> + select FW_LOADER
>> + ---help---
>> + Intel Wireless MultiCom 3200 Top driver is responsible for
>> + for firmware load and enabled coms enumeration
>
> This seems like the wrong approach to me.
>
> To me, it seems like you have a device that contains an internal bus and
> allows bus enumeration. Typically, we would surface that bus in the
> driver/device model and allow sub-drivers to bind to that by way of
> exposing the internal bus, like e.g. drivers/ssb/.
>From HW perspective your assumption is not exactly correct. All the
devices are visible on the SDIO bus but they are not operational
(probe won't succeed) until TOP download the firmware and kicks the
devices. From SW perspective to create another bus layer is an option.
I'm not sure if it's not more complicated one.
Thanks
Tomas
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: Johannes Berg @ 2009-09-23 7:34 UTC (permalink / raw)
To: Tomas Winkler
Cc: davem, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1ba2fa240909230023v17fe2b49v4981d464dba469ed@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]
On Wed, 2009-09-23 at 10:23 +0300, Tomas Winkler wrote:
> From HW perspective your assumption is not exactly correct. All the
> devices are visible on the SDIO bus but they are not operational
> (probe won't succeed) until TOP download the firmware and kicks the
> devices. From SW perspective to create another bus layer is an option.
> I'm not sure if it's not more complicated one.
Ah, ok, so it is quite different. Not sure how sdio probing works, so I
guess I can't say much here.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC] nl80211: introduce NL80211_ATTR_SCAN_EXPIRE
From: Holger Schurig @ 2009-09-23 7:34 UTC (permalink / raw)
To: Johannes Berg
Cc: Dan Williams, linux-wireless@vger.kernel.org, John W Linville
In-Reply-To: <1253690505.4458.29.camel@johannes.local>
> You can monitor nl80211 events for scan completion already, so this
> isn't really an issue. In fact, adding a "last scan" thing would not be
> a good idea since the scan might have been different, only contained a
> subset of channels, etc.
Ah, yes.
--
http://www.holgerschurig.de
^ permalink raw reply
* [PATCH] ath9k: Fix RFKILL bugs
From: Sujith @ 2009-09-23 8:19 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
This patch fixes 2 issues in RFKILL:
* Calling wiphy_rfkill_stop_polling() in ath9k_stop
would mean that the driver cannot report HW status
when the radio is re-enabled. Move this to ath_detach().
* Calling ath_radio_{enable/disable} without checking the current
state results in ath_radio_enable() being called repeatedly
for every invocation of rfkill_poll(). This is not needed
in any case since wiphy_rfkill_set_hw_state() would call
->stop() if the radio has been disabled.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 0d6bbb8..2278dcb 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1299,11 +1299,6 @@ static void ath9k_rfkill_poll_state(struct ieee80211_hw *hw)
bool blocked = !!ath_is_rfkill_set(sc);
wiphy_rfkill_set_hw_state(hw->wiphy, blocked);
-
- if (blocked)
- ath_radio_disable(sc);
- else
- ath_radio_enable(sc);
}
static void ath_start_rfkill_poll(struct ath_softc *sc)
@@ -1337,6 +1332,7 @@ void ath_detach(struct ath_softc *sc)
dev_dbg(sc->dev, "Detach ATH hw\n");
ath_deinit_leds(sc);
+ wiphy_rfkill_stop_polling(sc->hw->wiphy);
for (i = 0; i < sc->num_sec_wiphy; i++) {
struct ath_wiphy *aphy = sc->sec_wiphy[i];
@@ -2524,8 +2520,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)
} else
sc->rx.rxlink = NULL;
- wiphy_rfkill_stop_polling(sc->hw->wiphy);
-
/* disable HAL and put h/w to sleep */
ath9k_hw_disable(ah);
ath9k_hw_configpcipowersave(ah, 1, 1);
--
1.6.4.4
^ permalink raw reply related
* [PATCH] iwlagn: fix panic in iwl{5000,4965}_rx_reply_tx
From: Stanislaw Gruszka @ 2009-09-23 8:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Reinette Chatre, John W. Linville, Stanislaw Gruszka
In some cases firmware can give us bad value of index in transmit
buffers array. This patch add sanity check for such values and return
from processing function instantly when it happens.
https://bugzilla.redhat.com/show_bug.cgi?id=521931
Patch was tested by reporter on iwl5000. I think check can be also
helpful for 4965.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlwifi/iwl-4965.c | 6 ++++++
drivers/net/wireless/iwlwifi/iwl-5000.c | 6 ++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 8f3d4bc..573818f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2019,6 +2019,12 @@ static int iwl4965_tx_status_reply_tx(struct iwl_priv *priv,
agg->frame_count, txq_id, idx);
hdr = iwl_tx_queue_get_hdr(priv, txq_id, idx);
+ if (!hdr) {
+ IWL_ERR(priv,
+ "BUG_ON idx doesn't point to valid skb"
+ " idx=%d, txq_id=%d\n", idx, txq_id);
+ return -1;
+ }
sc = le16_to_cpu(hdr->seq_ctrl);
if (idx != (SEQ_TO_SN(sc) & 0xff)) {
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index b3c648c..460f1fb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -1139,6 +1139,12 @@ static int iwl5000_tx_status_reply_tx(struct iwl_priv *priv,
agg->frame_count, txq_id, idx);
hdr = iwl_tx_queue_get_hdr(priv, txq_id, idx);
+ if (!hdr) {
+ IWL_ERR(priv,
+ "BUG_ON idx doesn't point to valid skb"
+ " idx=%d, txq_id=%d\n", idx, txq_id);
+ return -1;
+ }
sc = le16_to_cpu(hdr->seq_ctrl);
if (idx != (SEQ_TO_SN(sc) & 0xff)) {
--
1.6.2.5
^ permalink raw reply related
* [PATCH] ath9k: Initialize txgain and rxgain for newer AR9287 chipsets.
From: Vivek Natarajan @ 2009-09-23 10:57 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index f74604d..7a4de3d 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -814,7 +814,7 @@ static void ath9k_hw_init_mode_regs(struct ath_hw *ah)
static void ath9k_hw_init_mode_gain_regs(struct ath_hw *ah)
{
- if (AR_SREV_9287_11(ah))
+ if (AR_SREV_9287_11_OR_LATER(ah))
INIT_INI_ARRAY(&ah->iniModesRxGain,
ar9287Modes_rx_gain_9287_1_1,
ARRAY_SIZE(ar9287Modes_rx_gain_9287_1_1), 6);
@@ -825,7 +825,7 @@ static void ath9k_hw_init_mode_gain_regs(struct ath_hw *ah)
else if (AR_SREV_9280_20(ah))
ath9k_hw_init_rxgain_ini(ah);
- if (AR_SREV_9287_11(ah)) {
+ if (AR_SREV_9287_11_OR_LATER(ah)) {
INIT_INI_ARRAY(&ah->iniModesTxGain,
ar9287Modes_tx_gain_9287_1_1,
ARRAY_SIZE(ar9287Modes_tx_gain_9287_1_1), 6);
--
1.6.4.4
^ permalink raw reply related
* Re: Flush TX - wireless summit topic
From: Bob Copeland @ 2009-09-23 11:59 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Jouni.Malinen, Johannes Berg, linux-wireless
In-Reply-To: <43e72e890909221541u67fa291fq353327d1d55841f2@mail.gmail.com>
On Tue, Sep 22, 2009 at 03:41:50PM -0700, Luis R. Rodriguez wrote:
> flush prior to channel change? Well one theory discussed was that we
> would see that issue disappear if we actually did a proper TX flush
> prior to channel change since we expect we would not see further
> incoming frames from our AP if we told it we were going to PS (sending
> a null func frame).
Yeah, but due to the way ath5k defers frames, there's still a race
condition (queue some packets, flush TX to send out the nullfunc frame,
then RX tasklet runs on unprocessed packets). I don't think TX flush
would hurt though, then we could probably drop the driver-side code
that tries to do the same.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: Tomas Winkler @ 2009-09-23 12:29 UTC (permalink / raw)
To: Johannes Berg
Cc: davem, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky
In-Reply-To: <1253691283.4458.38.camel@johannes.local>
On Wed, Sep 23, 2009 at 10:34 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-09-23 at 10:23 +0300, Tomas Winkler wrote:
>
>> From HW perspective your assumption is not exactly correct. All the
>> devices are visible on the SDIO bus but they are not operational
>> (probe won't succeed) until TOP download the firmware and kicks the
>> devices. From SW perspective to create another bus layer is an option.
>> I'm not sure if it's not more complicated one.
>
> Ah, ok, so it is quite different. Not sure how sdio probing works, so I
> guess I can't say much here.
This is not about SDIO probing this is rather unusual HW design.
Anyhow all comments and ideas are welcome.
Thanks
Tomas
^ permalink raw reply
* pull request: wireless-next-2.6 2009-09-23
From: John W. Linville @ 2009-09-23 15:53 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Please accept this one last round of wireless bits for the merge window.
They are fixes for the most part, and the teams involved are very eager
to have these for the 2.6.32 cycle. In particular, the b43 and ath9k
teams have some late breakers -- yes, I have reminded them of the
process, but they are quite insistent...
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 4142e0d1def2c0176c27fd2e810243045a62eb6d:
Linus Torvalds (1):
Merge branch 'osync_cleanup' of git://git.kernel.org/.../jack/linux-fs-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git
Albert Herranz (2):
b43: Add Soft-MAC SDIO device support
b43: fix build error if !CONFIG_B43_LEDS
Andrew Price (1):
rt2x00: fix the definition of rt2x00crypto_rx_insert_iv
Christian Lamparter (2):
p54usb: add Zcomax XG-705A usbid
ar9170usb: add usbid for TP-Link TL-WN821N v2
Daniel C Halperin (1):
iwlwifi: fix HT operation in 2.4 GHz band
Holger Schurig (2):
cfg80211: use cfg80211_wext_freq() for freq conversion
cfg80211: minimal error handling for wext-compat freq scanning
Johannes Berg (4):
iwlwifi: disable powersave for 4965
cfg80211: fix SME connect
mac80211: fix DTIM setting
cfg80211: don't overwrite privacy setting
Julia Lawall (1):
drivers/net/wireless: Use usb_endpoint_dir_out
Larry Finger (2):
ssb: Fix error when V1 SPROM extraction is forced
b43: Implement RFKILL status for LP PHY
Luis R. Rodriguez (1):
wireless: default CONFIG_WLAN to y
Martin Decky (1):
hostap: Revert a toxic part of the conversion to net_device_ops
Michael Buesch (11):
b43: Force-wake queues on init
ssb: Disable verbose SDIO coreswitch
b43: Fix resume failure
b43: Rewrite suspend/resume code
b43: Do not use _irqsafe callbacks
b43: Fix SDIO interrupt handler deadlock
b43: Fix IRQ sync for SDIO
b43: Add optional verbose runtime statistics
b43: Disable PMQ mechanism
b43: Don't abuse wl->current_dev in the led work
b43: Remove BROKEN attribute from SDIO
Pavel Roskin (1):
rc80211_minstrel: fix contention window calculation
Randy Dunlap (2):
ssb/sdio: fix printk format warnings
wl12xx: fix kconfig/link errors
Reinette Chatre (3):
iwlwifi: fix potential rx buffer loss
iwlwifi: do not send sync command while holding spinlock
iwlwifi: reduce noise when skb allocation fails
Senthil Balasubramanian (2):
ath9k: Adjust the chainmasks properly
ath9k: Fix bug in chain handling
Stanislaw Gruszka (1):
iwlagn: fix panic in iwl{5000,4965}_rx_reply_tx
Sujith (5):
ath9k: Fix bug in ANI channel handling
ath9k: Restore TSF after RESET
ath9k: Fix chip wakeup issue
ath9k: Fix regression in PA calibration
ath9k: Fix RFKILL bugs
Thomas Ilnseher (1):
b43: Add LP PHY Analog Switch Support
Vasanthakumar Thiagarajan (3):
ath9k: Fix rx data corruption
ath9k: Don't read NF when chip has gone through full sleep mode
ath9k: Do a full reset for AR9280
Vivek Natarajan (5):
ath9k: Set default noise floor value for AR9287
ath9k: Revamp PCIE workarounds
ath9k: Fix AHB reset for AR9280
ath9k: Disable autosleep feature by default.
ath9k: Initialize txgain and rxgain for newer AR9287 chipsets.
Wey-Yi Guy (1):
iwlwifi: find the correct first antenna
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/ath/ar9170/usb.c | 2 +
drivers/net/wireless/ath/ath9k/ani.c | 6 +-
drivers/net/wireless/ath/ath9k/calib.c | 23 ++-
drivers/net/wireless/ath/ath9k/calib.h | 1 +
drivers/net/wireless/ath/ath9k/eeprom_def.c | 4 +-
drivers/net/wireless/ath/ath9k/hw.c | 202 ++++++++++++--------
drivers/net/wireless/ath/ath9k/hw.h | 4 +-
drivers/net/wireless/ath/ath9k/main.c | 16 +-
drivers/net/wireless/ath/ath9k/reg.h | 3 +-
drivers/net/wireless/b43/Kconfig | 21 ++-
drivers/net/wireless/b43/Makefile | 1 +
drivers/net/wireless/b43/b43.h | 23 +--
drivers/net/wireless/b43/debugfs.c | 1 +
drivers/net/wireless/b43/debugfs.h | 1 +
drivers/net/wireless/b43/dma.c | 4 +-
drivers/net/wireless/b43/leds.c | 266 +++++++++++++++++++--------
drivers/net/wireless/b43/leds.h | 33 +++-
drivers/net/wireless/b43/main.c | 230 +++++++++++++----------
drivers/net/wireless/b43/phy_lp.c | 12 +-
drivers/net/wireless/b43/pio.c | 2 +-
drivers/net/wireless/b43/rfkill.c | 2 +-
drivers/net/wireless/b43/sdio.c | 202 ++++++++++++++++++++
drivers/net/wireless/b43/sdio.h | 45 +++++
drivers/net/wireless/b43/xmit.c | 5 +-
drivers/net/wireless/hostap/hostap_main.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 7 +
drivers/net/wireless/iwlwifi/iwl-5000.c | 6 +
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 1 +
drivers/net/wireless/iwlwifi/iwl-power.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 34 +++-
drivers/net/wireless/iwlwifi/iwl-sta.c | 2 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 33 +++-
drivers/net/wireless/p54/p54usb.c | 1 +
drivers/net/wireless/rt2x00/rt2x00lib.h | 2 +-
drivers/net/wireless/wl12xx/Kconfig | 2 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
drivers/ssb/pci.c | 1 +
drivers/ssb/sdio.c | 6 +-
net/mac80211/rc80211_minstrel.c | 2 +-
net/mac80211/scan.c | 4 +-
net/wireless/scan.c | 7 +-
net/wireless/sme.c | 21 ++-
net/wireless/wext-sme.c | 2 +-
46 files changed, 921 insertions(+), 349 deletions(-)
create mode 100644 drivers/net/wireless/b43/sdio.c
create mode 100644 drivers/net/wireless/b43/sdio.h
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-09-23.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] b43: Always use block-I/O for the PIO data registers
From: Michael Buesch @ 2009-09-23 16:51 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless, Albert Herranz
On SDIO the PIO data register seems to be hardwired to LE. So
the MACCTL bit has no effect on the endianness.
So also use block-I/O for the last word of the packet. block-I/O is always LE.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Index: wireless-testing/drivers/net/wireless/b43/pio.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/pio.c 2009-09-10 20:14:37.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/pio.c 2009-09-10 21:08:11.000000000 +0200
@@ -340,10 +340,15 @@ static u16 tx_write_2byte_queue(struct b
q->mmio_base + B43_PIO_TXDATA,
sizeof(u16));
if (data_len & 1) {
+ u8 tail[2] = { 0, };
+
/* Write the last byte. */
ctl &= ~B43_PIO_TXCTL_WRITEHI;
b43_piotx_write16(q, B43_PIO_TXCTL, ctl);
- b43_piotx_write16(q, B43_PIO_TXDATA, data[data_len - 1]);
+ tail[0] = data[data_len - 1];
+ ssb_block_write(dev->dev, tail, 2,
+ q->mmio_base + B43_PIO_TXDATA,
+ sizeof(u16));
}
return ctl;
@@ -386,26 +391,31 @@ static u32 tx_write_4byte_queue(struct b
q->mmio_base + B43_PIO8_TXDATA,
sizeof(u32));
if (data_len & 3) {
- u32 value = 0;
+ u8 tail[4] = { 0, };
/* Write the last few bytes. */
ctl &= ~(B43_PIO8_TXCTL_8_15 | B43_PIO8_TXCTL_16_23 |
B43_PIO8_TXCTL_24_31);
- data = &(data[data_len - 1]);
switch (data_len & 3) {
case 3:
- ctl |= B43_PIO8_TXCTL_16_23;
- value |= (u32)(*data) << 16;
- data--;
+ ctl |= B43_PIO8_TXCTL_16_23 | B43_PIO8_TXCTL_8_15;
+ tail[0] = data[data_len - 3];
+ tail[1] = data[data_len - 2];
+ tail[2] = data[data_len - 1];
+ break;
case 2:
ctl |= B43_PIO8_TXCTL_8_15;
- value |= (u32)(*data) << 8;
- data--;
+ tail[0] = data[data_len - 2];
+ tail[1] = data[data_len - 1];
+ break;
case 1:
- value |= (u32)(*data);
+ tail[0] = data[data_len - 1];
+ break;
}
b43_piotx_write32(q, B43_PIO8_TXCTL, ctl);
- b43_piotx_write32(q, B43_PIO8_TXDATA, value);
+ ssb_block_write(dev->dev, tail, 4,
+ q->mmio_base + B43_PIO8_TXDATA,
+ sizeof(u32));
}
return ctl;
@@ -693,21 +703,25 @@ data_ready:
q->mmio_base + B43_PIO8_RXDATA,
sizeof(u32));
if (len & 3) {
- u32 value;
- char *data;
+ u8 tail[4] = { 0, };
/* Read the last few bytes. */
- value = b43_piorx_read32(q, B43_PIO8_RXDATA);
- data = &(skb->data[len + padding - 1]);
+ ssb_block_read(dev->dev, tail, 4,
+ q->mmio_base + B43_PIO8_RXDATA,
+ sizeof(u32));
switch (len & 3) {
case 3:
- *data = (value >> 16);
- data--;
+ skb->data[len + padding - 3] = tail[0];
+ skb->data[len + padding - 2] = tail[1];
+ skb->data[len + padding - 1] = tail[2];
+ break;
case 2:
- *data = (value >> 8);
- data--;
+ skb->data[len + padding - 2] = tail[0];
+ skb->data[len + padding - 1] = tail[1];
+ break;
case 1:
- *data = value;
+ skb->data[len + padding - 1] = tail[0];
+ break;
}
}
} else {
@@ -715,11 +729,13 @@ data_ready:
q->mmio_base + B43_PIO_RXDATA,
sizeof(u16));
if (len & 1) {
- u16 value;
+ u8 tail[2] = { 0, };
/* Read the last byte. */
- value = b43_piorx_read16(q, B43_PIO_RXDATA);
- skb->data[len + padding - 1] = value;
+ ssb_block_read(dev->dev, tail, 2,
+ q->mmio_base + B43_PIO_RXDATA,
+ sizeof(u16));
+ skb->data[len + padding - 1] = tail[0];
}
}
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: Inaky Perez-Gonzalez @ 2009-09-23 17:48 UTC (permalink / raw)
To: Tomas Winkler
Cc: Johannes Berg, davem@davemloft.net, linville@tuxdriver.com,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, Zhu, Yi, Kao, Cindy H, Cohen, Guy,
Rindjunsky, Ron
In-Reply-To: <1ba2fa240909230023v17fe2b49v4981d464dba469ed@mail.gmail.com>
On Wed, 2009-09-23 at 01:23 -0600, Tomas Winkler wrote:
> On Wed, Sep 23, 2009 at 9:57 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Wed, 2009-09-23 at 02:38 +0300, Tomas Winkler wrote:
> >
> >> +config IWMC3200TOP
> >> + tristate "Intel Wireless MultiCom Top Driver"
> >> + depends on MMC && EXPERIMENTAL
> >> + select FW_LOADER
> >> + ---help---
> >> + Intel Wireless MultiCom 3200 Top driver is responsible for
> >> + for firmware load and enabled coms enumeration
> >
> > This seems like the wrong approach to me.
> >
> > To me, it seems like you have a device that contains an internal bus and
> > allows bus enumeration. Typically, we would surface that bus in the
> > driver/device model and allow sub-drivers to bind to that by way of
> > exposing the internal bus, like e.g. drivers/ssb/.
>
> From HW perspective your assumption is not exactly correct. All the
> devices are visible on the SDIO bus but they are not operational
> (probe won't succeed) until TOP download the firmware and kicks the
> devices. From SW perspective to create another bus layer is an option.
> I'm not sure if it's not more complicated one.
It is definitely more complicated; we thought about it and it wasn't
worth. The current solution works and it is simple enough.
To extend Tomas' explanation:
1 device powers up
2 enabling any sdio function that is not the top one fails; drivers
return -ENODEV
3 top function is enabled, firmware loaded, it initializes
the rest of the functions. Top driver kicks a SDIO bus rescan
on a workqueue
4 other sdio functions can be enabled and probe succesfully (uploading
firmware, yadah yadah).
A subbus would add a lot of complexity to all this, having to replicate
most of the device probing, suspend/resume, pre/post reset (that's is
being added to SDIO).
Thanks,
^ permalink raw reply
* Re: Comparison of wpa_supplicant with -Dnl80211 and -Dwext, WEP and WPA
From: Johannes Berg @ 2009-09-23 17:51 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, hostap
In-Reply-To: <200909230907.24750.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
On Wed, 2009-09-23 at 09:07 +0200, Holger Schurig wrote:
> > Those are expected, and ok.
>
> Okay, then here is a patch to silence this in wpa_supplicant.
No, they should only be ignored under certain circumstances.
johannes
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
>
> Index: wpasupplicant/src/drivers/driver_nl80211.c
> ===================================================================
> --- wpasupplicant.orig/src/drivers/driver_nl80211.c 2009-09-22 12:28:58.000000000 +0200
> +++ wpasupplicant/src/drivers/driver_nl80211.c 2009-09-22 12:30:29.000000000 +0200
> @@ -1819,6 +1819,8 @@ static int nl_set_encr(int ifindex, stru
> NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, ifindex);
>
> ret = send_and_recv_msgs(drv, msg, NULL, NULL);
> + if (ret == -ENOLINK)
> + ret = 0;
> if (ret == -ENOENT && alg == WPA_ALG_NONE)
> ret = 0;
> if (ret)
> @@ -1850,7 +1852,7 @@ static int nl_set_encr(int ifindex, stru
> NLA_PUT_FLAG(msg, NL80211_ATTR_KEY_DEFAULT);
>
> ret = send_and_recv_msgs(drv, msg, NULL, NULL);
> - if (ret == -ENOENT)
> + if (ret == -ENOENT || ret == -ENOLINK)
> ret = 0;
> if (ret)
> wpa_printf(MSG_DEBUG, "nl80211: set_key default failed; "
>
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] [compat-2.6] fix build problems
From: Hauke Mehrtens @ 2009-09-23 18:50 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
IRQ_WAKE_THREAD is not defined in kernel < 2.6.30
in include/linux/irqreturn.h .
In 09-threaded-irq.patch the condition was wrong.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/compat-2.6.30.h | 2 ++
compat/patches/09-threaded-irq.patch | 8 ++++----
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/compat/compat-2.6.30.h b/compat/compat-2.6.30.h
index 6a7c8fb..ed31198 100644
--- a/compat/compat-2.6.30.h
+++ b/compat/compat-2.6.30.h
@@ -14,6 +14,8 @@
#define TP_ARGS(args...) TPARGS(args)
#endif
+#define IRQ_WAKE_THREAD (2)
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,30)) */
#endif /* LINUX_26_30_COMPAT_H */
diff --git a/compat/patches/09-threaded-irq.patch b/compat/patches/09-threaded-irq.patch
index e6daa15..4b9a361 100644
--- a/compat/patches/09-threaded-irq.patch
+++ b/compat/patches/09-threaded-irq.patch
@@ -25,15 +25,15 @@ thread in process context as well.
}
} else {
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
- err = request_threaded_irq(dev->dev->irq, b43_interrupt_handler,
- b43_interrupt_thread_handler,
- IRQF_SHARED, KBUILD_MODNAME, dev);
-+#else
+ err = compat_request_threaded_irq(&dev->irq_compat,
+ dev->dev->irq,
+ b43_interrupt_handler,
+ b43_interrupt_thread_handler,
+ IRQF_SHARED, KBUILD_MODNAME, dev);
++#else
+ err = request_threaded_irq(dev->dev->irq, b43_interrupt_handler,
+ b43_interrupt_thread_handler,
+ IRQF_SHARED, KBUILD_MODNAME, dev);
+#endif
if (err) {
b43err(dev->wl, "Cannot request IRQ-%d\n", dev->dev->irq);
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH] [compat-2.6] fix build problems
From: Luis R. Rodriguez @ 2009-09-23 19:25 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless
In-Reply-To: <1253731843-1045-1-git-send-email-hauke@hauke-m.de>
On Wed, Sep 23, 2009 at 11:50 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> IRQ_WAKE_THREAD is not defined in kernel < 2.6.30
> in include/linux/irqreturn.h .
>
> In 09-threaded-irq.patch the condition was wrong.
Applied, thanks.
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox