* [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
* 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
* Re: [PATCH V2] b43: 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: <4a4ada70.t85pybsO8xH4owyV%Larry.Finger@lwfinger.net>
On Wednesday 01 July 2009 05:39:28 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
> ---
>
> 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,
> };
>
>
>
--
Greetings, Michael.
^ permalink raw reply
* 4965AGN loses connection on Custom wireless event
From: Jan Willies @ 2009-07-01 13:04 UTC (permalink / raw)
To: linux-wireless
Hello list,
I have a strange problem with an EAP-Network here. I can associate just
fine, but approx 1 min after the _initial_ connection completed the
network hangs. Though all the tools say I'm still connected (nm-applet,
iwconfig) I can't ping anything. I have to re-new the connection with
nm-applet and after that it works again (and longer!).
1. boot notebook and associate with wifi
2. wait 1 min -> hang
3. re-establish connection with nm-applet
4. after that it never hangs again (mostly)
You can find the log here: http://jan.willies.info/wpa_supplicant.log
Dan Williams says the interesting line is 1242720593.722277: "the driver
sends an association event *after* it's completed association, which the
supplicant interprets as a restart of the authentication process".
This is a Thinkpad X300 with Fedora 11 (iwlagn-1.3.27kds and
wpa_supplicant-0.6.8)
regards,
- jan
^ permalink raw reply
* Multiple BSSID status.
From: Kirill Berezin @ 2009-07-01 13:35 UTC (permalink / raw)
To: linux-wireless
Hie ALL!
I would like to know a currents status of multiple BSSID support for
atheros and broadcom chips. I found parts responsible for for mac group
handling in ath5k/9k drivers.
And the second question is what part of a system is responsible for
sending beacons with different SSID (driver or a higher level program,
say hostapd)?
I am trying to configure openwrt based wireless router (I have an asus
wl-500g deluxe) with multiple SSID, each with own BSSID and VLAN. It
looks like current version of hostapd supports multiple BSSID with
hiddent SSID, but it fails to UP interfaces for mac80211 (br43).
Kirill.
--
Кирилл Березин <kyb22@rol.ru>
Старший инженер-программист
Группа развития ISP систем, Совинтел
Группа Компаний ВымпелКом
^ permalink raw reply
* Re: 4965AGN loses connection on Custom wireless event
From: Dan Williams @ 2009-07-01 14:29 UTC (permalink / raw)
To: Jan Willies; +Cc: linux-wireless
In-Reply-To: <4A4B5EC8.8060804@willies.info>
On Wed, 2009-07-01 at 15:04 +0200, Jan Willies wrote:
> Hello list,
>
> I have a strange problem with an EAP-Network here. I can associate just
> fine, but approx 1 min after the _initial_ connection completed the
> network hangs. Though all the tools say I'm still connected (nm-applet,
> iwconfig) I can't ping anything. I have to re-new the connection with
> nm-applet and after that it works again (and longer!).
>
> 1. boot notebook and associate with wifi
> 2. wait 1 min -> hang
> 3. re-establish connection with nm-applet
> 4. after that it never hangs again (mostly)
1242720535.735207 - initial connection
1242720593.722277 - random assoc-info event
1242720593.744343 - WEXT assoc event for the AP you're already on
1242720593.745312 - supplicant decides to reauth with EAP
1242720603.745888 - supplicant-initiated reauth times out
So yeah, there's something going wrong here in the supplicant's handling
of a spurious association event sent from the driver.
Jouni, how should the supplicant handle a WEXT assoc event for the AP
that's already associated with? That seems to be what's going on here;
the card is coming back from a scan and emitting an assoc event (not
sure why) and that's making the supplicant (wrongly IMHO) try to reauth
at the EAP level for some reason.
Dan
> You can find the log here: http://jan.willies.info/wpa_supplicant.log
>
> Dan Williams says the interesting line is 1242720593.722277: "the driver
> sends an association event *after* it's completed association, which the
> supplicant interprets as a restart of the authentication process".
>
> This is a Thinkpad X300 with Fedora 11 (iwlagn-1.3.27kds and
> wpa_supplicant-0.6.8)
>
>
> regards,
>
> - jan
>
> --
> 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
^ permalink raw reply
* Re: [PATCH] rt2x00: use wiphy rfkill interface
From: Marcel Holtmann @ 2009-07-01 15:05 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: John Linville, users, linux-wireless
In-Reply-To: <200907011517.35638.IvDoorn@gmail.com>
Hi Ivo,
> 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.
as I mentioned in Berlin last week, I think this is the right way of
doing this. So ACK.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix aggregation limit
From: Marcel Holtmann @ 2009-07-01 15:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Reinette Chatre, linux-wireless
In-Reply-To: <1246453079.4131.19.camel@johannes.local>
Hi Johannes,
> 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)
why are you switching of hex now? Just putting (63) in there is not
enough?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix aggregation limit
From: Johannes Berg @ 2009-07-01 15:09 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: John Linville, Reinette Chatre, linux-wireless
In-Reply-To: <1246460817.12994.153.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On Wed, 2009-07-01 at 08:06 -0700, Marcel Holtmann wrote:
> Hi Johannes,
>
> > 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)
>
> why are you switching of hex now? Just putting (63) in there is not
> enough?
It would be, obviously, but the doc says 0x3f.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH V2] ssb: Add support for 4318E
From: Larry Finger @ 2009-07-01 15:28 UTC (permalink / raw)
To: John W Linville; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <200907011517.34061.mb@bu3sch.de>
Michael Buesch wrote:
> 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
>
Cc: Stable <stable@vger.kernel.org>
John,
I forgot the above line in both the b43 and ssb patches.
Larry
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix aggregation limit
From: Luciano Coelho @ 2009-07-01 15:52 UTC (permalink / raw)
To: ext Johannes Berg
Cc: Marcel Holtmann, John Linville, Reinette Chatre, linux-wireless
In-Reply-To: <1246460944.8154.0.camel@johannes.local>
ext Johannes Berg wrote:
> On Wed, 2009-07-01 at 08:06 -0700, Marcel Holtmann wrote:
>
>> Hi Johannes,
>>
>>
>>> 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)
>>>
>> why are you switching of hex now? Just putting (63) in there is not
>> enough?
>>
>
> It would be, obviously, but the doc says 0x3f.
>
I think it would be nicer to have (63) or otherwise convert all the
macros to use the 0x format. Does the spec use 0x1f for the default
value, for instance, instead of (31)?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [2.6.31-rc1] iwlagn (4965): regression when hardware rf switch is used
From: Frans Pop @ 2009-07-01 15:58 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org, Netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <1246383858.17896.527.camel@rc-desk>
On Tuesday 30 June 2009, reinette chatre wrote:
> Subject: [PATCH] iwlagn: do not send key clear commands when rfkill
> enabled
>
> Do all key clearing except sending sommands to device when rfkill
> enabled. When rfkill enabled the interface is brought down and will
> be brought back up correctly after rfkill is enabled again.
>
> Same change is not needed for iwl3945 as it ignores return code when
> sending key clearing command to device.
With this patch things look a lot cleaner:
[enable hardware rf kill switch]
iwlagn 0000:10:00.0: RF_KILL bit toggled to disable radio.
wlan0: deauthenticating by local choice (reason=3)
usb 3-1: USB disconnect, address 2
[disable hardware rf kill switch]
iwlagn 0000:10:00.0: RF_KILL bit toggled to enable radio.
usb 3-1: new full speed USB device using uhci_hcd and address 3
usb 3-1: configuration #1 chosen from 1 choice
[ifdown wlan0]
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ifup wlan0]
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: authenticate with AP 00:14:c1:38:e5:15
wlan0: authenticated
wlan0: associate with AP 00:14:c1:38:e5:15
wlan0: RX AssocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present
One thing I do not quite get is why both ifdown and ifup result in leds
getting registered. It does not happen when I do a "normal" ifdown (when
the wireless interface is up and rfkill is not enabled).
I could understand the leds being registered immediately after I disable
the rf kill switch, but don't understand why it gets postponed until I do
ifdown. That makes it seem as if the change in RF_KILL only gets
processed halfway through with the registering of leds left dangling.
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Reported-by: Frans Pop <elendil@planet.nl>
Tested-by: Frans Pop <elendil@planet.nl>
> --- a/drivers/net/wireless/iwlwifi/iwl-agn.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
> @@ -960,7 +960,7 @@ static void iwl_irq_tasklet_legacy(struct iwl_priv
> *priv) CSR_GP_CNTRL_REG_FLAG_HW_RF_KILL_SW))
> hw_rf_kill = 1;
>
> - IWL_DEBUG_RF_KILL(priv, "RF_KILL bit toggled to %s.\n",
> + IWL_WARN(priv, "RF_KILL bit toggled to %s.\n",
> hw_rf_kill ? "disable radio" : "enable radio");
>
> priv->isr_stats.rfkill++;
> @@ -1133,7 +1133,7 @@ static void iwl_irq_tasklet(struct iwl_priv
> *priv) CSR_GP_CNTRL_REG_FLAG_HW_RF_KILL_SW))
> hw_rf_kill = 1;
>
> - IWL_DEBUG_RF_KILL(priv, "RF_KILL bit toggled to %s.\n",
> + IWL_WARN(priv, "RF_KILL bit toggled to %s.\n",
> hw_rf_kill ? "disable radio" : "enable radio");
If these two messages get promoted to regular user messages, maybe they
could be made a bit less technical? I doubt "RF_KILL bit toggled" is
going to mean all that much to most users.
Thanks,
FJP
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix aggregation limit
From: Marcel Holtmann @ 2009-07-01 16:02 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Johannes Berg, John Linville, Reinette Chatre, linux-wireless
In-Reply-To: <4A4B862C.7080709@nokia.com>
Hi Johannes,
> >>> 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)
> >>>
> >> why are you switching of hex now? Just putting (63) in there is not
> >> enough?
> >>
> >
> > It would be, obviously, but the doc says 0x3f.
> >
>
> I think it would be nicer to have (63) or otherwise convert all the
> macros to use the 0x format. Does the spec use 0x1f for the default
> value, for instance, instead of (31)?
I would agree. Use (31) and let the commit message explain it. Not that
it is really that important.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Add prism 2/3 usb adaptor firmware for use with staging/wlan-ng driver.
From: Karl Relton @ 2009-07-01 16:16 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: dwmw2, linux-wireless
In-Reply-To: <43e72e890906301458y197c5411yfb93ea0089ed49f3@mail.gmail.com>
On Tue, 2009-06-30 at 14:58 -0700, Luis R. Rodriguez wrote:
> 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?
>
Yes, technically it does. The srec file is ~185KB, a binary image would
be ~64KB.
The reason it was left is that the driver has to do some runtime
plugging of data into the image, so pre-compilation would have meant
inventing both a compiler tool and an intermediate format for the driver
to read and process. Putting all the srec processing in the driver was
more expedient (just meant porting existing userspace code into driver
space).
Karl
^ permalink raw reply
* Compiling wpa_supplicant?
From: Jon Loeliger @ 2009-07-01 16:50 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Folks,
Has hostapd's wpa_supplicant code been brought up to a
consistent standard with the current libnl? In particular,
I'm trying to compile wpa_supplicant to use driver_nl80211,
but it is failing due to the use of the obsolete 'struct nl_handle'
in src/driver/driver_nl80211.c, line 131 or so.
I am using:
$ git remote -v
origin git://w1.fi/srv/git/hostap-06.git
$ git rev-parse HEAD
fa4e296f542af01da135d997358d6d45a32dd59e
and:
$ git remote -v
origin git://git.kernel.org/pub/scm/libs/netlink/libnl.git
$ git rev-parse HEAD
ef8ba32e0ca7ac7bbbaf87f6fd7b197af18aed25
In libnl, I see this commit:
commit b624b9ed936f4c23bc4f30d8dce34da49775dd15
Author: Thomas Graf <tgr@plip.localdomain>
Date: Wed Dec 10 18:02:25 2008 +0100
Remove obsoleted struct nl_handle definition
Is there a version of hostapd/wpa_suppliant that is more
up-to-date WRT libnl-2.0? Or should I just use the wext
driver for now?
Thanks,
jdl
^ permalink raw reply
* Re: [ath9k-devel] monitor mode parametars
From: Luis R. Rodriguez @ 2009-07-01 16:58 UTC (permalink / raw)
To: Vania Toperich; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <4C7973C2-BAB7-4BE3-AE88-1D59B03E6447@3folded.nl>
On Wed, Jul 1, 2009 at 8:05 AM, Vania Toperich<vaniat@3folded.nl> wrote:
> Hi,
>
> I am wondering how to configure monitor mode parameters for ath9k,
> specifically if N is using channel bonding and which one, lower or
> higher.
>
> Thanks for help.
I haven't tried this myself with monitor but it should work using iw:
iw dev <devname> set freq <freq> [HT20|HT40+|HT40-]
iw phy <phyname> set freq <freq> [HT20|HT40+|HT40-]
When done please help expand the documentation on the iw wiki:
http://wireless.kernel.org/en/users/Documentation/iw
Note that not all channels will be usable with HT40- or HT40+. If the
channel is disabled then you won't be able to use HT40. Then on
certain band edges you won't be able to use an extension channel
towards the end. This is obvious but in case you become confused for
any mac80211 driver you can specifically check the ht40 allow map
through debugfs.
For example, I get:
mcgrof@pogo ~ $ sudo mount -t debugfs debugfs /sys/kernel/debug/
mcgrof@pogo ~ $ cat /sys/kernel/debug/ieee80211/phy0/ht40allow_map
2412 HT40 +
2417 HT40 +
2422 HT40 +
2427 HT40 +
2432 HT40 -+
2437 HT40 -+
2442 HT40 -+
2447 HT40 -
2452 HT40 -
2457 HT40 -
2462 HT40 -
2467 Disabled
2472 Disabled
2484 Disabled
This stuff went in through debugfs and not through a channel flag as
Johannes wants to replaces this stuff later so we preferred to not add
it as exported userspace API, so you can only count on this being
there for the meantime.
Luis
^ permalink raw reply
* Re: [PATCH] Add prism 2/3 usb adaptor firmware for use with staging/wlan-ng driver.
From: Luis R. Rodriguez @ 2009-07-01 17:14 UTC (permalink / raw)
To: Karl Relton; +Cc: dwmw2, linux-wireless
In-Reply-To: <1246464991.4331.18.camel@localhost>
On Wed, Jul 1, 2009 at 9:16 AM, Karl
Relton<karllinuxtest.relton@ntlworld.com> wrote:
> On Tue, 2009-06-30 at 14:58 -0700, Luis R. Rodriguez wrote:
>> 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?
>>
> Yes, technically it does. The srec file is ~185KB, a binary image would
> be ~64KB.
>
> The reason it was left is that the driver has to do some runtime
> plugging of data into the image
Can you elaborate on this a little. Does the driver currently take the
srec file, append/prepend some data onto it and then run it on the
target CPU?
> , so pre-compilation would have meant
> inventing both a compiler tool and an intermediate format for the driver
> to read and process.
The srec->binary conversion just needs to be done once, and not sure
what the "extra" stuff is that you mention is required, but if its
always the same can't that just be put into a final binary file?
> Putting all the srec processing in the driver was
> more expedient (just meant porting existing userspace code into driver
> space).
At the cost of a firmware file size 3 times the size of the binary file.
Luis
^ permalink raw reply
* Re: [PATCH] Add prism 2/3 usb adaptor firmware for use with staging/wlan-ng driver.
From: Pavel Roskin @ 2009-07-01 17:22 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Karl Relton, dwmw2, linux-wireless
In-Reply-To: <43e72e890907011014v300bcf64u3c7b259173d93588@mail.gmail.com>
On Wed, 2009-07-01 at 10:14 -0700, Luis R. Rodriguez wrote:
> Can you elaborate on this a little. Does the driver currently take the
> srec file, append/prepend some data onto it and then run it on the
> target CPU?
Some data in the srec file is replaced by the data read from the card
(so called plug data area, or PDA). "Plugging" refers to that process.
> > , so pre-compilation would have meant
> > inventing both a compiler tool and an intermediate format for the driver
> > to read and process.
>
> The srec->binary conversion just needs to be done once, and not sure
> what the "extra" stuff is that you mention is required, but if its
> always the same can't that just be put into a final binary file?
We can use the same format as Spectrum firmware used in spectrum_cs, and
reuse its parser/plugger. Spectrum and Prism chipsets are related and
use the same idea of plugging, but Prism firmware is distributed as srec
files, whereas Spectrum firmware is cut from binary drivers as a binary.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: mac80211 and broadcast frames
From: Luis R. Rodriguez @ 2009-07-01 17:33 UTC (permalink / raw)
To: Valentin Manea; +Cc: linux-wireless
In-Reply-To: <4A4B056B.9000602@mrs.ro>
On Tue, Jun 30, 2009 at 11:42 PM, Valentin Manea<linux-wireless@mrs.ro> wrote:
>
>
> 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.
Well it would if you had had other nodes sending data on the same BSS,
it would mean more RX'd frames that are passed up on your host. This
would just be specific to your BSS as you would be using promiscuous
mode and not a real monitor mode, so just wanted to point that out.
> 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.
OK then the issue is further down and not related to the driver or
wireless stack it seems.
> 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.
More confirmation things are peachy on the linux-wireless front and
that this is a userspace issue somewhere.
> Any ideas where I could look? it just gets stranger and stranger.
If you see the frames do get to the host then definitely not on the
drivers / stack.
Luis
^ permalink raw reply
* Re: [Fwd: Re: [PATCH 4/5] Introduce separate HOST and TARGET compilation steps.]
From: Luis R. Rodriguez @ 2009-07-01 17:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Pavel Roskin, linux-wireless
In-Reply-To: <1246470361.11632.23.camel@jdl-desktop>
On Wed, Jul 1, 2009 at 10:46 AM, Jon Loeliger<jdl@bigfootnetworks.com> wrote:
> On Wed, 2009-07-01 at 10:35 -0700, Luis R. Rodriguez wrote:
>> On Wed, Jul 1, 2009 at 10:30 AM, Jon Loeliger<jdl@bigfootnetworks.com> wrote:
>>
>> > Do you agree or disagree with me when I say that the regdbdump program
>> > might need to be compiled twice -- once for the host and once for the
>> > target?
>>
>> Why?
>
> The existing binary regulatory DB binary is verified on the host
> using these rules. (This is from my version of the makefile, but
> they are there in the original too.):
>
> all: host target $(REG_BIN) $(BUILD_ALL) verify
>
> verify: $(REG_BIN) host/regdbdump
> $(NQ) ' CHK $(REG_BIN)'
> $(Q)./host/regdbdump $(REG_BIN) >/dev/null
>
> That is, as part of the host build process, the regdbdump tool
> is run *on the host*.
This helps to understand a little better some of your intentions, may
be good to mention this as part of your patches. Hm, interesting... I
suppose we don't want to just disable this check then.
> Ultimately, the regdbdump utility may *also* be needed or
> wanted on the target too.
ACK.
Luis
^ permalink raw reply
* Re: [PATCH] Add prism 2/3 usb adaptor firmware for use with staging/wlan-ng driver.
From: Dave @ 2009-07-01 17:51 UTC (permalink / raw)
To: Karl Relton; +Cc: Luis R. Rodriguez, dwmw2, linux-wireless
In-Reply-To: <1246464991.4331.18.camel@localhost>
Karl Relton wrote:
> On Tue, 2009-06-30 at 14:58 -0700, Luis R. Rodriguez wrote:
>> Why all the srec->binary conversion? Doesn't this waste space on
>> people's firmware directories?
>>
> Yes, technically it does. The srec file is ~185KB, a binary image would
> be ~64KB.
>
> The reason it was left is that the driver has to do some runtime
> plugging of data into the image, so pre-compilation would have meant
> inventing both a compiler tool and an intermediate format for the driver
> to read and process. Putting all the srec processing in the driver was
> more expedient (just meant porting existing userspace code into driver
> space).
I can't find the wlan_ng request_firmware call in my wireless-testing
tree (week or so old). Is that new?
>From what I can tell the wlan_ng, hostap and orinoco drivers all program
firmware that has the same basic format. Hostap doesn't use
request_firmware, and gives userspace the control over the write
sequence. orinoco places a very simple header in front of the binary image.
Do we really want to add srec processing to the driver (or even the kernel)?
It would be nice if the FW image was in the same format for orinoco and
wlan_ng, as the prism firmware ought to work on non-USB prism cards, and
we should be able to make orinoco use it.
Regards,
Dave.
^ permalink raw reply
* Re: [PATCH] Add prism 2/3 usb adaptor firmware for use with staging/wlan-ng driver.
From: Luis R. Rodriguez @ 2009-07-01 18:12 UTC (permalink / raw)
To: Dave; +Cc: Karl Relton, dwmw2, linux-wireless
In-Reply-To: <4A4BA21F.1070101@gmail.com>
On Wed, Jul 1, 2009 at 10:51 AM, Dave<kilroyd@googlemail.com> wrote:
> Karl Relton wrote:
>> On Tue, 2009-06-30 at 14:58 -0700, Luis R. Rodriguez wrote:
>>> Why all the srec->binary conversion? Doesn't this waste space on
>>> people's firmware directories?
>>>
>> Yes, technically it does. The srec file is ~185KB, a binary image would
>> be ~64KB.
>>
>> The reason it was left is that the driver has to do some runtime
>> plugging of data into the image, so pre-compilation would have meant
>> inventing both a compiler tool and an intermediate format for the driver
>> to read and process. Putting all the srec processing in the driver was
>> more expedient (just meant porting existing userspace code into driver
>> space).
>
> I can't find the wlan_ng request_firmware call in my wireless-testing
> tree (week or so old). Is that new?
>
> From what I can tell the wlan_ng, hostap and orinoco drivers all program
> firmware that has the same basic format. Hostap doesn't use
> request_firmware, and gives userspace the control over the write
> sequence. orinoco places a very simple header in front of the binary image.
>
> Do we really want to add srec processing to the driver (or even the kernel)?
>
> It would be nice if the FW image was in the same format for orinoco and
> wlan_ng, as the prism firmware ought to work on non-USB prism cards, and
> we should be able to make orinoco use it.
I never got the wlan_ng stuff.. Anyway now it is under
drivers/staging/wlan-ng. I was under the impression it targeted some
devices not covered by hostapd or orinoco, is that no the case?
Luis
^ permalink raw reply
* Re: [PATCH V2] ssb: Add support for 4318E
From: Michael Buesch @ 2009-07-01 18:18 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: Larry Finger, John W Linville, linux-wireless
In-Reply-To: <4A4B80AB.6090307@lwfinger.net>
On Wednesday 01 July 2009 17:28:43 Larry Finger wrote:
> Michael Buesch wrote:
> > 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
> >
>
> Cc: Stable <stable@vger.kernel.org>
I do not think these patches are subject to -stable.
--
Greetings, Michael.
^ permalink raw reply
* Wireless summit at FUDCon in Berlin -- thanks!
From: John W. Linville @ 2009-07-01 18:18 UTC (permalink / raw)
To: fedora-devel-list, linux-wireless
Cc: Paul Frields, Max Spevack, Peter Martuccelli
On 26-27 June 2009 a Linux wireless mini-summit was hosted by the
Fedora project as part of their FUDCon event in Berlin, Germany.
This event was attended by well over a dozen upstream Linux developers
representing various kernel wireless LAN drivers, kernel wireless
LAN infrastructure components, and related userland applications.
Attendees also represented hardware vendors, Fedora and other Linux
distributions, and other members of the overall community.
Discussions covered a number of development issues, including
status updates related to recent developments and preliminary
design discussions for future API enhancements. In particular,
the face-to-face involvement of hardware vendors revealed the need
for a "testing mode" extension to the new cfg80211 API for wireless
LAN configuration. One of the attendees is a voting member of the
IEEE802.11 standards body, and he gave a very useful overview of
current standards activities and their likely impacts on Linux over
the next few years.
On the BarCamp day of FUDCon some of the wireless attendees provided
content for two one-hour slots. One of these was an introduction
for would-be developers to understand the basics of the wireless LAN
APIs in the kernel. The other was split between a short overview
of some of the powersaving improvements happening for wireless LANs
and an interesting presentation on Freifunk, a community-based free
wireless LAN deployment in Berlin. The Freifunk presentation also
touched upon some similar projects ongoing throughout the world.
Given my position as the Linux kernel wireless LAN maintainer, I
found this meeting to be extremely valuable. Developers are far
more productive when they know each other and have some personal
connections. Further, face-to-face meetings enable fast-paced
discussions that would be difficult or impossible to complete in an
electronic (i.e. email, IRC, etc) environment. Keeping these people
working well together is the key to further improvements and successful
maintenance in RHEL, Fedora, and the rest of Linux community.
On behalf of the upstream Linux wireless LAN developer community,
I would like to express our gratitude to the Fedora project for doing
its part to enable our continued progress.
Of course, I also want to thank the wireless LAN developers (and
those who may have sponsored their travel) for coming to the event.
You guys are the ones who make all these good things happen. The fact
that you are all friendly and cooperative makes things even better!
I enjoyed seeing all of you in Berlin, both the ones I had already met
and the new faces as well. I look forward to our next opportunity to
meet face-to-face, and I anticipate lots of productive email between
now and then!
Thanks!
John
--
John W. Linville Linux should be at the core
linville@redhat.com of your literate lifestyle.
^ permalink raw reply
* Re: [Stable-review] [patch 000/108] 2.6.30-stable review
From: Luis R. Rodriguez @ 2009-07-01 18:24 UTC (permalink / raw)
To: Greg KH, linux-wireless, John W. Linville
Cc: linux-kernel, stable, akpm, torvalds, stable-review, alan,
ath9k-devel, ath5k-devel
In-Reply-To: <20090701002838.GA7100@kroah.com>
On Tue, Jun 30, 2009 at 5:28 PM, Greg KH<gregkh@suse.de> wrote:
> This is the start of the stable review cycle for the 2.6.30.1 release.
> There are 108 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let us know. If anyone is a maintainer of the proper subsystem, and
> wants to add a Signed-off-by: line to the patch, please respond with it.
> drivers/net/wireless/ath5k/base.c | 7 ++
> drivers/net/wireless/ath9k/calib.c | 67 ++++++----------
> drivers/net/wireless/ath9k/main.c | 28 +++++---
> drivers/net/wireless/ath9k/pci.c | 18 +++++
> drivers/net/wireless/ath9k/regd.c | 2 +-
> drivers/net/wireless/ath9k/xmit.c | 5 +-
> net/mac80211/rc80211_minstrel.c | 2 +-
> net/wireless/nl80211.c | 26 +++++--
> net/wireless/reg.c | 10 ++-
Cc'ing linux-wireless.
14 of the 108 patches for 2.6.30.1 are for wireless. Here they are [1]:
[patch 062/108] mac80211: fix minstrel single-rate memory corruption
[patch 063/108] cfg80211: fix for duplicate userspace replies
[patch 064/108] cfg80211: cleanup return calls on nl80211_set_reg()
[patch 065/108] cfg80211: return immediately if num reg rules >
NL80211_MAX_SUPP_REG_RULES
[patch 066/108] cfg80211: fix in nl80211_set_reg()
[patch 067/108] ath9k: Fix bug when using a card with a busted EEPROM
[patch 068/108] ath9k: Fix bug in calibration initialization
[patch 069/108] ath9k: Fix bug in determining calibration support
[patch 070/108] ath9k: Fix bug in checking HT flag
[patch 071/108] ath9k: Fix bug in scan termination
[patch 072/108] ath9k: Fix memleak on TX DMA failure
[patch 073/108] ath9k: Initialize ANI timers
[patch 074/108] ath9k: Fix PCI FATAL interrupts by restoring
RETRY_TIMEOUT disabling
[patch 088/108] ath5k: avoid PCI FATAL interrupts by restoring
RETRY_TIMEOUT disabling
All these look good. I can think of one fix which didn't make it, the
wext netlink fix for event sending which leaks 4 bytes of
uninitialized data. It didn't make it to stable as Johannes noted its
been broken for ages. I actually don't agree that's a good argument to
not fix it in stable as it can be fixed with a one-liner but whatever,
for details see the tread [2].
Only funny thing I did notice was that the revert for the PCI fatal
stuff for ath5k was for PCI resume, whereas ath9k had it for both
probe and resume. I did check and reason for this was that the
original ath5k patch only removed the 0x41 0 write on resume.
If there are any other patches missed for 2.6.31.1 please send to
stable@kernel.org by following the guidelines on
Documentation/stable_kernel_rules.txt for them to be queued up for
review for 2.6.31.2.
[1] http://linux.kernel.org/mailman/private/stable-review/2009-July/thread.html
[2] http://thread.gmane.org/gmane.linux.kernel.wireless.general/34960
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