[PATCH 0/9] RFKill airplane-mode indicator

[João Paulo Rechi Vita]

This series implements an airplane-mode indicator LED trigger, which can be
used by platform drivers. The default policy have have airplane-mode set when
all the radios known by RFKill are OFF, and unset otherwise. This policy can be
overwritten by userspace using the new operations _AIRPLANE_MODE_ACQUIRE,
_AIRPLANE_MODE_RELEASE, and _AIRPLANE_MODE_CHANGE. When the airplane-mode
indicator state changes, userspace gets notifications through the RFKill
control misc device (/dev/rfkill).

The series also contains a few general fixes and improvements to the subsystem.

João Paulo Rechi Vita (9):
  rfkill: Improve documentation language
  rfkill: Remove extra blank line
  rfkill: Point to the correct deprecated doc location
  rfkill: Move "state" sysfs file back to stable
  rfkill: Factor rfkill_global_states[].cur assignments
  rfkill: Add documentation about LED triggers
  rfkill: Create "rfkill-airplane_mode" LED trigger
  rfkill: Userspace control for airplane mode
  rfkill: Notify userspace of airplane-mode state changes

 Documentation/ABI/obsolete/sysfs-class-rfkill |  20 
 Documentation/ABI/stable/sysfs-class-rfkill   |  27 -
 Documentation/rfkill.txt  |  17 +++
 include/uapi/linux/rfkill.h   |   3 +
 net/rfkill/core.c | 144 +-
 5 files changed, 164 insertions(+), 47 deletions(-)
 delete mode 100644 Documentation/ABI/obsolete/sysfs-class-rfkill

-- 
2.5.0

--
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 5/9] rfkill: Factor rfkill_global_states[].cur assignments

[João Paulo Rechi Vita]

Factor all assignments to rfkill_global_states[].cur into a single
function rfkill_update_global_state().

Signed-off-by: João Paulo Rechi Vita 
---
 net/rfkill/core.c | 38 +-
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 56d79cb..8b96869 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -302,6 +302,19 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
blocked)
rfkill_event(rfkill);
 }
 
+static void rfkill_update_global_state(enum rfkill_type type, bool blocked)
+{
+   int i;
+
+   if (type != RFKILL_TYPE_ALL) {
+   rfkill_global_states[type].cur = blocked;
+   return;
+   }
+
+   for (i = 0; i < NUM_RFKILL_TYPES; i++)
+   rfkill_global_states[i].cur = blocked;
+}
+
 #ifdef CONFIG_RFKILL_INPUT
 static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
 
@@ -319,15 +332,7 @@ static void __rfkill_switch_all(const enum rfkill_type 
type, bool blocked)
 {
struct rfkill *rfkill;
 
-   if (type == RFKILL_TYPE_ALL) {
-   int i;
-
-   for (i = 0; i < NUM_RFKILL_TYPES; i++)
-   rfkill_global_states[i].cur = blocked;
-   } else {
-   rfkill_global_states[type].cur = blocked;
-   }
-
+   rfkill_update_global_state(type, blocked);
list_for_each_entry(rfkill, _list, node) {
if (rfkill->type != type && type != RFKILL_TYPE_ALL)
continue;
@@ -1164,15 +1169,8 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
 
mutex_lock(_global_mutex);
 
-   if (ev.op == RFKILL_OP_CHANGE_ALL) {
-   if (ev.type == RFKILL_TYPE_ALL) {
-   enum rfkill_type i;
-   for (i = 0; i < NUM_RFKILL_TYPES; i++)
-   rfkill_global_states[i].cur = ev.soft;
-   } else {
-   rfkill_global_states[ev.type].cur = ev.soft;
-   }
-   }
+   if (ev.op == RFKILL_OP_CHANGE_ALL)
+   rfkill_update_global_state(ev.type, ev.soft);
 
list_for_each_entry(rfkill, _list, node) {
if (rfkill->idx != ev.idx && ev.op != RFKILL_OP_CHANGE_ALL)
@@ -1261,10 +1259,8 @@ static struct miscdevice rfkill_miscdev = {
 static int __init rfkill_init(void)
 {
int error;
-   int i;
 
-   for (i = 0; i < NUM_RFKILL_TYPES; i++)
-   rfkill_global_states[i].cur = !rfkill_default_state;
+   rfkill_update_global_state(RFKILL_TYPE_ALL, !rfkill_default_state);
 
error = class_register(_class);
if (error)
-- 
2.5.0

--
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 4/9] rfkill: Move "state" sysfs file back to stable

[João Paulo Rechi Vita]

There is still quite a bit of code using this interface, so we can't
just remove it. Hopefully it will be possible in the future, but since
its scheduled removal date is past 2 years already, we are better having
the documentation reflecting the current state of things.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/ABI/obsolete/sysfs-class-rfkill | 20 
 Documentation/ABI/stable/sysfs-class-rfkill   | 25 ++---
 2 files changed, 22 insertions(+), 23 deletions(-)
 delete mode 100644 Documentation/ABI/obsolete/sysfs-class-rfkill

diff --git a/Documentation/ABI/obsolete/sysfs-class-rfkill 
b/Documentation/ABI/obsolete/sysfs-class-rfkill
deleted file mode 100644
index e736d14..000
--- a/Documentation/ABI/obsolete/sysfs-class-rfkill
+++ /dev/null
@@ -1,20 +0,0 @@
-rfkill - radio frequency (RF) connector kill switch support
-
-For details to this subsystem look at Documentation/rfkill.txt.
-
-What:  /sys/class/rfkill/rfkill[0-9]+/state
-Date:  09-Jul-2007
-KernelVersion  v2.6.22
-Contact:   linux-wireless@vger.kernel.org
-Description:   Current state of the transmitter.
-   This file is deprecated and scheduled to be removed in 2014,
-   because its not possible to express the 'soft and hard block'
-   state of the rfkill driver.
-Values:A numeric value.
-   0: RFKILL_STATE_SOFT_BLOCKED
-   transmitter is turned off by software
-   1: RFKILL_STATE_UNBLOCKED
-   transmitter is (potentially) active
-   2: RFKILL_STATE_HARD_BLOCKED
-   transmitter is forced off by something outside of
-   the driver's control.
diff --git a/Documentation/ABI/stable/sysfs-class-rfkill 
b/Documentation/ABI/stable/sysfs-class-rfkill
index e51571e..e1ba4a1 100644
--- a/Documentation/ABI/stable/sysfs-class-rfkill
+++ b/Documentation/ABI/stable/sysfs-class-rfkill
@@ -5,9 +5,6 @@ For details to this subsystem look at Documentation/rfkill.txt.
 For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
 Documentation/ABI/removed/sysfs-class-rfkill.
 
-For the deprecated /sys/class/rfkill/*/state knobs of this interface look in
-Documentation/ABI/obsolete/sysfs-class-rfkill.
-
 What:  /sys/class/rfkill
 Date:  09-Jul-2007
 KernelVersion: v2.6.22
@@ -44,6 +41,28 @@ Values:  A numeric value.
1: true
 
 
+What:  /sys/class/rfkill/rfkill[0-9]+/state
+Date:  09-Jul-2007
+KernelVersion  v2.6.22
+Contact:   linux-wireless@vger.kernel.org
+Description:   Current state of the transmitter.
+   This file was scheduled to be removed in 2014, but due to its
+   large number of users it will be sticking around for a bit
+   longer. Despite it being marked as stabe, the newer "hard" and
+   "soft" interfaces should be preffered, since it is not possible
+   to express the 'soft and hard block' state of the rfkill driver
+   through this interface. There will likely be another attempt to
+   remove it in the future.
+Values:A numeric value.
+   0: RFKILL_STATE_SOFT_BLOCKED
+   transmitter is turned off by software
+   1: RFKILL_STATE_UNBLOCKED
+   transmitter is (potentially) active
+   2: RFKILL_STATE_HARD_BLOCKED
+   transmitter is forced off by something outside of
+   the driver's control.
+
+
 What:  /sys/class/rfkill/rfkill[0-9]+/hard
 Date:  12-March-2010
 KernelVersion  v2.6.34
-- 
2.5.0

--
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 1/9] rfkill: Improve documentation language

[João Paulo Rechi Vita]

Signed-off-by: João Paulo Rechi Vita 
---
 net/rfkill/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index a805831..ffbc375 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -282,8 +282,8 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
blocked)
spin_lock_irqsave(>lock, flags);
if (err) {
/*
-* Failed -- reset status to _prev, this may be different
-* from what set set _PREV to earlier in this function
+* Failed -- reset status to _PREV, which may be different
+* from what we have set _PREV to earlier in this function
 * if rfkill_set_sw_state was invoked.
 */
if (rfkill->state & RFKILL_BLOCK_SW_PREV)
-- 
2.5.0

--
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 8/9] rfkill: Userspace control for airplane mode

[Marcel Holtmann]

Hi Joa Paulo,

> Provide an interface for the airplane-mode indicator be controlled from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
> 
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft". If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.

as explained in an earlier response, the concept Airplane Mode seems to be 
imposing policy into the kernel. Do we really want have this as a kernel 
exposed API.

Regards

Marcel

--
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 8/9] rfkill: Userspace control for airplane mode

[João Paulo Rechi Vita]

Provide an interface for the airplane-mode indicator be controlled from
userspace. User has to first acquire the control through
RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
it wants to be in control of the indicator. Closing the fd or using
RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.

To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
operation is used, passing the value on "struct rfkill_event.soft". If
the caller has not acquired the airplane-mode control beforehand, the
operation fails.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt| 10 ++
 include/uapi/linux/rfkill.h |  3 +++
 net/rfkill/core.c   | 47 ++---
 3 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index b13025a..aa6e014 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -87,6 +87,7 @@ RFKill provides per-switch LED triggers, which can be used to 
drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
 An airplane-mode indicator LED trigger is also available, which triggers
 LED_FULL when all radios known by RFKill are blocked, and LED_OFF otherwise.
+The airplane-mode indicator LED trigger policy can be overridden by userspace.
 
 
 5. Userspace support
@@ -123,5 +124,14 @@ RFKILL_TYPE
 The contents of these variables corresponds to the "name", "state" and
 "type" sysfs files explained above.
 
+Userspace can also override the default airplane-mode indicator policy through
+/dev/rfkill. Control of the airplane mode indicator has to be acquired first,
+using RFKILL_OP_AIRPLANE_MODE_ACQUIRE, and is only available for one userspace
+application at a time. Closing the fd or using RFKILL_OP_AIRPLANE_MODE_RELEASE
+reverts the airplane-mode indicator back to the default kernel policy and makes
+it available for other applications to take control. Changes to the
+airplane-mode indicator state can be made using RFKILL_OP_AIRPLANE_MODE_CHANGE,
+passing the new value in the 'soft' field of 'struct rfkill_event'.
+
 
 For further details consult Documentation/ABI/stable/sysfs-class-rfkill.
diff --git a/include/uapi/linux/rfkill.h b/include/uapi/linux/rfkill.h
index 2e00dce..9cb999b 100644
--- a/include/uapi/linux/rfkill.h
+++ b/include/uapi/linux/rfkill.h
@@ -67,6 +67,9 @@ enum rfkill_operation {
RFKILL_OP_DEL,
RFKILL_OP_CHANGE,
RFKILL_OP_CHANGE_ALL,
+   RFKILL_OP_AIRPLANE_MODE_ACQUIRE,
+   RFKILL_OP_AIRPLANE_MODE_RELEASE,
+   RFKILL_OP_AIRPLANE_MODE_CHANGE,
 };
 
 /**
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index fb11547..8067701 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -89,6 +89,7 @@ struct rfkill_data {
struct mutexmtx;
wait_queue_head_t   read_wait;
boolinput_handler;
+   boolis_apm_owner;
 };
 
 
@@ -123,7 +124,7 @@ static struct {
 } rfkill_global_states[NUM_RFKILL_TYPES];
 
 static bool rfkill_epo_lock_active;
-
+static bool rfkill_apm_owned;
 
 #ifdef CONFIG_RFKILL_LEDS
 static struct led_trigger rfkill_apm_led_trigger;
@@ -350,7 +351,8 @@ static void rfkill_update_global_state(enum rfkill_type 
type, bool blocked)
 
for (i = 0; i < NUM_RFKILL_TYPES; i++)
rfkill_global_states[i].cur = blocked;
-   rfkill_apm_led_trigger_event(blocked);
+   if (!rfkill_apm_owned)
+   rfkill_apm_led_trigger_event(blocked);
 }
 
 #ifdef CONFIG_RFKILL_INPUT
@@ -1183,6 +1185,7 @@ static ssize_t rfkill_fop_read(struct file *file, char 
__user *buf,
 static ssize_t rfkill_fop_write(struct file *file, const char __user *buf,
size_t count, loff_t *pos)
 {
+   struct rfkill_data *data = file->private_data;
struct rfkill *rfkill;
struct rfkill_event ev;
 
@@ -1199,7 +1202,7 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
if (copy_from_user(, buf, count))
return -EFAULT;
 
-   if (ev.op != RFKILL_OP_CHANGE && ev.op != RFKILL_OP_CHANGE_ALL)
+   if (ev.op < RFKILL_OP_CHANGE)
return -EINVAL;
 
if (ev.type >= NUM_RFKILL_TYPES)
@@ -1207,6 +1210,34 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
 
mutex_lock(_global_mutex);
 
+   if (ev.op == RFKILL_OP_AIRPLANE_MODE_ACQUIRE) {
+   if (rfkill_apm_owned && !data->is_apm_owner) {
+   count = -EACCES;
+   } else {
+   rfkill_apm_owned = true;
+   data->is_apm_owner = true;
+   }
+   }
+
+   if (ev.op == RFKILL_OP_AIRPLANE_MODE_RELEASE) {
+   if (rfkill_apm_owned && !data->is_apm_owner) {
+   count = -EACCES;
+   } else {
+ 

[PATCH 7/9] rfkill: Create "rfkill-airplane_mode" LED trigger

[João Paulo Rechi Vita]

This creates a new LED trigger to be used by platform drivers as a
default trigger for airplane-mode indicator LEDs.

By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called
for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL
when the changing the state to blocked, and to LED_OFF when the changing
the state to unblocked. In the future there will be a mechanism for
userspace to override the default policy, so it can implement its own.

This trigger will be used by the asus-wireless x86 platform driver.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt |  2 ++
 net/rfkill/core.c| 49 +++-
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 1f0c270..b13025a 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -85,6 +85,8 @@ device). Don't do this unless you cannot get the event in any 
other way.
 
 RFKill provides per-switch LED triggers, which can be used to drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
+An airplane-mode indicator LED trigger is also available, which triggers
+LED_FULL when all radios known by RFKill are blocked, and LED_OFF otherwise.
 
 
 5. Userspace support
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 8b96869..fb11547 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -126,6 +126,30 @@ static bool rfkill_epo_lock_active;
 
 
 #ifdef CONFIG_RFKILL_LEDS
+static struct led_trigger rfkill_apm_led_trigger;
+
+static void rfkill_apm_led_trigger_event(bool state)
+{
+   led_trigger_event(_apm_led_trigger, state ? LED_FULL : LED_OFF);
+}
+
+static void rfkill_apm_led_trigger_activate(struct led_classdev *led)
+{
+   rfkill_apm_led_trigger_event(!rfkill_default_state);
+}
+
+static int rfkill_apm_led_trigger_register(void)
+{
+   rfkill_apm_led_trigger.name = "rfkill-airplane_mode";
+   rfkill_apm_led_trigger.activate = rfkill_apm_led_trigger_activate;
+   return led_trigger_register(_apm_led_trigger);
+}
+
+static void rfkill_apm_led_trigger_unregister(void)
+{
+   led_trigger_unregister(_apm_led_trigger);
+}
+
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
struct led_trigger *trigger;
@@ -177,6 +201,19 @@ static void rfkill_led_trigger_unregister(struct rfkill 
*rfkill)
led_trigger_unregister(>led_trigger);
 }
 #else
+static void rfkill_apm_led_trigger_event(bool state)
+{
+}
+
+static int rfkill_apm_led_trigger_register(void)
+{
+   return 0;
+}
+
+static void rfkill_apm_led_trigger_unregister(void)
+{
+}
+
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
 }
@@ -313,6 +350,7 @@ static void rfkill_update_global_state(enum rfkill_type 
type, bool blocked)
 
for (i = 0; i < NUM_RFKILL_TYPES; i++)
rfkill_global_states[i].cur = blocked;
+   rfkill_apm_led_trigger_event(blocked);
 }
 
 #ifdef CONFIG_RFKILL_INPUT
@@ -1260,15 +1298,22 @@ static int __init rfkill_init(void)
 {
int error;
 
+   error = rfkill_apm_led_trigger_register();
+   if (error)
+   goto out;
+
rfkill_update_global_state(RFKILL_TYPE_ALL, !rfkill_default_state);
 
error = class_register(_class);
-   if (error)
+   if (error) {
+   rfkill_apm_led_trigger_unregister();
goto out;
+   }
 
error = misc_register(_miscdev);
if (error) {
class_unregister(_class);
+   rfkill_apm_led_trigger_unregister();
goto out;
}
 
@@ -1277,6 +1322,7 @@ static int __init rfkill_init(void)
if (error) {
misc_deregister(_miscdev);
class_unregister(_class);
+   rfkill_apm_led_trigger_unregister();
goto out;
}
 #endif
@@ -1293,5 +1339,6 @@ static void __exit rfkill_exit(void)
 #endif
misc_deregister(_miscdev);
class_unregister(_class);
+   rfkill_apm_led_trigger_unregister();
 }
 module_exit(rfkill_exit);
-- 
2.5.0

--
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 3/9] rfkill: Point to the correct deprecated doc location

[João Paulo Rechi Vita]

The "claim" sysfs interface has been removed, so its documentation now
lives in the "removed" folder.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/ABI/stable/sysfs-class-rfkill | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-class-rfkill 
b/Documentation/ABI/stable/sysfs-class-rfkill
index 097f522..e51571e 100644
--- a/Documentation/ABI/stable/sysfs-class-rfkill
+++ b/Documentation/ABI/stable/sysfs-class-rfkill
@@ -2,8 +2,10 @@ rfkill - radio frequency (RF) connector kill switch support
 
 For details to this subsystem look at Documentation/rfkill.txt.
 
-For the deprecated /sys/class/rfkill/*/state and
-/sys/class/rfkill/*/claim knobs of this interface look in
+For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
+Documentation/ABI/removed/sysfs-class-rfkill.
+
+For the deprecated /sys/class/rfkill/*/state knobs of this interface look in
 Documentation/ABI/obsolete/sysfs-class-rfkill.
 
 What:  /sys/class/rfkill
-- 
2.5.0

--
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 6/9] rfkill: Add documentation about LED triggers

[João Paulo Rechi Vita]

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 2ee6ef9..1f0c270 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -83,6 +83,8 @@ rfkill drivers that control devices that can be hard-blocked 
unless they also
 assign the poll_hw_block() callback (then the rfkill core will poll the
 device). Don't do this unless you cannot get the event in any other way.
 
+RFKill provides per-switch LED triggers, which can be used to drive LEDs
+according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
 
 
 5. Userspace support
-- 
2.5.0

--
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 8/9] rfkill: Userspace control for airplane mode

[Dan Williams]

On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote:
> Provide an interface for the airplane-mode indicator be controlled
> from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole
> time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
> 
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft".
> If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.

I'd like to clarify a bit, so tell me if I'm correct or not.  Using
RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
state. It's just an indicator with no relationship to any of the
registered rfkill switches, right?

I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't also
softblock all switches, otherwise you can set airplane mode all day
long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually enable
airplane mode at all?

Dan

> Signed-off-by: João Paulo Rechi Vita 
> ---
>  Documentation/rfkill.txt| 10 ++
>  include/uapi/linux/rfkill.h |  3 +++
>  net/rfkill/core.c   | 47
> ++---
>  3 files changed, 57 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
> index b13025a..aa6e014 100644
> --- a/Documentation/rfkill.txt
> +++ b/Documentation/rfkill.txt
> @@ -87,6 +87,7 @@ RFKill provides per-switch LED triggers, which can
> be used to drive LEDs
>  according to the switch state (LED_FULL when blocked, LED_OFF
> otherwise).
>  An airplane-mode indicator LED trigger is also available, which
> triggers
>  LED_FULL when all radios known by RFKill are blocked, and LED_OFF
> otherwise.
> +The airplane-mode indicator LED trigger policy can be overridden by
> userspace.
>  
>  
>  5. Userspace support
> @@ -123,5 +124,14 @@ RFKILL_TYPE
>  The contents of these variables corresponds to the "name", "state"
> and
>  "type" sysfs files explained above.
>  
> +Userspace can also override the default airplane-mode indicator
> policy through
> +/dev/rfkill. Control of the airplane mode indicator has to be
> acquired first,
> +using RFKILL_OP_AIRPLANE_MODE_ACQUIRE, and is only available for one
> userspace
> +application at a time. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE
> +reverts the airplane-mode indicator back to the default kernel
> policy and makes
> +it available for other applications to take control. Changes to the
> +airplane-mode indicator state can be made using
> RFKILL_OP_AIRPLANE_MODE_CHANGE,
> +passing the new value in the 'soft' field of 'struct rfkill_event'.
> +
>  
>  For further details consult Documentation/ABI/stable/sysfs-class
> -rfkill.
> diff --git a/include/uapi/linux/rfkill.h
> b/include/uapi/linux/rfkill.h
> index 2e00dce..9cb999b 100644
> --- a/include/uapi/linux/rfkill.h
> +++ b/include/uapi/linux/rfkill.h
> @@ -67,6 +67,9 @@ enum rfkill_operation {
>   RFKILL_OP_DEL,
>   RFKILL_OP_CHANGE,
>   RFKILL_OP_CHANGE_ALL,
> + RFKILL_OP_AIRPLANE_MODE_ACQUIRE,
> + RFKILL_OP_AIRPLANE_MODE_RELEASE,
> + RFKILL_OP_AIRPLANE_MODE_CHANGE,
>  };
>  
>  /**
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index fb11547..8067701 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -89,6 +89,7 @@ struct rfkill_data {
>   struct mutexmtx;
>   wait_queue_head_t   read_wait;
>   boolinput_handler;
> + boolis_apm_owner;
>  };
>  
>  
> @@ -123,7 +124,7 @@ static struct {
>  } rfkill_global_states[NUM_RFKILL_TYPES];
>  
>  static bool rfkill_epo_lock_active;
> -
> +static bool rfkill_apm_owned;
>  
>  #ifdef CONFIG_RFKILL_LEDS
>  static struct led_trigger rfkill_apm_led_trigger;
> @@ -350,7 +351,8 @@ static void rfkill_update_global_state(enum
> rfkill_type type, bool blocked)
>  
>   for (i = 0; i < NUM_RFKILL_TYPES; i++)
>   rfkill_global_states[i].cur = blocked;
> - rfkill_apm_led_trigger_event(blocked);
> + if (!rfkill_apm_owned)
> + rfkill_apm_led_trigger_event(blocked);
>  }
>  
>  #ifdef CONFIG_RFKILL_INPUT
> @@ -1183,6 +1185,7 @@ static ssize_t rfkill_fop_read(struct file
> *file, char __user *buf,
>  static ssize_t rfkill_fop_write(struct file *file, const char __user
> *buf,
>   size_t count, loff_t *pos)
>  {
> + struct rfkill_data *data = file->private_data;
>   struct rfkill *rfkill;
>   struct rfkill_event ev;
>  
> @@ -1199,7 +1202,7 @@ static ssize_t rfkill_fop_write(struct file
> *file, const char __user *buf,
>   if (copy_from_user(, buf, count))
>   return -EFAULT;
>  
> - if (ev.op != RFKILL_OP_CHANGE && ev.op !=
> RFKILL_OP_CHANGE_ALL)
> + if (ev.op < 

Re: [RFC v4] mac80211: add A-MSDU tx support

[Krishna Chaitanya]

On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  wrote:
> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
>> Requires software tx queueing support. frag_list support (for zero-copy)
>> is optional.
>>
>> Signed-off-by: Felix Fietkau 
>> ---
>
>
> Ok - looks fine, but... and here comes the hard stuff.
> The frame size in the PLCP is limited in a way that you can't - from a
> spec POV - enable A-MSDU for low rates. Of course, you don't want to
> do that for low rates at all regardless of the spec.
> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
> of the link quality, how do we prevent A-MSDU if the rate is low /
> dropping.
> I'd even argue that when the rates get lower, you'll  have more
> packets piling up in the software queue and ... even more chance to
> get A-MSDU in the exact case where you really want to avoid it?

Similar to triggering AMPDU setup, we should put this control
in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
drop below a pre-defined MCS (or) only for best-throughput rates.
--
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: [RFC v4] mac80211: add A-MSDU tx support

[Felix Fietkau]

On 2016-02-08 11:26, Emmanuel Grumbach wrote:
> On Mon, Feb 8, 2016 at 11:54 AM, Krishna Chaitanya
>  wrote:
>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
>> wrote:
>>> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
 Requires software tx queueing support. frag_list support (for zero-copy)
 is optional.

 Signed-off-by: Felix Fietkau 
 ---
>>>
>>>
>>> Ok - looks fine, but... and here comes the hard stuff.
>>> The frame size in the PLCP is limited in a way that you can't - from a
>>> spec POV - enable A-MSDU for low rates. Of course, you don't want to
>>> do that for low rates at all regardless of the spec.
>>> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
>>> of the link quality, how do we prevent A-MSDU if the rate is low /
>>> dropping.
>>> I'd even argue that when the rates get lower, you'll  have more
>>> packets piling up in the software queue and ... even more chance to
>>> get A-MSDU in the exact case where you really want to avoid it?
>>
>> Similar to triggering AMPDU setup, we should put this control
>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
>> drop below a pre-defined MCS (or) only for best-throughput rates.
> 
> Ok - but the size of A-MPDU is determined in the firmware / hardware
> typically (at least for Intel devices and I have to admit my ignorance
> about other designs...). So that if you get bad link conditions, the
> firmware can play for that size. A-MSDU built in the host is a
> different story. I remember that athXk devices attach the rate on the
> Tx packet itself so that the rate control is serialized with the data
> path.
> iwlwifi works differently: we have a map of rates in the firmware.
> This map is maintained in the driver updated based on the feedback we
> get from the device. When an update is needed, iwlwifi sends a command
> to the firmware and that command bypasses all the Tx packets currently
> queue so that a packet that is already waiting in the queue will be
> sent with the updated map. This allows iwlwifi to react downgrade
> faster when needed.
Even ath9k has been converted to use a per-sta rate table with optional
per-packet rate overrides for probing.

> So - for athXk (and maybe the MediaTek devices Felix is working on),
> this may not be a big problem: you'd need to add another input to the
> A-MSDU building code coming from the rate control.
> FWIW: in iwlwifi I simply decided to be on the safe side and allowed
> the driver to build A-MSDUs only if the rate is fairly high and we are
> not downgrading. But you saw (and commented on) that patch already I
> think :)
I think it would be a good idea for iwlwifi to start using the rate
control API properly. Not only would that simplify integration with the
A-MSDU code, it would also make it possible to compare minstrel_ht with
the iwlwifi rate control code.
The iwlwifi rate control code is doing some crazy things, and I'd be
really interested in seeing how it compares to the more simple and
structured approach taken in minstrel_ht.

- Felix
--
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 v3 3/3] mwifiex: parse host wakeup configuration from device tree

[Arnd Bergmann]

On Monday 08 February 2016 02:15:28 Amitkumar Karwar wrote:
> @@ -30,6 +84,44 @@ static int mwifiex_plt_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> +#ifdef CONFIG_PM_SLEEP
> +static int mwifiex_plt_suspend(struct device *dev)
> +{
> + struct mwifiex_wake_dev *ctx = dev_get_drvdata(dev);
> + int ret;
> +
...
> +static const struct dev_pm_ops mwifiex_plt_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(mwifiex_plt_suspend, mwifiex_plt_resume)
> +};
> +#endif /* CONFIG_PM_SLEEP */
> +
>  static const struct of_device_id mwifiex_dt_match[] = {
>   {
>   .compatible = "marvell,mwifiex",
> @@ -45,6 +137,9 @@ static struct platform_driver mwifiex_platform_driver = {
>   .driver = {
>   .name   = "mwifiex_plt",
>   .of_match_table = mwifiex_dt_match,
> +#ifdef CONFIG_PM_SLEEP
> + .pm = _plt_pm_ops,
> +#endif
>   }
>  };

Just remove the #ifdef here, and mark the functions as __maybe_unused.

Arnd
--
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: [RFC v4] mac80211: add A-MSDU tx support

[Krishna Chaitanya]

On Mon, Feb 8, 2016 at 3:56 PM, Emmanuel Grumbach  wrote:
> On Mon, Feb 8, 2016 at 11:54 AM, Krishna Chaitanya
>  wrote:
>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
>> wrote:
>>> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
 Requires software tx queueing support. frag_list support (for zero-copy)
 is optional.

 Signed-off-by: Felix Fietkau 
 ---
>>>
>>>
>>> Ok - looks fine, but... and here comes the hard stuff.
>>> The frame size in the PLCP is limited in a way that you can't - from a
>>> spec POV - enable A-MSDU for low rates. Of course, you don't want to
>>> do that for low rates at all regardless of the spec.
>>> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
>>> of the link quality, how do we prevent A-MSDU if the rate is low /
>>> dropping.
>>> I'd even argue that when the rates get lower, you'll  have more
>>> packets piling up in the software queue and ... even more chance to
>>> get A-MSDU in the exact case where you really want to avoid it?
>>
>> Similar to triggering AMPDU setup, we should put this control
>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
>> drop below a pre-defined MCS (or) only for best-throughput rates.
>
> Ok - but the size of A-MPDU is determined in the firmware / hardware
> typically (at least for Intel devices and I have to admit my ignorance
> about other designs...). So that if you get bad link conditions, the
> firmware can play for that size. A-MSDU built in the host is a
> different story. I remember that athXk devices attach the rate on the
> Tx packet itself so that the rate control is serialized with the data
> path.
> iwlwifi works differently: we have a map of rates in the firmware.
> This map is maintained in the driver updated based on the feedback we
> get from the device. When an update is needed, iwlwifi sends a command
> to the firmware and that command bypasses all the Tx packets currently
> queue so that a packet that is already waiting in the queue will be
> sent with the updated map. This allows iwlwifi to react downgrade
> faster when needed.
> So - for athXk (and maybe the MediaTek devices Felix is working on),
> this may not be a big problem: you'd need to add another input to the
> A-MSDU building code coming from the rate control.
> FWIW: in iwlwifi I simply decided to be on the safe side and allowed
> the driver to build A-MSDUs only if the rate is fairly high and we are
> not downgrading. But you saw (and commented on) that patch already I
> think :)

Yes, this approach is going to be tough for those devices with HW RC.
We might need something like amsdu_action to get some feedback from
device about using of amsdu?
--
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 v3 2/3] mwifiex: parse chip specific gpio from device tree

[Amitkumar Karwar]

From: Xinming Hu 

This patch parse chip specific gpio parameter from device
tree. Corresponding binding file is also updated.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 Documentation/devicetree/bindings/mwifiex.txt  | 6 --
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 9 +
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mwifiex.txt 
b/Documentation/devicetree/bindings/mwifiex.txt
index 39b6a74..367c97e 100644
--- a/Documentation/devicetree/bindings/mwifiex.txt
+++ b/Documentation/devicetree/bindings/mwifiex.txt
@@ -11,7 +11,9 @@ Optional properties:
   - mwifiex,caldata* : A series of properties with marvell,caldata prefix,
  represent Calibration data downloaded to the device during
  initialization. This is an array of unsigned values.
-
+  - mwifiex,chip-gpio : Chip's wakeup gpio pin number. This needs to be 
downloaded
+   to to firmware. Chip notifies wifi wakeup signal to SOC
+   through this pin.
 
 Example:
 
@@ -24,6 +26,6 @@ mwifiex {
 
mwifiex,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
 0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01 ...>;
-
+   mwifiex,chip-gpio = <3>;
 };
 
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index a8b6939..8c011eb 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2134,6 +2134,7 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 
first_sta, bool init)
enum state_11d_t state_11d;
struct mwifiex_ds_11n_tx_cfg tx_cfg;
u8 sdio_sp_rx_aggr_enable;
+   u32 data;
 
if (first_sta) {
if (priv->adapter->iface_type == MWIFIEX_PCIE) {
@@ -2157,6 +2158,14 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, 
u8 first_sta, bool init)
adapter->dt_node = mwifiex_plt_dev ?
mwifiex_plt_dev->dev.of_node : NULL;
if (adapter->dt_node) {
+   if (of_property_read_u32(adapter->dt_node,
+"mwifiex,chip-gpio",
+) == 0) {
+   mwifiex_dbg(adapter, INFO,
+   "chip_gpio = 0x%x\n", data);
+   adapter->hs_cfg.gpio = data;
+   }
+
ret = mwifiex_dnld_dt_cfgdata(priv, adapter->dt_node,
  "mwifiex,caldata");
if (ret)
-- 
1.8.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 v3 1/3] mwifiex: register platform specific driver

[Amitkumar Karwar]

From: Xinming Hu 

Platform device and driver provides easy way to
interact with device-tree-enabled system.

This patch registers platform driver and reorganise
existing device tree specific code.
Corresponding device tree binding file is
also created.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
v3: Don't update adapter->dt_node if mwifiex_plt_dev is NULL 
---
 Documentation/devicetree/bindings/mwifiex.txt  | 29 +++
 drivers/net/wireless/marvell/mwifiex/Makefile  |  1 +
 drivers/net/wireless/marvell/mwifiex/main.c|  2 +
 drivers/net/wireless/marvell/mwifiex/main.h| 14 +
 .../net/wireless/marvell/mwifiex/platform_drv.c| 59 ++
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c |  6 +--
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   |  2 +-
 7 files changed, 109 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mwifiex.txt
 create mode 100644 drivers/net/wireless/marvell/mwifiex/platform_drv.c

diff --git a/Documentation/devicetree/bindings/mwifiex.txt 
b/Documentation/devicetree/bindings/mwifiex.txt
new file mode 100644
index 000..39b6a74
--- /dev/null
+++ b/Documentation/devicetree/bindings/mwifiex.txt
@@ -0,0 +1,29 @@
+mwifiex
+--
+
+Required properties:
+
+  - name : must be "mwifiex"
+  - compatible : must be "marvell,mwifiex"
+
+Optional properties:
+
+  - mwifiex,caldata* : A series of properties with marvell,caldata prefix,
+ represent Calibration data downloaded to the device during
+ initialization. This is an array of unsigned values.
+
+
+Example:
+
+Tx power limit calibration data is configured in below example.
+The calibration data is an array of unsigned values, the length
+can vary between hw versions.
+
+mwifiex {
+   compatible = "marvell,mwifiex";
+
+   mwifiex,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
+0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01 ...>;
+
+};
+
diff --git a/drivers/net/wireless/marvell/mwifiex/Makefile 
b/drivers/net/wireless/marvell/mwifiex/Makefile
index fdfd9bf..1444fd1 100644
--- a/drivers/net/wireless/marvell/mwifiex/Makefile
+++ b/drivers/net/wireless/marvell/mwifiex/Makefile
@@ -42,6 +42,7 @@ mwifiex-y += cfg80211.o
 mwifiex-y += ethtool.o
 mwifiex-y += 11h.o
 mwifiex-y += tdls.o
+mwifiex-y += platform_drv.o
 mwifiex-$(CONFIG_DEBUG_FS) += debugfs.o
 obj-$(CONFIG_MWIFIEX) += mwifiex.o
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 3cfa946..b93ae69 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1538,6 +1538,7 @@ EXPORT_SYMBOL_GPL(_mwifiex_dbg);
 static int
 mwifiex_init_module(void)
 {
+   mwifiex_platform_drv_init();
 #ifdef CONFIG_DEBUG_FS
mwifiex_debugfs_init();
 #endif
@@ -1552,6 +1553,7 @@ mwifiex_init_module(void)
 static void
 mwifiex_cleanup_module(void)
 {
+   mwifiex_platform_drv_exit();
 #ifdef CONFIG_DEBUG_FS
mwifiex_debugfs_remove();
 #endif
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index aea7aee..464d79f 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -37,6 +37,16 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include "decl.h"
 #include "ioctl.h"
@@ -47,6 +57,7 @@
 #include "sdio.h"
 
 extern const char driver_version[];
+extern struct platform_device *mwifiex_plt_dev;
 
 struct mwifiex_adapter;
 struct mwifiex_private;
@@ -1597,6 +1608,9 @@ void mwifiex_process_multi_chan_event(struct 
mwifiex_private *priv,
  struct sk_buff *event_skb);
 void mwifiex_multi_chan_resync(struct mwifiex_adapter *adapter);
 
+int mwifiex_platform_drv_init(void);
+void mwifiex_platform_drv_exit(void);
+
 #ifdef CONFIG_DEBUG_FS
 void mwifiex_debugfs_init(void);
 void mwifiex_debugfs_remove(void);
diff --git a/drivers/net/wireless/marvell/mwifiex/platform_drv.c 
b/drivers/net/wireless/marvell/mwifiex/platform_drv.c
new file mode 100644
index 000..f64a12a
--- /dev/null
+++ b/drivers/net/wireless/marvell/mwifiex/platform_drv.c
@@ -0,0 +1,59 @@
+/* Marvell wireless LAN device driver: platform specific driver
+ *
+ * Copyright (C) 2015, Marvell International Ltd.
+ *
+ * This software file (the "File") is distributed by Marvell International
+ * Ltd. under the terms of the GNU General Public License Version 2, June 1991
+ * (the "License").  You may use, redistribute and/or modify this File in
+ * accordance with the terms and conditions of the License, a copy of which
+ * is available on the worldwide web at
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.
+ *
+ * THE FILE IS DISTRIBUTED AS-IS, WITHOUT WARRANTY OF ANY KIND, AND 

[RFC v4] mac80211: add A-MSDU tx support

[Felix Fietkau]

Requires software tx queueing support. frag_list support (for zero-copy)
is optional.

Signed-off-by: Felix Fietkau 
---
 include/net/mac80211.h |  13 
 net/mac80211/agg-tx.c  |   5 ++
 net/mac80211/debugfs.c |   2 +
 net/mac80211/ieee80211_i.h |   1 +
 net/mac80211/tx.c  | 160 +
 5 files changed, 181 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5714774..8c28210 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -709,6 +709,7 @@ enum mac80211_tx_info_flags {
  * @IEEE80211_TX_CTRL_PS_RESPONSE: This frame is a response to a poll
  * frame (PS-Poll or uAPSD).
  * @IEEE80211_TX_CTRL_RATE_INJECT: This frame is injected with rate information
+ * @IEEE80211_TX_CTRL_AMSDU: This frame is an A-MSDU frame
  *
  * These flags are used in tx_info->control.flags.
  */
@@ -716,6 +717,7 @@ enum mac80211_tx_control_flags {
IEEE80211_TX_CTRL_PORT_CTRL_PROTO   = BIT(0),
IEEE80211_TX_CTRL_PS_RESPONSE   = BIT(1),
IEEE80211_TX_CTRL_RATE_INJECT   = BIT(2),
+   IEEE80211_TX_CTRL_AMSDU = BIT(3),
 };
 
 /*
@@ -1964,6 +1966,12 @@ struct ieee80211_txq {
  * order and does not need to manage its own reorder buffer or BA session
  * timeout.
  *
+ * @IEEE80211_HW_TX_AMSDU: Hardware (or driver) supports software aggregated
+ * A-MSDU frames. Requires software tx queueing support.
+ *
+ * @IEEE80211_HW_TX_FRAG_LIST: Hardware (or driver) supports sending frag_list
+ * skbs, needed for zero-copy software A-MSDU.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2001,6 +2009,8 @@ enum ieee80211_hw_flags {
IEEE80211_HW_BEACON_TX_STATUS,
IEEE80211_HW_NEEDS_UNIQUE_STA_ADDR,
IEEE80211_HW_SUPPORTS_REORDERING_BUFFER,
+   IEEE80211_HW_TX_AMSDU,
+   IEEE80211_HW_TX_FRAG_LIST,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
@@ -2073,6 +2083,8 @@ enum ieee80211_hw_flags {
  * size is smaller (an example is LinkSys WRT120N with FW v1.0.07
  * build 002 Jun 18 2012).
  *
+ * @max_tx_fragments: maximum fragments per (A-)MSDU.
+ *
  * @offchannel_tx_hw_queue: HW queue ID to use for offchannel TX
  * (if %IEEE80211_HW_QUEUE_CONTROL is set)
  *
@@ -2127,6 +2139,7 @@ struct ieee80211_hw {
u8 max_rate_tries;
u8 max_rx_aggregation_subframes;
u8 max_tx_aggregation_subframes;
+   u8 max_tx_fragments;
u8 offchannel_tx_hw_queue;
u8 radiotap_mcs_details;
u16 radiotap_vht_details;
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 4932e9f..42fa810 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -935,6 +935,7 @@ void ieee80211_process_addba_resp(struct ieee80211_local 
*local,
  size_t len)
 {
struct tid_ampdu_tx *tid_tx;
+   struct ieee80211_txq *txq;
u16 capab, tid;
u8 buf_size;
bool amsdu;
@@ -945,6 +946,10 @@ void ieee80211_process_addba_resp(struct ieee80211_local 
*local,
buf_size = (capab & IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK) >> 6;
buf_size = min(buf_size, local->hw.max_tx_aggregation_subframes);
 
+   txq = sta->sta.txq[tid];
+   if (!amsdu && txq)
+   set_bit(IEEE80211_TXQ_NO_AMSDU, _txq_info(txq)->flags);
+
mutex_lock(>ampdu_mlme.mtx);
 
tid_tx = rcu_dereference_protected_tid_tx(sta, tid);
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index e433d0c..847779d 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -127,6 +127,8 @@ static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 
1] = {
FLAG(BEACON_TX_STATUS),
FLAG(NEEDS_UNIQUE_STA_ADDR),
FLAG(SUPPORTS_REORDERING_BUFFER),
+   FLAG(TX_AMSDU),
+   FLAG(TX_FRAG_LIST),
 
/* keep last for the build bug below */
(void *)0x1
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index a49c103..e68d8db 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -799,6 +799,7 @@ struct mac80211_qos_map {
 enum txq_info_flags {
IEEE80211_TXQ_STOP,
IEEE80211_TXQ_AMPDU,
+   IEEE80211_TXQ_NO_AMSDU,
 };
 
 struct txq_info {
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 7bb67fa9..0c9cc6b 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1324,6 +1324,10 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw 
*hw,
 out:
spin_unlock_bh(>queue.lock);
 
+   if (skb && skb_has_frag_list(skb) &&
+   !ieee80211_hw_check(>hw, TX_FRAG_LIST))
+   skb_linearize(skb);
+
return skb;
 }
 EXPORT_SYMBOL(ieee80211_tx_dequeue);
@@ -2766,6 +2770,158 @@ void ieee80211_clear_fast_xmit(struct sta_info *sta)
kfree_rcu(fast_tx, rcu_head);
 }
 
+static int ieee80211_amsdu_pad(struct 

Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

[Michal Kazior]

On 5 February 2016 at 17:47, Dave Taht  wrote:
>> A bursted txop can be as big as 5-10ms. If you consider you want to
>> queue 5-10ms worth of data for *each* station at any given time you
>> obviously introduce a lot of lag. If you have 10 stations you might
>> end up with service period at 10*10ms = 100ms. This gets even worse if
>> you consider MU-MIMO because you need to do an expensive sounding
>> procedure before transmitting. So while SU aggregation can probably
>> still work reasonably well with shorter bursts (1-2ms) MU needs at
>> least 3ms to get *any* gain when compared to SU (which obviously means
>> you want more to actually make MU pay off).
>
> I am not sure where you get these numbers. Got a spreadsheet?

Here's a nice summary on some of it:

  http://chimera.labs.oreilly.com/books/123401739/ch03.html#figure-mac-ampdu

Even if your single A-MPDU can be shorter than a txop you can burst a
few of them if my understanding is correct.

The overhead associated with MU sounding is something I've been told
only. Apparently for MU to pay off you need fairly big bursts. This
implies that the more stations you have to service the less it makes
sense to attempt MU if you consider latency.


> Gradually reducing the maximum sized txop as a function of the number
> of stations makes sense. If you have 10 stations pending delivery and
> reduced the max txop to 1ms, you hurt bandwidth at that instant, but
> by offering more service to more stations, in less time, they will
> converge on a reasonable share of the bandwidth for each, faster[1].
> And I'm sure that the person videoconferencing on a link like that
> would appreciate getting some service inside of a 10ms interval,
> rather than a 100ms.
>
> yes, there's overhead, and that's not the right number, which would
> vary as to g,n,ac and successors.
>
> You will also get more opportunities to use mu-mimo with shorter
> bursts extant and more stations being regularly serviced.
>
> [1] https://www.youtube.com/watch?v=Rb-UnHDw02o at about 13:50

This is my thinking as well, at least for most common use cases.

If you try to optimize for throughput by introducing extra induced
latency you might end up not being able to use aggregation in practice
anyway because you won't be able to start up connections and ask for
enough data - or at least that's what my intuition tells me.

But, like I've mentioned, there's interest in making it possible to
maximize for throughput (regardless of latency). This surely makes
sense for synthetic UDP benchmarks. But does it make sense for any
real-world application? No idea.


>> The rule of thumb is the
>> longer you wait the bigger capacity you can get.
>
> This is not strictly true as the "fountain" of packets is regulated by
> acks on the other side of the link, and ramp up or down as a function
> of service time and loss.

Yes, if you consider real world cases, i.e. TCP, web traffic, etc.
then you're correct.


>> Apparently there's interest in maximizing throughput but it stands in
>> direct opposition of keeping the latency down so I've been thinking
>> how to satisfy both.
>>
>> The current approach ath10k is taking (patches in review [1][2]) is to
>> use mac80211 software queues for per-station queuing, exposing queue
>> state to firmware (it decides where frames should be dequeued from)
>> and making it possible to stop/wake per-station tx subqueue with fake
>> netdev queues. I'm starting to think this is not the right way though
>> because it's inherently hard to control latency and there's a huge
>> memory overhead associated with the fake netdev queues.
>
> What is this overhead?

E.g. if you want to be able to maximize throughput for 50 MU clients
you need to be able to queue, in theory, 50*200 (roughly) frames. This
translates to both huge memory usage and latency *and* renders
(fq_)codel qdisc rather.. moot.


> Applying things  like codel tend to dramatically shorten the amount of
> skbs extant...

> modern 802.11ac capable hardware has tons more
> memory...

I don't think it does. QCA988x is able to handle "only" 1424 tx
descriptors (IOW 1500-byte long MSDUs) in the driver-to-firmware tx
queue (it's a flat queue). QCA99x0 is able to handle 2500 if asked
politely.

This is still not enough to satisfy the insane "maximize the
capacity/throughput" expectations though.

You could actually argue it's too much from the bufferbloat problem
point of view anyway and Emmanuel's patch proves it is beneficial to
buffer less in driver depending on the sojourn packet time.


>> Also fq_codel
>> is a less effective with this kind of setup.
>
> fq_codel's principal problems with working with wifi are long and
> documented in the talk above.
>
>> My current thinking is that the entire problem should be solved via
>> (per-AC) qdiscs, e.g. fq_codel. I guess one could use
>> limit/target/interval/quantum knobs to tune it for higher latency of
>> aggregation-oriented Wi-Fi links where long service 

Re: [RFC v4] mac80211: add A-MSDU tx support

[Felix Fietkau]

On 2016-02-08 12:06, Krishna Chaitanya wrote:
> On Mon, Feb 8, 2016 at 4:34 PM, Felix Fietkau  wrote:
>> On 2016-02-08 10:54, Krishna Chaitanya wrote:
>>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
>>> wrote:
 On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
> Requires software tx queueing support. frag_list support (for zero-copy)
> is optional.
>
> Signed-off-by: Felix Fietkau 
> ---


 Ok - looks fine, but... and here comes the hard stuff.
 The frame size in the PLCP is limited in a way that you can't - from a
 spec POV - enable A-MSDU for low rates. Of course, you don't want to
 do that for low rates at all regardless of the spec.
 Since you build the A-MSDU in the mac80211 Tx queue which is not aware
 of the link quality, how do we prevent A-MSDU if the rate is low /
 dropping.
 I'd even argue that when the rates get lower, you'll  have more
 packets piling up in the software queue and ... even more chance to
 get A-MSDU in the exact case where you really want to avoid it?
>>>
>>> Similar to triggering AMPDU setup, we should put this control
>>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
>>> drop below a pre-defined MCS (or) only for best-throughput rates.
>> I think starting/stopping A-MSDU based on the rate is a bad idea.
>> Even with low rates, using A-MSDU can be a good thing (especially for
>> TCP ACKs), it just needs different size limits.
> 
> By low rates, i was referring to bad channel conditions (more
> retries/crc errors)
> so using AMSDU might trigger more TCP level retries and for case
> of TCP ACK's its still worse in that it triggers TCP data retires from the
> peer.
Based on the research and data from the Bufferbloat project, I'd say
that in this case the latency due to queue buildup is a lot more harmful
than lost packets.
With unmanaged queues, the latency will cause unnecessary
retransmissions anyway.
With managed queues, packet drops start increasing with latency until
TCP starts behaving properly.
In both cases you have extra TCP retransmissions...

With bad conditions you also get a strong increase in per-TXOP latency.
With A-MSDU you need fewer TXOPs for the same amount of data in the queue.

- Felix
--
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 v3 3/3] mwifiex: parse host wakeup configuration from device tree

[Amitkumar Karwar]

From: Xinming Hu 

This patch implement a framework for board specific wakeup.
driver parse irq/gpio number from device tree, corresponding
resources will be allocated, and used for host suspend/resume.
driver private binding file is also updated in the patch.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
v2: Guarded ".pm = mwifiex_plt_pm_ops" line with CONFIG_PM_SLEEP
---
 Documentation/devicetree/bindings/mwifiex.txt  | 10 +++
 .../net/wireless/marvell/mwifiex/platform_drv.c| 95 ++
 2 files changed, 105 insertions(+)

diff --git a/Documentation/devicetree/bindings/mwifiex.txt 
b/Documentation/devicetree/bindings/mwifiex.txt
index 367c97e..68919c7 100644
--- a/Documentation/devicetree/bindings/mwifiex.txt
+++ b/Documentation/devicetree/bindings/mwifiex.txt
@@ -14,6 +14,11 @@ Optional properties:
   - mwifiex,chip-gpio : Chip's wakeup gpio pin number. This needs to be 
downloaded
to to firmware. Chip notifies wifi wakeup signal to SOC
through this pin.
+  - interrupt-parent: phandle of the parent interrupt controller
+  - interrupts : interrupt number to the cpu
+  - gpios: specify SOC's wakeup GPIO
+  - pinctrl-names : a pinctrl state named "default" must be defined
+  - pinctrl-0 : pin control group to be used for this controller
 
 Example:
 
@@ -27,5 +32,10 @@ mwifiex {
mwifiex,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
 0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01 ...>;
mwifiex,chip-gpio = <3>;
+   interrupt-parent = <>;
+   interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
+   gpios = < 38 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
 };
 
diff --git a/drivers/net/wireless/marvell/mwifiex/platform_drv.c 
b/drivers/net/wireless/marvell/mwifiex/platform_drv.c
index f64a12a..2eb813c 100644
--- a/drivers/net/wireless/marvell/mwifiex/platform_drv.c
+++ b/drivers/net/wireless/marvell/mwifiex/platform_drv.c
@@ -18,9 +18,63 @@
 
 struct platform_device *mwifiex_plt_dev;
 
+struct mwifiex_wake_dev {
+   struct device   *dev;
+   int irq_wifi;
+   boolwake_by_wifi;
+};
+
+static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
+{
+   struct mwifiex_wake_dev *ctx = priv;
+
+   if (ctx->irq_wifi >= 0) {
+   ctx->wake_by_wifi = true;
+   disable_irq_nosync(ctx->irq_wifi);
+   }
+
+   return IRQ_HANDLED;
+}
+
 static int mwifiex_plt_probe(struct platform_device *pdev)
 {
+   int ret;
+   struct mwifiex_wake_dev *ctx;
+   int gpio;
+
mwifiex_plt_dev = pdev;
+
+   ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
+   if (!ctx)
+   return -ENOMEM;
+
+   ctx->dev = >dev;
+   ctx->irq_wifi = platform_get_irq(pdev, 0);
+   if (ctx->irq_wifi < 0)
+   dev_err(>dev, "Failed to get irq_wifi\n");
+
+   gpio = of_get_gpio(pdev->dev.of_node, 0);
+   if (gpio_is_valid(gpio))
+   gpio_direction_input(gpio);
+   else
+   dev_err(>dev, "gpio wifi is invalid\n");
+
+   if (ctx->irq_wifi >= 0) {
+   ret = devm_request_irq(>dev, ctx->irq_wifi,
+  mwifiex_wake_irq_wifi,
+  IRQF_TRIGGER_LOW,
+  "wifi_wake", ctx);
+   if (ret) {
+   dev_err(>dev,
+   "Failed to request irq_wifi %d (%d)\n",
+   ctx->irq_wifi, ret);
+   return -EINVAL;
+   }
+   disable_irq(ctx->irq_wifi);
+   }
+
+   platform_set_drvdata(pdev, ctx);
+
return 0;
 }
 
@@ -30,6 +84,44 @@ static int mwifiex_plt_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int mwifiex_plt_suspend(struct device *dev)
+{
+   struct mwifiex_wake_dev *ctx = dev_get_drvdata(dev);
+   int ret;
+
+   if (ctx->irq_wifi >= 0) {
+   ctx->wake_by_wifi = false;
+   enable_irq(ctx->irq_wifi);
+   ret = enable_irq_wake(ctx->irq_wifi);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static int mwifiex_plt_resume(struct device *dev)
+{
+   struct mwifiex_wake_dev *ctx = dev_get_drvdata(dev);
+   int ret;
+
+   if (ctx->irq_wifi >= 0) {
+   ret = disable_irq_wake(ctx->irq_wifi);
+   if (!ctx->wake_by_wifi)
+   disable_irq(ctx->irq_wifi);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct dev_pm_ops mwifiex_plt_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(mwifiex_plt_suspend, mwifiex_plt_resume)
+};
+#endif /* CONFIG_PM_SLEEP */
+
 static const struct of_device_id mwifiex_dt_match[] = {
{
   

Re: [RFC v4] mac80211: add A-MSDU tx support

[Felix Fietkau]

On 2016-02-08 10:54, Krishna Chaitanya wrote:
> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  wrote:
>> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
>>> Requires software tx queueing support. frag_list support (for zero-copy)
>>> is optional.
>>>
>>> Signed-off-by: Felix Fietkau 
>>> ---
>>
>>
>> Ok - looks fine, but... and here comes the hard stuff.
>> The frame size in the PLCP is limited in a way that you can't - from a
>> spec POV - enable A-MSDU for low rates. Of course, you don't want to
>> do that for low rates at all regardless of the spec.
>> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
>> of the link quality, how do we prevent A-MSDU if the rate is low /
>> dropping.
>> I'd even argue that when the rates get lower, you'll  have more
>> packets piling up in the software queue and ... even more chance to
>> get A-MSDU in the exact case where you really want to avoid it?
> 
> Similar to triggering AMPDU setup, we should put this control
> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
> drop below a pre-defined MCS (or) only for best-throughput rates.
I think starting/stopping A-MSDU based on the rate is a bad idea.
Even with low rates, using A-MSDU can be a good thing (especially for
TCP ACKs), it just needs different size limits.

- Felix
--
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 v3 1/3] mwifiex: register platform specific driver

[Arnd Bergmann]

On Monday 08 February 2016 02:15:26 Amitkumar Karwar wrote:
> diff --git a/Documentation/devicetree/bindings/mwifiex.txt 
> b/Documentation/devicetree/bindings/mwifiex.txt
> new file mode 100644
> index 000..39b6a74
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mwifiex.txt
> @@ -0,0 +1,29 @@
> +mwifiex
> +--
> +
> +Required properties:
> +
> +  - name : must be "mwifiex"

This is a very unusual requirement.

Can you use one of the standard device names instead?

> +  - compatible : must be "marvell,mwifiex"
> +
> +Optional properties:
> +
> +  - mwifiex,caldata* : A series of properties with marvell,caldata prefix,
> + represent Calibration data downloaded to the device 
> during
> + initialization. This is an array of unsigned values.
> +
> +
> +Example:
> +
> +Tx power limit calibration data is configured in below example.
> +The calibration data is an array of unsigned values, the length
> +can vary between hw versions.
> +
> +mwifiex {
> +   compatible = "marvell,mwifiex";
> +
> +   mwifiex,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
> +0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01 ...>;
> +
> +};

Should we list the mac-address here as well, or is there always an eeprom
for that but not the calibration data?

Arnd
--
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: wl12xx regression on 4.5 (was: Re: linux-4.5-rc1 TI pandboard-es wifi wlcore locks and reset)

[Ross Green]

On Mon, Feb 8, 2016 at 9:05 AM, Emil Goode  wrote:
> Hello,
>
> On Tue, Feb 02, 2016 at 05:05:38PM +0100, Sebastian Reichel wrote:
>> On Tue, Feb 02, 2016 at 04:41:13PM +1100, Ross Green wrote:
>> > On Tue, Feb 2, 2016 at 3:34 PM, Sebastian Reichel  wrote:
>> > > On Mon, Feb 01, 2016 at 11:38:38PM +1100, Ross Green wrote:
>> > >> On Mon, Jan 25, 2016 at 11:47 PM, Ross Green  wrote:
>> > >> > Just tried the new kernel release on faithful pandaboard es with the
>> > >> > new 4.5-rc1 release.
>> > >> >
>> > >> > There is a problem with the wifi modules once the modules are loaded.
>> > >> > Looks like the wifi firmware gets loaded put no response after that
>> > >> > causing recovery action.
>> > >> >
>> > >> > the kernel 4.4 works quite happily with this board.
>> > >> >
>> > >> > Here is a dmesg dump in the attachment.
>> > >> >
>> > >> > Anyone have any ideas here?
>> >
>> > [...]
>> >
>> > If I get time, this evening, I'll see if I can give a bisect a try.
>>
>> On N950 [wl1271 via SPI, using extra patches to init from DT] I get wifi
>> working again on 4.5-rc1 with 3719c17e1816 ("wlcore/wl18xx: fw logger
>> over sdio") reverted.
>
> Reverting the changes in wlcore_set_partition() as below seem to help.
>
> Best regards,
>
> Emil Goode
>
> 8<
>
> --- a/drivers/net/wireless/ti/wlcore/io.c
> +++ b/drivers/net/wireless/ti/wlcore/io.c
> @@ -175,14 +175,15 @@ int wlcore_set_partition(struct wl1271 *wl,
> if (ret < 0)
> goto out;
>
> +   /*
> +* We don't need the size of the last partition, as it is
> +* automatically calculated based on the total memory size and
> +* the sizes of the previous partitions.
> +*/
> ret = wlcore_raw_write32(wl, HW_PART3_START_ADDR, p->mem3.start);
> if (ret < 0)
> goto out;
>
> -   ret = wlcore_raw_write32(wl, HW_PART3_SIZE_ADDR, p->mem3.size);
> -   if (ret < 0)
> -   goto out;
> -
>  out:
> return ret;
>  }
> diff --git a/drivers/net/wireless/ti/wlcore/io.h 
> b/drivers/net/wireless/ti/wlcore/io.h
> index 6c257b5..10cf374 100644
> --- a/drivers/net/wireless/ti/wlcore/io.h
> +++ b/drivers/net/wireless/ti/wlcore/io.h
> @@ -36,8 +36,8 @@
>  #define HW_PART1_START_ADDR (HW_PARTITION_REGISTERS_ADDR + 12)
>  #define HW_PART2_SIZE_ADDR  (HW_PARTITION_REGISTERS_ADDR + 16)
>  #define HW_PART2_START_ADDR (HW_PARTITION_REGISTERS_ADDR + 20)
> -#define HW_PART3_SIZE_ADDR  (HW_PARTITION_REGISTERS_ADDR + 24)
> -#define HW_PART3_START_ADDR (HW_PARTITION_REGISTERS_ADDR + 28)
> +#define HW_PART3_START_ADDR (HW_PARTITION_REGISTERS_ADDR + 24)
> +
>  #define HW_ACCESS_REGISTER_SIZE 4
>
>  #define HW_ACCESS_PRAM_MAX_RANGE   0x3c000
>



Thanks Emil,

Just tested linux-4.5-rc3 with the above patch and confirm everything
works as expected. So it would be good if this patch can find its way
into linux-4.5-rc4.



here is a portion of the dmesg:
# dmesg
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.5.0-rc3-panda (rfg@red.dwarf) (gcc
version 5.3.0 (Buildroot 2016.02-git-00183-g1682aee) ) #1 S6
[0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7),
cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: TI OMAP4 PandaBoard-ES
[0.00] Memory policy: Data cache writealloc
[0.00] OMAP4: Map 0xbfe0 to fe60 for dram barrier
[0.00] On node 0 totalpages: 261632

...
...[   39.164764] wlcore: loaded
[   52.577209] wlcore: firmware booted (Rev 6.3.10.0.133)
[   56.101531] wlan0: authenticate with 90:f6:52:81:ee:70
[   56.138732] wlan0: send auth to 90:f6:52:81:ee:70 (try 1/3)
[   56.146728] wlan0: authenticated
[   56.162078] wlan0: associate with 90:f6:52:81:ee:70 (try 1/3)
[   56.172821] wlan0: RX AssocResp from 90:f6:52:81:ee:70 (capab=0x431
status=0 aid=1)
[   56.188201] wlan0: associated
[   56.244812] wlcore: Association completed.


So all is happy with the wlcore code with this patch.
Now I can continue with the rest of the testing ;-)

Regards,

Ross Green
--
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: [RFC v4] mac80211: add A-MSDU tx support

[Krishna Chaitanya]

On Mon, Feb 8, 2016 at 4:34 PM, Felix Fietkau  wrote:
> On 2016-02-08 10:54, Krishna Chaitanya wrote:
>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
>> wrote:
>>> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
 Requires software tx queueing support. frag_list support (for zero-copy)
 is optional.

 Signed-off-by: Felix Fietkau 
 ---
>>>
>>>
>>> Ok - looks fine, but... and here comes the hard stuff.
>>> The frame size in the PLCP is limited in a way that you can't - from a
>>> spec POV - enable A-MSDU for low rates. Of course, you don't want to
>>> do that for low rates at all regardless of the spec.
>>> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
>>> of the link quality, how do we prevent A-MSDU if the rate is low /
>>> dropping.
>>> I'd even argue that when the rates get lower, you'll  have more
>>> packets piling up in the software queue and ... even more chance to
>>> get A-MSDU in the exact case where you really want to avoid it?
>>
>> Similar to triggering AMPDU setup, we should put this control
>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
>> drop below a pre-defined MCS (or) only for best-throughput rates.
> I think starting/stopping A-MSDU based on the rate is a bad idea.
> Even with low rates, using A-MSDU can be a good thing (especially for
> TCP ACKs), it just needs different size limits.

By low rates, i was referring to bad channel conditions (more
retries/crc errors)
so using AMSDU might trigger more TCP level retries and for case
of TCP ACK's its still worse in that it triggers TCP data retires from the
peer.
--
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: [RFC v4] mac80211: add A-MSDU tx support

[Emmanuel Grumbach]

On Mon, Feb 8, 2016 at 1:15 PM, Felix Fietkau  wrote:
> On 2016-02-08 11:26, Emmanuel Grumbach wrote:
>> On Mon, Feb 8, 2016 at 11:54 AM, Krishna Chaitanya
>>  wrote:
>>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
>>> wrote:
 On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
> Requires software tx queueing support. frag_list support (for zero-copy)
> is optional.
>
> Signed-off-by: Felix Fietkau 
> ---


 Ok - looks fine, but... and here comes the hard stuff.
 The frame size in the PLCP is limited in a way that you can't - from a
 spec POV - enable A-MSDU for low rates. Of course, you don't want to
 do that for low rates at all regardless of the spec.
 Since you build the A-MSDU in the mac80211 Tx queue which is not aware
 of the link quality, how do we prevent A-MSDU if the rate is low /
 dropping.
 I'd even argue that when the rates get lower, you'll  have more
 packets piling up in the software queue and ... even more chance to
 get A-MSDU in the exact case where you really want to avoid it?
>>>
>>> Similar to triggering AMPDU setup, we should put this control
>>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
>>> drop below a pre-defined MCS (or) only for best-throughput rates.
>>
>> Ok - but the size of A-MPDU is determined in the firmware / hardware
>> typically (at least for Intel devices and I have to admit my ignorance
>> about other designs...). So that if you get bad link conditions, the
>> firmware can play for that size. A-MSDU built in the host is a
>> different story. I remember that athXk devices attach the rate on the
>> Tx packet itself so that the rate control is serialized with the data
>> path.
>> iwlwifi works differently: we have a map of rates in the firmware.
>> This map is maintained in the driver updated based on the feedback we
>> get from the device. When an update is needed, iwlwifi sends a command
>> to the firmware and that command bypasses all the Tx packets currently
>> queue so that a packet that is already waiting in the queue will be
>> sent with the updated map. This allows iwlwifi to react downgrade
>> faster when needed.
> Even ath9k has been converted to use a per-sta rate table with optional
> per-packet rate overrides for probing.
>
>> So - for athXk (and maybe the MediaTek devices Felix is working on),
>> this may not be a big problem: you'd need to add another input to the
>> A-MSDU building code coming from the rate control.
>> FWIW: in iwlwifi I simply decided to be on the safe side and allowed
>> the driver to build A-MSDUs only if the rate is fairly high and we are
>> not downgrading. But you saw (and commented on) that patch already I
>> think :)
> I think it would be a good idea for iwlwifi to start using the rate
> control API properly. Not only would that simplify integration with the
> A-MSDU code, it would also make it possible to compare minstrel_ht with
> the iwlwifi rate control code.
> The iwlwifi rate control code is doing some crazy things, and I'd be
> really interested in seeing how it compares to the more simple and
> structured approach taken in minstrel_ht.

Yeah ok. So I agree that iwlwifi uses the rate control API in a crazy
way, the change is planned (well.. I've said that long ago
already...). The plan is to move to internal API only (not go through
the rate control API) though...
I guess we have enough material for a beer in Seville I think :)

>
> - Felix
--
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: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

[Emmanuel Grumbach]

On Mon, Feb 8, 2016 at 12:00 PM, Michal Kazior  wrote:
> On 5 February 2016 at 17:47, Dave Taht  wrote:
>>> A bursted txop can be as big as 5-10ms. If you consider you want to
>>> queue 5-10ms worth of data for *each* station at any given time you
>>> obviously introduce a lot of lag. If you have 10 stations you might
>>> end up with service period at 10*10ms = 100ms. This gets even worse if
>>> you consider MU-MIMO because you need to do an expensive sounding
>>> procedure before transmitting. So while SU aggregation can probably
>>> still work reasonably well with shorter bursts (1-2ms) MU needs at
>>> least 3ms to get *any* gain when compared to SU (which obviously means
>>> you want more to actually make MU pay off).
>>
>> I am not sure where you get these numbers. Got a spreadsheet?
>
> Here's a nice summary on some of it:
>
>   
> http://chimera.labs.oreilly.com/books/123401739/ch03.html#figure-mac-ampdu
>
> Even if your single A-MPDU can be shorter than a txop you can burst a
> few of them if my understanding is correct.
>
> The overhead associated with MU sounding is something I've been told
> only. Apparently for MU to pay off you need fairly big bursts. This
> implies that the more stations you have to service the less it makes
> sense to attempt MU if you consider latency.
>
>
>> Gradually reducing the maximum sized txop as a function of the number
>> of stations makes sense. If you have 10 stations pending delivery and
>> reduced the max txop to 1ms, you hurt bandwidth at that instant, but
>> by offering more service to more stations, in less time, they will
>> converge on a reasonable share of the bandwidth for each, faster[1].
>> And I'm sure that the person videoconferencing on a link like that
>> would appreciate getting some service inside of a 10ms interval,
>> rather than a 100ms.
>>
>> yes, there's overhead, and that's not the right number, which would
>> vary as to g,n,ac and successors.
>>
>> You will also get more opportunities to use mu-mimo with shorter
>> bursts extant and more stations being regularly serviced.
>>
>> [1] https://www.youtube.com/watch?v=Rb-UnHDw02o at about 13:50
>
> This is my thinking as well, at least for most common use cases.
>
> If you try to optimize for throughput by introducing extra induced
> latency you might end up not being able to use aggregation in practice
> anyway because you won't be able to start up connections and ask for
> enough data - or at least that's what my intuition tells me.
>
> But, like I've mentioned, there's interest in making it possible to
> maximize for throughput (regardless of latency). This surely makes
> sense for synthetic UDP benchmarks. But does it make sense for any
> real-world application? No idea.
>
>
>>> The rule of thumb is the
>>> longer you wait the bigger capacity you can get.
>>
>> This is not strictly true as the "fountain" of packets is regulated by
>> acks on the other side of the link, and ramp up or down as a function
>> of service time and loss.
>
> Yes, if you consider real world cases, i.e. TCP, web traffic, etc.
> then you're correct.
>
>
>>> Apparently there's interest in maximizing throughput but it stands in
>>> direct opposition of keeping the latency down so I've been thinking
>>> how to satisfy both.
>>>
>>> The current approach ath10k is taking (patches in review [1][2]) is to
>>> use mac80211 software queues for per-station queuing, exposing queue
>>> state to firmware (it decides where frames should be dequeued from)
>>> and making it possible to stop/wake per-station tx subqueue with fake
>>> netdev queues. I'm starting to think this is not the right way though
>>> because it's inherently hard to control latency and there's a huge
>>> memory overhead associated with the fake netdev queues.
>>
>> What is this overhead?
>
> E.g. if you want to be able to maximize throughput for 50 MU clients
> you need to be able to queue, in theory, 50*200 (roughly) frames. This
> translates to both huge memory usage and latency *and* renders
> (fq_)codel qdisc rather.. moot.

Ok - now I understand. So yes the conclusion below (make fq_codel
station aware) makes a lot sense.

>
>
>> Applying things  like codel tend to dramatically shorten the amount of
>> skbs extant...
>
>> modern 802.11ac capable hardware has tons more
>> memory...
>
> I don't think it does. QCA988x is able to handle "only" 1424 tx
> descriptors (IOW 1500-byte long MSDUs) in the driver-to-firmware tx
> queue (it's a flat queue). QCA99x0 is able to handle 2500 if asked
> politely.

As I said, our design is not flat which removes for the firmware to
classify the packets by station to be able to build aggregates, but
the downside is the number of clients you can service.

>
> This is still not enough to satisfy the insane "maximize the
> capacity/throughput" expectations though.
>
> You could actually argue it's too much from the bufferbloat problem
> point of view anyway and Emmanuel's patch 

Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

[Emmanuel Grumbach]

On Fri, Feb 5, 2016 at 10:44 AM, Michal Kazior  wrote:
> On 4 February 2016 at 22:14, Ben Greear  wrote:
>> On 02/04/2016 12:56 PM, Grumbach, Emmanuel wrote:
>>> On 02/04/2016 10:46 PM, Ben Greear wrote:
 On 02/04/2016 12:16 PM, Emmanuel Grumbach wrote:
>
> As many (all?) WiFi devices, Intel WiFi devices have
> transmit queues which have 256 transmit descriptors
> each and each descriptor corresponds to an MPDU.
> This means that when it is full, the queue contains
> 256 * ~1500 bytes to be transmitted (if we don't have
> A-MSDUs). The purpose of those queues is to have enough
> packets to be ready for transmission so that when the device
> gets an opportunity to transmit (TxOP), it can take as many
> packets as the spec allows and aggregate them into one
> A-MPDU or even several A-MPDUs if we are using bursts.

 I guess this is only really usable if you have exactly one
 peer connected (ie, in station mode)?

 Otherwise, you could have one slow peer and one fast one,
 and then I suspect this would not work so well?
>>>
>>>
>>> Yes. I guess this one (big) limitation. I guess that what would happen
>>> in this case is that the the latency would constantly jitter. But I also
>
> Hmm.. You'd probably need to track per-station packet sojourn time as
> well and make it possible to stop/wake queues per station.

Clearly here comes the difference between the devices you work on, and
the devices I work on. Intel devices are more client oriented. Our AP
mode doesn't handle many clients etc..

>
>
>>> noticed that I could reduce the transmit queue to 130 descriptors
>>> (instead of 256) and still reach maximal throughput because we can
>>> refill the queues quickly enough.
>>> In iwlwifi, we have plans to have one queue for each peer.
>>> This is under development. Not sure when it'll be ready. It also requires
>>> firmware change obviously.
>>
>> Per-peer queues will probably be nice, especially if we can keep the
>> buffer bloat manageable.
>
> Per-station queues sound tricky if you consider bufferbloat.

iwlwifi's A-MPDU model is different from athXk's I guess. In iwlwifi
(the Intel devices really since it is mostly firmware) the firmware
will try to use a TxOP whenever there is data in the queue. Then, once
we have a chance to transmit, we will look at what we have in the
queue and send the biggest aggregates we can (and bursts if allowed).
But we will not defer packets' transmission to get bigger aggregates.
Testing shows that under ideal conditions, we can have enough packets
in the queue to build big aggregates without creating artificial
latency.

>
> To maximize use of airtime (i.e. txop) you need to send big
> aggregates. Since aggregates are per station-tid to maximize
> multi-station performance (in AP mode) you'll need to queue a lot of
> frames, per each station, depending on the chosen tx rate.

Sure.

>
> A bursted txop can be as big as 5-10ms. If you consider you want to
> queue 5-10ms worth of data for *each* station at any given time you
> obviously introduce a lot of lag. If you have 10 stations you might
> end up with service period at 10*10ms = 100ms. This gets even worse if
> you consider MU-MIMO because you need to do an expensive sounding
> procedure before transmitting. So while SU aggregation can probably
> still work reasonably well with shorter bursts (1-2ms) MU needs at
> least 3ms to get *any* gain when compared to SU (which obviously means
> you want more to actually make MU pay off). The rule of thumb is the
> longer you wait the bigger capacity you can get.

I am not an expert about MU-MIMO, but I'll believe you :)
We can chat about this in a few days :)

Queueing frames under good conditions is fine in a way that it is a
"Good queue" (hey Stephen), you need those queues to maximize the
throughput because of the bursty nature of WiFi and the queue "moves"
quickly since you have high throughput so that the sojourn time in
your queue is relatively small, but when the link conditions gets less
good you need to reduce the queue length because it doesn't really
help you anyway.  This is what my patch aims at fixing.
All this is true when you have a small number of stations...
I understand from your comment that even in ideal conditions you still
need to create a lot of latency to gain TPT. Then there isn't much we
can do without impacting either TPT or latency. Then, there is a real
tradeoff.
I guess that again you are facing a classic AP problem that a station
or an AP with a small number of concurrent associated clients will
likely not have.

All this encourages me in my belief that I should do something in
iwlwifi for iwlwifi and at mac80211's level since there seem to be
very different problems / use cases. But this code can still suit
those use cases can all fit and we'd just (...) have to give different
parameters to the "algorithm"?

>
> Apparently there's 

Re: [RFC v4] mac80211: add A-MSDU tx support

[Michal Kazior]

On 8 February 2016 at 12:09, Krishna Chaitanya  wrote:
> On Mon, Feb 8, 2016 at 3:56 PM, Emmanuel Grumbach  wrote:
>> On Mon, Feb 8, 2016 at 11:54 AM, Krishna Chaitanya
>>  wrote:
>>> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
>>> wrote:
 On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
> Requires software tx queueing support. frag_list support (for zero-copy)
> is optional.
>
> Signed-off-by: Felix Fietkau 
> ---


 Ok - looks fine, but... and here comes the hard stuff.
 The frame size in the PLCP is limited in a way that you can't - from a
 spec POV - enable A-MSDU for low rates. Of course, you don't want to
 do that for low rates at all regardless of the spec.
 Since you build the A-MSDU in the mac80211 Tx queue which is not aware
 of the link quality, how do we prevent A-MSDU if the rate is low /
 dropping.
 I'd even argue that when the rates get lower, you'll  have more
 packets piling up in the software queue and ... even more chance to
 get A-MSDU in the exact case where you really want to avoid it?
>>>
>>> Similar to triggering AMPDU setup, we should put this control
>>> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
>>> drop below a pre-defined MCS (or) only for best-throughput rates.
>>
>> Ok - but the size of A-MPDU is determined in the firmware / hardware
>> typically (at least for Intel devices and I have to admit my ignorance
>> about other designs...). So that if you get bad link conditions, the
>> firmware can play for that size. A-MSDU built in the host is a
>> different story. I remember that athXk devices attach the rate on the
>> Tx packet itself so that the rate control is serialized with the data
>> path.
>> iwlwifi works differently: we have a map of rates in the firmware.
>> This map is maintained in the driver updated based on the feedback we
>> get from the device. When an update is needed, iwlwifi sends a command
>> to the firmware and that command bypasses all the Tx packets currently
>> queue so that a packet that is already waiting in the queue will be
>> sent with the updated map. This allows iwlwifi to react downgrade
>> faster when needed.
>> So - for athXk (and maybe the MediaTek devices Felix is working on),
>> this may not be a big problem: you'd need to add another input to the
>> A-MSDU building code coming from the rate control.
>> FWIW: in iwlwifi I simply decided to be on the safe side and allowed
>> the driver to build A-MSDUs only if the rate is fairly high and we are
>> not downgrading. But you saw (and commented on) that patch already I
>> think :)
>
> Yes, this approach is going to be tough for those devices with HW RC.
> We might need something like amsdu_action to get some feedback from
> device about using of amsdu?

The HW/FW rate control still may not have sufficient knobs for driver
to implement an amsdu_action().

What about if mac80211 tracked per-station-tid packet sojourn time and
based on that derive max A-MSDU bytelimit? This could also be useful
for the bufferbloat problem (discussed in the other thread) as well.


Michał
--
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 v3 2/3] mwifiex: parse chip specific gpio from device tree

[Arnd Bergmann]

On Monday 08 February 2016 02:15:27 Amitkumar Karwar wrote:
> if (adapter->dt_node) {
> +   if (of_property_read_u32(adapter->dt_node,
> +"mwifiex,chip-gpio",
> +) == 0) {
> +   mwifiex_dbg(adapter, INFO,
> +   "chip_gpio = 0x%x\n", data);
> +   adapter->hs_cfg.gpio = data;
> +   }
> +
> 

Please use the GPIO DT binding. Reading a number from DT is not a proper
way to get a GPIO number, as you may have more than one GPIO controller
in a system and it is not obvious to which controller this number belongs,
or if you need to specify things like polarity.

Arnd
--
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: [RFC v4] mac80211: add A-MSDU tx support

[Emmanuel Grumbach]

On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
> Requires software tx queueing support. frag_list support (for zero-copy)
> is optional.
>
> Signed-off-by: Felix Fietkau 
> ---


Ok - looks fine, but... and here comes the hard stuff.
The frame size in the PLCP is limited in a way that you can't - from a
spec POV - enable A-MSDU for low rates. Of course, you don't want to
do that for low rates at all regardless of the spec.
Since you build the A-MSDU in the mac80211 Tx queue which is not aware
of the link quality, how do we prevent A-MSDU if the rate is low /
dropping.
I'd even argue that when the rates get lower, you'll  have more
packets piling up in the software queue and ... even more chance to
get A-MSDU in the exact case where you really want to avoid it?


>  include/net/mac80211.h |  13 
>  net/mac80211/agg-tx.c  |   5 ++
>  net/mac80211/debugfs.c |   2 +
>  net/mac80211/ieee80211_i.h |   1 +
>  net/mac80211/tx.c  | 160 
> +
>  5 files changed, 181 insertions(+)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 5714774..8c28210 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -709,6 +709,7 @@ enum mac80211_tx_info_flags {
>   * @IEEE80211_TX_CTRL_PS_RESPONSE: This frame is a response to a poll
>   * frame (PS-Poll or uAPSD).
>   * @IEEE80211_TX_CTRL_RATE_INJECT: This frame is injected with rate 
> information
> + * @IEEE80211_TX_CTRL_AMSDU: This frame is an A-MSDU frame
>   *
>   * These flags are used in tx_info->control.flags.
>   */
> @@ -716,6 +717,7 @@ enum mac80211_tx_control_flags {
> IEEE80211_TX_CTRL_PORT_CTRL_PROTO   = BIT(0),
> IEEE80211_TX_CTRL_PS_RESPONSE   = BIT(1),
> IEEE80211_TX_CTRL_RATE_INJECT   = BIT(2),
> +   IEEE80211_TX_CTRL_AMSDU = BIT(3),
>  };
>
>  /*
> @@ -1964,6 +1966,12 @@ struct ieee80211_txq {
>   * order and does not need to manage its own reorder buffer or BA session
>   * timeout.
>   *
> + * @IEEE80211_HW_TX_AMSDU: Hardware (or driver) supports software aggregated
> + * A-MSDU frames. Requires software tx queueing support.
> + *
> + * @IEEE80211_HW_TX_FRAG_LIST: Hardware (or driver) supports sending 
> frag_list
> + * skbs, needed for zero-copy software A-MSDU.
> + *
>   * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
>   */
>  enum ieee80211_hw_flags {
> @@ -2001,6 +2009,8 @@ enum ieee80211_hw_flags {
> IEEE80211_HW_BEACON_TX_STATUS,
> IEEE80211_HW_NEEDS_UNIQUE_STA_ADDR,
> IEEE80211_HW_SUPPORTS_REORDERING_BUFFER,
> +   IEEE80211_HW_TX_AMSDU,
> +   IEEE80211_HW_TX_FRAG_LIST,
>
> /* keep last, obviously */
> NUM_IEEE80211_HW_FLAGS
> @@ -2073,6 +2083,8 @@ enum ieee80211_hw_flags {
>   * size is smaller (an example is LinkSys WRT120N with FW v1.0.07
>   * build 002 Jun 18 2012).
>   *
> + * @max_tx_fragments: maximum fragments per (A-)MSDU.
> + *
>   * @offchannel_tx_hw_queue: HW queue ID to use for offchannel TX
>   * (if %IEEE80211_HW_QUEUE_CONTROL is set)
>   *
> @@ -2127,6 +2139,7 @@ struct ieee80211_hw {
> u8 max_rate_tries;
> u8 max_rx_aggregation_subframes;
> u8 max_tx_aggregation_subframes;
> +   u8 max_tx_fragments;
> u8 offchannel_tx_hw_queue;
> u8 radiotap_mcs_details;
> u16 radiotap_vht_details;
> diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
> index 4932e9f..42fa810 100644
> --- a/net/mac80211/agg-tx.c
> +++ b/net/mac80211/agg-tx.c
> @@ -935,6 +935,7 @@ void ieee80211_process_addba_resp(struct ieee80211_local 
> *local,
>   size_t len)
>  {
> struct tid_ampdu_tx *tid_tx;
> +   struct ieee80211_txq *txq;
> u16 capab, tid;
> u8 buf_size;
> bool amsdu;
> @@ -945,6 +946,10 @@ void ieee80211_process_addba_resp(struct ieee80211_local 
> *local,
> buf_size = (capab & IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK) >> 6;
> buf_size = min(buf_size, local->hw.max_tx_aggregation_subframes);
>
> +   txq = sta->sta.txq[tid];
> +   if (!amsdu && txq)
> +   set_bit(IEEE80211_TXQ_NO_AMSDU, _txq_info(txq)->flags);
> +
> mutex_lock(>ampdu_mlme.mtx);
>
> tid_tx = rcu_dereference_protected_tid_tx(sta, tid);
> diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
> index e433d0c..847779d 100644
> --- a/net/mac80211/debugfs.c
> +++ b/net/mac80211/debugfs.c
> @@ -127,6 +127,8 @@ static const char *hw_flag_names[NUM_IEEE80211_HW_FLAGS + 
> 1] = {
> FLAG(BEACON_TX_STATUS),
> FLAG(NEEDS_UNIQUE_STA_ADDR),
> FLAG(SUPPORTS_REORDERING_BUFFER),
> +   FLAG(TX_AMSDU),
> +   FLAG(TX_FRAG_LIST),
>
> /* keep last for the build bug below */
> (void *)0x1
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 

Re: [RFC v4] mac80211: add A-MSDU tx support

[Emmanuel Grumbach]

On Mon, Feb 8, 2016 at 11:54 AM, Krishna Chaitanya
 wrote:
> On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  wrote:
>> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
>>> Requires software tx queueing support. frag_list support (for zero-copy)
>>> is optional.
>>>
>>> Signed-off-by: Felix Fietkau 
>>> ---
>>
>>
>> Ok - looks fine, but... and here comes the hard stuff.
>> The frame size in the PLCP is limited in a way that you can't - from a
>> spec POV - enable A-MSDU for low rates. Of course, you don't want to
>> do that for low rates at all regardless of the spec.
>> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
>> of the link quality, how do we prevent A-MSDU if the rate is low /
>> dropping.
>> I'd even argue that when the rates get lower, you'll  have more
>> packets piling up in the software queue and ... even more chance to
>> get A-MSDU in the exact case where you really want to avoid it?
>
> Similar to triggering AMPDU setup, we should put this control
> in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
> drop below a pre-defined MCS (or) only for best-throughput rates.

Ok - but the size of A-MPDU is determined in the firmware / hardware
typically (at least for Intel devices and I have to admit my ignorance
about other designs...). So that if you get bad link conditions, the
firmware can play for that size. A-MSDU built in the host is a
different story. I remember that athXk devices attach the rate on the
Tx packet itself so that the rate control is serialized with the data
path.
iwlwifi works differently: we have a map of rates in the firmware.
This map is maintained in the driver updated based on the feedback we
get from the device. When an update is needed, iwlwifi sends a command
to the firmware and that command bypasses all the Tx packets currently
queue so that a packet that is already waiting in the queue will be
sent with the updated map. This allows iwlwifi to react downgrade
faster when needed.
So - for athXk (and maybe the MediaTek devices Felix is working on),
this may not be a big problem: you'd need to add another input to the
A-MSDU building code coming from the rate control.
FWIW: in iwlwifi I simply decided to be on the safe side and allowed
the driver to build A-MSDUs only if the rate is fairly high and we are
not downgrading. But you saw (and commented on) that patch already I
think :)
--
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: [RFC v4] mac80211: add A-MSDU tx support

[Emmanuel Grumbach]

On Mon, Feb 8, 2016 at 1:23 PM, Felix Fietkau  wrote:
> On 2016-02-08 12:06, Krishna Chaitanya wrote:
>> On Mon, Feb 8, 2016 at 4:34 PM, Felix Fietkau  wrote:
>>> On 2016-02-08 10:54, Krishna Chaitanya wrote:
 On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
 wrote:
> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
>> Requires software tx queueing support. frag_list support (for zero-copy)
>> is optional.
>>
>> Signed-off-by: Felix Fietkau 
>> ---
>
>
> Ok - looks fine, but... and here comes the hard stuff.
> The frame size in the PLCP is limited in a way that you can't - from a
> spec POV - enable A-MSDU for low rates. Of course, you don't want to
> do that for low rates at all regardless of the spec.
> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
> of the link quality, how do we prevent A-MSDU if the rate is low /
> dropping.
> I'd even argue that when the rates get lower, you'll  have more
> packets piling up in the software queue and ... even more chance to
> get A-MSDU in the exact case where you really want to avoid it?

 Similar to triggering AMPDU setup, we should put this control
 in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
 drop below a pre-defined MCS (or) only for best-throughput rates.
>>> I think starting/stopping A-MSDU based on the rate is a bad idea.
>>> Even with low rates, using A-MSDU can be a good thing (especially for
>>> TCP ACKs), it just needs different size limits.
>>
>> By low rates, i was referring to bad channel conditions (more
>> retries/crc errors)
>> so using AMSDU might trigger more TCP level retries and for case
>> of TCP ACK's its still worse in that it triggers TCP data retires from the
>> peer.
> Based on the research and data from the Bufferbloat project, I'd say
> that in this case the latency due to queue buildup is a lot more harmful
> than lost packets.
> With unmanaged queues, the latency will cause unnecessary
> retransmissions anyway.
> With managed queues, packet drops start increasing with latency until
> TCP starts behaving properly.
> In both cases you have extra TCP retransmissions...
>
> With bad conditions you also get a strong increase in per-TXOP latency.
> With A-MSDU you need fewer TXOPs for the same amount of data in the queue.


Assuming you don't have collisions, then yes. But when things go bad,
you may very well have more collisions, and A-MSDU becomes a disaster.
The way I see it, collisions and "bad conditions" are tightly related.
--
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: rt2x00: Fix queue related oops in case of deselected mac80211 multi-queue feature.

[Gertjan van Wingerde]

Hi Dan,

(resending due to linux-wireless not accepting my message).

On Mon, Feb 8, 2016 at 6:55 PM, Dan Carpenter  wrote:
> Hello Gertjan van Wingerde,
>
> I have a question about patch 61448f88078e: "rt2x00: Fix queue related
> oops in case of deselected mac80211 multi-queue feature." from May 10,
> 2008 because I think there is an off by one.

Ouch, that's really a long time ago ;-)
I haven't been involved in rt2x00 for quite some time now, so let's see if I can
remember anything about this.

> drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
>   1239  /*
>   1240   * We need the following queues:
>   1241   * RX: 1
>   1242   * TX: ops->tx_queues
>   1243   * Beacon: 1
>   1244   * Atim: 1 (if required)
>   1245   */
>   1246  rt2x00dev->data_queues = 2 + rt2x00dev->ops->tx_queues + 
> req_atim;
> 
> ^
> We allocate everything at once in once chunk of memory.


Correct. That just simplifies the error handling and the whole piece of code.

The comment is the important thing here. These are the number of queues we have
to allocate. ops->tx_queues denotes the number of TX queues that the
hardware has.
As far as I can remember there are Ralink devices with 2 TX queues and
there are Ralink
devices with 4 TX queues. Also, there were devices with an ATIM queue
and there were
devices without an ATIM queue (again hardware dependent).

>   1247
>   1248  queue = kcalloc(rt2x00dev->data_queues, sizeof(*queue), 
> GFP_KERNEL);
>   1249  if (!queue) {
>   1250  rt2x00_err(rt2x00dev, "Queue allocation failed\n");
>   1251  return -ENOMEM;
>   1252  }
>   1253
>   1254  /*
>   1255   * Initialize pointers
>   1256   */
>   1257  rt2x00dev->rx = queue;
>
> This is equivalent to [0].  It's actually helpful to static
> checkers and people reading the code if you write it that because we
> are talking about the first element only and not the whole buffer.
> Meanwhile, people do it the reverse way and refer to >start to talk
> about that whole "foo" buffer...  :/


I guess I can agree with that. Feel free to send a patch to "fix" this.

>   1258  rt2x00dev->tx = [1];
>   1259  rt2x00dev->bcn = [1 + rt2x00dev->ops->tx_queues];
>
> There are 2 ->tx_queues, I think so we skipped one queue.  We should
> have put it at [2].  I looked at it briefly and I didn't see where
> the second queue is ever used so maybe this is harmless beyond the
> slight waste of memory.


As I mentioned above there can be either 2 or 4 TX queues. So for the
example of 2 TX queues,
these will be:
[1]
[2]

The beacon queue will be the next one, so this one will have to be
[3], which is exactly
1 + number of TX queues (= 2 in this example).

Note that rt2x00dev->tx is supposed to be array of TX queues, not just
a single queue.

>
>
>   1260  rt2x00dev->atim = req_atim ? [2 + 
> rt2x00dev->ops->tx_queues] : NULL;
>   1261
>   1262  /*
>

Next, the ATIM queue is there (when present on the hardware).
Continuing the example of
above, this should be [4], which again is exactly 2 + number of TX queues.

So, looking at this, I don't think there is an off-by-one error here.

---
Gertjan

-- 
---
Gertjan
--
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] cfg80211: reuse existing page fragments in A-MSDU rx

[Felix Fietkau]

This massively reduces data copying and thus improves rx performance

Signed-off-by: Felix Fietkau 
---
 net/wireless/util.c | 82 +
 1 file changed, 77 insertions(+), 5 deletions(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 9880c89..c7f6820 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -644,23 +644,93 @@ int ieee80211_data_from_8023(struct sk_buff *skb, const 
u8 *addr,
 }
 EXPORT_SYMBOL(ieee80211_data_from_8023);
 
+static void
+__frame_add_frag(struct sk_buff *skb, struct page *page,
+void *ptr, int len, int size)
+{
+   struct skb_shared_info *sh = skb_shinfo(skb);
+   int page_offset;
+
+   atomic_inc(>_count);
+   page_offset = ptr - page_address(page);
+   skb_add_rx_frag(skb, sh->nr_frags, page, page_offset, len, size);
+}
+
+static void
+__ieee80211_amsdu_copy_frag(struct sk_buff *skb, struct sk_buff *frame,
+   int offset, int len)
+{
+   struct skb_shared_info *sh = skb_shinfo(skb);
+   const skb_frag_t *frag = >frags[-1];
+   struct page *frag_page;
+   void *frag_ptr;
+   int frag_len, frag_size;
+   int head_size = skb->len - skb->data_len;
+   int cur_len;
+
+   frag_page = virt_to_head_page(skb->head);
+   frag_ptr = skb->data;
+   frag_size = head_size;
+
+   while (offset >= frag_size) {
+   offset -= frag_size;
+   frag++;
+   frag_page = skb_frag_page(frag);
+   frag_ptr = skb_frag_address(frag);
+   frag_size = skb_frag_size(frag);
+   }
+
+   frag_ptr += offset;
+   frag_len = frag_size - offset;
+
+   cur_len = min(len, frag_len);
+
+   __frame_add_frag(frame, frag_page, frag_ptr, cur_len, frag_size);
+   len -= cur_len;
+
+   while (len > 0) {
+   frag++;
+   frag_len = skb_frag_size(frag);
+   cur_len = min(len, frag_len);
+   __frame_add_frag(frame, skb_frag_page(frag),
+skb_frag_address(frag), cur_len, frag_len);
+   len -= cur_len;
+   }
+}
+
 static struct sk_buff *
 __ieee80211_amsdu_copy(struct sk_buff *skb, unsigned int hlen,
-  int offset, int len)
+  int offset, int len, bool reuse_frag)
 {
struct sk_buff *frame;
+   int cur_len = len;
 
if (skb->len - offset < len)
return NULL;
 
/*
+* When reusing framents, copy some data to the head to simplify
+* ethernet header handling and speed up protocol header processing
+* in the stack later.
+*/
+   if (reuse_frag)
+   cur_len = min_t(int, len, 32);
+
+   /*
 * Allocate and reserve two bytes more for payload
 * alignment since sizeof(struct ethhdr) is 14.
 */
-   frame = dev_alloc_skb(hlen + sizeof(struct ethhdr) + 2 + len);
+   frame = dev_alloc_skb(hlen + sizeof(struct ethhdr) + 2 + cur_len);
 
skb_reserve(frame, hlen + sizeof(struct ethhdr) + 2);
-   skb_copy_bits(skb, offset, skb_put(frame, len), len);
+   skb_copy_bits(skb, offset, skb_put(frame, cur_len), cur_len);
+
+   len -= cur_len;
+   if (!len)
+   return frame;
+
+   offset += cur_len;
+   __ieee80211_amsdu_copy_frag(skb, frame, offset, len);
 
return frame;
 }
@@ -676,6 +746,7 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct 
sk_buff_head *list,
u8 *payload;
int offset = 0, remaining, err;
struct ethhdr eth;
+   bool reuse_frag = skb->head_frag && !skb_has_frag_list(skb);
bool reuse_skb = false;
bool last = false;
 
@@ -703,12 +774,13 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct 
sk_buff_head *list,
offset += sizeof(struct ethhdr);
/* reuse skb for the last subframe */
last = remaining <= subframe_len + padding;
-   if (!skb_is_nonlinear(skb) && last) {
+   if (!skb_is_nonlinear(skb) && !reuse_frag && last) {
skb_pull(skb, offset);
frame = skb;
reuse_skb = true;
} else {
-   frame = __ieee80211_amsdu_copy(skb, hlen, offset, len);
+   frame = __ieee80211_amsdu_copy(skb, hlen, offset, len,
+  reuse_frag);
if (!frame)
goto purge;
 
-- 
2.2.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

[PATCH 9/9] rfkill: Notify userspace of airplane-mode state changes

[João Paulo Rechi Vita]

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt |  3 +++
 net/rfkill/core.c| 13 +
 2 files changed, 16 insertions(+)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index aa6e014..5248812 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -133,5 +133,8 @@ it available for other applications to take control. 
Changes to the
 airplane-mode indicator state can be made using RFKILL_OP_AIRPLANE_MODE_CHANGE,
 passing the new value in the 'soft' field of 'struct rfkill_event'.
 
+This same API is also used to provide userspace with notifications of changes
+to airplane-mode indicator state.
+
 
 For further details consult Documentation/ABI/stable/sysfs-class-rfkill.
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 8067701..abbb8f7 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -131,7 +131,20 @@ static struct led_trigger rfkill_apm_led_trigger;
 
 static void rfkill_apm_led_trigger_event(bool state)
 {
+   struct rfkill_data *data;
+   struct rfkill_int_event *ev;
+
led_trigger_event(_apm_led_trigger, state ? LED_FULL : LED_OFF);
+
+   list_for_each_entry(data, _fds, list) {
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   continue;
+   ev->ev.op = RFKILL_OP_AIRPLANE_MODE_CHANGE;
+   ev->ev.soft = state;
+   list_add_tail(>list, >events);
+   wake_up_interruptible(>read_wait);
+   }
 }
 
 static void rfkill_apm_led_trigger_activate(struct led_classdev *led)
-- 
2.5.0

--
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 2/9] rfkill: Remove extra blank line

[João Paulo Rechi Vita]

Signed-off-by: João Paulo Rechi Vita 
---
 net/rfkill/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index ffbc375..56d79cb 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -455,7 +455,6 @@ bool rfkill_get_global_sw_state(const enum rfkill_type type)
 }
 #endif
 
-
 bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
 {
unsigned long flags;
-- 
2.5.0

--
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

[ANN] wireless-regdb: master-2016-02-08

[Seth Forshee]

A new release of wireless-regdb (master-2016-02-08) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2016.02.08.tar.gz

The short log of changes since the 2015-12-14 release is below.

Thanks,
Seth

---

Seth Forshee (1):
  wireless-regdb: update regulatory.bin based on preceding changes

Xose Vazquez Perez (1):
  wireless-regdb: add 2.4GHz regulatory rules for Cuba (CU)
--
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] cfg80211: fix faulty variable initialization in ieee80211_amsdu_to_8023s

[Felix Fietkau]

reuse_skb is set to true if the code decides to use the last segment.
Fixes a memory leak

Signed-off-by: Felix Fietkau 
---
 net/wireless/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 6e4eb35..9880c89 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -676,7 +676,7 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct 
sk_buff_head *list,
u8 *payload;
int offset = 0, remaining, err;
struct ethhdr eth;
-   bool reuse_skb = true;
+   bool reuse_skb = false;
bool last = false;
 
if (has_80211_header) {
-- 
2.2.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 8/9] rfkill: Userspace control for airplane mode

[João Paulo Rechi Vita]

Hello Marcel,

On 8 February 2016 at 11:20, Marcel Holtmann  wrote:
> Hi Joa Paulo,
>
>> Provide an interface for the airplane-mode indicator be controlled from
>> userspace. User has to first acquire the control through
>> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
>> it wants to be in control of the indicator. Closing the fd or using
>> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
>>
>> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
>> operation is used, passing the value on "struct rfkill_event.soft". If
>> the caller has not acquired the airplane-mode control beforehand, the
>> operation fails.
>
> as explained in an earlier response, the concept Airplane Mode seems to be 
> imposing policy into the kernel. Do we really want have this as a kernel 
> exposed API.
>

On that very same thread we decided to keep using the "airplane mode"
name both for when having the default policy of "set it when all
radios are off" or when allowing userspace to override the default.
Please see the following message from Johannes
http://www.spinics.net/lists/linux-wireless/msg146069.html and let me
know if that covers your concern.

Thanks!

--
João Paulo Rechi Vita
http://about.me/jprvita
--
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 8/9] rfkill: Userspace control for airplane mode

[Johannes Berg]

On 2016-02-08 17:20, Marcel Holtmann wrote:


as explained in an earlier response, the concept Airplane Mode seems
to be imposing policy into the kernel. Do we really want have this as
a kernel exposed API.


This patch is the one that *solves* that problem ... please read it more 
carefully?


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

re: rtlwifi: fix broken VHT support

[Dan Carpenter]

Hello Larry Finger,

The patch d76d65fd2695: "rtlwifi: fix broken VHT support" from Feb 1,
2016, leads to the following static checker warning:

drivers/net/wireless/realtek/rtlwifi/rc.c:144 _rtl_rc_rate_set_series()
warn: impossible condition '(wireless_mode == 256) => (0-255 == 256)'

drivers/net/wireless/realtek/rtlwifi/rc.c
   135  if (sgi_20 || sgi_40 || sgi_80)
   136  rate->flags |= IEEE80211_TX_RC_SHORT_GI;
   137  if (sta && sta->ht_cap.ht_supported &&
   138  ((wireless_mode == WIRELESS_MODE_N_5G) ||
   139   (wireless_mode == WIRELESS_MODE_N_24G)))
   140  rate->flags |= IEEE80211_TX_RC_MCS;
   141  if (sta && sta->vht_cap.vht_supported &&
   142  (wireless_mode == WIRELESS_MODE_AC_5G ||
   143   wireless_mode == WIRELESS_MODE_AC_24G ||
   144   wireless_mode == WIRELESS_MODE_AC_ONLY))
 ^^
Not possible.  sta_entry->wireless_mode is u8 and WIRELESS_MODE_AC_ONLY
is 0x100.

   145  rate->flags |= IEEE80211_TX_RC_VHT_MCS;
   146  }
   147  }


regards,
dan carpenter
--
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: [RFC v4] mac80211: add A-MSDU tx support

[Dave Taht]

On Mon, Feb 8, 2016 at 3:23 AM, Felix Fietkau  wrote:
> On 2016-02-08 12:06, Krishna Chaitanya wrote:
>> On Mon, Feb 8, 2016 at 4:34 PM, Felix Fietkau  wrote:
>>> On 2016-02-08 10:54, Krishna Chaitanya wrote:
 On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel Grumbach  
 wrote:
> On Mon, Feb 8, 2016 at 10:38 AM, Felix Fietkau  wrote:
>> Requires software tx queueing support. frag_list support (for zero-copy)
>> is optional.
>>
>> Signed-off-by: Felix Fietkau 
>> ---
>
>
> Ok - looks fine, but... and here comes the hard stuff.
> The frame size in the PLCP is limited in a way that you can't - from a
> spec POV - enable A-MSDU for low rates. Of course, you don't want to
> do that for low rates at all regardless of the spec.
> Since you build the A-MSDU in the mac80211 Tx queue which is not aware
> of the link quality, how do we prevent A-MSDU if the rate is low /
> dropping.
> I'd even argue that when the rates get lower, you'll  have more
> packets piling up in the software queue and ... even more chance to
> get A-MSDU in the exact case where you really want to avoid it?

 Similar to triggering AMPDU setup, we should put this control
 in RC (minstrel) to start/stop AMSDU based on link quality/if the rates
 drop below a pre-defined MCS (or) only for best-throughput rates.
>>> I think starting/stopping A-MSDU based on the rate is a bad idea.
>>> Even with low rates, using A-MSDU can be a good thing (especially for
>>> TCP ACKs), it just needs different size limits.
>>
>> By low rates, i was referring to bad channel conditions (more
>> retries/crc errors)
>> so using AMSDU might trigger more TCP level retries and for case
>> of TCP ACK's its still worse in that it triggers TCP data retires from the
>> peer.
> Based on the research and data from the Bufferbloat project, I'd say
> that in this case the latency due to queue buildup is a lot more harmful
> than lost packets.

+1.

> With unmanaged queues, the latency will cause unnecessary
> retransmissions anyway.

typically at greater than 250ms, yes.

It's my hope that everyone has agreed that > 250ms of queuing is bad,
except for actual transit to the moon and back, at this point. My hope
is that everyone can aim for < 20ms in the more general case.

I was very happy to see the iwl patch go by cutting things down from
seconds to 30-250ms under load, but am now puzzled.

One iwl user has reported that AMPDUs are disabled by default on iwl,
and had to do this:

options iwlwifi 11n_disable=8

For a 4fold reduction in latency under load in his tests, iwl to ath9k.

What enables/disable AMPDU and AMSDU in the general case?

> With managed queues, packet drops start increasing with latency until
> TCP starts behaving properly.
> In both cases you have extra TCP retransmissions...

One thrust of mine has been to get ecn more widely adopted, which
would eliminate the tcp retransmit problem on devices using it for
congestion control (except on actual loss).

Apple turned ecn on universally on all dev devices last august. They
ran into trouble with one major ISP and had to turn it off, I am not
sure if they shipped with it on or not.

https://plus.google.com/u/0/107942175615993706558/posts/1j8nXtLGZDm

Stuart Cheshire also points at a real case where excessive queuing
hurts and fq doesn't help - screen sharing - with a nice demo
combining fq_codel + the tcp_netsent_lowat option. (his talk starts at
about 16 minutes in, he goes into the relevant bits at about 24
minutes in, and I'm sorry for always pointing people at talks rather
than papers)

Toke ("the good, the bad, and the wifi") points to excessive queuing
*not* being a problem so long as the fq portion is sufficiently close
to the hardware, in other scenarios.

http://www.sciencedirect.com/science/article/pii/S1389128615002479

Now, as to whether a driver or device doing retransmits should (or
even could) drop or mark packets is a good question. I am biased
towards achieving low latency and per device fairness so I lean
towards giving up a lot sooner in bad conditions and moving on

> With bad conditions you also get a strong increase in per-TXOP latency.

Having an agreed upon table for all the "bad" conditions and what
should be done in these cases would be good. I don't regard
"contention" as a bad condition, but as an indicator to be smarter
about bunching up and/or discarding packets. Interference is a "bad"
condition. Low rates for one station compared to the others is not a
bad condition, as striving for airtime fairness between all stations
is a reasonable goal... etc...


> With A-MSDU you need fewer TXOPs for the same amount of data in the queue.

I like it. :)

I note that for stations, I am perpetually seeing this sort of behavior:

ap -> transmits a bunch of packets to station
station -> takes 2 or more txops to respond

re: rt2x00: Fix queue related oops in case of deselected mac80211 multi-queue feature.

[Dan Carpenter]

Hello Gertjan van Wingerde,

I have a question about patch 61448f88078e: "rt2x00: Fix queue related
oops in case of deselected mac80211 multi-queue feature." from May 10,
2008 because I think there is an off by one.

drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
  1239  /*
  1240   * We need the following queues:
  1241   * RX: 1
  1242   * TX: ops->tx_queues
  1243   * Beacon: 1
  1244   * Atim: 1 (if required)
  1245   */
  1246  rt2x00dev->data_queues = 2 + rt2x00dev->ops->tx_queues + 
req_atim;

^
We allocate everything at once in once chunk of memory.

  1247  
  1248  queue = kcalloc(rt2x00dev->data_queues, sizeof(*queue), 
GFP_KERNEL);
  1249  if (!queue) {
  1250  rt2x00_err(rt2x00dev, "Queue allocation failed\n");
  1251  return -ENOMEM;
  1252  }
  1253  
  1254  /*
  1255   * Initialize pointers
  1256   */
  1257  rt2x00dev->rx = queue;

This is equivalent to [0].  It's actually helpful to static
checkers and people reading the code if you write it that because we
are talking about the first element only and not the whole buffer.
Meanwhile, people do it the reverse way and refer to >start to talk
about that whole "foo" buffer...  :/

  1258  rt2x00dev->tx = [1];
  1259  rt2x00dev->bcn = [1 + rt2x00dev->ops->tx_queues];

There are 2 ->tx_queues, I think so we skipped one queue.  We should
have put it at [2].  I looked at it briefly and I didn't see where
the second queue is ever used so maybe this is harmless beyond the
slight waste of memory.

  1260  rt2x00dev->atim = req_atim ? [2 + 
rt2x00dev->ops->tx_queues] : NULL;
  1261  
  1262  /*

regards,
dan carpenter
--
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 1/2] b43: Remove unnecessary synchronize_irq() before free_irq()

[Lars-Peter Clausen]

Calling synchronize_irq() right before free_irq() is quite useless. On one
hand the IRQ can easily fire again before free_irq() is entered, on the
other hand free_irq() itself calls synchronize_irq() internally (in a race
condition free way), before any state associated with the IRQ is freed.

Patch was generated using the following semantic patch:
// 
@@
expression irq;
@@
-synchronize_irq(irq);
 free_irq(irq, ...);
// 

Signed-off-by: Lars-Peter Clausen 
---
 drivers/net/wireless/broadcom/b43/main.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43/main.c 
b/drivers/net/wireless/broadcom/b43/main.c
index c279211..72380af 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -4375,12 +4375,10 @@ redo:
/* Synchronize and free the interrupt handlers. Unlock to avoid 
deadlocks. */
orig_dev = dev;
mutex_unlock(>mutex);
-   if (b43_bus_host_is_sdio(dev->dev)) {
+   if (b43_bus_host_is_sdio(dev->dev))
b43_sdio_free_irq(dev);
-   } else {
-   synchronize_irq(dev->dev->irq);
+   else
free_irq(dev->dev->irq, dev);
-   }
mutex_lock(>mutex);
dev = wl->current_dev;
if (!dev)
-- 
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

Re: [PATCH v3 2/3] mwifiex: parse chip specific gpio from device tree

[Rob Herring]

On Mon, Feb 08, 2016 at 01:11:03PM +0100, Arnd Bergmann wrote:
> On Monday 08 February 2016 02:15:27 Amitkumar Karwar wrote:
> > if (adapter->dt_node) {
> > +   if (of_property_read_u32(adapter->dt_node,
> > +"mwifiex,chip-gpio",
> > +) == 0) {
> > +   mwifiex_dbg(adapter, INFO,
> > +   "chip_gpio = 0x%x\n", data);
> > +   adapter->hs_cfg.gpio = data;
> > +   }
> > +
> > 
> 
> Please use the GPIO DT binding. Reading a number from DT is not a proper
> way to get a GPIO number, as you may have more than one GPIO controller
> in a system and it is not obvious to which controller this number belongs,
> or if you need to specify things like polarity.

My read of this is it is not the host SOC gpio, but the WiFi device's 
GPIO number. The host GPIO is defined in patch 3. We could still use the 
GPIO binding to describe it doing something like "marvell,-gpios". Then the assignment is based on the property name.

Rob
--
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 2/2] rtlwifi: Remove unnecessary synchronize_irq() before free_irq()

[Larry Finger]

On 02/08/2016 02:41 PM, Lars-Peter Clausen wrote:

Calling synchronize_irq() right before free_irq() is quite useless. On one
hand the IRQ can easily fire again before free_irq() is entered, on the
other hand free_irq() itself calls synchronize_irq() internally (in a race
condition free way), before any state associated with the IRQ is freed.

Patch was generated using the following semantic patch:
// 
@@
expression irq;
@@
-synchronize_irq(irq);
  free_irq(irq, ...);
// 

Signed-off-by: Lars-Peter Clausen 
---
  drivers/net/wireless/realtek/rtlwifi/pci.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 7f471bf..140d254 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -2392,7 +2392,6 @@ void rtl_pci_disconnect(struct pci_dev *pdev)
rtlpriv->cfg->ops->deinit_sw_vars(hw);

if (rtlpci->irq_alloc) {
-   synchronize_irq(rtlpci->pdev->irq);
free_irq(rtlpci->pdev->irq, hw);
rtlpci->irq_alloc = 0;
}



Acked-by: Larry Finger 

Makes sense to me.

Thanks,

Larry

--
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 2/2] rtlwifi: Remove unnecessary synchronize_irq() before free_irq()

[Lars-Peter Clausen]

Calling synchronize_irq() right before free_irq() is quite useless. On one
hand the IRQ can easily fire again before free_irq() is entered, on the
other hand free_irq() itself calls synchronize_irq() internally (in a race
condition free way), before any state associated with the IRQ is freed.

Patch was generated using the following semantic patch:
// 
@@
expression irq;
@@
-synchronize_irq(irq);
 free_irq(irq, ...);
// 

Signed-off-by: Lars-Peter Clausen 
---
 drivers/net/wireless/realtek/rtlwifi/pci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 7f471bf..140d254 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -2392,7 +2392,6 @@ void rtl_pci_disconnect(struct pci_dev *pdev)
rtlpriv->cfg->ops->deinit_sw_vars(hw);
 
if (rtlpci->irq_alloc) {
-   synchronize_irq(rtlpci->pdev->irq);
free_irq(rtlpci->pdev->irq, hw);
rtlpci->irq_alloc = 0;
}
-- 
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

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

[João Paulo Rechi Vita]

On 8 February 2016 at 11:11, Dan Williams  wrote:
> On Mon, 2016-02-08 at 10:41 -0500, João Paulo Rechi Vita wrote:
>> Provide an interface for the airplane-mode indicator be controlled
>> from
>> userspace. User has to first acquire the control through
>> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole
>> time
>> it wants to be in control of the indicator. Closing the fd or using
>> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
>>
>> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
>> operation is used, passing the value on "struct rfkill_event.soft".
>> If
>> the caller has not acquired the airplane-mode control beforehand, the
>> operation fails.
>
> I'd like to clarify a bit, so tell me if I'm correct or not.  Using
> RFKILL_OP_AIRPLANE_MODE_CHANGE does not actually change any device
> state. It's just an indicator with no relationship to any of the
> registered rfkill switches, right?
>

Yes, that's correct, and it is the intended behavior.

> I wonder if setting RFKILL_OP_AIRPLANE_MODE_CHANGE(true) shouldn't also
> softblock all switches, otherwise you can set airplane mode all day
> long with RFKILL_OP_AIRPLANE_MODE_CHANGE and it doesn't actually enable
> airplane mode at all?
>

The idea behind it is to just provide the mechanism for userspace to
decide what exactly being in airplane mode means, so it would
set/unset the indicator in the right moment.

--
João Paulo Rechi Vita
http://about.me/jprvita
--
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: rtlwifi: fix broken VHT support

[Larry Finger]

On 02/08/2016 12:22 PM, Dan Carpenter wrote:

Hello Larry Finger,

The patch d76d65fd2695: "rtlwifi: fix broken VHT support" from Feb 1,
2016, leads to the following static checker warning:

drivers/net/wireless/realtek/rtlwifi/rc.c:144 _rtl_rc_rate_set_series()
warn: impossible condition '(wireless_mode == 256) => (0-255 == 256)'

drivers/net/wireless/realtek/rtlwifi/rc.c
135  if (sgi_20 || sgi_40 || sgi_80)
136  rate->flags |= IEEE80211_TX_RC_SHORT_GI;
137  if (sta && sta->ht_cap.ht_supported &&
138  ((wireless_mode == WIRELESS_MODE_N_5G) ||
139   (wireless_mode == WIRELESS_MODE_N_24G)))
140  rate->flags |= IEEE80211_TX_RC_MCS;
141  if (sta && sta->vht_cap.vht_supported &&
142  (wireless_mode == WIRELESS_MODE_AC_5G ||
143   wireless_mode == WIRELESS_MODE_AC_24G ||
144   wireless_mode == WIRELESS_MODE_AC_ONLY))
  ^^
Not possible.  sta_entry->wireless_mode is u8 and WIRELESS_MODE_AC_ONLY
is 0x100.

145  rate->flags |= IEEE80211_TX_RC_VHT_MCS;
146  }
147  }




Dan,

Thanks for the heads-up. Obviously, wireless_mode needs to be u16, but I will 
need some time to consider any side effects as the underlying variable in the 
private space is used by several of the rtlwifi family.


Larry


--
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: [RFC v4] mac80211: add A-MSDU tx support

[Juliusz Chroboczek]

> One iwl user has reported that AMPDUs are disabled by default on iwl,

That was me.

> and had to do this:
>
> options iwlwifi 11n_disable=8
>
> For a 4fold reduction in latency under load in his tests, iwl to ath9k.

No, it was ath9k to iwl.  I don't understand it either: enabling AMPDUs on
the STA dramatically reduces latency under load in the AP->STA direction.

-- Juliusz


--
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 2/9] rfkill: Remove extra blank line

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> Signed-off-by: João Paulo Rechi Vita 

Looks sane to me.

Reviewed-by: Julian Calaby 

> ---
>  net/rfkill/core.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index ffbc375..56d79cb 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -455,7 +455,6 @@ bool rfkill_get_global_sw_state(const enum rfkill_type 
> type)
>  }
>  #endif
>
> -
>  bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
>  {
> unsigned long flags;
> --
> 2.5.0
>
> --
> 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



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 1/9] rfkill: Improve documentation language

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> Signed-off-by: João Paulo Rechi Vita 

Looks right to me.

Reviewed-by: Julian Calaby 

> ---
>  net/rfkill/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index a805831..ffbc375 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -282,8 +282,8 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
> blocked)
> spin_lock_irqsave(>lock, flags);
> if (err) {
> /*
> -* Failed -- reset status to _prev, this may be different
> -* from what set set _PREV to earlier in this function
> +* Failed -- reset status to _PREV, which may be different
> +* from what we have set _PREV to earlier in this function
>  * if rfkill_set_sw_state was invoked.
>  */
> if (rfkill->state & RFKILL_BLOCK_SW_PREV)
> --
> 2.5.0
>
> --
> 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



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 1/2] b43: Remove unnecessary synchronize_irq() before free_irq()

[Michael Büsch]

On Mon,  8 Feb 2016 21:41:12 +0100
Lars-Peter Clausen  wrote:

> Calling synchronize_irq() right before free_irq() is quite useless. On one
> hand the IRQ can easily fire again before free_irq() is entered,

Well, that depends on whether the interrupt is shared and whether we
disabled the interrupt mask inside of the device (which we did).

> on the
> other hand free_irq() itself calls synchronize_irq() internally (in a race
> condition free way), before any state associated with the IRQ is freed.

Ok, fair enough.

-- 
Michael


pgpK8kRWHD8VE.pgp
Description: OpenPGP digital signature

Re: [PATCH 8/9] rfkill: Userspace control for airplane mode

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> Provide an interface for the airplane-mode indicator be controlled from
> userspace. User has to first acquire the control through
> RFKILL_OP_AIRPLANE_MODE_ACQUIRE and keep the fd open for the whole time
> it wants to be in control of the indicator. Closing the fd or using
> RFKILL_OP_AIRPLANE_MODE_RELEASE restores the default policy.
>
> To change state of the indicator, the RFKILL_OP_AIRPLANE_MODE_CHANGE
> operation is used, passing the value on "struct rfkill_event.soft". If
> the caller has not acquired the airplane-mode control beforehand, the
> operation fails.
>
> Signed-off-by: João Paulo Rechi Vita 
> ---
>  Documentation/rfkill.txt| 10 ++
>  include/uapi/linux/rfkill.h |  3 +++
>  net/rfkill/core.c   | 47 
> ++---
>  3 files changed, 57 insertions(+), 3 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index fb11547..8067701 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -1207,6 +1210,34 @@ static ssize_t rfkill_fop_write(struct file *file, 
> const char __user *buf,
>
> mutex_lock(_global_mutex);
>
> +   if (ev.op == RFKILL_OP_AIRPLANE_MODE_ACQUIRE) {
> +   if (rfkill_apm_owned && !data->is_apm_owner) {
> +   count = -EACCES;
> +   } else {
> +   rfkill_apm_owned = true;
> +   data->is_apm_owner = true;
> +   }
> +   }
> +
> +   if (ev.op == RFKILL_OP_AIRPLANE_MODE_RELEASE) {
> +   if (rfkill_apm_owned && !data->is_apm_owner) {

Are you sure this is correct?

In the case that airplane mode isn't owned, the
rfkill_apm_led_trigger_event() call will be a noop, so we should
arguably not be calling it.

Also, should we just fail silently if we're not the owner? I.e. what
does userspace learn from this op failing and is that useful?

> +   count = -EACCES;
> +   } else {
> +   bool state = 
> rfkill_global_states[RFKILL_TYPE_ALL].cur;
> +
> +   rfkill_apm_owned = false;
> +   data->is_apm_owner = false;
> +   rfkill_apm_led_trigger_event(state);
> +   }
> +   }
> +
> +   if (ev.op == RFKILL_OP_AIRPLANE_MODE_CHANGE) {
> +   if (rfkill_apm_owned && data->is_apm_owner)
> +   rfkill_apm_led_trigger_event(ev.soft);
> +   else
> +   count = -EACCES;
> +   }
> +
> if (ev.op == RFKILL_OP_CHANGE_ALL)
> rfkill_update_global_state(ev.type, ev.soft);
>
> @@ -1230,7 +1261,17 @@ static int rfkill_fop_release(struct inode *inode, 
> struct file *file)
> struct rfkill_int_event *ev, *tmp;
>
> mutex_lock(_global_mutex);
> +
> +   if (data->is_apm_owner) {
> +   bool state = rfkill_global_states[RFKILL_TYPE_ALL].cur;
> +
> +   rfkill_apm_owned = false;
> +   data->is_apm_owner = false;
> +   rfkill_apm_led_trigger_event(state);

Also, this code is duplicated from the _RELEASE op above. Would it
make sense to factor it out into a separate function?

> +   }
> +
> list_del(>list);
> +

(extra line)

> mutex_unlock(_global_mutex);
>
> mutex_destroy(>mtx);

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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: wl12xx regression on 4.5 (was: Re: linux-4.5-rc1 TI pandboard-es wifi wlcore locks and reset)

[Emil Goode]

Hello Ross,

On Mon, Feb 08, 2016 at 07:26:34PM +1100, Ross Green wrote:
> On Mon, Feb 8, 2016 at 9:05 AM, Emil Goode  wrote:
> > Hello,
> >
> > On Tue, Feb 02, 2016 at 05:05:38PM +0100, Sebastian Reichel wrote:
> >> On Tue, Feb 02, 2016 at 04:41:13PM +1100, Ross Green wrote:
> >> > On Tue, Feb 2, 2016 at 3:34 PM, Sebastian Reichel  
> >> > wrote:
> >> > > On Mon, Feb 01, 2016 at 11:38:38PM +1100, Ross Green wrote:
> >> > >> On Mon, Jan 25, 2016 at 11:47 PM, Ross Green  
> >> > >> wrote:
> >> > >> > Just tried the new kernel release on faithful pandaboard es with the
> >> > >> > new 4.5-rc1 release.
> >> > >> >
> >> > >> > There is a problem with the wifi modules once the modules are 
> >> > >> > loaded.
> >> > >> > Looks like the wifi firmware gets loaded put no response after that
> >> > >> > causing recovery action.
> >> > >> >
> >> > >> > the kernel 4.4 works quite happily with this board.
> >> > >> >
> >> > >> > Here is a dmesg dump in the attachment.
> >> > >> >
> >> > >> > Anyone have any ideas here?
> >> >
> >> > [...]
> >> >
> >> > If I get time, this evening, I'll see if I can give a bisect a try.
> >>
> >> On N950 [wl1271 via SPI, using extra patches to init from DT] I get wifi
> >> working again on 4.5-rc1 with 3719c17e1816 ("wlcore/wl18xx: fw logger
> >> over sdio") reverted.
> >
> > Reverting the changes in wlcore_set_partition() as below seem to help.
> >
> > Best regards,
> >
> > Emil Goode
> >
> > 8<
> >
> > --- a/drivers/net/wireless/ti/wlcore/io.c
> > +++ b/drivers/net/wireless/ti/wlcore/io.c
> > @@ -175,14 +175,15 @@ int wlcore_set_partition(struct wl1271 *wl,
> > if (ret < 0)
> > goto out;
> >
> > +   /*
> > +* We don't need the size of the last partition, as it is
> > +* automatically calculated based on the total memory size and
> > +* the sizes of the previous partitions.
> > +*/
> > ret = wlcore_raw_write32(wl, HW_PART3_START_ADDR, p->mem3.start);
> > if (ret < 0)
> > goto out;
> >
> > -   ret = wlcore_raw_write32(wl, HW_PART3_SIZE_ADDR, p->mem3.size);
> > -   if (ret < 0)
> > -   goto out;
> > -
> >  out:
> > return ret;
> >  }
> > diff --git a/drivers/net/wireless/ti/wlcore/io.h 
> > b/drivers/net/wireless/ti/wlcore/io.h
> > index 6c257b5..10cf374 100644
> > --- a/drivers/net/wireless/ti/wlcore/io.h
> > +++ b/drivers/net/wireless/ti/wlcore/io.h
> > @@ -36,8 +36,8 @@
> >  #define HW_PART1_START_ADDR (HW_PARTITION_REGISTERS_ADDR + 12)
> >  #define HW_PART2_SIZE_ADDR  (HW_PARTITION_REGISTERS_ADDR + 16)
> >  #define HW_PART2_START_ADDR (HW_PARTITION_REGISTERS_ADDR + 20)
> > -#define HW_PART3_SIZE_ADDR  (HW_PARTITION_REGISTERS_ADDR + 24)
> > -#define HW_PART3_START_ADDR (HW_PARTITION_REGISTERS_ADDR + 28)
> > +#define HW_PART3_START_ADDR (HW_PARTITION_REGISTERS_ADDR + 24)
> > +
> >  #define HW_ACCESS_REGISTER_SIZE 4
> >
> >  #define HW_ACCESS_PRAM_MAX_RANGE   0x3c000
> >
> 
> Thanks Emil,
> 
> Just tested linux-4.5-rc3 with the above patch and confirm everything
> works as expected. So it would be good if this patch can find its way
> into linux-4.5-rc4.
> 
> So all is happy with the wlcore code with this patch.
> Now I can continue with the rest of the testing ;-)

Thank you for testing!

I'm not familiar with this code so it would be good to get a comment from ti 
developers, 
if not I will send this fix.

Best regards,

Emil Goode
--
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 5/9] rfkill: Factor rfkill_global_states[].cur assignments

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> Factor all assignments to rfkill_global_states[].cur into a single
> function rfkill_update_global_state().
>
> Signed-off-by: João Paulo Rechi Vita 

Looks sane to me.

Reviewed-by: Julian Calaby 

> ---
>  net/rfkill/core.c | 38 +-
>  1 file changed, 17 insertions(+), 21 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index 56d79cb..8b96869 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -302,6 +302,19 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
> blocked)
> rfkill_event(rfkill);
>  }
>
> +static void rfkill_update_global_state(enum rfkill_type type, bool blocked)
> +{
> +   int i;
> +
> +   if (type != RFKILL_TYPE_ALL) {
> +   rfkill_global_states[type].cur = blocked;
> +   return;
> +   }
> +
> +   for (i = 0; i < NUM_RFKILL_TYPES; i++)
> +   rfkill_global_states[i].cur = blocked;
> +}
> +
>  #ifdef CONFIG_RFKILL_INPUT
>  static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
>
> @@ -319,15 +332,7 @@ static void __rfkill_switch_all(const enum rfkill_type 
> type, bool blocked)
>  {
> struct rfkill *rfkill;
>
> -   if (type == RFKILL_TYPE_ALL) {
> -   int i;
> -
> -   for (i = 0; i < NUM_RFKILL_TYPES; i++)
> -   rfkill_global_states[i].cur = blocked;
> -   } else {
> -   rfkill_global_states[type].cur = blocked;
> -   }
> -
> +   rfkill_update_global_state(type, blocked);
> list_for_each_entry(rfkill, _list, node) {
> if (rfkill->type != type && type != RFKILL_TYPE_ALL)
> continue;
> @@ -1164,15 +1169,8 @@ static ssize_t rfkill_fop_write(struct file *file, 
> const char __user *buf,
>
> mutex_lock(_global_mutex);
>
> -   if (ev.op == RFKILL_OP_CHANGE_ALL) {
> -   if (ev.type == RFKILL_TYPE_ALL) {
> -   enum rfkill_type i;
> -   for (i = 0; i < NUM_RFKILL_TYPES; i++)
> -   rfkill_global_states[i].cur = ev.soft;
> -   } else {
> -   rfkill_global_states[ev.type].cur = ev.soft;
> -   }
> -   }
> +   if (ev.op == RFKILL_OP_CHANGE_ALL)
> +   rfkill_update_global_state(ev.type, ev.soft);
>
> list_for_each_entry(rfkill, _list, node) {
> if (rfkill->idx != ev.idx && ev.op != RFKILL_OP_CHANGE_ALL)
> @@ -1261,10 +1259,8 @@ static struct miscdevice rfkill_miscdev = {
>  static int __init rfkill_init(void)
>  {
> int error;
> -   int i;
>
> -   for (i = 0; i < NUM_RFKILL_TYPES; i++)
> -   rfkill_global_states[i].cur = !rfkill_default_state;
> +   rfkill_update_global_state(RFKILL_TYPE_ALL, !rfkill_default_state);
>
> error = class_register(_class);
> if (error)
> --
> 2.5.0
>
> --
> 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



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 3/9] rfkill: Point to the correct deprecated doc location

[Julian Calaby]

Hi João,

On Tue, Feb 9, 2016 at 2:41 AM, João Paulo Rechi Vita  wrote:
> The "claim" sysfs interface has been removed, so its documentation now
> lives in the "removed" folder.
>
> Signed-off-by: João Paulo Rechi Vita 

Looks right to me.

Reviewed-by: Julian Calaby 

> ---
>  Documentation/ABI/stable/sysfs-class-rfkill | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-class-rfkill 
> b/Documentation/ABI/stable/sysfs-class-rfkill
> index 097f522..e51571e 100644
> --- a/Documentation/ABI/stable/sysfs-class-rfkill
> +++ b/Documentation/ABI/stable/sysfs-class-rfkill
> @@ -2,8 +2,10 @@ rfkill - radio frequency (RF) connector kill switch support
>
>  For details to this subsystem look at Documentation/rfkill.txt.
>
> -For the deprecated /sys/class/rfkill/*/state and
> -/sys/class/rfkill/*/claim knobs of this interface look in
> +For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
> +Documentation/ABI/removed/sysfs-class-rfkill.
> +
> +For the deprecated /sys/class/rfkill/*/state knobs of this interface look in
>  Documentation/ABI/obsolete/sysfs-class-rfkill.
>
>  What:  /sys/class/rfkill
> --
> 2.5.0
>
> --
> 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



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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