* [PATCH 3/4] iwlwifi: remove deprecated 6000 series adapters
From: Reinette Chatre @ 2009-07-31 21:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy, Reinette Chatre
In-Reply-To: <1249075689-8973-1-git-send-email-reinette.chatre@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Remove the support for deprecated devices. These devices are
engineering samples and no longer supported by the uCode.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-6000.c | 16 ----------------
drivers/net/wireless/iwlwifi/iwl-agn.c | 5 -----
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 -
3 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index 052a704..4450943 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -150,22 +150,6 @@ static struct iwl_ops iwl6000_ops = {
.utils = &iwl6000_hcmd_utils,
};
-struct iwl_cfg iwl6000_2ag_cfg = {
- .name = "6000 Series 2x2 AG",
- .fw_name_pre = IWL6000_FW_PRE,
- .ucode_api_max = IWL6000_UCODE_API_MAX,
- .ucode_api_min = IWL6000_UCODE_API_MIN,
- .sku = IWL_SKU_A|IWL_SKU_G,
- .ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
- .eeprom_ver = EEPROM_5000_EEPROM_VERSION,
- .eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
- .mod_params = &iwl50_mod_params,
- .valid_tx_ant = ANT_BC,
- .valid_rx_ant = ANT_BC,
- .need_pll_cfg = false,
- .pa_type = IWL_PA_SYSTEM,
-};
/*
* "h": Hybrid configuration, use both internal and external Power Amplifier
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index a54330b..467c861 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -3139,17 +3139,12 @@ static struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x423C, PCI_ANY_ID, iwl5150_agn_cfg)},
{IWL_PCI_DEVICE(0x423D, PCI_ANY_ID, iwl5150_agn_cfg)},
/* 6000/6050 Series */
- {IWL_PCI_DEVICE(0x0082, 0x1102, iwl6000_2ag_cfg)},
- {IWL_PCI_DEVICE(0x0085, 0x1112, iwl6000_2ag_cfg)},
- {IWL_PCI_DEVICE(0x0082, 0x1122, iwl6000_2ag_cfg)},
{IWL_PCI_DEVICE(0x008D, PCI_ANY_ID, iwl6000h_2agn_cfg)},
{IWL_PCI_DEVICE(0x008E, PCI_ANY_ID, iwl6000h_2agn_cfg)},
{IWL_PCI_DEVICE(0x422B, PCI_ANY_ID, iwl6000_3agn_cfg)},
{IWL_PCI_DEVICE(0x422C, PCI_ANY_ID, iwl6000i_2agn_cfg)},
{IWL_PCI_DEVICE(0x4238, PCI_ANY_ID, iwl6000_3agn_cfg)},
{IWL_PCI_DEVICE(0x4239, PCI_ANY_ID, iwl6000i_2agn_cfg)},
- {IWL_PCI_DEVICE(0x0082, PCI_ANY_ID, iwl6000h_2agn_cfg)},
- {IWL_PCI_DEVICE(0x0085, PCI_ANY_ID, iwl6000_3agn_cfg)},
{IWL_PCI_DEVICE(0x0086, PCI_ANY_ID, iwl6050_3agn_cfg)},
{IWL_PCI_DEVICE(0x0087, PCI_ANY_ID, iwl6050_2agn_cfg)},
{IWL_PCI_DEVICE(0x0088, PCI_ANY_ID, iwl6050_3agn_cfg)},
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 335a8f3..cab6255 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -56,7 +56,6 @@ extern struct iwl_cfg iwl5350_agn_cfg;
extern struct iwl_cfg iwl5100_bg_cfg;
extern struct iwl_cfg iwl5100_abg_cfg;
extern struct iwl_cfg iwl5150_agn_cfg;
-extern struct iwl_cfg iwl6000_2ag_cfg;
extern struct iwl_cfg iwl6000h_2agn_cfg;
extern struct iwl_cfg iwl6000i_2agn_cfg;
extern struct iwl_cfg iwl6000_3agn_cfg;
--
1.5.6.3
^ permalink raw reply related
* [PATCH 2/4] iwlwifi: Distinguish power amplifier for 6000 series
From: Reinette Chatre @ 2009-07-31 21:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy, Reinette Chatre
In-Reply-To: <1249075689-8973-1-git-send-email-reinette.chatre@intel.com>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
For 6x00 2x2 NIC, two types of Power Amplifier are available.
In order for uCode to apply correct tx power,
driver needs to program the CSR_GP_DRIVER_REG register and
let uCode know the type of PA.
If driver do not program CSR_GP_DRIVER_REG register (default to 0),
then it is uCode's decision for tx power
2x2 Hybrid card: use both internal and external PA
2x2 IPA(Internal Power Amplifier) card: internal PA only
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-1000.c | 14 ++++++++-
drivers/net/wireless/iwlwifi/iwl-5000.c | 8 +----
drivers/net/wireless/iwlwifi/iwl-6000.c | 50 +++++++++++++++++++++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn.c | 8 +++--
drivers/net/wireless/iwlwifi/iwl-core.h | 3 ++
drivers/net/wireless/iwlwifi/iwl-csr.h | 10 +++++-
drivers/net/wireless/iwlwifi/iwl-dev.h | 16 +++++++++-
7 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index 5f7c520..cf3fbc6 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -73,6 +73,18 @@ static void iwl1000_set_ct_threshold(struct iwl_priv *priv)
priv->hw_params.ct_kill_exit_threshold = CT_KILL_EXIT_THRESHOLD;
}
+/* NIC configuration for 1000 series */
+static void iwl1000_nic_config(struct iwl_priv *priv)
+{
+ iwl5000_nic_config(priv);
+
+ /* Setting digital SVR for 1000 card to 1.32V */
+ /* locking is acquired in iwl_set_bits_mask_prph() function */
+ iwl_set_bits_mask_prph(priv, APMG_DIGITAL_SVR_REG,
+ APMG_SVR_DIGITAL_VOLTAGE_1_32,
+ ~APMG_SVR_VOLTAGE_CONFIG_BIT_MSK);
+}
+
static struct iwl_lib_ops iwl1000_lib = {
.set_hw_params = iwl5000_hw_set_hw_params,
.txq_update_byte_cnt_tbl = iwl5000_txq_update_byte_cnt_tbl,
@@ -95,7 +107,7 @@ static struct iwl_lib_ops iwl1000_lib = {
.init = iwl5000_apm_init,
.reset = iwl5000_apm_reset,
.stop = iwl5000_apm_stop,
- .config = iwl5000_nic_config,
+ .config = iwl1000_nic_config,
.set_pwr_src = iwl_set_pwr_src,
},
.eeprom_ops = {
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index ddd64fe..87957c0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -198,6 +198,7 @@ out:
}
+/* NIC configuration for 5000 series and up */
void iwl5000_nic_config(struct iwl_priv *priv)
{
unsigned long flags;
@@ -239,18 +240,11 @@ void iwl5000_nic_config(struct iwl_priv *priv)
APMG_PS_CTRL_EARLY_PWR_OFF_RESET_DIS,
~APMG_PS_CTRL_EARLY_PWR_OFF_RESET_DIS);
- if ((priv->hw_rev & CSR_HW_REV_TYPE_MSK) == CSR_HW_REV_TYPE_1000) {
- /* Setting digital SVR for 1000 card to 1.32V */
- iwl_set_bits_mask_prph(priv, APMG_DIGITAL_SVR_REG,
- APMG_SVR_DIGITAL_VOLTAGE_1_32,
- ~APMG_SVR_VOLTAGE_CONFIG_BIT_MSK);
- }
spin_unlock_irqrestore(&priv->lock, flags);
}
-
/*
* EEPROM
*/
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index 59ff735..052a704 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -68,6 +68,24 @@ static void iwl6000_set_ct_threshold(struct iwl_priv *priv)
priv->hw_params.ct_kill_exit_threshold = CT_KILL_EXIT_THRESHOLD;
}
+/* NIC configuration for 6000 series */
+static void iwl6000_nic_config(struct iwl_priv *priv)
+{
+ iwl5000_nic_config(priv);
+
+ /* no locking required for register write */
+ if (priv->cfg->pa_type == IWL_PA_HYBRID) {
+ /* 2x2 hybrid phy type */
+ iwl_write32(priv, CSR_GP_DRIVER_REG,
+ CSR_GP_DRIVER_REG_BIT_RADIO_SKU_2x2_HYB);
+ } else if (priv->cfg->pa_type == IWL_PA_INTERNAL) {
+ /* 2x2 IPA phy type */
+ iwl_write32(priv, CSR_GP_DRIVER_REG,
+ CSR_GP_DRIVER_REG_BIT_RADIO_SKU_2x2_IPA);
+ }
+ /* else do nothing, uCode configured */
+}
+
static struct iwl_lib_ops iwl6000_lib = {
.set_hw_params = iwl5000_hw_set_hw_params,
.txq_update_byte_cnt_tbl = iwl5000_txq_update_byte_cnt_tbl,
@@ -90,7 +108,7 @@ static struct iwl_lib_ops iwl6000_lib = {
.init = iwl5000_apm_init,
.reset = iwl5000_apm_reset,
.stop = iwl5000_apm_stop,
- .config = iwl5000_nic_config,
+ .config = iwl6000_nic_config,
.set_pwr_src = iwl_set_pwr_src,
},
.eeprom_ops = {
@@ -146,9 +164,13 @@ struct iwl_cfg iwl6000_2ag_cfg = {
.valid_tx_ant = ANT_BC,
.valid_rx_ant = ANT_BC,
.need_pll_cfg = false,
+ .pa_type = IWL_PA_SYSTEM,
};
-struct iwl_cfg iwl6000_2agn_cfg = {
+/*
+ * "h": Hybrid configuration, use both internal and external Power Amplifier
+ */
+struct iwl_cfg iwl6000h_2agn_cfg = {
.name = "6000 Series 2x2 AGN",
.fw_name_pre = IWL6000_FW_PRE,
.ucode_api_max = IWL6000_UCODE_API_MAX,
@@ -162,6 +184,27 @@ struct iwl_cfg iwl6000_2agn_cfg = {
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_AB,
.need_pll_cfg = false,
+ .pa_type = IWL_PA_HYBRID,
+};
+
+/*
+ * "i": Internal configuration, use internal Power Amplifier
+ */
+struct iwl_cfg iwl6000i_2agn_cfg = {
+ .name = "6000 Series 2x2 AGN",
+ .fw_name_pre = IWL6000_FW_PRE,
+ .ucode_api_max = IWL6000_UCODE_API_MAX,
+ .ucode_api_min = IWL6000_UCODE_API_MIN,
+ .sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
+ .ops = &iwl6000_ops,
+ .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_ver = EEPROM_5000_EEPROM_VERSION,
+ .eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
+ .mod_params = &iwl50_mod_params,
+ .valid_tx_ant = ANT_BC,
+ .valid_rx_ant = ANT_BC,
+ .need_pll_cfg = false,
+ .pa_type = IWL_PA_INTERNAL,
};
struct iwl_cfg iwl6050_2agn_cfg = {
@@ -178,6 +221,7 @@ struct iwl_cfg iwl6050_2agn_cfg = {
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_AB,
.need_pll_cfg = false,
+ .pa_type = IWL_PA_SYSTEM,
};
struct iwl_cfg iwl6000_3agn_cfg = {
@@ -194,6 +238,7 @@ struct iwl_cfg iwl6000_3agn_cfg = {
.valid_tx_ant = ANT_ABC,
.valid_rx_ant = ANT_ABC,
.need_pll_cfg = false,
+ .pa_type = IWL_PA_SYSTEM,
};
struct iwl_cfg iwl6050_3agn_cfg = {
@@ -210,6 +255,7 @@ struct iwl_cfg iwl6050_3agn_cfg = {
.valid_tx_ant = ANT_ABC,
.valid_rx_ant = ANT_ABC,
.need_pll_cfg = false,
+ .pa_type = IWL_PA_SYSTEM,
};
MODULE_FIRMWARE(IWL6000_MODULE_FIRMWARE(IWL6000_UCODE_API_MAX));
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 4cb1a1b..a54330b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -3142,11 +3142,13 @@ static struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x0082, 0x1102, iwl6000_2ag_cfg)},
{IWL_PCI_DEVICE(0x0085, 0x1112, iwl6000_2ag_cfg)},
{IWL_PCI_DEVICE(0x0082, 0x1122, iwl6000_2ag_cfg)},
+ {IWL_PCI_DEVICE(0x008D, PCI_ANY_ID, iwl6000h_2agn_cfg)},
+ {IWL_PCI_DEVICE(0x008E, PCI_ANY_ID, iwl6000h_2agn_cfg)},
{IWL_PCI_DEVICE(0x422B, PCI_ANY_ID, iwl6000_3agn_cfg)},
- {IWL_PCI_DEVICE(0x422C, PCI_ANY_ID, iwl6000_2agn_cfg)},
+ {IWL_PCI_DEVICE(0x422C, PCI_ANY_ID, iwl6000i_2agn_cfg)},
{IWL_PCI_DEVICE(0x4238, PCI_ANY_ID, iwl6000_3agn_cfg)},
- {IWL_PCI_DEVICE(0x4239, PCI_ANY_ID, iwl6000_2agn_cfg)},
- {IWL_PCI_DEVICE(0x0082, PCI_ANY_ID, iwl6000_2agn_cfg)},
+ {IWL_PCI_DEVICE(0x4239, PCI_ANY_ID, iwl6000i_2agn_cfg)},
+ {IWL_PCI_DEVICE(0x0082, PCI_ANY_ID, iwl6000h_2agn_cfg)},
{IWL_PCI_DEVICE(0x0085, PCI_ANY_ID, iwl6000_3agn_cfg)},
{IWL_PCI_DEVICE(0x0086, PCI_ANY_ID, iwl6050_3agn_cfg)},
{IWL_PCI_DEVICE(0x0087, PCI_ANY_ID, iwl6050_2agn_cfg)},
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index febcf76..10ddcdd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -206,6 +206,7 @@ struct iwl_mod_params {
* filename is constructed as fw_name_pre<api>.ucode.
* @ucode_api_max: Highest version of uCode API supported by driver.
* @ucode_api_min: Lowest version of uCode API supported by driver.
+ * @pa_type: used by 6000 series only to identify the type of Power Amplifier
*
* We enable the driver to be backward compatible wrt API version. The
* driver specifies which APIs it supports (with @ucode_api_max being the
@@ -226,6 +227,7 @@ struct iwl_mod_params {
* iwl_hcmd_utils_ops etc. we accommodate different command structures
* and flows between hardware versions (4965/5000) as well as their API
* versions.
+ *
*/
struct iwl_cfg {
const char *name;
@@ -242,6 +244,7 @@ struct iwl_cfg {
u8 valid_rx_ant;
bool need_pll_cfg;
bool use_isr_legacy;
+ enum iwl_pa_type pa_type;
};
/***************************
diff --git a/drivers/net/wireless/iwlwifi/iwl-csr.h b/drivers/net/wireless/iwlwifi/iwl-csr.h
index f03dae1..06437d1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-csr.h
+++ b/drivers/net/wireless/iwlwifi/iwl-csr.h
@@ -91,7 +91,8 @@
#define CSR_EEPROM_GP (CSR_BASE+0x030)
#define CSR_OTP_GP_REG (CSR_BASE+0x034)
#define CSR_GIO_REG (CSR_BASE+0x03C)
-#define CSR_GP_UCODE (CSR_BASE+0x044)
+#define CSR_GP_UCODE_REG (CSR_BASE+0x048)
+#define CSR_GP_DRIVER_REG (CSR_BASE+0x050)
#define CSR_UCODE_DRV_GP1 (CSR_BASE+0x054)
#define CSR_UCODE_DRV_GP1_SET (CSR_BASE+0x058)
#define CSR_UCODE_DRV_GP1_CLR (CSR_BASE+0x05c)
@@ -245,6 +246,13 @@
#define CSR_UCODE_DRV_GP1_BIT_CMD_BLOCKED (0x00000004)
#define CSR_UCODE_DRV_GP1_REG_BIT_CT_KILL_EXIT (0x00000008)
+/* GP Driver */
+#define CSR_GP_DRIVER_REG_BIT_RADIO_SKU_MSK (0x00000003)
+#define CSR_GP_DRIVER_REG_BIT_RADIO_SKU_3x3_HYB (0x00000000)
+#define CSR_GP_DRIVER_REG_BIT_RADIO_SKU_2x2_HYB (0x00000001)
+#define CSR_GP_DRIVER_REG_BIT_RADIO_SKU_2x2_IPA (0x00000002)
+
+
/* GI Chicken Bits */
#define CSR_GIO_CHICKEN_BITS_REG_BIT_L1A_NO_L0S_RX (0x00800000)
#define CSR_GIO_CHICKEN_BITS_REG_BIT_DIS_L0S_EXIT_TIMER (0x20000000)
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 0ee3ad2..335a8f3 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -57,7 +57,8 @@ extern struct iwl_cfg iwl5100_bg_cfg;
extern struct iwl_cfg iwl5100_abg_cfg;
extern struct iwl_cfg iwl5150_agn_cfg;
extern struct iwl_cfg iwl6000_2ag_cfg;
-extern struct iwl_cfg iwl6000_2agn_cfg;
+extern struct iwl_cfg iwl6000h_2agn_cfg;
+extern struct iwl_cfg iwl6000i_2agn_cfg;
extern struct iwl_cfg iwl6000_3agn_cfg;
extern struct iwl_cfg iwl6050_2agn_cfg;
extern struct iwl_cfg iwl6050_3agn_cfg;
@@ -888,6 +889,19 @@ enum iwl_nvm_type {
NVM_DEVICE_TYPE_OTP,
};
+
+/**
+ * enum iwl_pa_type - Power Amplifier type
+ * @IWL_PA_SYSTEM: based on uCode configuration
+ * @IWL_PA_HYBRID: use both Internal and external PA
+ * @IWL_PA_INTERNAL: use Internal only
+ */
+enum iwl_pa_type {
+ IWL_PA_SYSTEM = 0,
+ IWL_PA_HYBRID = 1,
+ IWL_PA_INTERNAL = 2,
+};
+
/* interrupt statistics */
struct isr_statistics {
u32 hw;
--
1.5.6.3
^ permalink raw reply related
* [PATCH 0/4] iwlwifi driver updates 07/31/2009
From: Reinette Chatre @ 2009-07-31 21:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
We add support for hardware that can have different power amplifiers. The
rest is cleanup and one fix. The fix is to a problem introduced by a patch
that is not in 2.6.31 so this fix only targets wireless-testing.
[PATCH 1/4] iwlwifi: clear iwl_cmd_meta structure before use
[PATCH 2/4] iwlwifi: Distinguish power amplifier for 6000 series
[PATCH 3/4] iwlwifi: remove deprecated 6000 series adapters
[PATCH 4/4] iwlwifi: remove duplicated version info from sysfs
Thank you
Reinette
^ permalink raw reply
* [PATCH 1/4] iwlwifi: clear iwl_cmd_meta structure before use
From: Reinette Chatre @ 2009-07-31 21:28 UTC (permalink / raw)
To: linville
Cc: linux-wireless, ipw3945-devel, Daniel C Halperin, Reinette Chatre
In-Reply-To: <1249075689-8973-1-git-send-email-reinette.chatre@intel.com>
From: Daniel C Halperin <daniel.c.halperin@intel.com>
Resolve an issue in which out-dated fields in iwl_cmd_meta
could be used for later hardware commands.
Signed-off-by: Daniel C Halperin <daniel.c.halperin@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-tx.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 6bb9602..288b871 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -970,6 +970,7 @@ int iwl_enqueue_hcmd(struct iwl_priv *priv, struct iwl_host_cmd *cmd)
out_cmd = txq->cmd[idx];
out_meta = &txq->meta[idx];
+ memset(out_meta, 0, sizeof(*out_meta)); /* re-initialize to NULL */
out_meta->flags = cmd->flags;
if (cmd->flags & CMD_WANT_SKB)
out_meta->source = cmd;
--
1.5.6.3
^ permalink raw reply related
* Re: Enabling and disabling Atheros AR9258 wireless card
From: Emiel Bruijntjes @ 2009-07-31 21:21 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890907200934o319e20d2y825592207b75b0f4@mail.gmail.com>
----- Original Message -----
From: "Luis R. Rodriguez" <mcgrof@gmail.com>
To: "Emiel Bruijntjes" <emiel@bruijntjes.net>
Cc: <linux-wireless@vger.kernel.org>
Sent: Monday, July 20, 2009 6:34 PM
Subject: Re: Enabling and disabling Atheros AR9258 wireless card
> On Sun, Jul 19, 2009 at 6:41 AM, Emiel Bruijntjes<emiel@bruijntjes.net>
> wrote:
>>
>> Hi,
>>
>> I hope this is the right channel to report a bug/feature-request.
>>
>> My laptop (Toshiba NB200) uses a Atheros AR9285 wireless card. Wireless
>> is
>> currently disabled, and the wireless LED is off. This is the default
>> factory
>> setting. There is no way to enable the wireless module from Linux. On
>> Windows, the Fn/F8 key combination enables and disables the wireless
>> module,
>> and turns on or off the LED. On Linux however, this isn't working.
>>
>> The advice that I read on discussion forums on the web was to boot
>> Windows,
>> turn on wireless, and then boot Linux again (see http://tjmcgrew.com/).
>> It
>> is - as far as I know - not possible to use the Atheros AR9285 wireless
>> card
>> on a Linux computer, without running Windows first to enable it. This is
>> not
>> very good.
>
> That would mean no one could use ath9k with AR9285 but that is
> obviously not the case.
>
> You are generalizing your issue to everyone and making wide assumptions.
>
You are of course correct that the AR9285 is supported, and that a lot of
users are already using it. I am sorry if I suggested that it wasn't working
for anyone at all.
My point however, is that it is currently not possible to switch the AR9285
card on or off from Linux. This is especially unhandy as the wireless card
is disabled by default on the Toshiba NB200 netbook. This problem did not
only happen on my computer: I've found several discussions on the internet
about this subject. The currently suggested workaround is: install Windows,
enable the wireless card, then install Linux.
>> To sum up:
>> - From Linux it is not possible to enable/disable the Atheros AR9285
>> wireless card, and to turn on and off the wireless LED.
>> - This should be fixed as the wireless card is disabled by default, and
>> it
>> is thus impossible to use it on a system without installing and running
>> Windows first.
>
> You probably just need the proper rfkill module to enable your device.
> Whether your rfkill triggers are supported is another question. For
> that you may want to try out the latest kernel and use a tree where
> rfkill was recently re-implemented.
>
> Please try building wireless-testing:
>
> http://wireless.kernel.org/en/developers/Documentation/git-guide
>
> or compat-wireless:
>
> http://wireless.kernel.org/en/users/Download/
>
> Luis
I had already installed compat-wireless - without it the wireless card was
not even detected - but I have had no luck with building wireless-testing. I
manage to compile it, but after installing it, the wlan0 interface is
completely gone. I suppose this is my fault, as I do not have much
experience with building and installing things like this, and I do not
really understand what I'm doing while I try all kinds of modprobe and 'make
load' commands. But on the other hand, I haven't seen a message in the
ChangeLog that suggests that this problem is fixed, so I did not expect that
it would solve my problem anyway.
I thinks your observation is right that it is probably a module that is
responsible for enabling and disabling that is missing or broken. I hope you
do recognize that this is a bug or missing feature that needs to be fixed,
and that it ends up somewhere on a TODO list.
Thanks.
Emiel
^ permalink raw reply
* Re: [RESEND] [PATCHv3] b43 add harware tkip
From: Michael Buesch @ 2009-07-31 21:20 UTC (permalink / raw)
To: gregor kowski; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <83a869cd0907311400g2e94f217g3f4aefc64681e0b5@mail.gmail.com>
On Friday 31 July 2009 23:00:01 gregor kowski wrote:
> Update v3 : add a module parameter to enable hw tkip, Coding style
> fix, locking fix
> Update v2 : work with qos, implement dump key, fix an issue with setting
> random value on tkip key clear.
> PS : this depends on "b43 : remove old kidx API" and "remove wrong
> probe_resp_plcp write"
>
> This add hardware tkip for b43.
>
> Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
>
> Index: linux-2.6/drivers/net/wireless/b43/dma.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/wireless/b43/dma.c 2009-07-31
> 20:51:10.000000000 +0000
> +++ linux-2.6/drivers/net/wireless/b43/dma.c 2009-07-31 20:54:06.000000000 +0000
> @@ -1188,7 +1188,7 @@
> header = &(ring->txhdr_cache[(slot / TX_SLOTS_PER_FRAME) * hdrsize]);
> cookie = generate_cookie(ring, slot);
> err = b43_generate_txhdr(ring->dev, header,
> - skb->data, skb->len, info, cookie);
> + skb, info, cookie);
> if (unlikely(err)) {
> ring->current_slot = old_top_slot;
> ring->used_slots = old_used_slots;
> Index: linux-2.6/drivers/net/wireless/b43/main.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/wireless/b43/main.c 2009-07-31
> 20:51:10.000000000 +0000
> +++ linux-2.6/drivers/net/wireless/b43/main.c 2009-07-31
> 20:56:10.000000000 +0000
> @@ -80,6 +80,10 @@
> module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
> MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
>
> +static int modparam_hwtkip;
> +module_param_named(hwtkip, modparam_hwtkip, int, 0444);
> +MODULE_PARM_DESC(hwtkip, "Enable hardware tkip.");
> +
> static int modparam_qos = 1;
> module_param_named(qos, modparam_qos, int, 0444);
> MODULE_PARM_DESC(qos, "Enable QOS support (default on)");
> @@ -836,6 +840,76 @@
> }
> }
>
> +/* The ucode will use phase1 key with TEK key to decrypt rx packets.
> + * When a packet is received, the iv32 is checked.
> + * - if it doesn't the packet is returned without modification (and software
> + * decryption can be done). That's what happen when iv16 wrap.
> + * - if it does, the rc4 key is computed, and decryption is tried.
> + * Either it will success and B43_RX_MAC_DEC is returned,
> + * either it fails and B43_RX_MAC_DEC|B43_RX_MAC_DECERR is returned
> + * and the packet is not usable (it got modified by the ucode).
> + * So in order to never have B43_RX_MAC_DECERR, we should provide
> + * a iv32 and phase1key that match. Because we drop packets in case of
> + * B43_RX_MAC_DECERR, if we have a correct iv32 but a wrong phase1key, all
> + * packets will be lost without higher layer knowing (ie no resync possible
> + * until next wrap).
> + *
> + * NOTE : this should support 50 key like RCMTA because
> + * (B43_SHM_SH_KEYIDXBLOCK - B43_SHM_SH_TKIPTSCTTAK)/14 = 50
> + */
> +static void rx_tkip_phase1_write(struct b43_wldev *dev, u8 index, u32 iv32,
> + u16 *phase1key)
> +{
> + unsigned int i;
> + u32 offset;
> + const u8 per_sta_keys_start = 4;
Can we add an empty line here before the code begins?
> + if (!modparam_hwtkip)
> + return;
> +
> + B43_WARN_ON(index < per_sta_keys_start);
> + /* We have four default TX/ RX keys.
> + * Physical mac 0 is mapped to physical key 4.
> + * So we must adjust the index here.
> + */
> + index -= per_sta_keys_start;
> +
> + if (b43_debug(dev, B43_DBG_KEYS)) {
> + b43dbg(dev->wl, "rx_tkip_phase1_write : idx 0x%x, iv32 0x%x\n",
> + index, iv32);
> + }
> + /* Write the key to the RX tkip shared mem */
> + offset = B43_SHM_SH_TKIPTSCTTAK + index * (10 + 4);
> + for (i = 0; i < 10; i += 2) {
> + b43_shm_write16(dev, B43_SHM_SHARED, offset + i,
> + phase1key ? phase1key[i / 2] : 0);
> + }
> + b43_shm_write16(dev, B43_SHM_SHARED, offset + i, iv32);
> + b43_shm_write16(dev, B43_SHM_SHARED, offset + i + 2, iv32 >> 16);
> +}
> +
> +static void b43_op_update_tkip_key(struct ieee80211_hw *hw,
> + struct ieee80211_key_conf *keyconf, const u8 *addr,
> + u32 iv32, u16 *phase1key)
> +{
> + struct b43_wl *wl = hw_to_b43_wl(hw);
> + struct b43_wldev *dev;
> + int index = keyconf->hw_key_idx;
> +
I'd add
if (B43_WARN_ON(!modparam_hwtkip))
return;
here, because it's a cheap way to detect possible mac80211 bugs.
Mac80211 should not ever call this function, if we reject all tkip keys. But if
it does (due to a bug), this cheap check will prevent keymac trashing and keep the
device working.
> + mutex_lock(&wl->mutex);
> +
> + dev = wl->current_dev;
> + if (!dev || b43_status(dev) < B43_STAT_INITIALIZED)
> + goto out_unlock;
> +
> + keymac_write(dev, index, NULL); /* First zero out mac to avoid race */
> +
> + rx_tkip_phase1_write(dev, index, iv32, phase1key);
> + keymac_write(dev, index, addr);
> +
> +out_unlock:
> + mutex_unlock(&wl->mutex);
> +}
> +
The rest of the patch looks very good.
--
Greetings, Michael.
^ permalink raw reply
* Re: [Linux Wireless] Update of "en/users/Download" by ReinetteChatre
From: Roman Macko @ 2009-07-31 21:19 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: reinette chatre, linux-wireless
In-Reply-To: <43e72e890907301831ped2ea3wd5173b95be54f912@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3646 bytes --]
Hi Luis,
here is promised patch
roman
Luis R. Rodriguez wrote:
> On Thu, Jul 30, 2009 at 6:20 PM, Roman Macko<rmacko72@gmail.com> wrote:
>
>> Hi Luis,
>>
>> I have version 3.6 of module-init-tools and this version reads /etc/depmod.d
>> directory too.
>>
>> But I wanted to understand how depmod reads config files, so I looked into
>> source codes (both version 3.6 and 3.10)
>> and finally found out how it works.
>>
>> Assume depmod is run without -C or --config option
>>
>> Version 3.6 reads firstly /etc/depmod.conf file and then it reads config
>> files in directory /etc/depmod.d.
>> Files in directory /etc/depmod.d are read and parsed in unpredictable order
>> by readdir function (this function uses
>> raw directory structures of filesystem)
>>
>> Version 3.10 reads /etc/depmod.conf firstly as well, but this config file is
>> considered as deprecated in this version
>> and prints out warning about that. Then it reads config files in directory
>> /etc/depmod.d by readdir function as well, but before it starts
>> to parse them, it sorts them accord to filename, so you know the order in
>> which they are going to be parsed
>> and this is very improtant!!! This behavior should be from version 3.7
>>
>> The same for both versions:
>> 1) List of directories to be searched is created from search commands from
>> all config files in order how particular
>> search commands are found in config files (so order of parsed config files
>> is important). If no search command is found,
>> updates directory is added before "built-in" directory.
>>
>> 2) As for override command, the last one found for particular module and
>> kernel in all config files wins,
>> so again the order of parsed config files is important.
>>
>> From this is evident, that both versions can work differently which depends
>> on the order of parsed config files from
>> /etc/depmod.d directory that is different in both versions.
>>
>> So solution would be:
>> 1) if there is no search command in any of config files (in /etc/depmod.conf
>> or those in /etc/depmod.d directory), do nothing.
>> 2) if there is a search command in any of config files and does not contain
>> updates directory before built-in add search command
>> "search updates" in
>> a) if system has version >=3.7, create config file in /etc/depmod.d
>> directory which name is alphabeticaly less than all you will find
>> in that directory
>> b) if system has version <=3.6 add search command "search updates" at the
>> begining of /etc/depmod.conf file
>>
>> But such adding of "search updates" can break depmod configuration in some
>> systems or it is not desirable to make search in
>> updates directory at all. So maybe it would be better to use another name
>> for directory than updates
>>
>> Or it would be also interesting to use override command for all modules
>> compiled in compat-wireless
>> and put it all to configuration file /etc/depmod.d/compat-wireless.conf and
>> not bothering with version of depmod nor
>> finding the search command in all configuration files, e.g
>>
>> compat-wireless.conf
>> ======================================
>> override iwlagn * updates/drivers/net/wireless/iwlwifi
>> override iwlcore * updates/drivers/net/wireless/iwlwifi
>> ....
>> ....
>> ....
>> ======================================
>>
>> it can make problem only when some other config file in /etc/depmod.d
>> directory contains override command for
>> any module from compat-wireless
>>
>>
>> I hope this help you
>>
>
> Thanks, since you have read this and can read code, mind putting
> together a patch for the script on compat-wireless?
>
> Luis
>
[-- Attachment #2: check_depmod.patch --]
[-- Type: text/plain, Size: 3270 bytes --]
--- compat-wireless-2009-07-31/scripts/check_depmod 2009-07-31 10:42:52.000000000 -0400
+++ compat-wireless-patch/scripts/check_depmod 2009-07-31 16:30:22.000000000 -0400
@@ -7,50 +7,77 @@
# Seems Mandriva has an $DEPMOD_DIR but it doesn't have any files,
# so lets deal with those distributions.
DEPMOD_CONF="/etc/depmod.conf"
+DEPMOD_CONF_TMP="$DEPMOD_CONF.compat-wireless.old"
DEPMOD_DIR="/etc/depmod.d/"
COMPAT_DEPMOD_FILE=compat-wireless.conf
+GREP_REGEX_UPDATES="^[[:space:]]*search.*[[:space:]]updates\([[:space:]]\|$\)"
+GREP_REGEX_SEARCH="^[[:space:]]*search[[:space:]].\+$"
+DEPMOD_CMD="depmod"
function add_compat_depmod_conf {
echo "NOTE: Your distribution lacks an $DEPMOD_DIR directory with "
- echo "updates/ directory being prioritized for mouldes, we're adding "
+ echo "updates/ directory being prioritized for modules, we're adding "
echo "one for you."
mkdir -p $DEPMOD_DIR
- echo "search updates extra built-in" > $DEPMOD_DIR/$COMPAT_DEPMOD_FILE
+ FIRST_FILE=$(ls $DEPMOD_DIR|head -1)
+ [ -n "$FIRST_FILE" ] && while [[ $FIRST_FILE < $COMPAT_DEPMOD_FILE ]]; do
+ COMPAT_DEPMOD_FILE="0$COMPAT_DEPMOD_FILE"
+ done
+ echo "search updates" > $DEPMOD_DIR/$COMPAT_DEPMOD_FILE
}
-function depmod_updates_ok {
- echo "depmod will prefer updates/ over kernel/ -- OK!"
+function add_global_depmod_conf {
+ echo "NOTE: Your distribution lacks updates/ directory being"
+ echo "prioritized for modules, we're adding it to $DEPMOD_CONF."
+ rm -f $DEPMOD_CONF_TMP
+ [ -f $DEPMOD_CONF ] && cp -f $DEPMOD_CONF $DEPMOD_CONF_TMP
+ echo "search updates" > $DEPMOD_CONF
+ [ -f $DEPMOD_CONF_TMP ] && cat $DEPMOD_CONF_TMP >> $DEPMOD_CONF
}
-function check_depmod_conf {
- if [ -f $DEPMOD_CONF ]; then
- grep -q updates $DEPMOD_CONF
- return $?
- fi
- return 1
+function depmod_updates_ok {
+ echo "depmod will prefer updates/ over kernel/ -- OK!"
}
-function add_depmod_conf_if_missing {
- check_depmod_conf
- if [[ $? -ne 0 ]]; then
- add_compat_depmod_conf
+function add_depmod_conf {
+ if [ -f "$DEPMOD_CONF" ]; then
+ add_global_depmod_conf
else
- depmod_updates_ok
+ DEPMOD_VERSION=$($DEPMOD_CMD --version | cut -d" " -f2 | sed "s/\.//")
+ if [[ $DEPMOD_VERSION -gt 36 ]]; then
+ add_compat_depmod_conf
+ else
+ add_global_depmod_conf
+ fi
fi
}
+# =============================================================================
+# === MAIN ====================================================================
+# =============================================================================
+
+GREP_FILES=""
+[ -f $DEPMOD_CONF ] && GREP_FILES="$DEPMOD_CONF"
if [ -d $DEPMOD_DIR ]; then
DEPMOD_FILE_COUNT=$(ls $DEPMOD_DIR | wc -l)
- if [[ $DEPMOD_FILE_COUNT -eq 0 ]]; then
- add_depmod_conf_if_missing
- else
- grep -q updates $DEPMOD_DIR/*
- if [[ $? -ne 0 ]]; then
- add_depmod_conf_if_missing
- else
+ [[ $DEPMOD_FILE_COUNT -gt 0 ]] && GREP_FILES="$GREP_FILES $DEPMOD_DIR/*"
+fi
+
+if [ -n "$GREP_FILES" ]; then
+ grep -q "$GREP_REGEX_SEARCH" $GREP_FILES
+ if [[ $? -eq 0 ]]; then
+ grep -q "$GREP_REGEX_UPDATES" $GREP_FILES
+ if [[ $? -eq 0 ]]; then
depmod_updates_ok
+ else
+ add_depmod_conf
fi
+ else
+ depmod_updates_ok
fi
else
- add_depmod_conf_if_missing
+ depmod_updates_ok
fi
+
+exit 0
+
^ permalink raw reply
* Re: [RESEND] [PATCHv2] b43 add harware tkip
From: Michael Buesch @ 2009-07-31 21:08 UTC (permalink / raw)
To: gregor kowski; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <83a869cd0907311404o793c1733p43e936437a923340@mail.gmail.com>
On Friday 31 July 2009 23:04:17 gregor kowski wrote:
> Hi Michael,
>
> On 7/28/09, Michael Buesch <mb@bu3sch.de> wrote:
> >> This add hardware tkip for b43.
> >
> > First of all, I don't really want to support hw tkip on b43.
> > Broadcom removed the support for hw tkip from their drivers. I bet they
> > had a very good reason to do so.
> Did they remove it from the firmware or only the driver ?
I'm not sure about the firmware. But they removed it from the driver.
> > It's mapped to 4, because you removed the old API support.
> > (I'm not sure whether we want to remove that support, yet. Gimme some time
> > on it...)
> >
> Does the old API still useful ?
Well, I'm not sure. Why do we remove it at all? It just avoids one single
if condition in your tkip patch, doesn't it?
> Are there v4 firmware supporting old API ?
Yes
--
Greetings, Michael.
^ permalink raw reply
* Re: [RESEND] [PATCHv2] b43 add harware tkip
From: gregor kowski @ 2009-07-31 21:04 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <200907281808.35906.mb@bu3sch.de>
Hi Michael,
On 7/28/09, Michael Buesch <mb@bu3sch.de> wrote:
>> This add hardware tkip for b43.
>
> First of all, I don't really want to support hw tkip on b43.
> Broadcom removed the support for hw tkip from their drivers. I bet they
> had a very good reason to do so.
Did they remove it from the firmware or only the driver ?
May be they remove it to support advanced stuff like multiple SSID ?
Which version of the driver it is ?
> It's mapped to 4, because you removed the old API support.
> (I'm not sure whether we want to remove that support, yet. Gimme some time
> on it...)
>
Does the old API still useful ?
Are there v4 firmware supporting old API ?
Regards,
Gregor
^ permalink raw reply
* Re: [RESEND] [PATCHv3] b43 add harware tkip
From: gregor kowski @ 2009-07-31 21:00 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: Michael Buesch, linux-wireless
In-Reply-To: <83a869cd0907271349h248204at74cc1603419fc83b@mail.gmail.com>
Update v3 : add a module parameter to enable hw tkip, Coding style
fix, locking fix
Update v2 : work with qos, implement dump key, fix an issue with setting
random value on tkip key clear.
PS : this depends on "b43 : remove old kidx API" and "remove wrong
probe_resp_plcp write"
This add hardware tkip for b43.
Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
Index: linux-2.6/drivers/net/wireless/b43/dma.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/dma.c 2009-07-31
20:51:10.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/dma.c 2009-07-31 20:54:06.000000000 +0000
@@ -1188,7 +1188,7 @@
header = &(ring->txhdr_cache[(slot / TX_SLOTS_PER_FRAME) * hdrsize]);
cookie = generate_cookie(ring, slot);
err = b43_generate_txhdr(ring->dev, header,
- skb->data, skb->len, info, cookie);
+ skb, info, cookie);
if (unlikely(err)) {
ring->current_slot = old_top_slot;
ring->used_slots = old_used_slots;
Index: linux-2.6/drivers/net/wireless/b43/main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/main.c 2009-07-31
20:51:10.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/main.c 2009-07-31
20:56:10.000000000 +0000
@@ -80,6 +80,10 @@
module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
+static int modparam_hwtkip;
+module_param_named(hwtkip, modparam_hwtkip, int, 0444);
+MODULE_PARM_DESC(hwtkip, "Enable hardware tkip.");
+
static int modparam_qos = 1;
module_param_named(qos, modparam_qos, int, 0444);
MODULE_PARM_DESC(qos, "Enable QOS support (default on)");
@@ -836,6 +840,76 @@
}
}
+/* The ucode will use phase1 key with TEK key to decrypt rx packets.
+ * When a packet is received, the iv32 is checked.
+ * - if it doesn't the packet is returned without modification (and software
+ * decryption can be done). That's what happen when iv16 wrap.
+ * - if it does, the rc4 key is computed, and decryption is tried.
+ * Either it will success and B43_RX_MAC_DEC is returned,
+ * either it fails and B43_RX_MAC_DEC|B43_RX_MAC_DECERR is returned
+ * and the packet is not usable (it got modified by the ucode).
+ * So in order to never have B43_RX_MAC_DECERR, we should provide
+ * a iv32 and phase1key that match. Because we drop packets in case of
+ * B43_RX_MAC_DECERR, if we have a correct iv32 but a wrong phase1key, all
+ * packets will be lost without higher layer knowing (ie no resync possible
+ * until next wrap).
+ *
+ * NOTE : this should support 50 key like RCMTA because
+ * (B43_SHM_SH_KEYIDXBLOCK - B43_SHM_SH_TKIPTSCTTAK)/14 = 50
+ */
+static void rx_tkip_phase1_write(struct b43_wldev *dev, u8 index, u32 iv32,
+ u16 *phase1key)
+{
+ unsigned int i;
+ u32 offset;
+ const u8 per_sta_keys_start = 4;
+ if (!modparam_hwtkip)
+ return;
+
+ B43_WARN_ON(index < per_sta_keys_start);
+ /* We have four default TX/ RX keys.
+ * Physical mac 0 is mapped to physical key 4.
+ * So we must adjust the index here.
+ */
+ index -= per_sta_keys_start;
+
+ if (b43_debug(dev, B43_DBG_KEYS)) {
+ b43dbg(dev->wl, "rx_tkip_phase1_write : idx 0x%x, iv32 0x%x\n",
+ index, iv32);
+ }
+ /* Write the key to the RX tkip shared mem */
+ offset = B43_SHM_SH_TKIPTSCTTAK + index * (10 + 4);
+ for (i = 0; i < 10; i += 2) {
+ b43_shm_write16(dev, B43_SHM_SHARED, offset + i,
+ phase1key ? phase1key[i / 2] : 0);
+ }
+ b43_shm_write16(dev, B43_SHM_SHARED, offset + i, iv32);
+ b43_shm_write16(dev, B43_SHM_SHARED, offset + i + 2, iv32 >> 16);
+}
+
+static void b43_op_update_tkip_key(struct ieee80211_hw *hw,
+ struct ieee80211_key_conf *keyconf, const u8 *addr,
+ u32 iv32, u16 *phase1key)
+{
+ struct b43_wl *wl = hw_to_b43_wl(hw);
+ struct b43_wldev *dev;
+ int index = keyconf->hw_key_idx;
+
+ mutex_lock(&wl->mutex);
+
+ dev = wl->current_dev;
+ if (!dev || b43_status(dev) < B43_STAT_INITIALIZED)
+ goto out_unlock;
+
+ keymac_write(dev, index, NULL); /* First zero out mac to avoid race */
+
+ rx_tkip_phase1_write(dev, index, iv32, phase1key);
+ keymac_write(dev, index, addr);
+
+out_unlock:
+ mutex_unlock(&wl->mutex);
+}
+
static void do_key_write(struct b43_wldev *dev,
u8 index, u8 algorithm,
const u8 *key, size_t key_len, const u8 *mac_addr)
@@ -848,6 +922,19 @@
if (index >= per_sta_keys_start)
keymac_write(dev, index, NULL); /* First zero out mac. */
+ if (algorithm == B43_SEC_ALGO_TKIP) {
+ /*
+ * We should provide an initial iv32, phase1key pair.
+ * We could start with iv32=0 and compute the corresponding
+ * phase1key, but this means calling ieee80211_get_tkip_key
+ * with a fake skb (or export other tkip function).
+ * Because we are lazy we hope iv32 won't start with
+ * 0xffffffff and let's b43_op_update_tkip_key provide a
+ * correct pair.
+ */
+ rx_tkip_phase1_write(dev, index, 0xffffffff, (u16*)buf);
+ } else if (index >= per_sta_keys_start) /* clear it */
+ rx_tkip_phase1_write(dev, index, 0, NULL);
if (key)
memcpy(buf, key, key_len);
key_write(dev, index, algorithm, buf);
@@ -865,6 +952,15 @@
{
int i;
+ /* For ALG_TKIP the key is encoded as a 256-bit (32 byte) data block:
+ * - Temporal Encryption Key (128 bits)
+ * - Temporal Authenticator Tx MIC Key (64 bits)
+ * - Temporal Authenticator Rx MIC Key (64 bits)
+ *
+ * Hardware only store TEK
+ */
+ if (algorithm == B43_SEC_ALGO_TKIP && key_len == 32)
+ key_len = 16;
if (key_len > B43_SEC_KEYSIZE)
return -EINVAL;
for (i = 0; i < dev->max_nr_keys; i++) {
@@ -946,6 +1042,14 @@
printk(" Algo: %04X/%02X", algo, key->algorithm);
if (index >= 4) {
+ if (key->algorithm == B43_SEC_ALGO_TKIP) {
+ printk(" TKIP: ");
+ offset = B43_SHM_SH_TKIPTSCTTAK + (index - 4) * (10 + 4);
+ for (i = 0; i < 14; i += 2) {
+ u16 tmp = b43_shm_read16(dev, B43_SHM_SHARED, offset + i);
+ printk("%02X%02X", (tmp & 0xFF), ((tmp >> 8) & 0xFF));
+ }
+ }
rcmta0 = b43_shm_read32(dev, B43_SHM_RCMTA,
((index - 4) * 2) + 0);
rcmta1 = b43_shm_read16(dev, B43_SHM_RCMTA,
@@ -3670,8 +3774,10 @@
switch (cmd) {
case SET_KEY:
- if (algorithm == B43_SEC_ALGO_TKIP) {
- /* FIXME: No TKIP hardware encryption for now. */
+ if (algorithm == B43_SEC_ALGO_TKIP &&
+ (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE) ||
+ !modparam_hwtkip)) {
+ /* We support only pairwise key */
err = -EOPNOTSUPP;
goto out_unlock;
}
@@ -3701,6 +3807,8 @@
b43_hf_read(dev) & ~B43_HF_USEDEFKEYS);
}
key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
+ if (algorithm == B43_SEC_ALGO_TKIP)
+ key->flags |= IEEE80211_KEY_FLAG_GENERATE_MMIC;
break;
case DISABLE_KEY: {
err = b43_key_clear(dev, key->hw_key_idx);
@@ -4428,6 +4536,7 @@
.bss_info_changed = b43_op_bss_info_changed,
.configure_filter = b43_op_configure_filter,
.set_key = b43_op_set_key,
+ .update_tkip_key = b43_op_update_tkip_key,
.get_stats = b43_op_get_stats,
.get_tx_stats = b43_op_get_tx_stats,
.get_tsf = b43_op_get_tsf,
Index: linux-2.6/drivers/net/wireless/b43/pio.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/pio.c 2009-07-31
20:51:10.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/pio.c 2009-07-31 20:54:06.000000000 +0000
@@ -461,8 +461,8 @@
cookie = generate_cookie(q, pack);
hdrlen = b43_txhdr_size(q->dev);
- err = b43_generate_txhdr(q->dev, (u8 *)&txhdr, skb->data,
- skb->len, info, cookie);
+ err = b43_generate_txhdr(q->dev, (u8 *)&txhdr, skb,
+ info, cookie);
if (err)
return err;
Index: linux-2.6/drivers/net/wireless/b43/xmit.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/xmit.c 2009-07-31
20:51:10.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/xmit.c 2009-07-31
20:54:06.000000000 +0000
@@ -180,11 +180,12 @@
/* Generate a TX data header. */
int b43_generate_txhdr(struct b43_wldev *dev,
u8 *_txhdr,
- const unsigned char *fragment_data,
- unsigned int fragment_len,
+ struct sk_buff *skb_frag,
struct ieee80211_tx_info *info,
u16 cookie)
{
+ const unsigned char *fragment_data = skb_frag->data;
+ unsigned int fragment_len = skb_frag->len;
struct b43_txhdr *txhdr = (struct b43_txhdr *)_txhdr;
const struct b43_phy *phy = &dev->phy;
const struct ieee80211_hdr *wlhdr =
@@ -257,9 +258,26 @@
mac_ctl |= (key->algorithm << B43_TXH_MAC_KEYALG_SHIFT) &
B43_TXH_MAC_KEYALG;
wlhdr_len = ieee80211_hdrlen(fctl);
- iv_len = min((size_t) info->control.hw_key->iv_len,
- ARRAY_SIZE(txhdr->iv));
- memcpy(txhdr->iv, ((u8 *) wlhdr) + wlhdr_len, iv_len);
+ if (key->algorithm == B43_SEC_ALGO_TKIP) {
+ u16 phase1key[5];
+ int i;
+ /* we give the phase1key and iv16 here, the key is stored in
+ * shm. With that the hardware can do phase 2 and encryption.
+ */
+ ieee80211_get_tkip_key(info->control.hw_key, skb_frag,
+ IEEE80211_TKIP_P1_KEY, (u8*)phase1key);
+ /* phase1key is in host endian */
+ for (i = 0; i < 5; i++)
+ phase1key[i] = cpu_to_le16(phase1key[i]);
+
+ memcpy(txhdr->iv, phase1key, 10);
+ /* iv16 */
+ memcpy(txhdr->iv + 10, ((u8 *) wlhdr) + wlhdr_len, 3);
+ } else {
+ iv_len = min((size_t) info->control.hw_key->iv_len,
+ ARRAY_SIZE(txhdr->iv));
+ memcpy(txhdr->iv, ((u8 *) wlhdr) + wlhdr_len, iv_len);
+ }
}
if (b43_is_old_txhdr_format(dev)) {
b43_generate_plcp_hdr((struct b43_plcp_hdr4 *)(&txhdr->old_format.plcp),
Index: linux-2.6/drivers/net/wireless/b43/xmit.h
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/xmit.h 2009-07-31
20:51:10.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/xmit.h 2009-07-31
20:54:06.000000000 +0000
@@ -176,8 +176,7 @@
int b43_generate_txhdr(struct b43_wldev *dev,
u8 * txhdr,
- const unsigned char *fragment_data,
- unsigned int fragment_len,
+ struct sk_buff *skb_frag,
struct ieee80211_tx_info *txctl, u16 cookie);
/* Transmit Status */
^ permalink raw reply
* Re: [PATCH] remove wrong probe_resp_plcp write
From: Michael Buesch @ 2009-07-31 20:38 UTC (permalink / raw)
To: linville; +Cc: gregor kowski, bcm43xx-dev, linux-wireless
In-Reply-To: <83a869cd0907311335h3065547aqc736573a663b6d42@mail.gmail.com>
On Friday 31 July 2009 22:35:49 gregor kowski wrote:
> The tkip hw support uncovered a bug in b43_write_probe_resp_template : it is
> writing at the wrong shm offset, it is in the B43_SHM_SH_TKIPTSCTTAK zone. This
> patch comments these writes.
>
> Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
>
> Index: linux-2.6/drivers/net/wireless/b43/main.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/wireless/b43/main.c 2009-07-31
> 20:32:21.000000000 +0000
> +++ linux-2.6/drivers/net/wireless/b43/main.c 2009-07-31
> 20:32:28.000000000 +0000
> @@ -1505,10 +1505,13 @@
> /* Looks like PLCP headers plus packet timings are stored for
> * all possible basic rates
> */
> + /* FIXME this is the wrong offset : it goes in tkip rx phase1 shm */
> +#if 0
> b43_write_probe_resp_plcp(dev, 0x31A, size, &b43_b_ratetable[0]);
> b43_write_probe_resp_plcp(dev, 0x32C, size, &b43_b_ratetable[1]);
> b43_write_probe_resp_plcp(dev, 0x33E, size, &b43_b_ratetable[2]);
> b43_write_probe_resp_plcp(dev, 0x350, size, &b43_b_ratetable[3]);
> +#endif
>
> size = min((size_t) size, 0x200 - sizeof(struct b43_plcp_hdr6));
> b43_write_template_common(dev, probe_resp_data,
>
>
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] remove wrong probe_resp_plcp write
From: gregor kowski @ 2009-07-31 20:35 UTC (permalink / raw)
To: bcm43xx-dev, linux-wireless; +Cc: Michael Buesch
The tkip hw support uncovered a bug in b43_write_probe_resp_template : it is
writing at the wrong shm offset, it is in the B43_SHM_SH_TKIPTSCTTAK zone. This
patch comments these writes.
Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
Index: linux-2.6/drivers/net/wireless/b43/main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/main.c 2009-07-31
20:32:21.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/main.c 2009-07-31
20:32:28.000000000 +0000
@@ -1505,10 +1505,13 @@
/* Looks like PLCP headers plus packet timings are stored for
* all possible basic rates
*/
+ /* FIXME this is the wrong offset : it goes in tkip rx phase1 shm */
+#if 0
b43_write_probe_resp_plcp(dev, 0x31A, size, &b43_b_ratetable[0]);
b43_write_probe_resp_plcp(dev, 0x32C, size, &b43_b_ratetable[1]);
b43_write_probe_resp_plcp(dev, 0x33E, size, &b43_b_ratetable[2]);
b43_write_probe_resp_plcp(dev, 0x350, size, &b43_b_ratetable[3]);
+#endif
size = min((size_t) size, 0x200 - sizeof(struct b43_plcp_hdr6));
b43_write_template_common(dev, probe_resp_data,
^ permalink raw reply
* Re: [PATCH 000/002] Fix frequent reconnects caused by new conection monitor
From: Maxim Levitsky @ 2009-07-31 20:05 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: reinette chatre, linux-wireless, linville, Johannes Berg
In-Reply-To: <1249068449.23662.17.camel@localhost.localdomain>
On Fri, 2009-07-31 at 12:27 -0700, Marcel Holtmann wrote:
> Hi Maxim,
>
> > > > Hi, here is the updated version of these two patches that fix the
> > > > $SUBJECT issue.
> > > >
> > > > I attach these (in case mailer mangles them), and reply with patches.
> > > >
> > > > Tested both with low quality signal, and beacon loss.
> > > > Lack of TX is found, every 30 seconds now, and quite reliable.
> > > > Lack of beacons, triggers probe like it did every 2 seconds.
> > >
> > > Thanks!
> > >
> > > I've been running with this for two hours now with no disconnects. This
> > > is where before the patches I would get disconnected after a few
> > > minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx
> > > after 500ms, try 1" messages in my log.
> > This is normal, or at least can be normal, I patched the driver to
> > display this message, when there is a probe timeout, but instead of
> > disconnect, it retries, currently 5 times, but this can be even further
> > increased is necessarily.
> > (these messages are only in logs when verbose mac debugging is enabled)
> >
> > I don't know exactly why probes aren't answered, but I strongly suspect
> > that my AP sometimes 'goes out to lunch' and then answers, since
> > typically after a failed probe it sends many replies.
> > (Or it could be some buffering done by iwl3945 microcode). I currently
> > can't monitor the connection from outside, but as soon as I can I see
> > whether the above is true. Nevertheless if signal quality isn't great,
> > there are valid reasons for probe loss, and it shouldn't cause all the
> > fuzz (and since I use WPA2, every reconnection causes whole WPA
> > handshake to be preformed, and this takes at least 2 seconds, and if a
> > reconnection happens each 5 seconds, it gets very very annoying, and
> > almost unusable.
>
> I am testing your patches and so far so good. Seems to be working
> perfectly fine. I see this in the logs:
>
> [41027.333419] wlan0: detected beacon loss from AP - sending probe request
> [41027.389260] wlan0: cancelling probereq poll due to a received beacon
> [41027.793518] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 1
> [41028.292731] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 2
>
> Need to watch out if this pattern emerges and if the beacon loss trigger
> might give us an indication. Maybe the ucode is just not ready then.
Here (on my system) I see no beacon losses at all, like I said there
could be many reasons behind packet losses, and best way to mitigate
them is to retry.
Your logs indicate that beacons weren't recieved for 2 seconds, then
mac80211 tried to send a probe, but a beacon is recieved before the
probe answer, this probe is canceled (at least should be) then after a
while, a probe request (same one?) is time outed, and retried twice,
then finally answered.
Best regards,
Maxim Levitsky
>
> Regards
>
> Marcel
>
>
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Nick Kossifidis @ 2009-07-31 19:52 UTC (permalink / raw)
To: Bob Copeland
Cc: Luis R. Rodriguez, ath5k-devel, linux-wireless, linville,
jirislaby, nbd
In-Reply-To: <b6c5339f0907311211w4d810b23uc6ec8027924da647@mail.gmail.com>
2009/7/31 Bob Copeland <me@bobcopeland.com>:
> On Fri, Jul 31, 2009 at 2:25 PM, Nick Kossifidis<mickflemm@gmail.com> wrote:
>> Also we don't need to run calibration if we are idle (no interrupts).
>
> I think this is the big win right now...
>
>> c) Having calibration on a tasklet is better since during calibration
>> we can't transmit or receive (antennas are detached to measure
>> noise floor), previously calibration could run in parallel with tx/rx
>> and interfere (packet loss).
>
> This can still happen, no? Two tasklets can run in parallel on
> different processors, as long as they are different tasklets.
>
> In practice, this won't happen much because tasklets run on the
> cpu that scheduled them, and irq affinity is such (at least on my
> hardware) that it's almost always the same CPU. But I think to
> make the above true it needs to stop the queues etc when doing
> calibration.
>
ACK, how do we do that ?
ieee80211_stop_queues / ieee80211_wake_queues
> Also we are missing tasklet_kill()?
>
Yup, resending...
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH] iwlwifi: don't export symbols not needed in other modules
From: reinette chatre @ 2009-07-31 19:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1248982009.23496.5.camel@johannes.local>
On Thu, 2009-07-30 at 12:26 -0700, Johannes Berg wrote:
> On Thu, 2009-07-30 at 11:47 -0700, reinette chatre wrote:
>
> > No. If this is what you want then I think you also need to remove
> > iwl_rx_ant_restriction.
>
> Hm, I missed that, I actually have removed as part of my powersave
> patch.
now I see.
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Pavel Roskin @ 2009-07-31 19:43 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Luis R. Rodriguez, jirislaby, linux-wireless, ath5k-devel,
linville
In-Reply-To: <40f31dec0907311235g63c10e53obec06ba542d942cd@mail.gmail.com>
On Fri, 2009-07-31 at 22:35 +0300, Nick Kossifidis wrote:
> Nope calibration deals mostly with noise immunity, it calculates the
> noise floor and fixes QAM constellation. It's not related to the synthesizer
> so it's not related to the channel frequency.
OK then, good to know.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Nick Kossifidis @ 2009-07-31 19:35 UTC (permalink / raw)
To: Pavel Roskin
Cc: Luis R. Rodriguez, jirislaby, linux-wireless, ath5k-devel,
linville
In-Reply-To: <1249067385.20276.16.camel@mj>
2009/7/31 Pavel Roskin <proski@gnu.org>:
> On Fri, 2009-07-31 at 21:25 +0300, Nick Kossifidis wrote:
>
>> a) We don't need a timer for this, there is no need for accuracy
>> even with round_jiffies i think this is a waste of resources.
>> Also we don't need to run calibration if we are idle (no interrupts).
>
> It doesn't sound right to me.
>
> Can it be that the device gets so miscalibrated during the silence that
> it won't be able to receive signal once it's there? Say, the device is
> set to channel 1 but it actually listens to channel 3, and there are
> some weak beacons on channel 1.
>
Nope calibration deals mostly with noise immunity, it calculates the
noise floor and fixes QAM constellation. It's not related to the synthesizer
so it's not related to the channel frequency.
> And then there is an issue of the frequency straying outside the
> permitted spectrum. Perhaps the transmission will trigger interrupts
> and thus recalibration, but in case of scanning, the first probe
> requests could be on wrong frequencies.
>
On each reset we trigger calibration so no worries there.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH 000/002] Fix frequent reconnects caused by new conection monitor
From: Marcel Holtmann @ 2009-07-31 19:27 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: reinette chatre, linux-wireless, linville, Johannes Berg
In-Reply-To: <1249067293.19089.10.camel@maxim-laptop>
Hi Maxim,
> > > Hi, here is the updated version of these two patches that fix the
> > > $SUBJECT issue.
> > >
> > > I attach these (in case mailer mangles them), and reply with patches.
> > >
> > > Tested both with low quality signal, and beacon loss.
> > > Lack of TX is found, every 30 seconds now, and quite reliable.
> > > Lack of beacons, triggers probe like it did every 2 seconds.
> >
> > Thanks!
> >
> > I've been running with this for two hours now with no disconnects. This
> > is where before the patches I would get disconnected after a few
> > minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx
> > after 500ms, try 1" messages in my log.
> This is normal, or at least can be normal, I patched the driver to
> display this message, when there is a probe timeout, but instead of
> disconnect, it retries, currently 5 times, but this can be even further
> increased is necessarily.
> (these messages are only in logs when verbose mac debugging is enabled)
>
> I don't know exactly why probes aren't answered, but I strongly suspect
> that my AP sometimes 'goes out to lunch' and then answers, since
> typically after a failed probe it sends many replies.
> (Or it could be some buffering done by iwl3945 microcode). I currently
> can't monitor the connection from outside, but as soon as I can I see
> whether the above is true. Nevertheless if signal quality isn't great,
> there are valid reasons for probe loss, and it shouldn't cause all the
> fuzz (and since I use WPA2, every reconnection causes whole WPA
> handshake to be preformed, and this takes at least 2 seconds, and if a
> reconnection happens each 5 seconds, it gets very very annoying, and
> almost unusable.
I am testing your patches and so far so good. Seems to be working
perfectly fine. I see this in the logs:
[41027.333419] wlan0: detected beacon loss from AP - sending probe request
[41027.389260] wlan0: cancelling probereq poll due to a received beacon
[41027.793518] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 1
[41028.292731] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 2
Need to watch out if this pattern emerges and if the beacon loss trigger
might give us an indication. Maybe the ucode is just not ready then.
Regards
Marcel
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Bob Copeland @ 2009-07-31 19:11 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Luis R. Rodriguez, ath5k-devel, linux-wireless, linville,
jirislaby, nbd
In-Reply-To: <40f31dec0907311125o1654bd23jee861ba8bea57611@mail.gmail.com>
On Fri, Jul 31, 2009 at 2:25 PM, Nick Kossifidis<mickflemm@gmail.com> wrote:
> Also we don't need to run calibration if we are idle (no interrupts).
I think this is the big win right now...
> c) Having calibration on a tasklet is better since during calibration
> we can't transmit or receive (antennas are detached to measure
> noise floor), previously calibration could run in parallel with tx/rx
> and interfere (packet loss).
This can still happen, no? Two tasklets can run in parallel on
different processors, as long as they are different tasklets.
In practice, this won't happen much because tasklets run on the
cpu that scheduled them, and irq affinity is such (at least on my
hardware) that it's almost always the same CPU. But I think to
make the above true it needs to stop the queues etc when doing
calibration.
Also we are missing tasklet_kill()?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Pavel Roskin @ 2009-07-31 19:09 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Luis R. Rodriguez, jirislaby, linux-wireless, ath5k-devel,
linville
In-Reply-To: <40f31dec0907311125o1654bd23jee861ba8bea57611@mail.gmail.com>
On Fri, 2009-07-31 at 21:25 +0300, Nick Kossifidis wrote:
> a) We don't need a timer for this, there is no need for accuracy
> even with round_jiffies i think this is a waste of resources.
> Also we don't need to run calibration if we are idle (no interrupts).
It doesn't sound right to me.
Can it be that the device gets so miscalibrated during the silence that
it won't be able to receive signal once it's there? Say, the device is
set to channel 1 but it actually listens to channel 3, and there are
some weak beacons on channel 1.
And then there is an issue of the frequency straying outside the
permitted spectrum. Perhaps the transmission will trigger interrupts
and thus recalibration, but in case of scanning, the first probe
requests could be on wrong frequencies.
I would probably leave the timer and allow the interrupts make the
delays shorter.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] [compat-2.6] Fix building on 2.6.31
From: Luis R. Rodriguez @ 2009-07-31 19:09 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: Luis Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <1249066349-24956-1-git-send-email-hauke@hauke-m.de>
On Fri, Jul 31, 2009 at 11:52:29AM -0700, Hauke Mehrtens wrote:
> The netdevice.h header file should be loaded before dev_change_net_namespace is overwritten.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied, thanks.
Luis
^ permalink raw reply
* Re: [PATCH 000/002] Fix frequent reconnects caused by new conection monitor
From: Maxim Levitsky @ 2009-07-31 19:08 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless, linville, Johannes Berg
In-Reply-To: <1249066338.30019.214.camel@rc-desk>
On Fri, 2009-07-31 at 11:52 -0700, reinette chatre wrote:
> On Fri, 2009-07-31 at 09:13 -0700, Maxim Levitsky wrote:
> > Hi, here is the updated version of these two patches that fix the
> > $SUBJECT issue.
> >
> > I attach these (in case mailer mangles them), and reply with patches.
> >
> > Tested both with low quality signal, and beacon loss.
> > Lack of TX is found, every 30 seconds now, and quite reliable.
> > Lack of beacons, triggers probe like it did every 2 seconds.
>
> Thanks!
>
> I've been running with this for two hours now with no disconnects. This
> is where before the patches I would get disconnected after a few
> minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx
> after 500ms, try 1" messages in my log.
This is normal, or at least can be normal, I patched the driver to
display this message, when there is a probe timeout, but instead of
disconnect, it retries, currently 5 times, but this can be even further
increased is necessarily.
(these messages are only in logs when verbose mac debugging is enabled)
I don't know exactly why probes aren't answered, but I strongly suspect
that my AP sometimes 'goes out to lunch' and then answers, since
typically after a failed probe it sends many replies.
(Or it could be some buffering done by iwl3945 microcode). I currently
can't monitor the connection from outside, but as soon as I can I see
whether the above is true. Nevertheless if signal quality isn't great,
there are valid reasons for probe loss, and it shouldn't cause all the
fuzz (and since I use WPA2, every reconnection causes whole WPA
handshake to be preformed, and this takes at least 2 seconds, and if a
reconnection happens each 5 seconds, it gets very very annoying, and
almost unusable.
And polling every 2 seconds, this way or another, I think is too much
anyway.
Best regards,
Maxim Levitsky
>
> Reinette
>
>
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 3/4] ath5k: Wakeup fixes
From: Luis R. Rodriguez @ 2009-07-31 19:05 UTC (permalink / raw)
To: Ben Greear; +Cc: ath5k-devel, linux-wireless, linville, jirislaby, me, nbd
In-Reply-To: <4A733FFD.60407@candelatech.com>
On Fri, Jul 31, 2009 at 12:03 PM, Ben Greear<greearb@candelatech.com> wrote:
> On 07/31/2009 11:08 AM, Nick Kossifidis wrote:
>>
>> * Don't put chip to full sleep because there are problems during
>> wakeup. Instead hold MAC/Baseband on warm reset state via a new
>> function ath5k_hw_on_hold.
>>
>> * Durring attach preserve pcicfg bits when enabling pci core
>> sw retry fix.
>>
>> * Minor cleanups
>
> I patched just this patch (not your other 3) into 2.6.31-rc4 and it seems
> to fix the wakeup problems I was seeing on module unload/load.
And now you can throw in a Tested-by in the commit log. The commit log
will make more sense as if you refer to the issue we can refer to it
later in the future and see it was tested perhaps by the same user who
reported the issue.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 3/4] ath5k: Wakeup fixes
From: Ben Greear @ 2009-07-31 19:03 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, jirislaby, me, mcgrof, nbd
In-Reply-To: <20090731180805.GD7963@makis>
On 07/31/2009 11:08 AM, Nick Kossifidis wrote:
> * Don't put chip to full sleep because there are problems during
> wakeup. Instead hold MAC/Baseband on warm reset state via a new
> function ath5k_hw_on_hold.
>
> * Durring attach preserve pcicfg bits when enabling pci core
> sw retry fix.
>
> * Minor cleanups
I patched just this patch (not your other 3) into 2.6.31-rc4 and it seems
to fix the wakeup problems I was seeing on module unload/load.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] compat-2.6: Makefile: fixed test expressions for target install
From: Luis R. Rodriguez @ 2009-07-31 19:04 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Joerg Albert, linux-wireless@vger.kernel.org
In-Reply-To: <1249066564.20276.3.camel@mj>
On Fri, Jul 31, 2009 at 11:56 AM, Pavel Roskin<proski@gnu.org> wrote:
> On Fri, 2009-07-31 at 20:50 +0200, Joerg Albert wrote:
>
>> joerg@thinkpad:~$ echo $BASH_VERSION
>> 3.2.39(1)-release
>> joerg@thinkpad:~$ if [ -z "" && -z "" ]; then echo "both empty"; fi
>> bash: [: missing `]'
>> joerg@thinkpad:~$ if [ -z "" -a -z "" ]; then echo "both empty"; fi
>> both empty
>> joerg@thinkpad:~$ if [[ -z "" && -z "" ]]; then echo "both empty"; fi
>> both empty
>> joerg@thinkpad:~$
>
> No, I didn't mean that. I meant:
>
> if [ -z "" ] && [ -z "" ]; then echo "both empty"; fi
>
>> If the link for the man page of bash v1 on http://wwwbs.informatik.htw-dresden.de/fbs/bash/old.bash.html is correct,
>> that version supported -a in test.
>> Unfortunately [[ ... ]] was introduced after bash v1 (2.02 AFAIR).
>
> We should not rely on any bash features as /bin/sh may not be bash at
> all.
compat-wireless depends on bash, hence /bin/bash at the top.
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