* Re: [PATCH V2] ssb: Add support for 4318E
From: Michael Buesch @ 2009-07-01 13:17 UTC (permalink / raw)
To: Larry Finger; +Cc: John W Linville, ccmcphe, bcm43xx-dev, linux-wireless
In-Reply-To: <4a4ada7f.oItwGXurq7WMW+HE%Larry.Finger@lwfinger.net>
On Wednesday 01 July 2009 05:39:43 Larry Finger wrote:
> From: Clyde McPherson <ccmcphe@verizon.net>
>
> Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
> 4318E can do 802.11A/B/G, only B and G mode are supported in b43.
>
> Signed-off-by: Clyde McPherson <ccmcphe@verizon.net>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
ack
> ---
>
> Index: wireless-testing/drivers/ssb/pcmcia.c
> ===================================================================
> --- wireless-testing.orig/drivers/ssb/pcmcia.c
> +++ wireless-testing/drivers/ssb/pcmcia.c
> @@ -678,7 +678,8 @@ int ssb_pcmcia_get_invariants(struct ssb
> sprom->board_rev = tuple.TupleData[1];
> break;
> case SSB_PCMCIA_CIS_PA:
> - GOTO_ERROR_ON(tuple.TupleDataLen != 9,
> + GOTO_ERROR_ON((tuple.TupleDataLen != 9) &&
> + (tuple.TupleDataLen != 10),
> "pa tpl size");
> sprom->pa0b0 = tuple.TupleData[1] |
> ((u16)tuple.TupleData[2] << 8);
> @@ -718,7 +719,8 @@ int ssb_pcmcia_get_invariants(struct ssb
> sprom->antenna_gain.ghz5.a3 = tuple.TupleData[1];
> break;
> case SSB_PCMCIA_CIS_BFLAGS:
> - GOTO_ERROR_ON(tuple.TupleDataLen != 3,
> + GOTO_ERROR_ON((tuple.TupleDataLen != 3) &&
> + (tuple.TupleDataLen != 5),
> "bfl tpl size");
> sprom->boardflags_lo = tuple.TupleData[1] |
> ((u16)tuple.TupleData[2] << 8);
>
>
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] rt2x00: use wiphy rfkill interface
From: Ivo van Doorn @ 2009-07-01 13:17 UTC (permalink / raw)
To: John Linville; +Cc: users, linux-wireless
Remove the input_polldev from rt2x00 and replace it with
the rfkill interface offered by the wiphy structure. This
simplifies the entire rfkill handling in rt2x00 and allows
us to remove the CONFIG_RT2X00_LIB_RFKILL option and always
enables rfkill capabilities.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/Kconfig | 8 --
drivers/net/wireless/rt2x00/Makefile | 1 -
drivers/net/wireless/rt2x00/rt2400pci.c | 7 +--
drivers/net/wireless/rt2x00/rt2500pci.c | 7 +--
drivers/net/wireless/rt2x00/rt2500usb.c | 7 +--
drivers/net/wireless/rt2x00/rt2800usb.c | 7 +--
drivers/net/wireless/rt2x00/rt2x00.h | 13 +---
drivers/net/wireless/rt2x00/rt2x00dev.c | 2 -
drivers/net/wireless/rt2x00/rt2x00lib.h | 21 +----
drivers/net/wireless/rt2x00/rt2x00mac.c | 9 ++
drivers/net/wireless/rt2x00/rt2x00rfkill.c | 127 ----------------------------
drivers/net/wireless/rt2x00/rt61pci.c | 7 +--
drivers/net/wireless/rt2x00/rt73usb.c | 7 +--
13 files changed, 20 insertions(+), 203 deletions(-)
delete mode 100644 drivers/net/wireless/rt2x00/rt2x00rfkill.c
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index b6e8fb4..96f9d61 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -142,14 +142,6 @@ config RT2X00_LIB_FIRMWARE
config RT2X00_LIB_CRYPTO
boolean
-config RT2X00_LIB_RFKILL
- boolean
- default y if (RT2X00_LIB=y && INPUT=y) || (RT2X00_LIB=m && INPUT!=n)
- select INPUT_POLLDEV
-
-comment "rt2x00 rfkill support disabled due to modularized INPUT and built-in rt2x00"
- depends on RT2X00_LIB=y && INPUT=m
-
config RT2X00_LIB_LEDS
boolean
default y if (RT2X00_LIB=y && LEDS_CLASS=y) || (RT2X00_LIB=m && LEDS_CLASS!=n)
diff --git a/drivers/net/wireless/rt2x00/Makefile b/drivers/net/wireless/rt2x00/Makefile
index 2d1be47..912f5f6 100644
--- a/drivers/net/wireless/rt2x00/Makefile
+++ b/drivers/net/wireless/rt2x00/Makefile
@@ -5,7 +5,6 @@ rt2x00lib-y += rt2x00queue.o
rt2x00lib-y += rt2x00link.o
rt2x00lib-$(CONFIG_RT2X00_LIB_DEBUGFS) += rt2x00debug.o
rt2x00lib-$(CONFIG_RT2X00_LIB_CRYPTO) += rt2x00crypto.o
-rt2x00lib-$(CONFIG_RT2X00_LIB_RFKILL) += rt2x00rfkill.o
rt2x00lib-$(CONFIG_RT2X00_LIB_FIRMWARE) += rt2x00firmware.o
rt2x00lib-$(CONFIG_RT2X00_LIB_LEDS) += rt2x00leds.o
rt2x00lib-$(CONFIG_RT2X00_LIB_HT) += rt2x00ht.o
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index 435f945..d8035e3 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -199,7 +199,6 @@ static const struct rt2x00debug rt2400pci_rt2x00debug = {
};
#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
-#ifdef CONFIG_RT2X00_LIB_RFKILL
static int rt2400pci_rfkill_poll(struct rt2x00_dev *rt2x00dev)
{
u32 reg;
@@ -207,9 +206,6 @@ static int rt2400pci_rfkill_poll(struct rt2x00_dev *rt2x00dev)
rt2x00pci_register_read(rt2x00dev, GPIOCSR, ®);
return rt2x00_get_field32(reg, GPIOCSR_BIT0);
}
-#else
-#define rt2400pci_rfkill_poll NULL
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
#ifdef CONFIG_RT2X00_LIB_LEDS
static void rt2400pci_brightness_set(struct led_classdev *led_cdev,
@@ -1391,10 +1387,8 @@ static int rt2400pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
/*
* Detect if this device has an hardware controlled radio.
*/
-#ifdef CONFIG_RT2X00_LIB_RFKILL
if (rt2x00_get_field16(eeprom, EEPROM_ANTENNA_HARDWARE_RADIO))
__set_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags);
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
/*
* Check if the BBP tuning should be enabled.
@@ -1573,6 +1567,7 @@ static const struct ieee80211_ops rt2400pci_mac80211_ops = {
.get_tx_stats = rt2x00mac_get_tx_stats,
.get_tsf = rt2400pci_get_tsf,
.tx_last_beacon = rt2400pci_tx_last_beacon,
+ .rfkill_poll = rt2x00mac_rfkill_poll,
};
static const struct rt2x00lib_ops rt2400pci_rt2x00_ops = {
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 08b30d0..c123e28 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -199,7 +199,6 @@ static const struct rt2x00debug rt2500pci_rt2x00debug = {
};
#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
-#ifdef CONFIG_RT2X00_LIB_RFKILL
static int rt2500pci_rfkill_poll(struct rt2x00_dev *rt2x00dev)
{
u32 reg;
@@ -207,9 +206,6 @@ static int rt2500pci_rfkill_poll(struct rt2x00_dev *rt2x00dev)
rt2x00pci_register_read(rt2x00dev, GPIOCSR, ®);
return rt2x00_get_field32(reg, GPIOCSR_BIT0);
}
-#else
-#define rt2500pci_rfkill_poll NULL
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
#ifdef CONFIG_RT2X00_LIB_LEDS
static void rt2500pci_brightness_set(struct led_classdev *led_cdev,
@@ -1548,10 +1544,8 @@ static int rt2500pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
/*
* Detect if this device has an hardware controlled radio.
*/
-#ifdef CONFIG_RT2X00_LIB_RFKILL
if (rt2x00_get_field16(eeprom, EEPROM_ANTENNA_HARDWARE_RADIO))
__set_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags);
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
/*
* Check if the BBP tuning should be enabled.
@@ -1872,6 +1866,7 @@ static const struct ieee80211_ops rt2500pci_mac80211_ops = {
.get_tx_stats = rt2x00mac_get_tx_stats,
.get_tsf = rt2500pci_get_tsf,
.tx_last_beacon = rt2500pci_tx_last_beacon,
+ .rfkill_poll = rt2x00mac_rfkill_poll,
};
static const struct rt2x00lib_ops rt2500pci_rt2x00_ops = {
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 66daf68..795706d 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -277,7 +277,6 @@ static const struct rt2x00debug rt2500usb_rt2x00debug = {
};
#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
-#ifdef CONFIG_RT2X00_LIB_RFKILL
static int rt2500usb_rfkill_poll(struct rt2x00_dev *rt2x00dev)
{
u16 reg;
@@ -285,9 +284,6 @@ static int rt2500usb_rfkill_poll(struct rt2x00_dev *rt2x00dev)
rt2500usb_register_read(rt2x00dev, MAC_CSR19, ®);
return rt2x00_get_field32(reg, MAC_CSR19_BIT7);
}
-#else
-#define rt2500usb_rfkill_poll NULL
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
#ifdef CONFIG_RT2X00_LIB_LEDS
static void rt2500usb_brightness_set(struct led_classdev *led_cdev,
@@ -1601,10 +1597,8 @@ static int rt2500usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
/*
* Detect if this device has an hardware controlled radio.
*/
-#ifdef CONFIG_RT2X00_LIB_RFKILL
if (rt2x00_get_field16(eeprom, EEPROM_ANTENNA_HARDWARE_RADIO))
__set_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags);
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
/*
* Check if the BBP tuning should be disabled.
@@ -1905,6 +1899,7 @@ static const struct ieee80211_ops rt2500usb_mac80211_ops = {
.bss_info_changed = rt2x00mac_bss_info_changed,
.conf_tx = rt2x00mac_conf_tx,
.get_tx_stats = rt2x00mac_get_tx_stats,
+ .rfkill_poll = rt2x00mac_rfkill_poll,
};
static const struct rt2x00lib_ops rt2500usb_rt2x00_ops = {
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 3756166..a204e66 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -264,7 +264,6 @@ static const struct rt2x00debug rt2800usb_rt2x00debug = {
};
#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
-#ifdef CONFIG_RT2X00_LIB_RFKILL
static int rt2800usb_rfkill_poll(struct rt2x00_dev *rt2x00dev)
{
u32 reg;
@@ -272,9 +271,6 @@ static int rt2800usb_rfkill_poll(struct rt2x00_dev *rt2x00dev)
rt2x00usb_register_read(rt2x00dev, GPIO_CTRL_CFG, ®);
return rt2x00_get_field32(reg, GPIO_CTRL_CFG_BIT2);
}
-#else
-#define rt2800usb_rfkill_poll NULL
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
#ifdef CONFIG_RT2X00_LIB_LEDS
static void rt2800usb_brightness_set(struct led_classdev *led_cdev,
@@ -2385,10 +2381,8 @@ static int rt2800usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
/*
* Detect if this device has an hardware controlled radio.
*/
-#ifdef CONFIG_RT2X00_LIB_RFKILL
if (rt2x00_get_field16(eeprom, EEPROM_NIC_HW_RADIO))
__set_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags);
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
/*
* Store led settings, for correct led behaviour.
@@ -2800,6 +2794,7 @@ static const struct ieee80211_ops rt2800usb_mac80211_ops = {
.conf_tx = rt2800usb_conf_tx,
.get_tx_stats = rt2x00mac_get_tx_stats,
.get_tsf = rt2800usb_get_tsf,
+ .rfkill_poll = rt2x00mac_rfkill_poll,
};
static const struct rt2x00lib_ops rt2800usb_rt2x00_ops = {
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index 509ab90..de3f13a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -657,18 +657,6 @@ struct rt2x00_dev {
enum ieee80211_band curr_band;
/*
- * rfkill structure for RF state switching support.
- * This will only be compiled in when required.
- */
-#ifdef CONFIG_RT2X00_LIB_RFKILL
- unsigned long rfkill_state;
-#define RFKILL_STATE_ALLOCATED 1
-#define RFKILL_STATE_REGISTERED 2
-#define RFKILL_STATE_BLOCKED 3
- struct input_polled_dev *rfkill_poll_dev;
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
-
- /*
* If enabled, the debugfs interface structures
* required for deregistration of debugfs.
*/
@@ -998,6 +986,7 @@ void rt2x00mac_bss_info_changed(struct ieee80211_hw *hw,
u32 changes);
int rt2x00mac_conf_tx(struct ieee80211_hw *hw, u16 queue,
const struct ieee80211_tx_queue_params *params);
+void rt2x00mac_rfkill_poll(struct ieee80211_hw *hw);
/*
* Driver allocation handlers.
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 41e3379..4fff3a8 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -871,7 +871,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
*/
rt2x00link_register(rt2x00dev);
rt2x00leds_register(rt2x00dev);
- rt2x00rfkill_allocate(rt2x00dev);
rt2x00debug_register(rt2x00dev);
set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
@@ -903,7 +902,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
* Free extra components
*/
rt2x00debug_deregister(rt2x00dev);
- rt2x00rfkill_free(rt2x00dev);
rt2x00leds_unregister(rt2x00dev);
/*
diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h b/drivers/net/wireless/rt2x00/rt2x00lib.h
index 39e00b3..2c3c239 100644
--- a/drivers/net/wireless/rt2x00/rt2x00lib.h
+++ b/drivers/net/wireless/rt2x00/rt2x00lib.h
@@ -30,10 +30,8 @@
/*
* Interval defines
- * Both the link tuner as the rfkill will be called once per second.
*/
#define LINK_TUNE_INTERVAL round_jiffies_relative(HZ)
-#define RFKILL_POLL_INTERVAL 1000
/*
* rt2x00_rate: Per rate device information
@@ -386,29 +384,18 @@ static inline void rt2x00ht_create_tx_descriptor(struct queue_entry *entry,
/*
* RFkill handlers.
*/
-#ifdef CONFIG_RT2X00_LIB_RFKILL
-void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev);
-void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev);
-void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev);
-void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev);
-#else
static inline void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
{
+ if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags))
+ wiphy_rfkill_start_polling(rt2x00dev->hw->wiphy);
}
static inline void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
{
+ if (test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags))
+ wiphy_rfkill_stop_polling(rt2x00dev->hw->wiphy);
}
-static inline void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
-{
-}
-
-static inline void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
-{
-}
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
-
/*
* LED handlers
*/
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index 475a3ed..b7e0ddd 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -688,3 +688,12 @@ int rt2x00mac_conf_tx(struct ieee80211_hw *hw, u16 queue_idx,
return 0;
}
EXPORT_SYMBOL_GPL(rt2x00mac_conf_tx);
+
+void rt2x00mac_rfkill_poll(struct ieee80211_hw *hw)
+{
+ struct rt2x00_dev *rt2x00dev = hw->priv;
+ bool blocked = !!rt2x00dev->ops->lib->rfkill_poll(rt2x00dev);
+
+ wiphy_rfkill_set_hw_state(hw->wiphy, blocked);
+}
+EXPORT_SYMBOL_GPL(rt2x00mac_rfkill_poll);
diff --git a/drivers/net/wireless/rt2x00/rt2x00rfkill.c b/drivers/net/wireless/rt2x00/rt2x00rfkill.c
deleted file mode 100644
index b6d4c67..0000000
--- a/drivers/net/wireless/rt2x00/rt2x00rfkill.c
+++ /dev/null
@@ -1,127 +0,0 @@
-/*
- Copyright (C) 2004 - 2009 rt2x00 SourceForge Project
- <http://rt2x00.serialmonkey.com>
-
- 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.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the
- Free Software Foundation, Inc.,
- 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-/*
- Module: rt2x00rfkill
- Abstract: rt2x00 rfkill routines.
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-
-#include "rt2x00.h"
-#include "rt2x00lib.h"
-
-static void rt2x00rfkill_poll(struct input_polled_dev *poll_dev)
-{
- struct rt2x00_dev *rt2x00dev = poll_dev->private;
- int state, old_state;
-
- if (!test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state) ||
- !test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags))
- return;
-
- /*
- * Poll latest state, if the state is different then the previous state,
- * we should generate an input event.
- */
- state = !!rt2x00dev->ops->lib->rfkill_poll(rt2x00dev);
- old_state = !!test_bit(RFKILL_STATE_BLOCKED, &rt2x00dev->rfkill_state);
-
- if (old_state != state) {
- input_report_switch(poll_dev->input, SW_RFKILL_ALL, state);
- change_bit(RFKILL_STATE_BLOCKED, &rt2x00dev->rfkill_state);
- }
-}
-
-void rt2x00rfkill_register(struct rt2x00_dev *rt2x00dev)
-{
- if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
- test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
- return;
-
- if (input_register_polled_device(rt2x00dev->rfkill_poll_dev)) {
- ERROR(rt2x00dev, "Failed to register polled device.\n");
- return;
- }
-
- __set_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state);
-
- /*
- * Force initial poll which will detect the initial device state,
- * and correctly sends the signal to the input layer about this
- * state.
- */
- rt2x00rfkill_poll(rt2x00dev->rfkill_poll_dev);
-}
-
-void rt2x00rfkill_unregister(struct rt2x00_dev *rt2x00dev)
-{
- if (!test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
- !test_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state))
- return;
-
- input_unregister_polled_device(rt2x00dev->rfkill_poll_dev);
-
- __clear_bit(RFKILL_STATE_REGISTERED, &rt2x00dev->rfkill_state);
-}
-
-void rt2x00rfkill_allocate(struct rt2x00_dev *rt2x00dev)
-{
- struct input_polled_dev *poll_dev;
-
- if (test_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state) ||
- !test_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags))
- return;
-
- poll_dev = input_allocate_polled_device();
- if (!poll_dev) {
- ERROR(rt2x00dev, "Failed to allocate polled device.\n");
- return;
- }
-
- poll_dev->private = rt2x00dev;
- poll_dev->poll = rt2x00rfkill_poll;
- poll_dev->poll_interval = RFKILL_POLL_INTERVAL;
-
- poll_dev->input->name = rt2x00dev->ops->name;
- poll_dev->input->phys = wiphy_name(rt2x00dev->hw->wiphy);
- poll_dev->input->id.bustype = BUS_HOST;
- poll_dev->input->id.vendor = 0x1814;
- poll_dev->input->id.product = rt2x00dev->chip.rt;
- poll_dev->input->id.version = rt2x00dev->chip.rev;
- poll_dev->input->dev.parent = wiphy_dev(rt2x00dev->hw->wiphy);
- poll_dev->input->evbit[0] = BIT(EV_SW);
- poll_dev->input->swbit[0] = BIT(SW_RFKILL_ALL);
-
- rt2x00dev->rfkill_poll_dev = poll_dev;
-
- __set_bit(RFKILL_STATE_ALLOCATED, &rt2x00dev->rfkill_state);
-}
-
-void rt2x00rfkill_free(struct rt2x00_dev *rt2x00dev)
-{
- if (!__test_and_clear_bit(RFKILL_STATE_ALLOCATED,
- &rt2x00dev->rfkill_state))
- return;
-
- input_free_polled_device(rt2x00dev->rfkill_poll_dev);
- rt2x00dev->rfkill_poll_dev = NULL;
-}
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 49b29ff..8a49d99 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -237,7 +237,6 @@ static const struct rt2x00debug rt61pci_rt2x00debug = {
};
#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
-#ifdef CONFIG_RT2X00_LIB_RFKILL
static int rt61pci_rfkill_poll(struct rt2x00_dev *rt2x00dev)
{
u32 reg;
@@ -245,9 +244,6 @@ static int rt61pci_rfkill_poll(struct rt2x00_dev *rt2x00dev)
rt2x00pci_register_read(rt2x00dev, MAC_CSR13, ®);
return rt2x00_get_field32(reg, MAC_CSR13_BIT5);
}
-#else
-#define rt61pci_rfkill_poll NULL
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
#ifdef CONFIG_RT2X00_LIB_LEDS
static void rt61pci_brightness_set(struct led_classdev *led_cdev,
@@ -2338,10 +2334,8 @@ static int rt61pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
/*
* Detect if this device has an hardware controlled radio.
*/
-#ifdef CONFIG_RT2X00_LIB_RFKILL
if (rt2x00_get_field16(eeprom, EEPROM_ANTENNA_HARDWARE_RADIO))
__set_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags);
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
/*
* Read frequency offset and RF programming sequence.
@@ -2728,6 +2722,7 @@ static const struct ieee80211_ops rt61pci_mac80211_ops = {
.conf_tx = rt61pci_conf_tx,
.get_tx_stats = rt2x00mac_get_tx_stats,
.get_tsf = rt61pci_get_tsf,
+ .rfkill_poll = rt2x00mac_rfkill_poll,
};
static const struct rt2x00lib_ops rt61pci_rt2x00_ops = {
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index c188488..ad2898c 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -183,7 +183,6 @@ static const struct rt2x00debug rt73usb_rt2x00debug = {
};
#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
-#ifdef CONFIG_RT2X00_LIB_RFKILL
static int rt73usb_rfkill_poll(struct rt2x00_dev *rt2x00dev)
{
u32 reg;
@@ -191,9 +190,6 @@ static int rt73usb_rfkill_poll(struct rt2x00_dev *rt2x00dev)
rt2x00usb_register_read(rt2x00dev, MAC_CSR13, ®);
return rt2x00_get_field32(reg, MAC_CSR13_BIT7);
}
-#else
-#define rt73usb_rfkill_poll NULL
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
#ifdef CONFIG_RT2X00_LIB_LEDS
static void rt73usb_brightness_set(struct led_classdev *led_cdev,
@@ -1863,10 +1859,8 @@ static int rt73usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
/*
* Detect if this device has an hardware controlled radio.
*/
-#ifdef CONFIG_RT2X00_LIB_RFKILL
if (rt2x00_get_field16(eeprom, EEPROM_ANTENNA_HARDWARE_RADIO))
__set_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags);
-#endif /* CONFIG_RT2X00_LIB_RFKILL */
/*
* Read frequency offset.
@@ -2253,6 +2247,7 @@ static const struct ieee80211_ops rt73usb_mac80211_ops = {
.conf_tx = rt73usb_conf_tx,
.get_tx_stats = rt2x00mac_get_tx_stats,
.get_tsf = rt73usb_get_tsf,
+ .rfkill_poll = rt2x00mac_rfkill_poll,
};
static const struct rt2x00lib_ops rt73usb_rt2x00_ops = {
--
1.6.3.1
^ permalink raw reply related
* [PATCH] iwlwifi: fix aggregation limit
From: Johannes Berg @ 2009-07-01 12:57 UTC (permalink / raw)
To: John Linville; +Cc: Reinette Chatre, linux-wireless
According to the documentation, the limit is 0x3f == 63, not 64.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
It seems bug 2018 is related to the link quality command, because it
seems I can trivially trigger it or similar bugs that way, but this
doesn't fix it.
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-commands.h 2009-07-01 14:53:33.804427206 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-commands.h 2009-07-01 14:53:38.924427592 +0200
@@ -1922,7 +1922,7 @@ struct iwl_link_qual_general_params {
#define LINK_QUAL_AGG_DISABLE_START_MIN (0)
#define LINK_QUAL_AGG_FRAME_LIMIT_DEF (31)
-#define LINK_QUAL_AGG_FRAME_LIMIT_MAX (64)
+#define LINK_QUAL_AGG_FRAME_LIMIT_MAX 0x3f
#define LINK_QUAL_AGG_FRAME_LIMIT_MIN (0)
/**
^ permalink raw reply
* Re: Some thoughts about background scanning
From: Helmut Schaa @ 2009-07-01 10:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: Helmut Schaa, linux-wireless
In-Reply-To: <1246441038.4131.12.camel@johannes.local>
Am Mittwoch, 1. Juli 2009 schrieb Johannes Berg:
> > My current approach is quite easy but works well: Extend the scan state
> > machine with a new state (OPERATION) which restores the channel and the
> > correct filter flags and notifies the AP that we're back.
>
> Makes sense. You can optimise scanning for the _current_ channel by a
> combination of OPERATION and scanning, leaving the filter flags at the
> scan version, and sending the probe requests. In fact, if you scan that
> channel first, you can avoid IEEE80211_PROBE_DELAY since the NAV should
> be known on that channel.
>
> Tangentially related, we can also move into SCAN_SEND_PROBE _before_
> IEEE80211_PROBE_DELAY has passed, if we receive a frame (which means NAV
> update).
Correct, that would be another minor optimzation.
> > The state
> > machine moves there after every scanned channel. The result is that
> > the complete scan can take quite some time, something a round 15 seconds.
>
> That doesn't sound too bad. How long are you staying on the operational
> channel though?
I used the beacon interval of the currently associated AP (100ms here).
Hence, we can be sure that we receive at least one beacon from that AP
and would notice if the AP is gone in the meantime. Of course that can
be optimized by the approach I described in the last mail by proceeding
with the scan once we receive a beacon without TIM bit set.
> > Scanning multiple channels before switching back would allow us to
> > reduce the amount of time the scan takes. So, what I'd like to have is
> > integration with pm_qos in order to determine how much channels may be
> > scanned at once before we have to switch back. Shouldn't be that
> > difficult ;)
>
> You might be able to use local->hw.conf.max_sleep_period from
> ieee80211_recalc_ps? Or probably better move the calculation into a
> helper function since it needs to work across all managed interfaces, if
> there are multiple.
Yep. Already thought about that one. It only needs minor adjustments (for
example it is only available if powersave is done within mac80211).
[...]
> > Advantages:
> >
> > We could split the actual scan algorithm out of the scan state machine,
> > for example if pm_qos allows us to stay away for 150ms we could reorder
> > the channels to scan one active channel followed by one passive channel
> > before switching back to the operating channel. Should allow us to use
> > all sorts of insane optimizations.
>
> :)
> It might be better to have even more states, e.g. make the list look
> like this:
> - SWITCH_TO 2412 MHz
> - NAV_WAIT max 33ms
> - SEND_PROBES
> - WAIT_PROBES
> - SWITCH_TO (operation channel)
> - OPERATION
> ...
>
> That way we can short-circuit the NAV_WAIT on receiving a frame, for
> example. We don't receive all frames, of course, so it would be useful
> to have some driver assistance for that at some point too.
Yeah, cool idea. Have to think about which states make sense and which
don't.
> > In some cases we might shorten the pre-computed values. For example if
> > we switch back to the operating channel and receive a beacon without
> > TIM being set for our association and our TX queue is empty we might
> > immediately proceed with the scan without having to stay on the channel
> > for the full amount of time. Not sure if we can do this properly without
> > recomputing the whole table (depends on the actual algorithm used).
>
> I think short-circuiting states should be possible from the outside for
> the NAV wait too.
Agreed.
> > Does that kind of approach sound useful? Is it overkill?
>
> Seems useful to me :)
Great, thanks. I'll look into it some more.
Helmut
^ permalink raw reply
* Re: [PATCH] cfg80211: set conn.state properly in the connect() case
From: Johannes Berg @ 2009-07-01 10:58 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20090630153522.GA28206@sortiz.org>
[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]
On Tue, 2009-06-30 at 17:35 +0200, Samuel Ortiz wrote:
> We need to set the conn.state to ASSOCIATING for the ->connect() path. By
> default, it is set to 0, i.e. SCANNING, which causes sme_scan_done() to
> eventually call conn_do_work(), which then would call assoc() and auth()
> blindly. That's why we also bug on those hooks not being defined there.
Maybe it would be better to have a default IDLE state for this state
machine as well, instead?
johannes
> Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com>
> ---
> net/wireless/sme.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> Index: iwm-2.6/net/wireless/sme.c
> ===================================================================
> --- iwm-2.6.orig/net/wireless/sme.c 2009-06-30 16:39:58.000000000 +0200
> +++ iwm-2.6/net/wireless/sme.c 2009-06-30 17:17:14.000000000 +0200
> @@ -103,6 +103,7 @@ static int cfg80211_conn_do_work(struct
> u.auth_req.ie = NULL;
> u.auth_req.ie_len = 0;
> wdev->conn.state = CFG80211_CONN_AUTHENTICATING;
> + BUG_ON(!drv->ops->auth);
> return drv->ops->auth(wdev->wiphy, wdev->netdev, &u.auth_req);
> case CFG80211_CONN_ASSOCIATE_NEXT:
> u.assoc_req.chan = wdev->conn.params.channel;
> @@ -115,6 +116,7 @@ static int cfg80211_conn_do_work(struct
> memcpy(&u.assoc_req.crypto, &wdev->conn.params.crypto,
> sizeof(u.assoc_req.crypto));
> wdev->conn.state = CFG80211_CONN_ASSOCIATING;
> + BUG_ON(!drv->ops->assoc);
> return drv->ops->assoc(wdev->wiphy, wdev->netdev,
> &u.assoc_req);
> default:
> @@ -455,6 +457,7 @@ int cfg80211_connect(struct cfg80211_reg
> return err;
> } else {
> wdev->sme_state = CFG80211_SME_CONNECTING;
> + wdev->conn.state = CFG80211_CONN_ASSOCIATING;
> err = rdev->ops->connect(&rdev->wiphy, dev, connect);
> if (err) {
> wdev->sme_state = CFG80211_SME_IDLE;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 8/8 v3.1] mac80211: re-add HT disabling
From: Johannes Berg @ 2009-07-01 10:42 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org,
Jouni Malinen
In-Reply-To: <20090701101336.GD24667@vasanth-laptop>
[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]
On Wed, 2009-07-01 at 15:43 +0530, Vasanthakumar Thiagarajan wrote:
> On Wed, Jul 01, 2009 at 01:09:16PM +0530, Johannes Berg wrote:
> > The IEEE80211_STA_TKIP_WEP_USED flag is used internally to
> > disable HT when WEP or TKIP are used. Now that cfg80211 is
> > giving us the required information, we can set the flag
> > appropriately again.
> >
> > Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> > ---
> > net/mac80211/cfg.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > --- wireless-testing.orig/net/mac80211/cfg.c 2009-07-01 09:01:25.000000000 +0200
> > +++ wireless-testing/net/mac80211/cfg.c 2009-07-01 09:09:01.000000000 +0200
> > @@ -1228,7 +1228,7 @@ static int ieee80211_assoc(struct wiphy
> > struct cfg80211_assoc_request *req)
> > {
> > struct ieee80211_sub_if_data *sdata;
> > - int ret;
> > + int ret, i;
> >
> > sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> >
> > @@ -1236,6 +1236,14 @@ static int ieee80211_assoc(struct wiphy
> > !(sdata->u.mgd.flags & IEEE80211_STA_AUTHENTICATED))
> > return -ENOLINK; /* not authenticated */
> >
> > + sdata->u.mgd.flags &= ~IEEE80211_STA_TKIP_WEP_USED;
> > +
> > + for (i = 0; i < req->crypto.n_ciphers_pairwise; i++)
> > + if (req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_WEP40 ||
> > + req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_TKIP ||
> > + req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_WEP104)
> > + sdata->u.mgd.flags |= IEEE80211_STA_TKIP_WEP_USED;
> > +
>
> for..loop does not seem to be necessary here as it is very unlikely that
> an assoc req will have more than one cipher suite.
True, but so far we've defined the API that way. Should we redefine the
API? I keep forgetting what is valid where. Jouni?
> I'm not sure if this patch series will get into 2.6.31-rc, if it
> does not, we may need a variant of this patch to fix
> http://bugzilla.kernel.org/show_bug.cgi?id=13630, I'll work on it.
> Thanks!.
I don't think we can. Even the above patch relies on wpa_supplicant to
pass us the correct information. Otherwise we would have to parse the
IEs, which is somewhat ugly.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Some thoughts about background scanning
From: Johannes Berg @ 2009-07-01 9:37 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless
In-Reply-To: <200907011003.49857.helmut.schaa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]
Hi,
> just thought a bit about background scanning (not triggering scans at
> any time but just hopping back to the operating channel once in a while
> to allow RX/TX).
:)
> My current approach is quite easy but works well: Extend the scan state
> machine with a new state (OPERATION) which restores the channel and the
> correct filter flags and notifies the AP that we're back.
Makes sense. You can optimise scanning for the _current_ channel by a
combination of OPERATION and scanning, leaving the filter flags at the
scan version, and sending the probe requests. In fact, if you scan that
channel first, you can avoid IEEE80211_PROBE_DELAY since the NAV should
be known on that channel.
Tangentially related, we can also move into SCAN_SEND_PROBE _before_
IEEE80211_PROBE_DELAY has passed, if we receive a frame (which means NAV
update).
> The state
> machine moves there after every scanned channel. The result is that
> the complete scan can take quite some time, something a round 15 seconds.
That doesn't sound too bad. How long are you staying on the operational
channel though?
> Scanning multiple channels before switching back would allow us to
> reduce the amount of time the scan takes. So, what I'd like to have is
> integration with pm_qos in order to determine how much channels may be
> scanned at once before we have to switch back. Shouldn't be that
> difficult ;)
You might be able to use local->hw.conf.max_sleep_period from
ieee80211_recalc_ps? Or probably better move the calculation into a
helper function since it needs to work across all managed interfaces, if
there are multiple.
> However, the current scan state machine is very inflexible
> and I'd have to add a lot of ugly stuff to make it work really good (at
> least that's my impression currently).
>
> So, a completely new approach would be to pre-compute all necessary scan
> states. Based on the cfg80211 scan request, the current pm_qos values
> and the beacon characteristics we could derive a table of necessary scan
> states and extend it by operation states.
>
> For example:
> Channel 1, Active Scan, 30ms
> Channel 2, Active Scan, 30ms
> Channel 3, Active Scan, 30ms
> Channel 4, Active Scan, 30ms
> Channel 11, Operation Mode, 120ms
> Channel 52, Passive Scan, 120ms
> Channel 11, Operation Mode, 120ms
> ...
Sounds reasonable.
> Advantages:
>
> We could split the actual scan algorithm out of the scan state machine,
> for example if pm_qos allows us to stay away for 150ms we could reorder
> the channels to scan one active channel followed by one passive channel
> before switching back to the operating channel. Should allow us to use
> all sorts of insane optimizations.
:)
It might be better to have even more states, e.g. make the list look
like this:
- SWITCH_TO 2412 MHz
- NAV_WAIT max 33ms
- SEND_PROBES
- WAIT_PROBES
- SWITCH_TO (operation channel)
- OPERATION
...
That way we can short-circuit the NAV_WAIT on receiving a frame, for
example. We don't receive all frames, of course, so it would be useful
to have some driver assistance for that at some point too.
> Disadvantages:
>
> If we compute the table while we're associated but lose association in
> the middle of the scan we would either have to update the scan table to
> reflect the current state or leave it as is which of course lengthens the
> scan. And of course we need more memory to store the table.
The memory consumption wouldn't be a problem, and if we lose association
we can always skip the operational states, i.e. check whether we lost
association during that state and if not go to the next.
> In some cases we might shorten the pre-computed values. For example if
> we switch back to the operating channel and receive a beacon without
> TIM being set for our association and our TX queue is empty we might
> immediately proceed with the scan without having to stay on the channel
> for the full amount of time. Not sure if we can do this properly without
> recomputing the whole table (depends on the actual algorithm used).
I think short-circuiting states should be possible from the outside for
the NAV wait too.
> I'd like to first get some comments on that idea before thinking about
> implementing it :)
>
> Does that kind of approach sound useful? Is it overkill?
Seems useful to me :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 8/8 v3.1] mac80211: re-add HT disabling
From: Vasanthakumar Thiagarajan @ 2009-07-01 10:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org
In-Reply-To: <1246433956.16643.35.camel@johannes.local>
On Wed, Jul 01, 2009 at 01:09:16PM +0530, Johannes Berg wrote:
> The IEEE80211_STA_TKIP_WEP_USED flag is used internally to
> disable HT when WEP or TKIP are used. Now that cfg80211 is
> giving us the required information, we can set the flag
> appropriately again.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/mac80211/cfg.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> --- wireless-testing.orig/net/mac80211/cfg.c 2009-07-01 09:01:25.000000000 +0200
> +++ wireless-testing/net/mac80211/cfg.c 2009-07-01 09:09:01.000000000 +0200
> @@ -1228,7 +1228,7 @@ static int ieee80211_assoc(struct wiphy
> struct cfg80211_assoc_request *req)
> {
> struct ieee80211_sub_if_data *sdata;
> - int ret;
> + int ret, i;
>
> sdata = IEEE80211_DEV_TO_SUB_IF(dev);
>
> @@ -1236,6 +1236,14 @@ static int ieee80211_assoc(struct wiphy
> !(sdata->u.mgd.flags & IEEE80211_STA_AUTHENTICATED))
> return -ENOLINK; /* not authenticated */
>
> + sdata->u.mgd.flags &= ~IEEE80211_STA_TKIP_WEP_USED;
> +
> + for (i = 0; i < req->crypto.n_ciphers_pairwise; i++)
> + if (req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_WEP40 ||
> + req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_TKIP ||
> + req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_WEP104)
> + sdata->u.mgd.flags |= IEEE80211_STA_TKIP_WEP_USED;
> +
for..loop does not seem to be necessary here as it is very unlikely that
an assoc req will have more than one cipher suite.
I'm not sure if this patch series will get into 2.6.31-rc, if it
does not, we may need a variant of this patch to fix
http://bugzilla.kernel.org/show_bug.cgi?id=13630, I'll work on it.
Thanks!.
Vasanth
^ permalink raw reply
* Re: none
From: Kalle Valo @ 2009-07-01 8:32 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, ccmcphe, bcm43xx-dev,
linux-wireless
In-Reply-To: <4a4ad9e4.vPnta8trzUXc4YPz%Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> From: Clyde McPherson <ccmcphe@verizon.net>
>
> Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
> 4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Subject missing from this one as well.
--
Kalle Valo
^ permalink raw reply
* Re: none
From: Kalle Valo @ 2009-07-01 8:31 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, ccmcphe, bcm43xx-dev,
linux-wireless
In-Reply-To: <4a4ad9ca.vjHlJqRZ71Q1f7CP%Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> From: Clyde McPherson <ccmcphe@verizon.net>
>
> Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
> 4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Subject missing.
--
Kalle Valo
^ permalink raw reply
* who can share 802.11s draft
From: Angela @ 2009-07-01 8:04 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4A4B056B.9000602@mrs.ro>
Hi all,
who can share me 802.11s draft?? thanks!
2009-07-01
Angela
^ permalink raw reply
* Some thoughts about background scanning
From: Helmut Schaa @ 2009-07-01 8:03 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
Hey,
just thought a bit about background scanning (not triggering scans at
any time but just hopping back to the operating channel once in a while
to allow RX/TX).
My current approach is quite easy but works well: Extend the scan state
machine with a new state (OPERATION) which restores the channel and the
correct filter flags and notifies the AP that we're back. The state
machine moves there after every scanned channel. The result is that
the complete scan can take quite some time, something a round 15 seconds.
Scanning multiple channels before switching back would allow us to
reduce the amount of time the scan takes. So, what I'd like to have is
integration with pm_qos in order to determine how much channels may be
scanned at once before we have to switch back. Shouldn't be that
difficult ;) However, the current scan state machine is very inflexible
and I'd have to add a lot of ugly stuff to make it work really good (at
least that's my impression currently).
So, a completely new approach would be to pre-compute all necessary scan
states. Based on the cfg80211 scan request, the current pm_qos values
and the beacon characteristics we could derive a table of necessary scan
states and extend it by operation states.
For example:
Channel 1, Active Scan, 30ms
Channel 2, Active Scan, 30ms
Channel 3, Active Scan, 30ms
Channel 4, Active Scan, 30ms
Channel 11, Operation Mode, 120ms
Channel 52, Passive Scan, 120ms
Channel 11, Operation Mode, 120ms
...
Advantages:
We could split the actual scan algorithm out of the scan state machine,
for example if pm_qos allows us to stay away for 150ms we could reorder
the channels to scan one active channel followed by one passive channel
before switching back to the operating channel. Should allow us to use
all sorts of insane optimizations.
Disadvantages:
If we compute the table while we're associated but lose association in
the middle of the scan we would either have to update the scan table to
reflect the current state or leave it as is which of course lengthens the
scan. And of course we need more memory to store the table.
In some cases we might shorten the pre-computed values. For example if
we switch back to the operating channel and receive a beacon without
TIM being set for our association and our TX queue is empty we might
immediately proceed with the scan without having to stay on the channel
for the full amount of time. Not sure if we can do this properly without
recomputing the whole table (depends on the actual algorithm used).
I'd like to first get some comments on that idea before thinking about
implementing it :)
Does that kind of approach sound useful? Is it overkill?
Thanks,
Helmut
^ permalink raw reply
* [PATCH 8/8 v3.1] mac80211: re-add HT disabling
From: Johannes Berg @ 2009-07-01 7:39 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org
In-Reply-To: <1246370452.16643.11.camel@johannes.local>
The IEEE80211_STA_TKIP_WEP_USED flag is used internally to
disable HT when WEP or TKIP are used. Now that cfg80211 is
giving us the required information, we can set the flag
appropriately again.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/cfg.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- wireless-testing.orig/net/mac80211/cfg.c 2009-07-01 09:01:25.000000000 +0200
+++ wireless-testing/net/mac80211/cfg.c 2009-07-01 09:09:01.000000000 +0200
@@ -1228,7 +1228,7 @@ static int ieee80211_assoc(struct wiphy
struct cfg80211_assoc_request *req)
{
struct ieee80211_sub_if_data *sdata;
- int ret;
+ int ret, i;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
@@ -1236,6 +1236,14 @@ static int ieee80211_assoc(struct wiphy
!(sdata->u.mgd.flags & IEEE80211_STA_AUTHENTICATED))
return -ENOLINK; /* not authenticated */
+ sdata->u.mgd.flags &= ~IEEE80211_STA_TKIP_WEP_USED;
+
+ for (i = 0; i < req->crypto.n_ciphers_pairwise; i++)
+ if (req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_WEP40 ||
+ req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_TKIP ||
+ req->crypto.ciphers_pairwise[i] == WLAN_CIPHER_SUITE_WEP104)
+ sdata->u.mgd.flags |= IEEE80211_STA_TKIP_WEP_USED;
+
sdata->u.mgd.flags &= ~IEEE80211_STA_AUTO_BSSID_SEL;
sdata->u.mgd.flags |= IEEE80211_STA_BSSID_SET;
^ permalink raw reply
* Re: ath5k and Atheros AR242x - No scan results
From: Joel Roth @ 2009-07-01 7:24 UTC (permalink / raw)
To: Nick Kossifidis; +Cc: linux-wireless
In-Reply-To: <40f31dec0906301416m39e6943ewef8d9c5bc5591880@mail.gmail.com>
On Wed, Jul 01, 2009 at 12:16:47AM +0300, Nick Kossifidis wrote:
> 2009/6/30 Joel Roth <joelz@pobox.com>:
> > Hello all,
> >
> > I'd appreciate some help troubleshooting my wireless connection.
> >
> > I have a Toshiba Satellite L305 series laptop running Debian
> > sid with a recent, stock Debian kernel version 2.6.29-2-486.
> >
> > $ lspci | grep Atheros
> >
> > 05:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
> >
> > I am seeking to connect to a D-Link 614+ wireless router.
> > For initial testing, the AP is unencrypted, unsecured.
> >
> > My wife's G3 i-Book with AfterTheMac USB wireless adapter
> > connected just fine, on the first try.
> >
> > I believe I have the modules I should have:
> >
> > $ lsmod | grep 80211
> > mac80211 139680 1 ath5k
> > cfg80211 21576 2 ath5k,mac80211
> >
> > My wireless network interface is present:
> >
> > $ iwconfig wlan0
> >
> > wlan0 IEEE 802.11 ESSID:""
> > Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
> > Tx-Power=0 dBm
> > Retry min limit:7 RTS thr:off Fragment thr=2352 B
> > Link Quality:0 Signal level:0 Noise level:0
> > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> > Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> >
> > $ ifconfig wlan0
> >
> > wlan0 Link encap:Ethernet HWaddr 00:21:63:82:82:40
> > UP BROADCAST MULTICAST MTU:1500 Metric:1
> > RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> >
> >
> > However, I don't find the D-Link 614+:
> >
> > $ iwlist wlan0 scan
> >
> > wlan0 No scan results
> >
> > And of course, dhclient fails to find a server.
> >
> > Am I missing something? What could I try next?
> > I'd appreciate any pointers.
> >
> > Thanks.
> >
> > --
> > Joel Roth
>
> Hello ;-)
>
> Can you please sent the dmesg output when ath5k loads ?
> Also do you see any messages on dmesg while scaning ?
Hi :-)
On loading the ath5k driver, dmesg reports:
[83838.020161] ath5k 0000:05:00.0: PCI INT A disabled
[83852.364249] cfg80211: Using static regulatory domain info
[83852.364253] cfg80211: Regulatory domain: US
[83852.364255] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[83852.364258] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[83852.364261] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[83852.364264] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[83852.364266] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[83852.364269] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[83852.364271] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[83852.364274] cfg80211: Calling CRDA for country: US
[83852.427844] ath5k 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[83852.427858] ath5k 0000:05:00.0: setting latency timer to 64
[83852.427916] ath5k 0000:05:00.0: registered as 'phy0'
[83852.620221] wmaster0 (ath5k): not using net_device_ops yet
[83852.620896] phy0: Selected rate control algorithm 'minstrel'
[83852.620913] wlan0 (ath5k): not using net_device_ops yet
[83852.621565] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
On attempting to scan:
[84202.916169] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Thanks!
--
Joel Roth
^ permalink raw reply
* Re: mac80211 and broadcast frames
From: Valentin Manea @ 2009-07-01 6:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890906300920j1963ae07v800468db9a908a1@mail.gmail.com>
On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<linux-wireless@mrs.ro> wrote:
>> Hi,
>>
>> I've been working on a small project that basically sends broadcast UDP
>> frames from an Wireless AP to multiple clients. While I can send UDP frames
>> just fine from the AP to the client the only a few broadcast frames reach my
>> client. What is really puzzling is that on the client machine using tcpdump
>> I can see all the broadcast frames arriving, my application sees only a
>> small fraction of them.
>
> Keep in mind when you use tcpdump it will modify the RX filters of the
> device you use but if you say you see them on tcpdump and at the same
> time do not see them on the application that seems fishy and non
> driver related.
>
> Luis
tcpdump doesn't affect the results at all, with or without it running
it's the same.
I have tried tracing the packets, I thought that maybe there is a
problem in the 80211 stack and for some reason they would be dropped but
as far as I can tell every packet is routed to the ip stack with the
correct protocol and pkt_type.
One more strange thing, if I'm looking at netstat -s everything seems to
be normal, InBcastPkts is fine, also the number of incomming UDP packets.
Any ideas where I could look? it just gets stranger and stranger.
Thanks,
Valentin
^ permalink raw reply
* [PATCH V2] ssb: Add support for 4318E
From: Larry Finger @ 2009-07-01 3:39 UTC (permalink / raw)
To: John W Linville, Michael Buesch, ccmcphe; +Cc: bcm43xx-dev, linux-wireless
From: Clyde McPherson <ccmcphe@verizon.net>
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Signed-off-by: Clyde McPherson <ccmcphe@verizon.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Index: wireless-testing/drivers/ssb/pcmcia.c
===================================================================
--- wireless-testing.orig/drivers/ssb/pcmcia.c
+++ wireless-testing/drivers/ssb/pcmcia.c
@@ -678,7 +678,8 @@ int ssb_pcmcia_get_invariants(struct ssb
sprom->board_rev = tuple.TupleData[1];
break;
case SSB_PCMCIA_CIS_PA:
- GOTO_ERROR_ON(tuple.TupleDataLen != 9,
+ GOTO_ERROR_ON((tuple.TupleDataLen != 9) &&
+ (tuple.TupleDataLen != 10),
"pa tpl size");
sprom->pa0b0 = tuple.TupleData[1] |
((u16)tuple.TupleData[2] << 8);
@@ -718,7 +719,8 @@ int ssb_pcmcia_get_invariants(struct ssb
sprom->antenna_gain.ghz5.a3 = tuple.TupleData[1];
break;
case SSB_PCMCIA_CIS_BFLAGS:
- GOTO_ERROR_ON(tuple.TupleDataLen != 3,
+ GOTO_ERROR_ON((tuple.TupleDataLen != 3) &&
+ (tuple.TupleDataLen != 5),
"bfl tpl size");
sprom->boardflags_lo = tuple.TupleData[1] |
((u16)tuple.TupleData[2] << 8);
^ permalink raw reply
* [PATCH V2] b43: Add support for 4318E
From: Larry Finger @ 2009-07-01 3:39 UTC (permalink / raw)
To: John W Linville, Michael Buesch, ccmcphe; +Cc: bcm43xx-dev, linux-wireless
From: Clyde McPherson <ccmcphe@verizon.net>
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Signed-off-by: Clyde McPherson <ccmcphe@verizon.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
diff --git a/drivers/net/wireless/b43/pcmcia.c
b/drivers/net/wireless/b43/pcmcia.c
index 3cfc303..6c3a749 100644
--- a/drivers/net/wireless/b43/pcmcia.c
+++ b/drivers/net/wireless/b43/pcmcia.c
@@ -35,6 +35,7 @@
static /*const */ struct pcmcia_device_id b43_pcmcia_tbl[] = {
PCMCIA_DEVICE_MANF_CARD(0x2D0, 0x448),
+ PCMCIA_DEVICE_MANF_CARD(0x2D0, 0x476),
PCMCIA_DEVICE_NULL,
};
^ permalink raw reply related
* (no subject)
From: Larry Finger @ 2009-07-01 3:37 UTC (permalink / raw)
To: John W Linville, Michael Buesch, ccmcphe; +Cc: bcm43xx-dev, linux-wireless
From: Clyde McPherson <ccmcphe@verizon.net>
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Signed-off-by: Clyde McPherson <ccmcphe@verizon.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Index: wireless-testing/drivers/ssb/pcmcia.c
===================================================================
--- wireless-testing.orig/drivers/ssb/pcmcia.c
+++ wireless-testing/drivers/ssb/pcmcia.c
@@ -678,7 +678,8 @@ int ssb_pcmcia_get_invariants(struct ssb
sprom->board_rev = tuple.TupleData[1];
break;
case SSB_PCMCIA_CIS_PA:
- GOTO_ERROR_ON(tuple.TupleDataLen != 9,
+ GOTO_ERROR_ON((tuple.TupleDataLen != 9) &&
+ (tuple.TupleDataLen != 10),
"pa tpl size");
sprom->pa0b0 = tuple.TupleData[1] |
((u16)tuple.TupleData[2] << 8);
@@ -718,7 +719,8 @@ int ssb_pcmcia_get_invariants(struct ssb
sprom->antenna_gain.ghz5.a3 = tuple.TupleData[1];
break;
case SSB_PCMCIA_CIS_BFLAGS:
- GOTO_ERROR_ON(tuple.TupleDataLen != 3,
+ GOTO_ERROR_ON((tuple.TupleDataLen != 3) &&
+ (tuple.TupleDataLen != 5),
"bfl tpl size");
sprom->boardflags_lo = tuple.TupleData[1] |
((u16)tuple.TupleData[2] << 8);
^ permalink raw reply
* (no subject)
From: Larry Finger @ 2009-07-01 3:36 UTC (permalink / raw)
To: John W Linville, Michael Buesch, ccmcphe; +Cc: bcm43xx-dev, linux-wireless
From: Clyde McPherson <ccmcphe@verizon.net>
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Signed-off-by: Clyde McPherson <ccmcphe@verizon.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
diff --git a/drivers/net/wireless/b43/pcmcia.c
b/drivers/net/wireless/b43/pcmcia.c
index 3cfc303..6c3a749 100644
--- a/drivers/net/wireless/b43/pcmcia.c
+++ b/drivers/net/wireless/b43/pcmcia.c
@@ -35,6 +35,7 @@
static /*const */ struct pcmcia_device_id b43_pcmcia_tbl[] = {
PCMCIA_DEVICE_MANF_CARD(0x2D0, 0x448),
+ PCMCIA_DEVICE_MANF_CARD(0x2D0, 0x476),
PCMCIA_DEVICE_NULL,
};
^ permalink raw reply related
* Fwd: kernel .30 BROKE ATH5K with my AR5212 atheros.
From: Jasin Colegrove @ 2009-06-30 22:50 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <6c354a1a0906301524m389d49a9sfd812e1ea4740ff5@mail.gmail.com>
---------- Forwarded message ----------
From: Jasin Colegrove <j.wholesalesupply@gmail.com>
Date: Tue, Jun 30, 2009 at 6:24 PM
Subject: kernel .30 BROKE ATH5K with my AR5212 atheros.
To: linux-wireless@vger.kernel.org
I AM NOT A SUBSCRIBER. Please reply to me directly at this e-mail
address j.wholesalesupply@gmail.com
lspci -vvvvvvvvvv
02:02.0 Ethernet controller: Atheros Communications Inc. AR5212
802.11abg NIC (rev 01)
Subsystem: Phillips Components Device 8331
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at c0200000 (32-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: ath5k
Kernel modules: ath5k
$ lsmod | grep ath
ath5k 107192 0
mac80211 158652 1 ath5k
led_class 3416 2 thinkpad_acpi,ath5k
cfg80211 36524 2 ath5k,mac80211
Once I installed and ran the .30 release on my laptop my internet
connection was down. Wicd reported that the ping failed because it did
not recieve a response from the access point. So I started checking
things out, I have no wpa/wep security. I have no mac filtering. If I
try using a static IP to the router, the manual method of ifconfig
192.168.1.4; route add default gw 192.168.1.1 works, but I can not
ping anything outside of my localhost. Pinging the gateway fails,
pinging other computers on the network fails. If I try dhcp, it
timesout waiting for an ip and same thing, no ping outside of
localhost, as expected.
Then I decided to see if it the card was working, So I tried to iwlist
wlan0 scan, it returned the expected results. It see's the multiple
AP's in my area. The card seems fine.
That got me to thinking, maybe I should downgrade the kernel and see
if it works, as soon as i rebooted into .29 kernel release the
authentication to the AP went through and i could ping the gw, other
networked computers etc.
There is clearly a problem with the .30 release of ath5k module using
the atheros chipset AR5212. I would be glad to offer up as much
information as I can, but I don't have the slightest on how to debug
this issue? Any help on that issue is much appreciated. Where can I
file the appropriate bug and what information do I need to post from a
technical standpoint. I am rather competent with linux and the command
line so if i can be of some use researching this bug please let me
know what I can do to help
I am also using the ath9k module on my desktop pc with an atheros
AR5008 and the .30 kernel release and everything works as expected.
this problem seems specific to the ath5k module.
^ permalink raw reply
* Re: [PATCH 4/5] Introduce separate HOST and TARGET compilation steps.
From: Pavel Roskin @ 2009-06-30 22:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Luis R. Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <1246396772.13176.264.camel@jdl-desktop>
On Tue, 2009-06-30 at 16:19 -0500, Jon Loeliger wrote:
> +TARGET_CFLAGS += -Wall -g
That's a misleading name. There is nothing wrong with using CFLAGS for
compilation.
"target" normally refers to the system for which the program being
compiled would create or manipulate binaries. CRDA doesn't manipulate
system-dependent binaries. It's not a compiler or an assembler. It
works with a system-independent database.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Announcing ConnMan.net
From: Thomas Fjellstrom @ 2009-06-30 22:01 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4A438C0F.7090907@draigBrady.com>
On Thu June 25 2009, Pádraig Brady wrote:
> Marcel Holtmann wrote:
> > Intel and Nokia are pleased to jointly launch the ConnMan project, an
> > open source project to accelerate and expand development of Internet
> > connection management for Linux Devices. ConnMan will be utilized as a
> > technology within Moblin and Maemo. Connman.net is now the place to
> > bring developers together who are interested in furthering the
> > development of Internet connection management within Linux. Review the
> > source code for more information. ConnMan is licensed under GPLv2, and
> > provides a daemon for managing Internet connections within Linux
> > devices. ConnMan is a fully modular system that can be extended, through
> > plugins, to support all kinds of wired or wireless technologies.
> > Configuration methods, like DHCP and domain name resolving, are
> > implemented using plug-ins as well. The plug-in approach allows for easy
> > adaption and modification for various use cases. Nokia and Intel will
> > jointly maintain the ConnMan project. We'd like to invite all developers
> > to join the connman.net effort and community.
> >
> > Marcel Holtmann, Intel Open Source Technology Center
> > Jukka Rissanen, Nokia Devices, Maemo Software
>
> I was wondering how this related to networkmanager.
> Dan Williams just posted some comparisons:
> http://blogs.gnome.org/dcbw/2009/06/25/networkmanager-and-connman/
It will probably work better more often on more systems. At least that's what
I'm hoping. NWM refuses to work on my laptop at all (and its a thinkpad, with
a normal wifi card).
> cheers,
> Pádraig.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thomas Fjellstrom
tfjellstrom@shaw.ca
^ permalink raw reply
* Re: [PATCH] Add prism 2/3 usb adaptor firmware for use with staging/wlan-ng driver.
From: Luis R. Rodriguez @ 2009-06-30 21:58 UTC (permalink / raw)
To: Karl Relton; +Cc: dwmw2, linux-wireless
In-Reply-To: <1246396179.4949.76.camel@localhost>
On Tue, Jun 30, 2009 at 2:09 PM, Karl
Relton<karllinuxtest.relton@ntlworld.com> wrote:
> On Tue, 2009-06-30 at 12:17 -0700, Luis R. Rodriguez wrote:
>> On Tue, Jun 30, 2009 at 12:05 PM, Karl
>> Relton<karllinuxtest.relton@ntlworld.com> wrote:
>> > Signed-Off-By: Karl Relton
>> > Signed-Off-By: Mark S. Mathews
>>
>> The commit log is empty. Where is this driver? Is it in staging at
>> least? If so does this get users of the driver a usable firmware? What
>> is the future of the driver BTW?
>>
>
> Oops - put text in wrong part of patch documentation. I can move this up
> to the 'commit log' part.
>
> The driver is under 'staging' - maintained by Greg Koah-Hartman
>
> The firmware blob in 'srec' format for prism 2/3 usb adaptors.
> The driver will read the srec file using a standard request_firmware()
> call, and will convert it into the appropriate binary format and upload to
> the adaptor. Note the processing is left to the driver (rather than
> pre-compiling) because the driver needs to insert runtime data obtained from
> the adaptor into the blob. The appropriate insertion locations are conveyed
> by the srec format.
Why all the srec->binary conversion? Doesn't this waste space on
people's firmware directories?
Luis
^ permalink raw reply
* Re: iwlagn: possible regressions from 2.6.29 in 2.6.30
From: Paul Collins @ 2009-06-30 21:53 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1246378651.17896.523.camel@rc-desk>
reinette chatre <reinette.chatre@intel.com> writes:
> On Mon, 2009-06-29 at 22:30 -0700, Paul Collins wrote:
>> Two things I liked about iwlagn in 2.6.29 no longer happen with 2.6.30:
>>
>> 1. reassociation following resume from suspend-to-ram
>> 2. transmission of packets > 250 bytes following resume from suspend-to-ram
>>
>> I can script around the first problem just by doing "iwconfig wlan0 ap
>> auto" on resume, but the second problem requires me to ifdown/ifup wlan0
>> before I can usefully use my network again, so fixing the first problem
>> doesn't get me very far.
>
> For reliable reassociation you need to use a userspace application like
> wpa_supplicant.
I'm using WEP here, though. And, as I mentioned, 2.6.29 did seem to
reassociate every time by itself, but maybe I just got lucky.
>> When I say "packets > 250 bytes" I mean 250-byte packets as claimed by
>> "ping -s 222 mygateway":
>>
>> PING cornelius.lan (10.2.4.1) 222(250) bytes of data.
>>
>> The above will work, but "ping -s 223 cornelius" yields no replies.
>
> Are you saying this works before suspend, but not after resume? What do
> you usually do to get this working again?
Yes, normally it works great; I can ping with packet sizes up to the
MTU. However, after suspend/resume and reassociation, "ping -s 223" or
greater does not work. I get replies with "-s 222" or less,
i.e. packets of 250 bytes or less.
To get it working again I do "ifdown wlan0" followed by "ifup wlan0",
which does the equivalent of "ip set link wlan0 down/up" and applying
the network configuration.
I will give the patch a shot when I get home.
Regards,
Paul
^ permalink raw reply
* [PATCH 5/5] Unbury Makefile-meta config definitions.
From: Jon Loeliger @ 2009-06-30 21:19 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless@vger.kernel.org
Rather than having them buried in the middle of the Makefile,
relocate the "quiet/not-quiet" options, MKDIR and INSTALL definitions
to the top of the file.
Signed-off-by: Jon Loeliger <jdl@bigfootnetworks.com>
---
Makefile | 23 ++++++++++++-----------
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index b755b67..9f9ae01 100644
--- a/Makefile
+++ b/Makefile
@@ -25,6 +25,18 @@ UDEV_RULE_DIR?=/lib/udev/rules.d/
PUBKEY_DIR?=pubkeys
+MKDIR ?= mkdir -p
+INSTALL ?= install
+
+
+ifeq ($(V),1)
+ Q=
+ NQ=@true
+else
+ Q=@
+ NQ=@echo
+endif
+
#
# Determine what target and host libraries and executables
# need to be built as that will determine what libraries will
@@ -236,17 +248,6 @@ verify: $(REG_BIN) host/regdbdump
$(Q)./host/regdbdump $(REG_BIN) >/dev/null
-MKDIR ?= mkdir -p
-INSTALL ?= install
-
-ifeq ($(V),1)
-Q=
-NQ=@true
-else
-Q=@
-NQ=@echo
-endif
-
$(REG_BIN):
$(NQ) ' EXIST ' $(REG_BIN)
$(NQ)
--
1.6.3.GIT
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox