demos | 2 Apr 10:06 2015
Picon

(wifi) specific feature list

Salve, grüzi, moin,

Has somebody an idea which (wifi) specific features, we - the EDN
project- see below -  could ask wireless software projects (such as
CJDNS, Qaulnet, Commotion Wireless etc.) to get a good overview, of what
they have reached so far/are able to do?

Here is the current list:

'[BaseSystemComponentsNotes Projects] Feature List'

##### General Information

1. Project name
2. Short description of what it does
3. Software license
4. Email contact
5. Programming language
6. What has this project that others don't have?
7. Future plans

##### Software Architecture

8. Link to codebase
9. Architecture diagram (wrt OSI-layer)
10. Included applications (for example messaging)
11. It has got a GUI
 12. For network administration
 13. For simple using
14. Supports Anonymisation
(Continue reading)

Grumbach, Emmanuel | 2 Apr 08:37 2015
Picon

pull request: iwlwifi-next 2015-04-02

Hi Kalle,

This is for 4.1. A bunch of work all over from the team.
I'll be away for a week or so, but I'll monitor email, but I hope you
won't have issues with this.
Let me know. Thanks!


The following changes since commit 2c44be81f0fc147eed9dc63e2601318b2c007aeb:

  mac80211: set QoS capability before changing station state (2015-03-30 15:11:01 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2015-04-02

for you to fetch changes up to 31755207afc5d5a30e3eea9e4f2a518fc5b680c1:

  iwlwifi: mvm: capture connection loss as part of MLME trigger (2015-04-02 09:29:13 +0300)

----------------------------------------------------------------
* some more work on LAR
* fixes for UMAC scan
* more work on debugging framework
* more work for 8000 devices
* cleanups and small bugfixes

----------------------------------------------------------------
Alexander Bondar (1):
      iwlwifi: mvm: Clean up UMAC scan UIDs in the reset and drv_stop flows
(Continue reading)

Malcolm Priestley | 1 Apr 23:32 2015
Picon

[PATCH 1/2] staging: vt6655: s_vGenerateTxParameter Replace PSTxBufHead with struct vnt_tx_fifo_head

With endian correction on fifo_ctl and current_rate.

Removing pTxBufHead, pFifoHead and wFifoCtl

Signed-off-by: Malcolm Priestley <tvboxspy@...>
---
 drivers/staging/vt6655/rxtx.c | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index 5b869d1..195dcc9 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
 <at>  <at>  -116,7 +116,7  <at>  <at>  void
 s_vGenerateTxParameter(
 	struct vnt_private *pDevice,
 	unsigned char byPktType,
-	void *pTxBufHead,
+	struct vnt_tx_fifo_head *,
 	void *pvRrvTime,
 	void *pvRTS,
 	void *pvCTS,
 <at>  <at>  -944,7 +944,7  <at>  <at>  void
 s_vGenerateTxParameter(
 	struct vnt_private *pDevice,
 	unsigned char byPktType,
-	void *pTxBufHead,
+	struct vnt_tx_fifo_head *tx_buffer_head,
 	void *pvRrvTime,
 	void *pvRTS,
(Continue reading)

Jakub Kiciński | 1 Apr 22:01 2015
Picon

Re: mediatek mt7630e and ksoftirqd CPU load

On Wed, 1 Apr 2015 19:33:13 +0000, gmoutso@... wrote:
> Thank you very much for your reply.
> 
> https://github.com/kuba-moo/mt7630e  solves my 100% CPU problem. 
> 
> I will publicize your repository on the Ubuntu bug
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1220146
> 
> If you don’t mind. You will make many people like me happy!

Glad to hear that it works for you.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Johannes Berg | 1 Apr 14:38 2015
Picon

[PATCH] mac80211: fix RX A-MPDU session reorder timer deletion

From: Johannes Berg <johannes.berg@...>

There's an issue with the way the RX A-MPDU reorder timer is
deleted that can cause a kernel crash like this:

 * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
 * station is destroyed
 * reorder timer fires before ieee80211_free_tid_rx() runs,
   accessing the station, thus potentially crashing due to
   the use-after-free

The station deletion is protected by synchronize_net(), but
that isn't enough -- ieee80211_free_tid_rx() need not have
run when that returns (it deletes the timer.) We could use
rcu_barrier() instead of synchronize_net(), but that's much
more expensive.

Instead, to fix this, add a field tracking that the session
is being deleted. In this case, the only re-arming of the
timer happens with the reorder spinlock held, so make that
code not rearm it if the session is being deleted and also
delete the timer after setting that field. This ensures the
timer cannot fire after ___ieee80211_stop_rx_ba_session()
returns, which fixes the problem.

Cc: stable@...
Signed-off-by: Johannes Berg <johannes.berg@...>
---
 net/mac80211/agg-rx.c   | 8 ++++++--
 net/mac80211/rx.c       | 7 ++++---
(Continue reading)

Johannes Berg | 1 Apr 14:27 2015
Picon

[PATCH] mac80211: fix RX A-MPDU session reorder timer deletion

From: Johannes Berg <johannes.berg@...>

There's an issue with the way the RX A-MPDU reorder timer is
deleted that can cause a kernel crash like this:

 * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
 * station is destroyed
 * reorder timer fires before ieee80211_free_tid_rx() runs,
   accessing the station, thus potentially crashing due to
   the use-after-free

The station deletion is protected by synchronize_net(), but
that isn't enough -- ieee80211_free_tid_rx() need not have
run when that returns (it deletes the timer.) We could use
rcu_barrier() instead of synchronize_net(), but that's much
more expensive.

Instead, to fix this, add a field tracking that the session
is being deleted. In this case, the only re-arming of the
timer happens with the reorder spinlock held, so make that
code not rearm it if the session is being deleted and also
delete the timer after setting that field. This ensures the
timer cannot fire after ___ieee80211_stop_rx_ba_session()
returns, which fixes the problem.

Signed-off-by: Johannes Berg <johannes.berg@...>
---
 net/mac80211/agg-rx.c   | 8 ++++++--
 net/mac80211/rx.c       | 7 ++++---
 net/mac80211/sta_info.h | 2 ++
(Continue reading)

miaoqing | 1 Apr 04:19 2015

[PATCH] ath9k: add extra GPIO led support

From: Miaoqing Pan <miaoqing@...>

ar9550 or later chips, the AR_GPIO_IN_OUT register only can
control GPIO[0:3]. For the extra GPIO, use standard GPIO calls
instead of WMAC internal registers.

Signed-off-by: Miaoqing Pan <miaoqing@...>
---
 drivers/net/wireless/ath/ath9k/gpio.c |  8 +++++++-
 drivers/net/wireless/ath/ath9k/hw.c   | 17 +++++++++++++++--
 drivers/net/wireless/ath/ath9k/hw.h   |  1 +
 drivers/net/wireless/ath/ath9k/reg.h  |  4 ++++
 4 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/gpio.c b/drivers/net/wireless/ath/ath9k/gpio.c
index 86d46c1..2847067 100644
--- a/drivers/net/wireless/ath/ath9k/gpio.c
+++ b/drivers/net/wireless/ath/ath9k/gpio.c
 <at>  <at>  -69,9 +69,15  <at>  <at>  void ath_fill_led_pin(struct ath_softc *sc)
 {
 	struct ath_hw *ah = sc->sc_ah;

-	if (AR_SREV_9100(ah) || (ah->led_pin >= 0))
+	if (AR_SREV_9100(ah))
 		return;

+	if (ah->led_pin >= 0) {
+		if (!((1 << ah->led_pin) & AR_GPIO_OE_OUT_MASK))
+			ath9k_hw_request_gpio(ah, ah->led_pin, "ath9k-led");
+		return;
(Continue reading)

Peter Oh | 1 Apr 01:44 2015

[PATCH v2 1/2] ath: define JP DFS patterns separated from FCC

Separate Japan's DFS pattern from FCC to control PPB threshold.

Currently all the radar detectors use the same threshold rate at
50%, but it's not able to achieve if data traffic rate is higher
than 40% because WLAN baseband used by ath9k and ath10k often fails
detecting radar pulses, so that SW cannot get enough radar reports
to achieve the rate.

Since Japan's W53 band requires 50% data traffic during its DFS
test we need to apply different threshold rate than others on it.
Hence define its own pattern to give flexibility to threshold rate.

Signed-off-by: Peter Oh <poh@...>
---
 drivers/net/wireless/ath/dfs_pattern_detector.c | 29 +++++++++++++++----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index b1de8c6..2d4ad45 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
 <at>  <at>  -41,7 +41,8  <at>  <at>  struct radar_types {

 /* percentage on ppb threshold to trigger detection */
 #define MIN_PPB_THRESH	50
-#define PPB_THRESH(PPB) ((PPB * MIN_PPB_THRESH + 50) / 100)
+#define PPB_THRESH_RATE(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
+#define PPB_THRESH(PPB) PPB_THRESH_RATE(PPB, MIN_PPB_THRESH)
 #define PRF2PRI(PRF) ((1000000 + PRF / 2) / PRF)
 /* percentage of pulse width tolerance */
(Continue reading)

ferran | 31 Mar 20:44 2015
Picon

Fwd: Unable to operate a rt2770 device at 5GHz in mesh mode


Hello everyone,

I want to build a mesh network at 5GHz with raspberry-pi's connected
each to one rt2770 device.
Following this tutorial [1] I succeed to create a virtual mesh
interface(1), set the channel(2) (let's say 11 by now) and then join a
mesh network(3). I can see the probes with Wireshark, and when more than
one has joined the mesh, I can also see the stats of the peers(4), and
then leave the network (5).

    # 1
    iw dev wlan0 interface add mesh0 type mp

    # 2
    iw dev mesh0 set channel 11

    # 3
    iw dev mesh0 mesh join my_mesh_id

    # 4
    iw dev mesh0 station dump

    # 5
    iw dev mesh0 mesh leave

As I say, everything works at 2.4 channels. However, when setting the
channel to one of the 5GHz band, I receive an error when trying to join
a mesh network. I tested all the channels that the driver claims to
support, and indeed, no 5GHz channel works.
(Continue reading)

Peter Oh | 31 Mar 20:16 2015

[PATCH 1/2] ath: define JP DFS patterns separated from FCC

Separate Japan's DFS pattern from FCC to control PPB threshold.

Currently all the radar detectors use the same threshold rate at
50%, but it's not able to achieve if data traffic rate is higher
than 40% because WLAN baseband used by ath9k and ath10k often fails
detecting radar pulses, so that SW cannot get enough radar reports
to achieve the rate.

Since Japan's W53 band requires 50% data traffic during its DFS
test we need to apply different threshold rate than others on it.
Hence define its own pattern to give flexibility to threshold rate.

Signed-off-by: Peter Oh <poh@...>
---
 drivers/net/wireless/ath/dfs_pattern_detector.c | 27 ++++++++++++++++---------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index b1de8c6..8d1e082 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
 <at>  <at>  -42,6 +42,7  <at>  <at>  struct radar_types {
 /* percentage on ppb threshold to trigger detection */
 #define MIN_PPB_THRESH	50
 #define PPB_THRESH(PPB) ((PPB * MIN_PPB_THRESH + 50) / 100)
+#define PPB_THRESH_JP(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
 #define PRF2PRI(PRF) ((1000000 + PRF / 2) / PRF)
 /* percentage of pulse width tolerance */
 #define WIDTH_TOLERANCE 5
 <at>  <at>  -96,17 +97,23  <at>  <at>  static const struct radar_types fcc_radar_types = {
(Continue reading)

John W. Linville | 31 Mar 16:49 2015

[PATCH] mac80211: reduce log spam from ieee80211_handle_pwr_constr

This changes a couple of messages from sdata_info to sdata_dbg.
This should reduce some log spam, as reported here:

	https://bugzilla.redhat.com/show_bug.cgi?id=1206468

Signed-off-by: John W. Linville <linville@...>
---
 net/mac80211/mlme.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 00103f36dcbf..26053bf2faa8 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
 <at>  <at>  -1348,15 +1348,15  <at>  <at>  static u32 ieee80211_handle_pwr_constr(struct ieee80211_sub_if_data *sdata,
 	 */
 	if (has_80211h_pwr &&
 	    (!has_cisco_pwr || pwr_level_80211h <= pwr_level_cisco)) {
-		sdata_info(sdata,
-			   "Limiting TX power to %d (%d - %d) dBm as advertised by %pM\n",
-			   pwr_level_80211h, chan_pwr, pwr_reduction_80211h,
-			   sdata->u.mgd.bssid);
+		sdata_dbg(sdata,
+			  "Limiting TX power to %d (%d - %d) dBm as advertised by %pM\n",
+			  pwr_level_80211h, chan_pwr, pwr_reduction_80211h,
+			  sdata->u.mgd.bssid);
 		new_ap_level = pwr_level_80211h;
 	} else {  /* has_cisco_pwr is always true here. */
-		sdata_info(sdata,
-			   "Limiting TX power to %d dBm as advertised by %pM\n",
(Continue reading)


Gmane