* Re: rtl8192cu: testing with EdiMax USB
From: Larry Finger @ 2013-09-13 18:00 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: linux-wireless
In-Reply-To: <523312D0.3020001@ilande.co.uk>
On 09/13/2013 08:27 AM, Mark Cave-Ayland wrote:
> On 13/09/13 14:01, Mark Cave-Ayland wrote:
>
>>> I spent a bit more time tinkering further with debug=0x5, forgetting
>>> that I had left your last diagnostic patch applied. Based upon when the
>>> beacon output disappears in the logs (after updating the power
>>> registers), it does seem likely that is a power-related problem.
>>
>> FWIW I just tried a quick test where I commented out the entire
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() function to make it a
>> nop, and that didn't seem to make any difference...
>
> Aha! The following diff to remove the call to rtl92c_dm_diginit() keeps me
> associated to the AP:
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> index d2d57a2..c18362d 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
> @@ -1275,7 +1275,7 @@ void rtl92c_dm_init(struct ieee80211_hw *hw)
> struct rtl_priv *rtlpriv = rtl_priv(hw);
>
> rtlpriv->dm.dm_type = DM_TYPE_BYDRIVER;
> - rtl92c_dm_diginit(hw);
> + //rtl92c_dm_diginit(hw);
> rtl92c_dm_init_dynamic_txpower(hw);
> rtl92c_dm_init_edca_turbo(hw);
> rtl92c_dm_init_rate_adaptive_mask(hw);
>
> However, dhclient still takes a very long time get an IP address and the
> connection seems extremely lossy, much like it was when I could get a connection
> before. Perhaps there are two different bugs here, one for the association and
> one for the data loss?
Thanks for the info. Eliminating the call to rtl92c_dm_diginit() is a very large
hammer to attack a small flea, but that points to a potential problem.
Larry
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-13 17:52 UTC (permalink / raw)
To: Timothy Rundle; +Cc: Mark Cave-Ayland, linux-wireless
In-Reply-To: <CALa3VXbxQ1Z2J5weV7rQ16c53D1MQyDL1YGQrV6EkCJYfh=uYA@mail.gmail.com>
On 09/12/2013 05:24 PM, Timothy Rundle wrote:
>
> I finally got some free time to go through all the patches. My results were
> similar to Mark's, but I do not get the watchdog messages, though I am pretty
> sure watchdog is disabled on my PC. I did even try installing openSUSE 12.3, but
> did not have any success. It didn't even find my wireless network. I manually
> configured the network via network-manager, but still no luck.
>
> Let me know if you need anything else from me.
The watchdog in rtl8192cu has nothing to do with any kernel watchdog timers.
They are totally separate.
Larry
^ permalink raw reply
* [PATCH 7/7] rtlwifi: rtl8188ee: Fix smatch warning in rtl8188ee/hw.c
From: Larry Finger @ 2013-09-13 17:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Stable
In-Reply-To: <1379094304-22041-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c:149 _rtl88ee_set_fw_clock_on() info: ignoring unreachable code.
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c:149 _rtl88ee_set_fw_clock_on() info: ignoring unreachable code.
This info message is the result of a real error due to a missing break statement
in a "while (1)" loop.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [3.10+]
---
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
index b68cae3..e06971b 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/hw.c
@@ -143,6 +143,7 @@ static void _rtl88ee_set_fw_clock_on(struct ieee80211_hw *hw,
} else {
rtlhal->fw_clk_change_in_progress = false;
spin_unlock_bh(&rtlpriv->locks.fw_ps_lock);
+ break;
}
}
--
1.8.1.4
^ permalink raw reply related
* [PATCH 6/7] rtlwifi: Fix smatch warnings in usb.c
From: Larry Finger @ 2013-09-13 17:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In-Reply-To: <1379094304-22041-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch displays the following:
CHECK drivers/net/wireless/rtlwifi/usb.c
drivers/net/wireless/rtlwifi/usb.c:458 _rtl_usb_rx_process_agg() warn: assigning (-98) to unsigned variable 'stats.noise'
drivers/net/wireless/rtlwifi/usb.c:503 _rtl_usb_rx_process_noagg() warn: assigning (-98) to unsigned variable 'stats.noise'
drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring unreachable code.
drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring unreachable code.
The negative number to an unsigned quantity is fixed by adding 256 to -98
to get the equivalent negative number.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/usb.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
index e56778c..9f3dcb8 100644
--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -455,7 +455,7 @@ static void _rtl_usb_rx_process_agg(struct ieee80211_hw *hw,
struct ieee80211_rx_status rx_status = {0};
struct rtl_stats stats = {
.signal = 0,
- .noise = -98,
+ .noise = 158, /* -98 dBm */
.rate = 0,
};
@@ -498,7 +498,7 @@ static void _rtl_usb_rx_process_noagg(struct ieee80211_hw *hw,
struct ieee80211_rx_status rx_status = {0};
struct rtl_stats stats = {
.signal = 0,
- .noise = -98,
+ .noise = 158, /* -98 dBm */
.rate = 0,
};
@@ -582,12 +582,15 @@ static void _rtl_rx_work(unsigned long param)
static unsigned int _rtl_rx_get_padding(struct ieee80211_hdr *hdr,
unsigned int len)
{
+#if NET_IP_ALIGN != 0
unsigned int padding = 0;
+#endif
/* make function no-op when possible */
- if (NET_IP_ALIGN == 0 || len < sizeof(*hdr))
+ if (NET_IP_ALIGN == 0 || len < sizeof(struct ieee80211_hdr))
return 0;
+#if NET_IP_ALIGN != 0
/* alignment calculation as in lbtf_rx() / carl9170_rx_copy_data() */
/* TODO: deduplicate common code, define helper function instead? */
@@ -608,6 +611,7 @@ static unsigned int _rtl_rx_get_padding(struct ieee80211_hdr *hdr,
padding ^= NET_IP_ALIGN;
return padding;
+#endif
}
#define __RADIO_TAP_SIZE_RSV 32
--
1.8.1.4
^ permalink raw reply related
* [PATCH 5/7: rtlwifi: Fix smatch warning in pci.c
From: Larry Finger @ 2013-09-13 17:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In-Reply-To: <1379094304-22041-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch reports the following:
CHECK drivers/net/wireless/rtlwifi/pci.c
drivers/net/wireless/rtlwifi/pci.c:739 _rtl_pci_rx_interrupt() warn: assigning (-98) to unsigned variable 'stats.noise'
This problem is fixed by changing the value to 256 - 98.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 703f839..bf498f5 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -736,7 +736,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
struct rtl_stats stats = {
.signal = 0,
- .noise = -98,
+ .noise = 158, /* -98 dBm */
.rate = 0,
};
int index = rtlpci->rx_ring[rx_queue_idx].idx;
--
1.8.1.4
^ permalink raw reply related
* [PATCH 4/7] rtlwifi: rtl8192_common: Fix smatch errors and warnings in rtl8192c/dm_common.c
From: Larry Finger @ 2013-09-13 17:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In-Reply-To: <1379094304-22041-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor() info: ignoring unreachable code.
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor() info: ignoring unreachable code.
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:882 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:883 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:891 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:892 rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'txpwr_level' 2 <= 2
The unreachable code message is fixed by commenting out the code that follows a return.
The errors are fixed by increasing the size of txpwr_level.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
index d2d57a2..0721756 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
@@ -541,6 +541,7 @@ EXPORT_SYMBOL(rtl92c_dm_write_dig);
static void rtl92c_dm_pwdb_monitor(struct ieee80211_hw *hw)
{
+/*
struct rtl_priv *rtlpriv = rtl_priv(hw);
long tmpentry_max_pwdb = 0, tmpentry_min_pwdb = 0xff;
@@ -564,6 +565,7 @@ static void rtl92c_dm_pwdb_monitor(struct ieee80211_hw *hw)
h2c_parameter[0] = 0;
rtl92c_fill_h2c_cmd(hw, H2C_RSSI_REPORT, 3, h2c_parameter);
+ */
}
void rtl92c_dm_init_edca_turbo(struct ieee80211_hw *hw)
@@ -673,7 +675,7 @@ static void rtl92c_dm_txpower_tracking_callback_thermalmeter(struct ieee80211_hw
s8 cck_index = 0;
int i;
bool is2t = IS_92C_SERIAL(rtlhal->version);
- s8 txpwr_level[2] = {0, 0};
+ s8 txpwr_level[3] = {0, 0, 0};
u8 ofdm_min_index = 6, rf;
rtlpriv->dm.txpower_trackinginit = true;
--
1.8.1.4
^ permalink raw reply related
* [PATCH 3/7] rtlwifi: rtl8192cu: Fix smatch warning in rtl8192cu/trx.c
From: Larry Finger @ 2013-09-13 17:45 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In-Reply-To: <1379094304-22041-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c:367 _rtl_rx_process() warn: assigning (-98) to unsigned variable 'stats.noise'
This warning is fixed by setting the value to 256-98.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
index 763cf1d..18308b0 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
@@ -364,7 +364,7 @@ static void _rtl_rx_process(struct ieee80211_hw *hw, struct sk_buff *skb)
u8 *rxdesc;
struct rtl_stats stats = {
.signal = 0,
- .noise = -98,
+ .noise = 158, /* -98 dBm */
.rate = 0,
};
struct rx_fwinfo_92c *p_drvinfo;
--
1.8.1.4
^ permalink raw reply related
* [PATCH 2/7] rtlwifi: rtl8192de: Fix smatch warnings in rtl8192de/hw.c
From: Larry Finger @ 2013-09-13 17:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In-Reply-To: <1379094304-22041-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8192de/hw.c
drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info: ignoring unreachable code.
drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info: ignoring unreachable code.
Dead code is removed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
index 7dd8f6d..c9b0894 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/hw.c
@@ -1194,6 +1194,7 @@ void rtl92d_linked_set_reg(struct ieee80211_hw *hw)
* mac80211 will send pkt when scan */
void rtl92de_set_qos(struct ieee80211_hw *hw, int aci)
{
+/*
struct rtl_priv *rtlpriv = rtl_priv(hw);
rtl92d_dm_init_edca_turbo(hw);
return;
@@ -1213,6 +1214,7 @@ void rtl92de_set_qos(struct ieee80211_hw *hw, int aci)
RT_ASSERT(false, "invalid aci: %d !\n", aci);
break;
}
+ */
}
void rtl92de_enable_interrupt(struct ieee80211_hw *hw)
--
1.8.1.4
^ permalink raw reply related
* [PATCH 1/7] rtlwifi: rtl8192du: Fix smatch errors in /rtl8192de/dm.c
From: Larry Finger @ 2013-09-13 17:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In-Reply-To: <1379094304-22041-1-git-send-email-Larry.Finger@lwfinger.net>
Smatch lists the following:
CHECK drivers/net/wireless/rtlwifi/rtl8192de/dm.c
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1054 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'ofdm_index' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1056 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'ofdm_index' 2 <= 2
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1126 rtl92d_dm_txpower_tracking_callback_thermalmeter() debug: remove_pools: nr_children over 4000 (4596). (rtlpriv->dbg.global_debuglevel merged)
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1126 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1129 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1132 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1135 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1138 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1141 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1144 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1147 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch1ch13' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1151 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1154 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1157 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1160 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1163 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1166 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1169 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:1172 rtl92d_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow 'cckswing_table_ch14' 33 <= 255
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192de/dm.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/dm.c b/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
index 47875ba..eaeee77 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
@@ -840,9 +840,9 @@ static void rtl92d_dm_txpower_tracking_callback_thermalmeter(
bool internal_pa = false;
long ele_a = 0, ele_d, temp_cck, val_x, value32;
long val_y, ele_c = 0;
- u8 ofdm_index[2];
+ u8 ofdm_index[3];
s8 cck_index = 0;
- u8 ofdm_index_old[2] = {0, 0};
+ u8 ofdm_index_old[3] = {0, 0, 0};
s8 cck_index_old = 0;
u8 index;
int i;
@@ -1118,6 +1118,10 @@ static void rtl92d_dm_txpower_tracking_callback_thermalmeter(
val_x, val_y, ele_a, ele_c, ele_d,
val_x, val_y);
+ if (cck_index >= CCK_TABLE_SIZE)
+ cck_index = CCK_TABLE_SIZE - 1;
+ if (cck_index < 0)
+ cck_index = 0;
if (rtlhal->current_bandtype == BAND_ON_2_4G) {
/* Adjust CCK according to IQK result */
if (!rtlpriv->dm.cck_inch14) {
--
1.8.1.4
^ permalink raw reply related
* [PATCH 0/7] rtlwifi: Patches to fix problems shown by smatch
From: Larry Finger @ 2013-09-13 17:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
*** BLURB HERE ***
Larry Finger (7):
rtlwifi: rtl8192du: Fix smatch errors in /rtl8192de/dm.c
rtlwifi: rtl8192de: Fix smatch warnings in rtl8192de/hw.c
rtlwifi: rtl8192cu: Fix smatch warning in rtl8192cu/trx.c
rtlwifi: rtl8192_common: Fix smatch errors and warnings in
rtl8192c/dm_common.c
rtlwifi: Fix smatch warning in pci.c
rtlwifi: Fix smatch warnings in usb.c
rtlwifi: rtl8188ee: Fix smatch warning in rtl8188ee/hw.c
drivers/net/wireless/rtlwifi/pci.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8188ee/hw.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c | 4 +-
drivers/net/wireless/rtlwifi/rtl8192cu/mac.c | 187 +---------------------
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192de/dm.c | 8 +-
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2 +
drivers/net/wireless/rtlwifi/usb.c | 10 +-
8 files changed, 23 insertions(+), 193 deletions(-)
--
1.8.1.4
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192cu: Convert driver to use rtl_process_phyinfo()
From: Larry Finger @ 2013-09-13 17:44 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
Remove routine _rtl92c_process_phyinfo() by using the equivalent routine
in driver rtlwifi.
This change also allows the removal of 5 additional routines from rtl8192cu.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/rtl8192cu/mac.c | 187 +--------------------------
1 file changed, 2 insertions(+), 185 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c b/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c
index da4f587..3936853 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/mac.c
@@ -32,6 +32,7 @@
#include "../usb.h"
#include "../ps.h"
#include "../cam.h"
+#include "../stats.h"
#include "reg.h"
#include "def.h"
#include "phy.h"
@@ -738,16 +739,6 @@ static u8 _rtl92c_evm_db_to_percentage(char value)
return ret_val;
}
-static long _rtl92c_translate_todbm(struct ieee80211_hw *hw,
- u8 signal_strength_index)
-{
- long signal_power;
-
- signal_power = (long)((signal_strength_index + 1) >> 1);
- signal_power -= 95;
- return signal_power;
-}
-
static long _rtl92c_signal_scale_mapping(struct ieee80211_hw *hw,
long currsig)
{
@@ -913,180 +904,6 @@ static void _rtl92c_query_rxphystatus(struct ieee80211_hw *hw,
(hw, total_rssi /= rf_rx_num));
}
-static void _rtl92c_process_ui_rssi(struct ieee80211_hw *hw,
- struct rtl_stats *pstats)
-{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- struct rtl_phy *rtlphy = &(rtlpriv->phy);
- u8 rfpath;
- u32 last_rssi, tmpval;
-
- if (pstats->packet_toself || pstats->packet_beacon) {
- rtlpriv->stats.rssi_calculate_cnt++;
- if (rtlpriv->stats.ui_rssi.total_num++ >=
- PHY_RSSI_SLID_WIN_MAX) {
- rtlpriv->stats.ui_rssi.total_num =
- PHY_RSSI_SLID_WIN_MAX;
- last_rssi =
- rtlpriv->stats.ui_rssi.elements[rtlpriv->
- stats.ui_rssi.index];
- rtlpriv->stats.ui_rssi.total_val -= last_rssi;
- }
- rtlpriv->stats.ui_rssi.total_val += pstats->signalstrength;
- rtlpriv->stats.ui_rssi.elements[rtlpriv->stats.ui_rssi.
- index++] = pstats->signalstrength;
- if (rtlpriv->stats.ui_rssi.index >= PHY_RSSI_SLID_WIN_MAX)
- rtlpriv->stats.ui_rssi.index = 0;
- tmpval = rtlpriv->stats.ui_rssi.total_val /
- rtlpriv->stats.ui_rssi.total_num;
- rtlpriv->stats.signal_strength =
- _rtl92c_translate_todbm(hw, (u8) tmpval);
- pstats->rssi = rtlpriv->stats.signal_strength;
- }
- if (!pstats->is_cck && pstats->packet_toself) {
- for (rfpath = RF90_PATH_A; rfpath < rtlphy->num_total_rfpath;
- rfpath++) {
- if (!rtl8192_phy_check_is_legal_rfpath(hw, rfpath))
- continue;
- if (rtlpriv->stats.rx_rssi_percentage[rfpath] == 0) {
- rtlpriv->stats.rx_rssi_percentage[rfpath] =
- pstats->rx_mimo_signalstrength[rfpath];
- }
- if (pstats->rx_mimo_signalstrength[rfpath] >
- rtlpriv->stats.rx_rssi_percentage[rfpath]) {
- rtlpriv->stats.rx_rssi_percentage[rfpath] =
- ((rtlpriv->stats.
- rx_rssi_percentage[rfpath] *
- (RX_SMOOTH_FACTOR - 1)) +
- (pstats->rx_mimo_signalstrength[rfpath])) /
- (RX_SMOOTH_FACTOR);
-
- rtlpriv->stats.rx_rssi_percentage[rfpath] =
- rtlpriv->stats.rx_rssi_percentage[rfpath] +
- 1;
- } else {
- rtlpriv->stats.rx_rssi_percentage[rfpath] =
- ((rtlpriv->stats.
- rx_rssi_percentage[rfpath] *
- (RX_SMOOTH_FACTOR - 1)) +
- (pstats->rx_mimo_signalstrength[rfpath])) /
- (RX_SMOOTH_FACTOR);
- }
- }
- }
-}
-
-static void _rtl92c_update_rxsignalstatistics(struct ieee80211_hw *hw,
- struct rtl_stats *pstats)
-{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- int weighting = 0;
-
- if (rtlpriv->stats.recv_signal_power == 0)
- rtlpriv->stats.recv_signal_power = pstats->recvsignalpower;
- if (pstats->recvsignalpower > rtlpriv->stats.recv_signal_power)
- weighting = 5;
- else if (pstats->recvsignalpower < rtlpriv->stats.recv_signal_power)
- weighting = (-5);
- rtlpriv->stats.recv_signal_power =
- (rtlpriv->stats.recv_signal_power * 5 +
- pstats->recvsignalpower + weighting) / 6;
-}
-
-static void _rtl92c_process_pwdb(struct ieee80211_hw *hw,
- struct rtl_stats *pstats)
-{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
- long undec_sm_pwdb = 0;
-
- if (mac->opmode == NL80211_IFTYPE_ADHOC) {
- return;
- } else {
- undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb;
- }
- if (pstats->packet_toself || pstats->packet_beacon) {
- if (undec_sm_pwdb < 0)
- undec_sm_pwdb = pstats->rx_pwdb_all;
- if (pstats->rx_pwdb_all > (u32) undec_sm_pwdb) {
- undec_sm_pwdb = (((undec_sm_pwdb) *
- (RX_SMOOTH_FACTOR - 1)) +
- (pstats->rx_pwdb_all)) / (RX_SMOOTH_FACTOR);
- undec_sm_pwdb += 1;
- } else {
- undec_sm_pwdb = (((undec_sm_pwdb) *
- (RX_SMOOTH_FACTOR - 1)) +
- (pstats->rx_pwdb_all)) / (RX_SMOOTH_FACTOR);
- }
- rtlpriv->dm.undec_sm_pwdb = undec_sm_pwdb;
- _rtl92c_update_rxsignalstatistics(hw, pstats);
- }
-}
-
-static void _rtl92c_process_LINK_Q(struct ieee80211_hw *hw,
- struct rtl_stats *pstats)
-{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- u32 last_evm = 0, n_stream, tmpval;
-
- if (pstats->signalquality != 0) {
- if (pstats->packet_toself || pstats->packet_beacon) {
- if (rtlpriv->stats.LINK_Q.total_num++ >=
- PHY_LINKQUALITY_SLID_WIN_MAX) {
- rtlpriv->stats.LINK_Q.total_num =
- PHY_LINKQUALITY_SLID_WIN_MAX;
- last_evm =
- rtlpriv->stats.LINK_Q.elements
- [rtlpriv->stats.LINK_Q.index];
- rtlpriv->stats.LINK_Q.total_val -=
- last_evm;
- }
- rtlpriv->stats.LINK_Q.total_val +=
- pstats->signalquality;
- rtlpriv->stats.LINK_Q.elements
- [rtlpriv->stats.LINK_Q.index++] =
- pstats->signalquality;
- if (rtlpriv->stats.LINK_Q.index >=
- PHY_LINKQUALITY_SLID_WIN_MAX)
- rtlpriv->stats.LINK_Q.index = 0;
- tmpval = rtlpriv->stats.LINK_Q.total_val /
- rtlpriv->stats.LINK_Q.total_num;
- rtlpriv->stats.signal_quality = tmpval;
- rtlpriv->stats.last_sigstrength_inpercent = tmpval;
- for (n_stream = 0; n_stream < 2;
- n_stream++) {
- if (pstats->RX_SIGQ[n_stream] != -1) {
- if (!rtlpriv->stats.RX_EVM[n_stream]) {
- rtlpriv->stats.RX_EVM[n_stream]
- = pstats->RX_SIGQ[n_stream];
- }
- rtlpriv->stats.RX_EVM[n_stream] =
- ((rtlpriv->stats.RX_EVM
- [n_stream] *
- (RX_SMOOTH_FACTOR - 1)) +
- (pstats->RX_SIGQ
- [n_stream] * 1)) /
- (RX_SMOOTH_FACTOR);
- }
- }
- }
- } else {
- ;
- }
-}
-
-static void _rtl92c_process_phyinfo(struct ieee80211_hw *hw,
- u8 *buffer,
- struct rtl_stats *pcurrent_stats)
-{
- if (!pcurrent_stats->packet_matchbssid &&
- !pcurrent_stats->packet_beacon)
- return;
- _rtl92c_process_ui_rssi(hw, pcurrent_stats);
- _rtl92c_process_pwdb(hw, pcurrent_stats);
- _rtl92c_process_LINK_Q(hw, pcurrent_stats);
-}
-
void rtl92c_translate_rx_signal_stuff(struct ieee80211_hw *hw,
struct sk_buff *skb,
struct rtl_stats *pstats,
@@ -1123,5 +940,5 @@ void rtl92c_translate_rx_signal_stuff(struct ieee80211_hw *hw,
_rtl92c_query_rxphystatus(hw, pstats, pdesc, p_drvinfo,
packet_matchbssid, packet_toself,
packet_beacon);
- _rtl92c_process_phyinfo(hw, tmp_buf, pstats);
+ rtl_process_phyinfo(hw, tmp_buf, pstats);
}
--
1.8.1.4
^ permalink raw reply related
* Re: brcmfmac, BCM43241
From: Jan-Oliver Kaiser @ 2013-09-13 17:41 UTC (permalink / raw)
To: frankyl; +Cc: linux-wireless
In-Reply-To: <52334860.1050505@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Hi Franky,
The nvram file is attached to this mail. I am using aptosid, based on
Debian unstable.
Best regards,
Jan-Oliver
On 09/13/2013 07:16 PM, Franky Lin wrote:
> On 09/11/2013 01:35 PM, Jan-Oliver Kaiser wrote:
>> I copied the firmware to /lib/firmware/brcm/brcmfmac-sdio.bin and copied
>> the content of /dev/nvram to /lib/firmware/brcm/brcmfmac-sdio.txt.
> Hi Jan-Oliver,
>
> Could you share me the nvram file you retrieve through /dev/nvram? Which
> distro are you using?
>
> Thanks,
> Franky
>
[-- Attachment #2: nvram --]
[-- Type: text/plain, Size: 114 bytes --]
ÿ\0ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ\x1dâÿÿ ÿÿ\a\0\x12\0\0\0\0\0\0\0\0V\0\0\0\x01ÿ\x01\x01ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ\a\0ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
^ permalink raw reply
* RE: problems setting the channel
From: Albert Lo @ 2013-09-13 17:30 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <523349B1.8010306@candelatech.com>
Hi Ben,
yes, for normal use, I shouldn't have to specify the channel.
But I have a not normal use case.
Thx.
cheers,
Albert
________________________________________
From: Ben Greear <greearb@candelatech.com>
Sent: Friday, September 13, 2013 10:21 AM
To: Albert Lo
Cc: linux-wireless@vger.kernel.org
Subject: Re: problems setting the channel
On 09/13/2013 10:11 AM, Albert Lo wrote:
>
> Hello,
>
> Forgive the newbie question, but I'm having a hard time setting the channel. Here is my output:
>
> ======================================
> root@OpenWrt:~# iw dev wlan0 info
> Interface wlan0
> ifindex 7
> wdev 0x2
> addr 04:f0:21:01:1b:91
> type AP
> wiphy 0
> channel 11 (2462 MHz) NO HT
> root@OpenWrt:~# iw reg get
> country US:
> (2402 - 2472 @ 40), (3, 27)
> (5170 - 5250 @ 40), (3, 17)
> (5250 - 5330 @ 40), (3, 20), DFS
> (5490 - 5600 @ 40), (3, 20), DFS
> (5650 - 5710 @ 40), (3, 20), DFS
> (5735 - 5835 @ 40), (3, 30)
> root@OpenWrt:/# iw dev wlan0 set channel 10
> root@OpenWrt:/# iw dev wlan0 set channel 19
> command failed: Invalid argument (-22)
> ==================================================
>
>
> Any ideas why setting channel to 10 is ok, but setting channel to 19 fails?
> I do notice that my phy is split into two parts, Band1 and Band2.
There is no channel 19. Band2 starts at channel 36.
> Frequencies:
> * 5180 MHz [36] (17.0 dBm)
> * 5200 MHz [40] (17.0 dBm)
> * 5220 MHz [44] (17.0 dBm)
> * 5240 MHz [48] (17.0 dBm)
> * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5600 MHz [120] (disabled)
> * 5620 MHz [124] (disabled)
> * 5640 MHz [128] (disabled)
> * 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5745 MHz [149] (30.0 dBm)
> * 5765 MHz [153] (30.0 dBm)
> * 5785 MHz [157] (30.0 dBm)
> * 5805 MHz [161] (30.0 dBm)
> * 5825 MHz [165] (30.0 dBm)
For normal use, you usually don't need to specify the channel anyway, by the way.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: problems setting the channel
From: Albert Lo @ 2013-09-13 17:29 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <523349F2.2000702@lwfinger.net>
Hi Larry,
Thanks for the info. I tried setting the channel to one that is listed in the link you provided, and even to one that is listed in phy info. ch=36 is nice and safe.
however when I type:
> iw dev wlan0 info
It is still reporting it's on the old channel (11).
Any ideas why it is reporting the old channel?
Thx.
Cheers,
Albert
________________________________________
From: Larry Finger <larry.finger@gmail.com> on behalf of Larry Finger <Larry.Finger@lwfinger.net>
Sent: Friday, September 13, 2013 10:22 AM
To: Albert Lo
Cc: linux-wireless@vger.kernel.org
Subject: Re: problems setting the channel
On 09/13/2013 12:11 PM, Albert Lo wrote:
>
> Hello,
>
> Forgive the newbie question, but I'm having a hard time setting the channel. Here is my output:
>
> ======================================
> root@OpenWrt:~# iw dev wlan0 info
> Interface wlan0
> ifindex 7
> wdev 0x2
> addr 04:f0:21:01:1b:91
> type AP
> wiphy 0
> channel 11 (2462 MHz) NO HT
> root@OpenWrt:~# iw reg get
> country US:
> (2402 - 2472 @ 40), (3, 27)
> (5170 - 5250 @ 40), (3, 17)
> (5250 - 5330 @ 40), (3, 20), DFS
> (5490 - 5600 @ 40), (3, 20), DFS
> (5650 - 5710 @ 40), (3, 20), DFS
> (5735 - 5835 @ 40), (3, 30)
> root@OpenWrt:/# iw dev wlan0 set channel 10
> root@OpenWrt:/# iw dev wlan0 set channel 19
> command failed: Invalid argument (-22)
--snip--
> Any ideas as to how I can set wlan0 to the channels in Band2?
There is no channel 19 in wifi! That is the reason you cannot select it.
To select Band 2, you would need a dual-band Access Point. Do you have one?
Clearly, you have little knowledge of wifi. I suggest you read
http://en.wikipedia.org/wiki/List_of_WLAN_channels.
Larry
^ permalink raw reply
* Re: problems setting the channel
From: Larry Finger @ 2013-09-13 17:22 UTC (permalink / raw)
To: Albert Lo; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <bd4dc3b2edbb45789121bddb33960aa2@CO1PR05MB345.namprd05.prod.outlook.com>
On 09/13/2013 12:11 PM, Albert Lo wrote:
>
> Hello,
>
> Forgive the newbie question, but I'm having a hard time setting the channel. Here is my output:
>
> ======================================
> root@OpenWrt:~# iw dev wlan0 info
> Interface wlan0
> ifindex 7
> wdev 0x2
> addr 04:f0:21:01:1b:91
> type AP
> wiphy 0
> channel 11 (2462 MHz) NO HT
> root@OpenWrt:~# iw reg get
> country US:
> (2402 - 2472 @ 40), (3, 27)
> (5170 - 5250 @ 40), (3, 17)
> (5250 - 5330 @ 40), (3, 20), DFS
> (5490 - 5600 @ 40), (3, 20), DFS
> (5650 - 5710 @ 40), (3, 20), DFS
> (5735 - 5835 @ 40), (3, 30)
> root@OpenWrt:/# iw dev wlan0 set channel 10
> root@OpenWrt:/# iw dev wlan0 set channel 19
> command failed: Invalid argument (-22)
--snip--
> Any ideas as to how I can set wlan0 to the channels in Band2?
There is no channel 19 in wifi! That is the reason you cannot select it.
To select Band 2, you would need a dual-band Access Point. Do you have one?
Clearly, you have little knowledge of wifi. I suggest you read
http://en.wikipedia.org/wiki/List_of_WLAN_channels.
Larry
^ permalink raw reply
* Re: problems setting the channel
From: Ben Greear @ 2013-09-13 17:21 UTC (permalink / raw)
To: Albert Lo; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <bd4dc3b2edbb45789121bddb33960aa2@CO1PR05MB345.namprd05.prod.outlook.com>
On 09/13/2013 10:11 AM, Albert Lo wrote:
>
> Hello,
>
> Forgive the newbie question, but I'm having a hard time setting the channel. Here is my output:
>
> ======================================
> root@OpenWrt:~# iw dev wlan0 info
> Interface wlan0
> ifindex 7
> wdev 0x2
> addr 04:f0:21:01:1b:91
> type AP
> wiphy 0
> channel 11 (2462 MHz) NO HT
> root@OpenWrt:~# iw reg get
> country US:
> (2402 - 2472 @ 40), (3, 27)
> (5170 - 5250 @ 40), (3, 17)
> (5250 - 5330 @ 40), (3, 20), DFS
> (5490 - 5600 @ 40), (3, 20), DFS
> (5650 - 5710 @ 40), (3, 20), DFS
> (5735 - 5835 @ 40), (3, 30)
> root@OpenWrt:/# iw dev wlan0 set channel 10
> root@OpenWrt:/# iw dev wlan0 set channel 19
> command failed: Invalid argument (-22)
> ==================================================
>
>
> Any ideas why setting channel to 10 is ok, but setting channel to 19 fails?
> I do notice that my phy is split into two parts, Band1 and Band2.
There is no channel 19. Band2 starts at channel 36.
> Frequencies:
> * 5180 MHz [36] (17.0 dBm)
> * 5200 MHz [40] (17.0 dBm)
> * 5220 MHz [44] (17.0 dBm)
> * 5240 MHz [48] (17.0 dBm)
> * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5600 MHz [120] (disabled)
> * 5620 MHz [124] (disabled)
> * 5640 MHz [128] (disabled)
> * 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5745 MHz [149] (30.0 dBm)
> * 5765 MHz [153] (30.0 dBm)
> * 5785 MHz [157] (30.0 dBm)
> * 5805 MHz [161] (30.0 dBm)
> * 5825 MHz [165] (30.0 dBm)
For normal use, you usually don't need to specify the channel anyway, by the way.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: brcmfmac, BCM43241
From: Franky Lin @ 2013-09-13 17:16 UTC (permalink / raw)
To: mail; +Cc: linux-wireless
In-Reply-To: <5230D40B.20704@janno-kaiser.de>
On 09/11/2013 01:35 PM, Jan-Oliver Kaiser wrote:
> I copied the firmware to /lib/firmware/brcm/brcmfmac-sdio.bin and copied
> the content of /dev/nvram to /lib/firmware/brcm/brcmfmac-sdio.txt.
Hi Jan-Oliver,
Could you share me the nvram file you retrieve through /dev/nvram? Which
distro are you using?
Thanks,
Franky
^ permalink raw reply
* problems setting the channel
From: Albert Lo @ 2013-09-13 17:11 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hello,
Forgive the newbie question, but I'm having a hard time setting the channel. Here is my output:
======================================
root@OpenWrt:~# iw dev wlan0 info
Interface wlan0
ifindex 7
wdev 0x2
addr 04:f0:21:01:1b:91
type AP
wiphy 0
channel 11 (2462 MHz) NO HT
root@OpenWrt:~# iw reg get
country US:
(2402 - 2472 @ 40), (3, 27)
(5170 - 5250 @ 40), (3, 17)
(5250 - 5330 @ 40), (3, 20), DFS
(5490 - 5600 @ 40), (3, 20), DFS
(5650 - 5710 @ 40), (3, 20), DFS
(5735 - 5835 @ 40), (3, 30)
root@OpenWrt:/# iw dev wlan0 set channel 10
root@OpenWrt:/# iw dev wlan0 set channel 19
command failed: Invalid argument (-22)
==================================================
Any ideas why setting channel to 10 is ok, but setting channel to 19 fails?
I do notice that my phy is split into two parts, Band1 and Band2.
==================================================
root@OpenWrt:~# iw phy phy0 info
Wiphy phy0
Band 1:
Capabilities: 0x11ce
HT20/HT40
SM Power Save disabled
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:
* 2412 MHz [1] (27.0 dBm)
* 2417 MHz [2] (27.0 dBm)
* 2422 MHz [3] (27.0 dBm)
* 2427 MHz [4] (27.0 dBm)
* 2432 MHz [5] (27.0 dBm)
* 2437 MHz [6] (27.0 dBm)
* 2442 MHz [7] (27.0 dBm)
* 2447 MHz [8] (27.0 dBm)
* 2452 MHz [9] (27.0 dBm)
* 2457 MHz [10] (27.0 dBm)
* 2462 MHz [11] (27.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Band 2:
Capabilities: 0x11ce
HT20/HT40
SM Power Save disabled
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-15
Frequencies:
* 5180 MHz [36] (17.0 dBm)
* 5200 MHz [40] (17.0 dBm)
* 5220 MHz [44] (17.0 dBm)
* 5240 MHz [48] (17.0 dBm)
* 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
.......
Any ideas as to how I can set wlan0 to the channels in Band2?
Best Regards,
Albert
^ permalink raw reply
* [PATCH] ath9k: mark wmi_event_swba as __packed
From: Chris Metcalf @ 2013-09-13 16:14 UTC (permalink / raw)
To: Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
Senthil Balasubramanian, John W. Linville, linux-wireless,
ath9k-devel, netdev, linux-kernel
The other structures in wmi.h are already marked this way.
Without this marking, we get an unaliged access panic in the tilegx kernel:
Starting stack dump of tid 0, pid 0 (swapper) on cpu 35 at cycle 198675113844
frame 0: 0xfffffff7103ada90 ath9k_htc_swba+0x120/0x618 [ath9k_htc]
frame 1: 0xfffffff7103a4b10 ath9k_wmi_event_tasklet+0x1b0/0x270 [ath9k_htc]
frame 2: 0xfffffff700326570 tasklet_action+0x148/0x298
[...]
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
---
drivers/net/wireless/ath/ath9k/wmi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/wmi.h b/drivers/net/wireless/ath/ath9k/wmi.h
index fde6da6..0db37f2 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.h
+++ b/drivers/net/wireless/ath/ath9k/wmi.h
@@ -39,7 +39,7 @@ struct wmi_fw_version {
struct wmi_event_swba {
__be64 tsf;
u8 beacon_pending;
-};
+} __packed;
/*
* 64 - HTC header - WMI header - 1 / txstatus
--
1.8.3.1
^ permalink raw reply related
* Re: WEP/WPA/WPA2 implementation in software
From: Oleksij Rempel @ 2013-09-13 14:24 UTC (permalink / raw)
To: Prabhunath G; +Cc: linux-wireless, kernelnewbies
In-Reply-To: <CACPKTAM-mtTS7QVSq817TQ11dS-cLA+nKgXF6yDGYvxw9rhucw@mail.gmail.com>
Am 13.09.2013 13:53, schrieb Prabhunath G:
> Dear All,
>
> Suppose there is no hardware support for
> encryption/decryption for Wi-Fi devices. Will the data be
> encrypted/decrypted by software implementation. If yes, is it done at
> the application level or at the kernel level (mac80211).
> Kindly clarify.
> If the question has to be rephrased, please do it
Hi,
see hostapd on AP site and wpa_supplicant on STA:
http://wireless.kernel.org/en/users/Documentation/wpa_supplicant
http://wireless.kernel.org/en/users/Documentation/hostapd
check documentation here on:
http://wireless.kernel.org/en/users/Documentation
may be it will answer some of your questions.
--
Regards,
Oleksij
^ permalink raw reply
* Re: regulatory will stuck when cfg80211 is built-in
From: Eugene Krasnikov @ 2013-09-13 14:12 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87d2ogtv57.fsf@purkki.adurom.net>
Let me try to describe the problem in more details:
1) When user space is calling "iw reg set <contry_code>" iw utility
will send NL80211_CMD_REQ_SET_REG through nl80211 to cfg80211.
2) cfg80211 will process this call in reg_todo work that is defined
here https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/tree/net/wireless/reg.c#n1621
3) reg_todo work is calling reg_process_pending_hints to process the
call from user space where it checks if last request was
processed(https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/tree/net/wireless/reg.c#n1576).
But last request is still there! This last request is
"NL80211_REGDOM_SET_BY_CORE" request that cfg80211 sent on init for
first regulatory domain initialization.
So the problem is that the first request that is sent by inbuilt
cfg80211 will be never process and will always stay in last_request
variable(https://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/tree/net/wireless/reg.c#n91)
Kalle, did you ever tried inbuilt into kernel cfg80211? This problem
is 100% reproducible because inbuilt modules will be always initialize
before user space.
2013/9/10 Kalle Valo <kvalo@adurom.com>:
> Eugene Krasnikov <k.eugene.e@gmail.com> writes:
>
>> No, the flag CONFIG_CFG80211_INTERNAL_REGDB does not help and it should not.
>>
>> The problem is that cfg80211 will stuck in situation when cfg80211 is
>> initialized before user space. One way to get cfg80211 out of this
>> state is to run crda once right after user space is up and running.
>> But again is this intentional? Or it is more like a workaround?
>
> With the internal regdb you do not need crda anymore, so why does it still
> get stuck? Where does it exactly get stuck?
>
> --
> Kalle Valo
--
Best regards,
Eugene
^ permalink raw reply
* Re: WEP/WPA/WPA2 implementation in software
From: Valdis.Kletnieks @ 2013-09-13 13:32 UTC (permalink / raw)
To: Prabhunath G; +Cc: linux-wireless, kernelnewbies
In-Reply-To: <CACPKTAM-mtTS7QVSq817TQ11dS-cLA+nKgXF6yDGYvxw9rhucw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 800 bytes --]
On Fri, 13 Sep 2013 17:23:22 +0530, Prabhunath G said:
> Suppose there is no hardware support for
> encryption/decryption for Wi-Fi devices
1) Do not use WEP. It's busted. It's *known* busted. You transmit
packets for more than a minute or so using WEP, you may as well not
bother with crypto at all. Yes, it's really that busted.
2) You're much better off spending the $15 to get a wireless card
that actually has hardware WPA2 support on it. The devices are
cheap, there's no reason to inflict pain on yourself.
I'd not be at all surprised if a card that doesn't have crypto
support isn't *also* lacking other hardware support for WPA/WPA2
So while it may well be *possible* to do it in software, I'd have
to rank it as one of the more masochistic ideas I've heard in a
long time.
[-- Attachment #2: Type: application/pgp-signature, Size: 865 bytes --]
^ permalink raw reply
* Re: rtl8192cu: testing with EdiMax USB
From: Mark Cave-Ayland @ 2013-09-13 13:27 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <52330CB4.7020902@ilande.co.uk>
On 13/09/13 14:01, Mark Cave-Ayland wrote:
>> I spent a bit more time tinkering further with debug=0x5, forgetting
>> that I had left your last diagnostic patch applied. Based upon when the
>> beacon output disappears in the logs (after updating the power
>> registers), it does seem likely that is a power-related problem.
>
> FWIW I just tried a quick test where I commented out the entire
> rtl92c_dm_txpower_tracking_callback_thermalmeter() function to make it a
> nop, and that didn't seem to make any difference...
Aha! The following diff to remove the call to rtl92c_dm_diginit() keeps
me associated to the AP:
diff --git a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
index d2d57a2..c18362d 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
@@ -1275,7 +1275,7 @@ void rtl92c_dm_init(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
rtlpriv->dm.dm_type = DM_TYPE_BYDRIVER;
- rtl92c_dm_diginit(hw);
+ //rtl92c_dm_diginit(hw);
rtl92c_dm_init_dynamic_txpower(hw);
rtl92c_dm_init_edca_turbo(hw);
rtl92c_dm_init_rate_adaptive_mask(hw);
However, dhclient still takes a very long time get an IP address and the
connection seems extremely lossy, much like it was when I could get a
connection before. Perhaps there are two different bugs here, one for
the association and one for the data loss?
ATB,
Mark.
^ permalink raw reply related
* Re: rtl8192cu: testing with EdiMax USB
From: Mark Cave-Ayland @ 2013-09-13 13:01 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <5232DAF0.6040907@ilande.co.uk>
On 13/09/13 10:29, Mark Cave-Ayland wrote:
> I spent a bit more time tinkering further with debug=0x5, forgetting
> that I had left your last diagnostic patch applied. Based upon when the
> beacon output disappears in the logs (after updating the power
> registers), it does seem likely that is a power-related problem.
FWIW I just tried a quick test where I commented out the entire
rtl92c_dm_txpower_tracking_callback_thermalmeter() function to make it a
nop, and that didn't seem to make any difference...
ATB,
Mark.
^ permalink raw reply
* [PATCHv2 7/7] ath10k: remove wmi event worker thread
From: Michal Kazior @ 2013-09-13 12:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1379074618-30534-1-git-send-email-michal.kazior@tieto.com>
It's not really necessary to have this processed
in a worker. There are no sleepable calls (and
actually shouldn't be).
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.h | 3 ---
drivers/net/wireless/ath/ath10k/wmi.c | 44 +-------------------------------
2 files changed, 1 insertion(+), 46 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index c2b6a76..fcf94ee 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -113,9 +113,6 @@ struct ath10k_wmi {
struct completion service_ready;
struct completion unified_ready;
wait_queue_head_t tx_credits_wq;
-
- struct sk_buff_head wmi_event_list;
- struct work_struct wmi_event_work;
};
struct ath10k_peer_stat {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index b29d2b9..6803ead 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1055,7 +1055,7 @@ static int ath10k_wmi_ready_event_rx(struct ath10k *ar, struct sk_buff *skb)
return 0;
}
-static void ath10k_wmi_event_process(struct ath10k *ar, struct sk_buff *skb)
+static void ath10k_wmi_process_rx(struct ath10k *ar, struct sk_buff *skb)
{
struct wmi_cmd_hdr *cmd_hdr;
enum wmi_event_id id;
@@ -1174,43 +1174,6 @@ static void ath10k_wmi_event_process(struct ath10k *ar, struct sk_buff *skb)
dev_kfree_skb(skb);
}
-static void ath10k_wmi_event_work(struct work_struct *work)
-{
- struct ath10k *ar = container_of(work, struct ath10k,
- wmi.wmi_event_work);
- struct sk_buff *skb;
-
- for (;;) {
- skb = skb_dequeue(&ar->wmi.wmi_event_list);
- if (!skb)
- break;
-
- ath10k_wmi_event_process(ar, skb);
- }
-}
-
-static void ath10k_wmi_process_rx(struct ath10k *ar, struct sk_buff *skb)
-{
- struct wmi_cmd_hdr *cmd_hdr = (struct wmi_cmd_hdr *)skb->data;
- enum wmi_event_id event_id;
-
- event_id = MS(__le32_to_cpu(cmd_hdr->cmd_id), WMI_CMD_HDR_CMD_ID);
-
- /* some events require to be handled ASAP
- * thus can't be defered to a worker thread */
- switch (event_id) {
- case WMI_MGMT_RX_EVENTID:
- case WMI_HOST_SWBA_EVENTID:
- ath10k_wmi_event_process(ar, skb);
- return;
- default:
- break;
- }
-
- skb_queue_tail(&ar->wmi.wmi_event_list, skb);
- queue_work(ar->workqueue, &ar->wmi.wmi_event_work);
-}
-
/* WMI Initialization functions */
int ath10k_wmi_attach(struct ath10k *ar)
{
@@ -1218,16 +1181,11 @@ int ath10k_wmi_attach(struct ath10k *ar)
init_completion(&ar->wmi.unified_ready);
init_waitqueue_head(&ar->wmi.tx_credits_wq);
- skb_queue_head_init(&ar->wmi.wmi_event_list);
- INIT_WORK(&ar->wmi.wmi_event_work, ath10k_wmi_event_work);
-
return 0;
}
void ath10k_wmi_detach(struct ath10k *ar)
{
- cancel_work_sync(&ar->wmi.wmi_event_work);
- skb_queue_purge(&ar->wmi.wmi_event_list);
}
int ath10k_wmi_connect_htc_service(struct ath10k *ar)
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox