[PATCH] ath10k: Fix target to cpu address conversion logic
'commit 418ca5992e2f (ath10k: Make target cpu address to CE address conversion chip specific)' mask 0x7fff is added by mistake instead of 0x7ff. Fix this regression. Signed-off-by: Vasanthakumar Thiagarajan vthia...@qti.qualcomm.com --- drivers/net/wireless/ath/ath10k/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c index 130746b..a69bfa4 100644 --- a/drivers/net/wireless/ath/ath10k/pci.c +++ b/drivers/net/wireless/ath/ath10k/pci.c @@ -765,7 +765,7 @@ static u32 ath10k_pci_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr) case ATH10K_HW_QCA6174: val = (ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS + CORE_CTRL_ADDRESS) - 0x7fff) 21; + 0x7ff) 21; break; case ATH10K_HW_QCA99X0: val = ath10k_pci_read32(ar, PCIE_BAR_REG_ADDRESS); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-regdb: update CA rules for 5600 - 5650 mHz
On Fri, Jul 3, 2015 at 4:08 AM, Zefir Kurtisi zefir.kurt...@neratec.com wrote: On 07/02/2015 07:44 AM, Wei Zhong wrote: commit 2fef4cad8a1bd9cbbf178e59a1b3ca672b057095 Author: Wei Zhong wzh...@google.com Date: Wed Jul 1 22:39:09 2015 -0700 wireless-regdb: update CA rules for 5600 - 5650 mHz Related regulation: http://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10971.html#s6.2.3 Frequency Bands 5470-5600 MHz and 5650-5725 MHz Until further notice, devices subject to this section [i.e. Wifi device supporting 5 GHz bands] shall not be capable of transmitting in the band 5600-5650 MHz. This restriction is for the protection of Environment Canada’s weather radars operating in this band. diff --git a/db.txt b/db.txt index 809cd3c..da0cfad 100644 --- a/db.txt +++ b/db.txt @@ -216,7 +216,8 @@ country CA: DFS-FCC (2402 - 2472 @ 40), (30) (5170 - 5250 @ 80), (17), AUTO-BW (5250 - 5330 @ 80), (24), DFS, AUTO-BW - (5490 - 5730 @ 160), (24), DFS + (5490 - 5600 @ 80), (24), DFS + (5650 - 5730 @ 40), (24), DFS (5735 - 5835 @ 80), (30) # Source: -- I believe this could also be interpreted differently. If the change is only about removing the weather radar band (5600-5650), the change should be - (5490 - 5730 @ 160), (24), DFS + (5490 - 5570 @ 80), (24), DFS + (5570 - 5590 @ 20), (24), DFS + (5650 - 5730 @ 80), (24), DFS The second rule explicitly states that channel 116 remains available for HT20. If this level of strict correctness is not needed, rule 1 and 2 combined would be - (5490 - 5730 @ 160), (24), DFS + (5490 - 5590 @ 80), (24), DFS I agree. 5590 is more strict than 5600. + (5650 - 5730 @ 80), (24), DFS 5690 MHz is not a channel can be used, is it still necessary to mark this band as 80MHz while in practice it is not possible to fully unitize the entire band? Cheers Zefir -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-regdb: update CA rules for 5600 - 5650 mHz
On 07/03/2015 04:20 PM, Wei Zhong wrote: On Fri, Jul 3, 2015 at 4:08 AM, Zefir Kurtisi zefir.kurt...@neratec.com wrote: On 07/02/2015 07:44 AM, Wei Zhong wrote: commit 2fef4cad8a1bd9cbbf178e59a1b3ca672b057095 Author: Wei Zhong wzh...@google.com Date: Wed Jul 1 22:39:09 2015 -0700 wireless-regdb: update CA rules for 5600 - 5650 mHz Related regulation: http://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10971.html#s6.2.3 Frequency Bands 5470-5600 MHz and 5650-5725 MHz Until further notice, devices subject to this section [i.e. Wifi device supporting 5 GHz bands] shall not be capable of transmitting in the band 5600-5650 MHz. This restriction is for the protection of Environment Canada’s weather radars operating in this band. diff --git a/db.txt b/db.txt index 809cd3c..da0cfad 100644 --- a/db.txt +++ b/db.txt @@ -216,7 +216,8 @@ country CA: DFS-FCC (2402 - 2472 @ 40), (30) (5170 - 5250 @ 80), (17), AUTO-BW (5250 - 5330 @ 80), (24), DFS, AUTO-BW - (5490 - 5730 @ 160), (24), DFS + (5490 - 5600 @ 80), (24), DFS + (5650 - 5730 @ 40), (24), DFS (5735 - 5835 @ 80), (30) # Source: -- I believe this could also be interpreted differently. If the change is only about removing the weather radar band (5600-5650), the change should be - (5490 - 5730 @ 160), (24), DFS + (5490 - 5570 @ 80), (24), DFS + (5570 - 5590 @ 20), (24), DFS + (5650 - 5730 @ 80), (24), DFS The second rule explicitly states that channel 116 remains available for HT20. If this level of strict correctness is not needed, rule 1 and 2 combined would be - (5490 - 5730 @ 160), (24), DFS + (5490 - 5590 @ 80), (24), DFS I agree. 5590 is more strict than 5600. + (5650 - 5730 @ 80), (24), DFS 5690 MHz is not a channel can be used, is it still necessary to mark this band as 80MHz while in practice it is not possible to fully unitize the entire band? I must be missing something here, where does the restriction for 5690 come from? The document handles the band 5650-5725 as available, I don't see any further restrictions for 5690. From your other post: - (5490 - 5730 @ 160), (24), DFS + (5490 - 5590 @ 80), (24), DFS I agree. 5590 is more strict than 5600. On a second thought, 5590 implies channel 116 can't have 40MHz. I think that is still allowed per regulation. No, channel 116 is not usable for HT40 if weather radar channels are disabled, since it can only be combined with channel 120 and that one partially falls into the restricted range. I found the FCC channel plans (which CA conforms to) in [1] very helpful when checking the restrictions. [1] https://apps.fcc.gov/kdb/GetAttachment.html?id=lp4w3WTVG9PReWNFG0ckTg%3D%3D -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: fix QCA61X4 boot up
commit a521ee983d312db7 ath10k: Add new reg_address/mask to hw register
table commit has broken the QCA61x4 support, by providing wrong
fw_indicator_address, which shall be 0x0003a028 instead of 0x9028.
User experience was a failing boot up sequence (crashing device during
initialization)
[ 181.663874] ath10k_pci :02:00.0: enabling device ( - 0002)
[ 181.664787] ath10k_pci :02:00.0: pci irq msi-x interrupts 8 irq_mode 0
reset_mode 0
[ 181.66] ath10k_pci :02:00.0: device has crashed during init
[ 181.688897] ath10k_pci :02:00.0: failed to wait for target after cold
reset: -70
[ 181.688902] ath10k_pci :02:00.0: failed to reset chip: -70
[ 181.689774] ath10k_pci: probe of :02:00.0 failed with error -70
Fix it by updating the address with correct value.
Signed-off-by: Bartosz Markowski bartosz.markow...@tieto.com
---
drivers/net/wireless/ath/ath10k/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.c
b/drivers/net/wireless/ath/ath10k/hw.c
index 1414e1f3c7ac..fef7ccf6e185 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -63,7 +63,7 @@ const struct ath10k_hw_regs qca6174_regs = {
.soc_reset_control_ce_rst_mask = 0x0001,
.soc_chip_id_address= 0x00f0,
.scratch_3_address = 0x0028,
- .fw_indicator_address = 0x9028,
+ .fw_indicator_address = 0x0003a028,
.pcie_local_base_address= 0x0008,
.ce_wrap_intr_sum_host_msi_lsb = 0x0008,
.ce_wrap_intr_sum_host_msi_mask = 0xff00,
--
2.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ath9k_htc: introduce support for different fw versions
Am 03.07.2015 um 12:53 schrieb Kalle Valo: Oleksij Rempel li...@rempel-privat.de writes: Any updates here? What do you mean? If you are asking why the patch isn't applied it's because merge window is still open. I'll start applying patches after net-next is open again. Ouch.. i was in my own world :) Sorry, -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Re: Q: iw - how to scan for a specific ssid / AP mode scan
On Fri, 2015-07-03 at 18:51 +0200, Zefir Kurtisi wrote: Folks, I have difficulties using iw for a specific use case or fail to understand the documentation correctly. My platform is a recent OpenWRT, running ath9k. First use case is scanning for a given ssid in managed mode. According do iw's documentation (and the attribute description in nl80211.h), issuing iw dev wlan0 scan flush ssid SSID should do exactly this, but I keep receiving a full list of visible APs. This is telling it to scan for that particular network, and that's what it's going to do, but it's still going to report everything that it heard, for example when hearing beacons while scanning. The second issue is about scanning in AP mode. Where I want to go is having two APs operating on arbitrary DFS channels with periodic scans to discover each other. What I observe is a) passive scanning: iw dev wlan0 scan flush ap-force passive = does not work - no scan results are provided b) active scanning: iw dev wlan0 scan flush ap-force * finds only a subset of APs compared to a scan in managed mode * finds only APs on non-DFS channels Again, I might be missing some relevant documentation, but to me the observed results look rather like 'not yet implemented' than inherent limitations. Not sure - but you do need to realize that the AP isn't really allowed to go off-channel for any period of time (like scanning) so this isn't really guaranteed to work well. Especially passive scanning seems like a really bad idea. As to why it's not actually working, I have no idea. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Q: iw - how to scan for a specific ssid / AP mode scan
Folks, I have difficulties using iw for a specific use case or fail to understand the documentation correctly. My platform is a recent OpenWRT, running ath9k. First use case is scanning for a given ssid in managed mode. According do iw's documentation (and the attribute description in nl80211.h), issuing iw dev wlan0 scan flush ssid SSID should do exactly this, but I keep receiving a full list of visible APs. I double checked that NL80211_SCAN_FLAG_FLUSH and NL80211_ATTR_SCAN_SSIDS are set correctly, so am puzzled whether there is some bug left or I miss some detail. The second issue is about scanning in AP mode. Where I want to go is having two APs operating on arbitrary DFS channels with periodic scans to discover each other. What I observe is a) passive scanning: iw dev wlan0 scan flush ap-force passive = does not work - no scan results are provided b) active scanning: iw dev wlan0 scan flush ap-force * finds only a subset of APs compared to a scan in managed mode * finds only APs on non-DFS channels Again, I might be missing some relevant documentation, but to me the observed results look rather like 'not yet implemented' than inherent limitations. Any hint / feedback is appreciated. Thanks, Zefir -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mesh support on rtl8192cu
2015-07-03 18:59 GMT+09:00 Bruno Randolf b...@thinktube.com: On 07/03/2015 10:34 AM, Richard Palethorpe wrote: Hello Taehee, I have been experimenting with MESH mode on kernel 4.0.7. It is sending beacons out, but is unable to establish a connection. I have two rtl8192cu based dongles connected to identical VMs and am using the following commands to set up the mesh: iw dev wls160u2 set type mesh ip addr add 192.168.2.1/24 broadcast 192.168.2.255 dev wls160u2 ip link set wls160u2 up iw dev wls160u2 mesh join lmmesh Running 'iw dev wls160u2 mpath dump' produces no results and there is nothing regarding mesh in dmesg. I can't find any other information on mesh with rtl8192cu other than the patch which you submitted. I am wondering if it does work, but there is a step I am missing or if something is wrong with the code? I don't know about this 'mesh' mode, but I have noted problems in ad-hoc mode with this chipset and driver. The problem seems to be that ARP replies are not sent on the air... Not sure what the reason is or if it's possible to fix it in the driver, but my conclusion for now is that this device is unusable for ad-hoc mode. Similar problems may exist for mesh? bruno I don't know about a mesh network. But, according to my ping test result, 'mpath dump' shows ping traffics. Did you generate any traffics? -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] mac80211: mesh: separate plid and aid concepts
According to 802.11-2012 13.3.1, a mesh STA should assign an AID
upon receipt of a mesh peering open frame rather than using the link
id of the peer. Using the peer link id has two potential issues:
it may not be unique among the peers, and by its nature it is random,
so the TIM may not compress well.
In preparation for allocating it properly, use sta-sta.aid, but keep
the existing behavior of using the plid.
Additionally, fix a bug where the AID is written into the wrong place
in peering confirm frame skbs.
Signed-off-by: Bob Copeland m...@bobcopeland.com
---
net/mac80211/mesh_plink.c | 20
net/mac80211/sta_info.c | 5 +
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 7b071e36e55e..9dca16bd3eb9 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -200,6 +200,7 @@ static u32 mesh_set_ht_prot_mode(struct
ieee80211_sub_if_data *sdata)
}
static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
+ struct sta_info *sta,
enum ieee80211_self_protected_actioncode action,
u8 *da, u16 llid, u16 plid, u16 reason)
{
@@ -249,7 +250,7 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data
*sdata,
if (action == WLAN_SP_MESH_PEERING_CONFIRM) {
/* AID */
pos = skb_put(skb, 2);
- put_unaligned_le16(plid, pos + 2);
+ put_unaligned_le16(sta-sta.aid, pos);
}
if (ieee80211_add_srates_ie(sdata, skb, true, band) ||
ieee80211_add_ext_srates_ie(sdata, skb, true, band) ||
@@ -362,7 +363,7 @@ u32 mesh_plink_deactivate(struct sta_info *sta)
spin_lock_bh(sta-mesh-plink_lock);
changed = __mesh_plink_deactivate(sta);
sta-mesh-reason = WLAN_REASON_MESH_PEER_CANCELED;
- mesh_plink_frame_tx(sdata, WLAN_SP_MESH_PEERING_CLOSE,
+ mesh_plink_frame_tx(sdata, sta, WLAN_SP_MESH_PEERING_CLOSE,
sta-sta.addr, sta-mesh-llid, sta-mesh-plid,
sta-mesh-reason);
spin_unlock_bh(sta-mesh-plink_lock);
@@ -619,7 +620,7 @@ static void mesh_plink_timer(unsigned long data)
}
spin_unlock_bh(sta-mesh-plink_lock);
if (action)
- mesh_plink_frame_tx(sdata, action, sta-sta.addr,
+ mesh_plink_frame_tx(sdata, sta, action, sta-sta.addr,
sta-mesh-llid, sta-mesh-plid, reason);
}
@@ -689,7 +690,7 @@ u32 mesh_plink_open(struct sta_info *sta)
/* set the non-peer mode to active during peering */
changed = ieee80211_mps_local_status_update(sdata);
- mesh_plink_frame_tx(sdata, WLAN_SP_MESH_PEERING_OPEN,
+ mesh_plink_frame_tx(sdata, sta, WLAN_SP_MESH_PEERING_OPEN,
sta-sta.addr, sta-mesh-llid, 0, 0);
return changed;
}
@@ -871,13 +872,13 @@ static u32 mesh_plink_fsm(struct ieee80211_sub_if_data
*sdata,
}
spin_unlock_bh(sta-mesh-plink_lock);
if (action) {
- mesh_plink_frame_tx(sdata, action, sta-sta.addr,
+ mesh_plink_frame_tx(sdata, sta, action, sta-sta.addr,
sta-mesh-llid, sta-mesh-plid,
sta-mesh-reason);
/* also send confirm in open case */
if (action == WLAN_SP_MESH_PEERING_OPEN) {
- mesh_plink_frame_tx(sdata,
+ mesh_plink_frame_tx(sdata, sta,
WLAN_SP_MESH_PEERING_CONFIRM,
sta-sta.addr, sta-mesh-llid,
sta-mesh-plid, 0);
@@ -1067,8 +1068,9 @@ mesh_process_plink_frame(struct ieee80211_sub_if_data
*sdata,
goto unlock_rcu;
}
sta-mesh-plid = plid;
+ sta-sta.aid = plid;
} else if (!sta event == OPN_RJCT) {
- mesh_plink_frame_tx(sdata, WLAN_SP_MESH_PEERING_CLOSE,
+ mesh_plink_frame_tx(sdata, NULL, WLAN_SP_MESH_PEERING_CLOSE,
mgmt-sa, 0, plid,
WLAN_REASON_MESH_CONFIG);
goto unlock_rcu;
@@ -1078,8 +1080,10 @@ mesh_process_plink_frame(struct ieee80211_sub_if_data
*sdata,
}
/* 802.11-2012 13.3.7.2 - update plid on CNF if not set */
- if (!sta-mesh-plid event == CNF_ACPT)
+ if (!sta-mesh-plid event == CNF_ACPT) {
sta-mesh-plid = plid;
+ sta-sta.aid = sta-mesh-plid;
+ }
changed |= mesh_plink_fsm(sdata, sta, event);
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 9da7d2bc271a..70cd9fa57424 100644
---
[PATCH v2 3/3] mac80211: select an AID when creating new mesh STAs
Instead of using peer link id for AID, generate a new
AID when creating mesh STAs in the kernel peering manager.
This enables smaller TIM elements and more closely follows
the standard, and it also enables mesh to work on drivers
that require a valid AID when the STA is inserted (ath10k
firmware has this requirement, for example).
In the case of userspace-managed stations, we use the AID
from NL80211_CMD_NEW_STATION.
Signed-off-by: Bob Copeland m...@bobcopeland.com
---
v2: generate the bitmap as needed inside mesh_allocate_aid rather
than maintaining the whole time (Johannes)
[generating a bitmap is not really required, but I guess it would
be better than a nested loop here.]
net/mac80211/mesh_plink.c | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 9dca16bd3eb9..9619159f3dbe 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -421,20 +421,54 @@ out:
spin_unlock_bh(sta-mesh-plink_lock);
}
+static int mesh_allocate_aid(struct ieee80211_sub_if_data *sdata)
+{
+ struct sta_info *sta;
+ unsigned long *aid_map;
+ int aid;
+
+ aid_map = kcalloc(BITS_TO_LONGS(IEEE80211_MAX_AID + 1),
+ sizeof(*aid_map), GFP_KERNEL);
+ if (!aid_map)
+ return -ENOMEM;
+
+ /* reserve aid 0 for mcast indication */
+ __set_bit(0, aid_map);
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(sta, sdata-local-sta_list, list)
+ __set_bit(sta-sta.aid, aid_map);
+ rcu_read_unlock();
+
+ aid = find_first_zero_bit(aid_map, IEEE80211_MAX_AID + 1);
+ kfree(aid_map);
+
+ if (aid IEEE80211_MAX_AID)
+ return -ENOBUFS;
+
+ return aid;
+}
+
static struct sta_info *
__mesh_sta_info_alloc(struct ieee80211_sub_if_data *sdata, u8 *hw_addr)
{
struct sta_info *sta;
+ int aid;
if (sdata-local-num_sta = MESH_MAX_PLINKS)
return NULL;
+ aid = mesh_allocate_aid(sdata);
+ if (aid 0)
+ return NULL;
+
sta = sta_info_alloc(sdata, hw_addr, GFP_KERNEL);
if (!sta)
return NULL;
sta-mesh-plink_state = NL80211_PLINK_LISTEN;
sta-sta.wme = true;
+ sta-sta.aid = aid;
sta_info_pre_move_state(sta, IEEE80211_STA_AUTH);
sta_info_pre_move_state(sta, IEEE80211_STA_ASSOC);
@@ -658,8 +692,6 @@ static u16 mesh_get_new_llid(struct ieee80211_sub_if_data
*sdata)
do {
get_random_bytes(llid, sizeof(llid));
- /* for mesh PS we still only have the AID range for TIM bits */
- llid = (llid % IEEE80211_MAX_AID) + 1;
} while (llid_in_use(sdata, llid));
return llid;
@@ -1068,7 +1100,6 @@ mesh_process_plink_frame(struct ieee80211_sub_if_data
*sdata,
goto unlock_rcu;
}
sta-mesh-plid = plid;
- sta-sta.aid = plid;
} else if (!sta event == OPN_RJCT) {
mesh_plink_frame_tx(sdata, NULL, WLAN_SP_MESH_PEERING_CLOSE,
mgmt-sa, 0, plid,
@@ -1080,10 +,8 @@ mesh_process_plink_frame(struct ieee80211_sub_if_data
*sdata,
}
/* 802.11-2012 13.3.7.2 - update plid on CNF if not set */
- if (!sta-mesh-plid event == CNF_ACPT) {
+ if (!sta-mesh-plid event == CNF_ACPT)
sta-mesh-plid = plid;
- sta-sta.aid = sta-mesh-plid;
- }
changed |= mesh_plink_fsm(sdata, sta, event);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] mac80211: reorder mesh_plink to remove forward decl
Move mesh_plink_frame_tx() above the first caller to remove
the forward declaration.
Signed-off-by: Bob Copeland m...@bobcopeland.com
---
net/mac80211/mesh_plink.c | 109 ++
1 file changed, 52 insertions(+), 57 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 1a7d98398626..7b071e36e55e 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -53,11 +53,6 @@ static const char * const mplevents[] = {
[CLS_IGNR] = CLS_IGNR
};
-static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
- enum ieee80211_self_protected_actioncode action,
- u8 *da, u16 llid, u16 plid, u16 reason);
-
-
/* We only need a valid sta if user configured a minimum rssi_threshold. */
static bool rssi_threshold_check(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta)
@@ -204,58 +199,6 @@ static u32 mesh_set_ht_prot_mode(struct
ieee80211_sub_if_data *sdata)
return BSS_CHANGED_HT;
}
-/**
- * __mesh_plink_deactivate - deactivate mesh peer link
- *
- * @sta: mesh peer link to deactivate
- *
- * All mesh paths with this peer as next hop will be flushed
- * Returns beacon changed flag if the beacon content changed.
- *
- * Locking: the caller must hold sta-mesh-plink_lock
- */
-static u32 __mesh_plink_deactivate(struct sta_info *sta)
-{
- struct ieee80211_sub_if_data *sdata = sta-sdata;
- u32 changed = 0;
-
- lockdep_assert_held(sta-mesh-plink_lock);
-
- if (sta-mesh-plink_state == NL80211_PLINK_ESTAB)
- changed = mesh_plink_dec_estab_count(sdata);
- sta-mesh-plink_state = NL80211_PLINK_BLOCKED;
- mesh_path_flush_by_nexthop(sta);
-
- ieee80211_mps_sta_status_update(sta);
- changed |= ieee80211_mps_set_sta_local_pm(sta,
- NL80211_MESH_POWER_UNKNOWN);
-
- return changed;
-}
-
-/**
- * mesh_plink_deactivate - deactivate mesh peer link
- *
- * @sta: mesh peer link to deactivate
- *
- * All mesh paths with this peer as next hop will be flushed
- */
-u32 mesh_plink_deactivate(struct sta_info *sta)
-{
- struct ieee80211_sub_if_data *sdata = sta-sdata;
- u32 changed;
-
- spin_lock_bh(sta-mesh-plink_lock);
- changed = __mesh_plink_deactivate(sta);
- sta-mesh-reason = WLAN_REASON_MESH_PEER_CANCELED;
- mesh_plink_frame_tx(sdata, WLAN_SP_MESH_PEERING_CLOSE,
- sta-sta.addr, sta-mesh-llid, sta-mesh-plid,
- sta-mesh-reason);
- spin_unlock_bh(sta-mesh-plink_lock);
-
- return changed;
-}
-
static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
enum ieee80211_self_protected_actioncode action,
u8 *da, u16 llid, u16 plid, u16 reason)
@@ -375,6 +318,58 @@ free:
return err;
}
+/**
+ * __mesh_plink_deactivate - deactivate mesh peer link
+ *
+ * @sta: mesh peer link to deactivate
+ *
+ * All mesh paths with this peer as next hop will be flushed
+ * Returns beacon changed flag if the beacon content changed.
+ *
+ * Locking: the caller must hold sta-mesh-plink_lock
+ */
+static u32 __mesh_plink_deactivate(struct sta_info *sta)
+{
+ struct ieee80211_sub_if_data *sdata = sta-sdata;
+ u32 changed = 0;
+
+ lockdep_assert_held(sta-mesh-plink_lock);
+
+ if (sta-mesh-plink_state == NL80211_PLINK_ESTAB)
+ changed = mesh_plink_dec_estab_count(sdata);
+ sta-mesh-plink_state = NL80211_PLINK_BLOCKED;
+ mesh_path_flush_by_nexthop(sta);
+
+ ieee80211_mps_sta_status_update(sta);
+ changed |= ieee80211_mps_set_sta_local_pm(sta,
+ NL80211_MESH_POWER_UNKNOWN);
+
+ return changed;
+}
+
+/**
+ * mesh_plink_deactivate - deactivate mesh peer link
+ *
+ * @sta: mesh peer link to deactivate
+ *
+ * All mesh paths with this peer as next hop will be flushed
+ */
+u32 mesh_plink_deactivate(struct sta_info *sta)
+{
+ struct ieee80211_sub_if_data *sdata = sta-sdata;
+ u32 changed;
+
+ spin_lock_bh(sta-mesh-plink_lock);
+ changed = __mesh_plink_deactivate(sta);
+ sta-mesh-reason = WLAN_REASON_MESH_PEER_CANCELED;
+ mesh_plink_frame_tx(sdata, WLAN_SP_MESH_PEERING_CLOSE,
+ sta-sta.addr, sta-mesh-llid, sta-mesh-plid,
+ sta-mesh-reason);
+ spin_unlock_bh(sta-mesh-plink_lock);
+
+ return changed;
+}
+
static void mesh_sta_info_init(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta,
struct ieee802_11_elems *elems, bool insert)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Mesh AID fixes
This patchset corrects the use of peer link id as a stand-in for the association ID, which is at odds with the standard. Using an incremental AID generated on the local sta whenever a peer is added enables smaller TIM elements, and removes one possible source of ambiguity when plids collide. Using a proper aid also will make it easier to implement mesh on ath10k. Because mac80211 currently only implements the buffering side of mesh power save, we don't need to change any code that reads the AID from confirm frames. Which is good because it was previously always wrong. v2: dynamically create the bitmap on demand rather than maintain it Bob Copeland (3): mac80211: reorder mesh_plink to remove forward decl mac80211: mesh: separate plid and aid concepts mac80211: select an AID when creating new mesh STAs net/mac80211/cfg.c | 3 + net/mac80211/ieee80211_i.h | 1 + net/mac80211/mesh.c| 7 +++ net/mac80211/mesh_plink.c | 147 + net/mac80211/sta_info.c| 5 +- 5 files changed, 94 insertions(+), 69 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath9k: export HW random number generator
From: Miaoqing Pan miaoq...@qca.qualcomm.com
We measured the ADC-based entropy in 3 ways, Shannon entropy,
collision entropy, and directly measured min-entropy. Entropy is
in bits per 16 bit value,
---
Shannon | collision | min
---
12.00 | 10.80 | 9.18
---
Recommend: A generous safety factor be used. NIST Special Publication
800-90B (draft) requires that data used to seed a deterministic random
bit generator with N bits of strength have an estimated entropy at least
twice the block size of the underlying primitive. Given all the
uncertainties, it would be wise to collect even more.
Analysis was done by Jacobson,David(djaco...@qti.qualcomm.com).
Signed-off-by: Miaoqing Pan miaoq...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/Kconfig | 7
drivers/net/wireless/ath/ath9k/Makefile | 1 +
drivers/net/wireless/ath/ath9k/ath9k.h | 24 +++
drivers/net/wireless/ath/ath9k/main.c | 4 ++
drivers/net/wireless/ath/ath9k/rng.c| 73 +
5 files changed, 109 insertions(+)
create mode 100644 drivers/net/wireless/ath/ath9k/rng.c
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
b/drivers/net/wireless/ath/ath9k/Kconfig
index fee0cad..2a879cb 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -176,3 +176,10 @@ config ATH9K_HTC_DEBUGFS
depends on ATH9K_HTC DEBUG_FS
---help---
Say Y, if you need access to ath9k_htc's statistics.
+
+config ATH9K_HWRNG
+ bool Random number generator support
+ depends on ATH9K (HW_RANDOM = y || HW_RANDOM = ATH9K)
+ default n
+ ---help---
+ Provides a hardware random number generator to the kernel.
diff --git a/drivers/net/wireless/ath/ath9k/Makefile
b/drivers/net/wireless/ath/ath9k/Makefile
index ecda613..76f9dc3 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -15,6 +15,7 @@ ath9k-$(CONFIG_ATH9K_DFS_DEBUGFS) += dfs_debug.o
ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += dfs.o
ath9k-$(CONFIG_ATH9K_TX99) += tx99.o
ath9k-$(CONFIG_ATH9K_WOW) += wow.o
+ath9k-$(CONFIG_ATH9K_HWRNG) += rng.o
ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index a7a81b3..a68744b 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -23,6 +23,7 @@
#include linux/leds.h
#include linux/completion.h
#include linux/time.h
+#include linux/hw_random.h
#include common.h
#include debug.h
@@ -1041,6 +1042,12 @@ struct ath_softc {
u32 wow_intr_before_sleep;
bool force_wow;
#endif
+
+#ifdef CONFIG_ATH9K_HWRNG
+ struct hwrng rng;
+ bool rng_initialized;
+ u32 rng_last;
+#endif
};
//
@@ -1063,6 +1070,23 @@ static inline int ath9k_tx99_send(struct ath_softc *sc,
}
#endif /* CONFIG_ATH9K_TX99 */
+/***/
+/* Random Number Generator */
+/***/
+#ifdef CONFIG_ATH9K_HWRNG
+void ath9k_rng_unregister(struct ath_softc *sc);
+int ath9k_rng_register(struct ath_softc *sc);
+#else
+static inline void ath9k_rng_unregister(struct ath_softc *sc)
+{
+}
+
+static inline int ath9k_rng_register(struct ath_softc *sc)
+{
+ return 0;
+}
+#endif
+
static inline void ath_read_cachesize(struct ath_common *common, int *csz)
{
common-bus_ops-read_cachesize(common, csz);
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index cfd45cb..5916ab2 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -739,6 +739,8 @@ static int ath9k_start(struct ieee80211_hw *hw)
ath9k_ps_restore(sc);
+ ath9k_rng_register(sc);
+
return 0;
}
@@ -828,6 +830,8 @@ static void ath9k_stop(struct ieee80211_hw *hw)
ath9k_deinit_channel_context(sc);
+ ath9k_rng_unregister(sc);
+
mutex_lock(sc-mutex);
ath_cancel_work(sc);
diff --git a/drivers/net/wireless/ath/ath9k/rng.c
b/drivers/net/wireless/ath/ath9k/rng.c
new file mode 100644
index 000..8cc4d18
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -0,0 +1,73 @@
+/*
+ * Copyright (c) 2015 Qualcomm Atheros, Inc.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF
RE: [PATCH] mwifiex: fix leak of gen_ie storage on exit from mwifiex_del_mgmt_ies
Hi John, From: John W. Linville [mailto:linvi...@tuxdriver.com] Sent: Saturday, June 27, 2015 1:00 AM To: linux-wireless@vger.kernel.org Cc: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; John W. Linville Subject: [PATCH] mwifiex: fix leak of gen_ie storage on exit from mwifiex_del_mgmt_ies Storage pointed to by gen_ie is allocated with kmalloc, but was never freed. Coverity CID #1271251 Signed-off-by: John W. Linville linvi...@tuxdriver.com Acked-by: Amitkumar Karwar akar...@marvell.com Regards, Amitkumar -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath9k: export HW random number generator
On Fri, 2015-07-03 at 15:29 +0800, miaoq...@qti.qualcomm.com wrote: +config ATH9K_HWRNG + bool Random number generator support + depends on ATH9K (HW_RANDOM = y || HW_RANDOM = ATH9K) + default n you don't need to state 'default n' +void ath9k_rng_unregister(struct ath_softc *sc); +int ath9k_rng_register(struct ath_softc *sc); unregister before register? not that it matters though. you're not using the return value, why bother having it? johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ath9k: export HW random number generator
From: Miaoqing Pan miaoq...@qca.qualcomm.com
We measured the ADC-based entropy in 3 ways, Shannon entropy,
collision entropy, and directly measured min-entropy. Entropy is
in bits per 16 bit value,
---
Shannon | collision | min
---
12.00 | 10.80 | 9.18
---
Recommend: A generous safety factor be used. NIST Special Publication
800-90B (draft) requires that data used to seed a deterministic random
bit generator with N bits of strength have an estimated entropy at least
twice the block size of the underlying primitive. Given all the
uncertainties, it would be wise to collect even more.
Analysis was done by Jacobson,David(djaco...@qti.qualcomm.com).
Signed-off-by: Miaoqing Pan miaoq...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/Kconfig | 7
drivers/net/wireless/ath/ath9k/Makefile | 1 +
drivers/net/wireless/ath/ath9k/ath9k.h | 23
drivers/net/wireless/ath/ath9k/main.c | 4 ++
drivers/net/wireless/ath/ath9k/rng.c| 66 +
5 files changed, 101 insertions(+)
create mode 100644 drivers/net/wireless/ath/ath9k/rng.c
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
b/drivers/net/wireless/ath/ath9k/Kconfig
index fee0cad..bde62ec9 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -176,3 +176,10 @@ config ATH9K_HTC_DEBUGFS
depends on ATH9K_HTC DEBUG_FS
---help---
Say Y, if you need access to ath9k_htc's statistics.
+
+config ATH9K_HWRNG
+ bool Random number generator support
+ depends on ATH9K (HW_RANDOM = y || HW_RANDOM = ATH9K)
+ default y
+ ---help---
+ Provides a hardware random number generator to the kernel.
diff --git a/drivers/net/wireless/ath/ath9k/Makefile
b/drivers/net/wireless/ath/ath9k/Makefile
index ecda613..76f9dc3 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -15,6 +15,7 @@ ath9k-$(CONFIG_ATH9K_DFS_DEBUGFS) += dfs_debug.o
ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += dfs.o
ath9k-$(CONFIG_ATH9K_TX99) += tx99.o
ath9k-$(CONFIG_ATH9K_WOW) += wow.o
+ath9k-$(CONFIG_ATH9K_HWRNG) += rng.o
ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index a7a81b3..45596e5 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -23,6 +23,7 @@
#include linux/leds.h
#include linux/completion.h
#include linux/time.h
+#include linux/hw_random.h
#include common.h
#include debug.h
@@ -1041,6 +1042,12 @@ struct ath_softc {
u32 wow_intr_before_sleep;
bool force_wow;
#endif
+
+#ifdef CONFIG_ATH9K_HWRNG
+ struct hwrng rng;
+ bool rng_initialized;
+ u32 rng_last;
+#endif
};
//
@@ -1063,6 +1070,22 @@ static inline int ath9k_tx99_send(struct ath_softc *sc,
}
#endif /* CONFIG_ATH9K_TX99 */
+/***/
+/* Random Number Generator */
+/***/
+#ifdef CONFIG_ATH9K_HWRNG
+void ath9k_rng_register(struct ath_softc *sc);
+void ath9k_rng_unregister(struct ath_softc *sc);
+#else
+static inline void ath9k_rng_register(struct ath_softc *sc)
+{
+}
+
+static inline void ath9k_rng_unregister(struct ath_softc *sc)
+{
+}
+#endif
+
static inline void ath_read_cachesize(struct ath_common *common, int *csz)
{
common-bus_ops-read_cachesize(common, csz);
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index cfd45cb..5916ab2 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -739,6 +739,8 @@ static int ath9k_start(struct ieee80211_hw *hw)
ath9k_ps_restore(sc);
+ ath9k_rng_register(sc);
+
return 0;
}
@@ -828,6 +830,8 @@ static void ath9k_stop(struct ieee80211_hw *hw)
ath9k_deinit_channel_context(sc);
+ ath9k_rng_unregister(sc);
+
mutex_lock(sc-mutex);
ath_cancel_work(sc);
diff --git a/drivers/net/wireless/ath/ath9k/rng.c
b/drivers/net/wireless/ath/ath9k/rng.c
new file mode 100644
index 000..e2cce31
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -0,0 +1,66 @@
+/*
+ * Copyright (c) 2015 Qualcomm Atheros, Inc.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT,
[PATCH] ath10k: Delay device access after cold reset
It is observed that during cold reset pcie access right
after a write operation to SOC_GLOBAL_RESET_ADDRESS causes
Data Bus Error and system hard lockup. The reason
for bus error is that pcie needs some time to get
back to stable state for any transaction during cold reset. Add
delay of 20 msecs after write of SOC_GLOBAL_RESET_ADDRESS
to fix this issue.
Signed-off-by: Vasanthakumar Thiagarajan vthia...@qti.qualcomm.com
---
drivers/net/wireless/ath/ath10k/pci.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 1b4634a..130746b 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2761,7 +2761,6 @@ static int ath10k_pci_wait_for_target_init(struct ath10k
*ar)
static int ath10k_pci_cold_reset(struct ath10k *ar)
{
- int i;
u32 val;
ath10k_dbg(ar, ATH10K_DBG_BOOT, boot cold reset\n);
@@ -2777,23 +2776,18 @@ static int ath10k_pci_cold_reset(struct ath10k *ar)
val |= 1;
ath10k_pci_reg_write32(ar, SOC_GLOBAL_RESET_ADDRESS, val);
- for (i = 0; i ATH_PCI_RESET_WAIT_MAX; i++) {
- if (ath10k_pci_reg_read32(ar, RTC_STATE_ADDRESS)
- RTC_STATE_COLD_RESET_MASK)
- break;
- msleep(1);
- }
+ /* After writing into SOC_GLOBAL_RESET to put device into
+* reset and pulling out of reset pcie may not be stable
+* for any immediate pcie register access and cause bus error,
+* add delay before any pcie access request to fix this issue.
+*/
+ msleep(20);
/* Pull Target, including PCIe, out of RESET. */
val = ~1;
ath10k_pci_reg_write32(ar, SOC_GLOBAL_RESET_ADDRESS, val);
- for (i = 0; i ATH_PCI_RESET_WAIT_MAX; i++) {
- if (!(ath10k_pci_reg_read32(ar, RTC_STATE_ADDRESS)
- RTC_STATE_COLD_RESET_MASK))
- break;
- msleep(1);
- }
+ msleep(20);
ath10k_dbg(ar, ATH10K_DBG_BOOT, boot cold reset complete\n);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mesh support on rtl8192cu
Hello Taehee, I have been experimenting with MESH mode on kernel 4.0.7. It is sending beacons out, but is unable to establish a connection. I have two rtl8192cu based dongles connected to identical VMs and am using the following commands to set up the mesh: iw dev wls160u2 set type mesh ip addr add 192.168.2.1/24 broadcast 192.168.2.255 dev wls160u2 ip link set wls160u2 up iw dev wls160u2 mesh join lmmesh Running 'iw dev wls160u2 mpath dump' produces no results and there is nothing regarding mesh in dmesg. I can't find any other information on mesh with rtl8192cu other than the patch which you submitted. I am wondering if it does work, but there is a step I am missing or if something is wrong with the code? Thank you, Richard. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mwifiex: usb: Fix double add error when submitting rx urb
Hi Reyad, From: Reyad Attiyat [mailto:reyad.atti...@gmail.com] Sent: Monday, June 29, 2015 6:38 AM To: Amitkumar Karwar; pat...@marvell.com; kv...@codeaurora.org; bz...@marvell.com Cc: linux-wireless@vger.kernel.org; net...@vger.kernel.org; linux- ker...@vger.kernel.org; Reyad Attiyat Subject: [PATCH] mwifiex: usb: Fix double add error when submitting rx urb There is an error that can occur where the driver adds the same URB to USB submission list twice. This happens since mwifiex_usb_submit_rem_rx can submit packets at same time as an rx urb complete callback. This causes list corruption and is fixed by not setting the skb to NULL when submitting an rx packet. [ 84.461242] WARNING: CPU: 1 PID: 748 at lib/list_debug.c:36 __list_add+0xcb/0xd0() [ 84.461245] list_add double add: new=8800c92b0c50, prev=8800c92b0c50, next=8800ced6c430. [ 84.461247] Modules linked in: rfcomm fuse cmac nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bnep iptable_mangle iptable_security iptable_raw btusb btintel bluetooth mwifiex_usb mwifiex x86_pkg_temp_thermal cfg80211 coretemp r8712u(C) kvm_intel kvm hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger hid_sensor_iio_common industrialio_triggered_buffer kfifo_buf rfkill iTCO_wdt industrialio iTCO_vendor_support [ 84.461316] crc32_pclmul crc32c_intel ghash_clmulni_intel microcode snd_hda_codec_realtek vfat snd_hda_codec_generic fat snd_hda_codec_hdmi snd_hda_intel snd_hda_controller uvcvideo snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hwdep videobuf2_core snd_hda_core joydev v4l2_common videodev hid_sensor_hub snd_seq hid_multitouch media snd_seq_device snd_pcm snd_timer mei_me snd i2c_i801 lpc_ich mei soundcore tpm_infineon tpm_tis tpm i2c_hid i2c_designware_platform i2c_designware_core nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel i915 i2c_algo_bit drm_kms_helper drm xhci_pci xhci_hcd ehci_pci sd_mod ehci_hcd video [ 84.461383] CPU: 1 PID: 748 Comm: kworker/u9:0 Tainted: G C 4.1.0-rc5+ #163 [ 84.461386] Hardware name: Microsoft Corporation Surface Pro 2/Surface Pro 2, BIOS 2.05.0250 04/10/2015 [ 84.461396] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 84.461399] 81a8150e 8801174cf8e8 817df830 [ 84.461405] 8801174cf938 8801174cf928 810a54ba 8800c86bd750 [ 84.461410] 8800c92b0c50 8800c92b0c50 8800ced6c430 88010c057178 [ 84.461416] Call Trace: [ 84.461421] [817df830] dump_stack+0x4f/0x7b [ 84.461428] [810a54ba] warn_slowpath_common+0x8a/0xc0 [ 84.461432] [810a5536] warn_slowpath_fmt+0x46/0x50 [ 84.461436] [814109fb] __list_add+0xcb/0xd0 [ 84.461442] [815c551a] ? usb_hcd_link_urb_to_ep+0x2a/0xa0 [ 84.461446] [815c5570] usb_hcd_link_urb_to_ep+0x80/0xa0 [ 84.461459] [a004318a] prepare_transfer+0xaa/0x130 [xhci_hcd] [ 84.461470] [a0044cf7] xhci_queue_bulk_tx+0xb7/0x7a0 [xhci_hcd] [ 84.461480] [a003b67f] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd] [ 84.461489] [a003b67f] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd] [ 84.461498] [a003b735] xhci_urb_enqueue+0x5c5/0x660 [xhci_hcd] [ 84.461503] [815c7ad3] usb_hcd_submit_urb+0x93/0xa70 [ 84.461507] [8168dde8] ? __alloc_skb+0x78/0x1f0 [ 84.461511] [8168d301] ? __kmalloc_reserve.isra.26+0x31/0x90 [ 84.461515] [8168ddbc] ? __alloc_skb+0x4c/0x1f0 [ 84.461519] [8168ddfc] ? __alloc_skb+0x8c/0x1f0 [ 84.461523] [8168badd] ? skb_dequeue+0x5d/0x80 [ 84.461527] [815c987e] usb_submit_urb+0x42e/0x5f0 [ 84.461531] [816931d9] ? __alloc_rx_skb+0x39/0x100 [ 84.461536] [a05aa372] mwifiex_usb_submit_rx_urb+0xb2/0x170 [mwifiex_usb] [ 84.461542] [a05aa5f5] mwifiex_usb_submit_rem_rx_urbs+0x45/0x50 [mwifiex_usb] [ 84.461550] [a07094be] mwifiex_rx_work_queue+0x10e/0x140 [mwifiex] [ 84.461556] [810c4429] process_one_work+0x229/0x890 [ 84.461559] [810c438c] ? process_one_work+0x18c/0x890 [ 84.461565] [810c4ae3] worker_thread+0x53/0x470 [ 84.461569] [810c4a90] ? process_one_work+0x890/0x890 [ 84.461572] [810cb162] kthread+0xf2/0x110 [ 84.461577] [811031ad] ? trace_hardirqs_on+0xd/0x10 [ 84.461581] [810cb070] ? kthread_create_on_node+0x230/0x230 [ 84.461586] [817e9662] ret_from_fork+0x42/0x70
Re: [PATCH v5] Add new mac80211 driver mwlwifi.
+/* Bit definitio for MACREG_REG_A2H_INTERRUPT_CAUSE (A2HRIC) */
typo
+/* Bit definitio for MACREG_REG_H2A_INTERRUPT_CAUSE (H2ARIC) */
same here
+struct mwl_chip_info {
+ char *part_name;
+ char *fw_image;
+};
const char *?
+struct mwl_tx_hndl {
+ struct sk_buff *psk_buff;
+ u8 *sta_info;
u8 * seems very strange for sta_info?
+ struct mwl_tx_desc *pdesc;
+ struct mwl_tx_hndl *pnext;
+};
You probably shouldn't hand-write your own linked list
implementation... You could possibly even put all this into the skb-cb
and get rid of the extra struct entirely, just using an skb list?
+struct mwl_rx_hndl {
+ struct sk_buff *psk_buff;/* associated sk_buff for Linux
*/
+ struct mwl_rx_desc *pdesc;
+ struct mwl_rx_hndl *pnext;
+};
Ditto here.
+ struct mwl_tx_pwr_tbl tx_pwr_tbl[SYSADPT_MAX_NUM_CHANNELS];
+ u32 cdd; /* 0: off, 1: on */
bool?
+ spinlock_t sta_lock; /* for private sta info
*/
+ struct list_head sta_list; /* List of stations
*/
Could consider using the mac80211 station iteration
ieee80211_iterate_stations_atomic().
+struct beacon_info {
+ bool valid;
+ u16 cap_info;
+ u8 b_rate_set[SYSADPT_MAX_DATA_RATES_G];
+ u8 op_rate_set[SYSADPT_MAX_DATA_RATES_G];
+ u16 ie_wmm_len; /* Keep WMM IE */
+ u8 *ie_wmm_ptr;
+ u16 ie_rsn_len; /* Keep WPA IE */
+ u8 *ie_rsn_ptr;
+ u16 ie_rsn48_len; /* Keep WPA2 IE */
+ u8 *ie_rsn48_ptr;
+ u16 ie_ht_len;/* Keep HT IE */
+ u8 *ie_ht_ptr;
+ u8 ie_list_ht[148];
+ u16 ie_vht_len; /* Keep VHT IE */
+ u8 *ie_vht_ptr;
+ u8 ie_list_vht[24];
+};
That struct is packed really inefficiently with pointers and u16s
interleaved. Those u16s can also be u8s.
+struct mwl_vif {
+ struct list_head list;
Could also consider using iterate_active_interfaces() and friends.
+ struct ieee80211_vif *vif;
and you should probably embed the struct into the vif-priv, then you
don't need a vif pointer in it (use container_of)
+ u16 seqno; /* Non AMPDU sequence number assigned by
driver. */
That seems a bit strange - why not just leave it up to mac80211 then?
+ /* Indicate if this is station mode */
+ bool is_sta;
use vif-type instead
+struct mwl_amsdu_frag {
+ struct sk_buff *skb;
+ u8 pad;
+ u8 *cur_pos;
+ u8 num;
+ u32 jiffies;
unsigned long
also struct ordering is really about as bad as it could be with lots of
padding
+struct mwl_sta {
+ struct list_head list;
+ struct ieee80211_sta *sta;
same here - embed the struct into sta-priv and get rid of the sta
pointer
+/* Transmission information to transmit a socket buffer. */
+struct mwl_tx_ctrl {
+ void *sta;
+ void *vif;
+ void *k_conf;
void pointers don't seem so great
But perhaps you do want them to avoid mistakes, but you should add a
comment then.
If you're not sure what mistakes I'm talking about - consider an
interface or station that's removed while the packet is pending TX.
+static inline struct mwl_vif *mwl_dev_get_vif(const struct
ieee80211_vif *vif)
+{
+ return (struct mwl_vif *)vif-drv_priv;
+}
+
+static inline struct mwl_sta *mwl_dev_get_sta(const struct
ieee80211_sta *sta)
+{
+ return (struct mwl_sta *)sta-drv_priv;
+}
Oh wait, so you *do* embed the structs - you can use container_of() to
go the other way then and get rid of the pointers.
+static int mwl_fwcmd_wait_complete(struct mwl_priv *priv, unsigned
short cmd)
+{
+ unsigned int curr_iteration = MAX_WAIT_FW_COMPLETE_ITERATIONS;
+
+ unsigned short int_code = 0;
+
+ do {
+ int_code = le16_to_cpu(*((__le16 *)priv
-pcmd_buf[0]));
+ mdelay(1);
+ } while ((int_code != cmd) (--curr_iteration));
+
+ if (curr_iteration == 0) {
+ wiphy_err(priv-hw-wiphy, cmd 0x%04x=%s timed
out\n,
+ cmd, mwl_fwcmd_get_cmd_string(cmd));
+ return -EIO;
+ }
+
+ mdelay(3);
Both mdelay(1) and mdelay(3) are EXTREMELY long for atomic context,
this is made much worse by the iteration counter starting at 1,
which means that this function can, in the failure case, block the
system for 10 seconds!
That seems excessive, particularly when it's called from atomic
context.
Do you really need that btw? might be far better to sleep for some
event/interrupt here. Almost all mac80211 API functions can sleep, and
you probably (hopefully) aren't getting here for TX/RX.
+static int mwl_fwcmd_get_tx_powers(struct mwl_priv *priv, u16
*powlist, u16 ch,
+u16 band, u16 width, u16 sub_ch)
+{
+ struct hostcmd_cmd_802_11_tx_power *pcmd;
+ int i;
+
+ pcmd = (struct hostcmd_cmd_802_11_tx_power *)priv
-pcmd_buf[0];
+
+ spin_lock(priv-fwcmd_lock);
Re: mesh support on rtl8192cu
On 07/03/2015 10:34 AM, Richard Palethorpe wrote: Hello Taehee, I have been experimenting with MESH mode on kernel 4.0.7. It is sending beacons out, but is unable to establish a connection. I have two rtl8192cu based dongles connected to identical VMs and am using the following commands to set up the mesh: iw dev wls160u2 set type mesh ip addr add 192.168.2.1/24 broadcast 192.168.2.255 dev wls160u2 ip link set wls160u2 up iw dev wls160u2 mesh join lmmesh Running 'iw dev wls160u2 mpath dump' produces no results and there is nothing regarding mesh in dmesg. I can't find any other information on mesh with rtl8192cu other than the patch which you submitted. I am wondering if it does work, but there is a step I am missing or if something is wrong with the code? I don't know about this 'mesh' mode, but I have noted problems in ad-hoc mode with this chipset and driver. The problem seems to be that ARP replies are not sent on the air... Not sure what the reason is or if it's possible to fix it in the driver, but my conclusion for now is that this device is unusable for ad-hoc mode. Similar problems may exist for mesh? bruno -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ath9k_htc: introduce support for different fw versions
Oleksij Rempel li...@rempel-privat.de writes: Any updates here? What do you mean? If you are asking why the patch isn't applied it's because merge window is still open. I'll start applying patches after net-next is open again. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-regdb: update CA rules for 5600 - 5650 mHz
On 07/02/2015 07:44 AM, Wei Zhong wrote: commit 2fef4cad8a1bd9cbbf178e59a1b3ca672b057095 Author: Wei Zhong wzh...@google.com Date: Wed Jul 1 22:39:09 2015 -0700 wireless-regdb: update CA rules for 5600 - 5650 mHz Related regulation: http://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf10971.html#s6.2.3 Frequency Bands 5470-5600 MHz and 5650-5725 MHz Until further notice, devices subject to this section [i.e. Wifi device supporting 5 GHz bands] shall not be capable of transmitting in the band 5600-5650 MHz. This restriction is for the protection of Environment Canada’s weather radars operating in this band. diff --git a/db.txt b/db.txt index 809cd3c..da0cfad 100644 --- a/db.txt +++ b/db.txt @@ -216,7 +216,8 @@ country CA: DFS-FCC (2402 - 2472 @ 40), (30) (5170 - 5250 @ 80), (17), AUTO-BW (5250 - 5330 @ 80), (24), DFS, AUTO-BW - (5490 - 5730 @ 160), (24), DFS + (5490 - 5600 @ 80), (24), DFS + (5650 - 5730 @ 40), (24), DFS (5735 - 5835 @ 80), (30) # Source: -- I believe this could also be interpreted differently. If the change is only about removing the weather radar band (5600-5650), the change should be - (5490 - 5730 @ 160), (24), DFS + (5490 - 5570 @ 80), (24), DFS + (5570 - 5590 @ 20), (24), DFS + (5650 - 5730 @ 80), (24), DFS The second rule explicitly states that channel 116 remains available for HT20. If this level of strict correctness is not needed, rule 1 and 2 combined would be - (5490 - 5730 @ 160), (24), DFS + (5490 - 5590 @ 80), (24), DFS + (5650 - 5730 @ 80), (24), DFS Cheers Zefir -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
