[PATCH 4/4] ath10k: update bss channel survey information

[Rajkumar Manoharan]

During hw scan, firmware sends two channel information events (pre-
complete, complete) to host for each channel change. The snap shot of cycle
counters (rx_clear and total) between these two events are given for
survey dump. In order to get latest survey statistics of all channels, a
scan request has to be issued. In general, an AP DUT is brought up, it
won't leave BSS channel except few cases like overlapping bss or radar
detection. So survey statistics of bss channel is always referring to
older data that are collected before starting AP (either ACS/OBSS scan).

To collect latest survey information from target, firmware provides WMI
interface to read cycle counters from hardware. For each survey dump
request, BSS channel cycle counters are read and cleared in hardware.
This makes sure that behavior is in align with ath9k survey report.
So survey dump always gives snap shot of cycle counters b/w two survey
requests.

Signed-off-by: Yanbo Li 
Signed-off-by: Rajkumar Manoharan 
---
 drivers/net/wireless/ath/ath10k/core.c |  5 +
 drivers/net/wireless/ath/ath10k/core.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c  | 35 ++
 drivers/net/wireless/ath/ath10k/wmi.c  | 29 
 4 files changed, 70 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 1c4106b84a35..5f846bd4054c 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1460,6 +1460,7 @@ static void ath10k_core_restart(struct work_struct *work)
complete_all(>install_key_done);
complete_all(>vdev_setup_done);
complete_all(>thermal.wmi_sync);
+   complete_all(>bss_survey_done);
wake_up(>htt.empty_tx_wq);
wake_up(>wmi.tx_credits_wq);
wake_up(>peer_mapping_wq);
@@ -1787,6 +1788,9 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode)
if (ath10k_peer_stats_enabled(ar))
val = WMI_10_4_PEER_STATS;
 
+   if (test_bit(WMI_SERVICE_BSS_CHANNEL_INFO_64, ar->wmi.svc_map))
+   val |= WMI_10_4_BSS_CHANNEL_INFO_64;
+
status = ath10k_mac_ext_resource_config(ar, val);
if (status) {
ath10k_err(ar,
@@ -2142,6 +2146,7 @@ struct ath10k *ath10k_core_create(size_t priv_size, 
struct device *dev,
init_completion(>install_key_done);
init_completion(>vdev_setup_done);
init_completion(>thermal.wmi_sync);
+   init_completion(>bss_survey_done);
 
INIT_DELAYED_WORK(>scan.timeout, ath10k_scan_timeout_work);
 
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index ccc3d639b077..16c979b1bf2d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -859,6 +859,7 @@ struct ath10k {
 * avoid reporting garbage data.
 */
bool ch_info_can_report_survey;
+   struct completion bss_survey_done;
 
struct dfs_pattern_detector *dfs_detector;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index bcf025f51310..8e5fb931d816 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6404,6 +6404,39 @@ static void ath10k_reconfig_complete(struct ieee80211_hw 
*hw,
mutex_unlock(>conf_mutex);
 }
 
+static void
+ath10k_mac_update_bss_chan_survey(struct ath10k *ar,
+ struct ieee80211_channel *channel)
+{
+   int ret;
+   enum wmi_bss_survey_req_type type = WMI_BSS_SURVEY_REQ_TYPE_READ_CLEAR;
+
+   lockdep_assert_held(>conf_mutex);
+
+   if (!test_bit(WMI_SERVICE_BSS_CHANNEL_INFO_64, ar->wmi.svc_map) ||
+   (ar->rx_channel != channel))
+   return;
+
+   if (ar->scan.state != ATH10K_SCAN_IDLE) {
+   ath10k_dbg(ar, ATH10K_DBG_MAC, "ignoring bss chan info request 
while scanning..\n");
+   return;
+   }
+
+   reinit_completion(>bss_survey_done);
+
+   ret = ath10k_wmi_pdev_bss_chan_info_request(ar, type);
+   if (ret) {
+   ath10k_warn(ar, "failed to send pdev bss chan info request\n");
+   return;
+   }
+
+   ret = wait_for_completion_timeout(>bss_survey_done, 3 * HZ);
+   if (!ret) {
+   ath10k_warn(ar, "bss channel survey timed out\n");
+   return;
+   }
+}
+
 static int ath10k_get_survey(struct ieee80211_hw *hw, int idx,
 struct survey_info *survey)
 {
@@ -6428,6 +6461,8 @@ static int ath10k_get_survey(struct ieee80211_hw *hw, int 
idx,
goto exit;
}
 
+   ath10k_mac_update_bss_chan_survey(ar, survey->channel);
+
spin_lock_bh(>data_lock);
memcpy(survey, ar_survey, sizeof(*survey));

[PATCH 1/4] ath10k: add pdev bss channel info wmi definitions

[Rajkumar Manoharan]

Add WMI definitions for pdev bss channel information request and
event.

Signed-off-by: Rajkumar Manoharan 
---
 drivers/net/wireless/ath/ath10k/wmi.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index db2553522d8b..40bd08d246af 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -1444,6 +1444,7 @@ enum wmi_10_2_cmd_id {
WMI_10_2_MU_CAL_START_CMDID,
WMI_10_2_SET_LTEU_CONFIG_CMDID,
WMI_10_2_SET_CCA_PARAMS,
+   WMI_10_2_PDEV_BSS_CHAN_INFO_REQUEST_CMDID,
WMI_10_2_PDEV_UTF_CMDID = WMI_10_2_END_CMDID - 1,
 };
 
@@ -1487,6 +1488,8 @@ enum wmi_10_2_event_id {
WMI_10_2_WDS_PEER_EVENTID,
WMI_10_2_PEER_STA_PS_STATECHG_EVENTID,
WMI_10_2_PDEV_TEMPERATURE_EVENTID,
+   WMI_10_2_MU_REPORT_EVENTID,
+   WMI_10_2_PDEV_BSS_CHAN_INFO_EVENTID,
WMI_10_2_PDEV_UTF_EVENTID = WMI_10_2_END_EVENTID - 1,
 };
 
@@ -2450,6 +2453,7 @@ enum wmi_10_2_feature_mask {
WMI_10_2_RX_BATCH_MODE = BIT(0),
WMI_10_2_ATF_CONFIG= BIT(1),
WMI_10_2_COEX_GPIO = BIT(3),
+   WMI_10_2_BSS_CHAN_INFO = BIT(6),
WMI_10_2_PEER_STATS= BIT(7),
 };
 
-- 
2.8.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/4] ath10k: implement wmi_pdev_bss_chan_info_request

[Rajkumar Manoharan]

Add WMI ops to send pdev_bss_chan_info_request command to target.
This command will be used to retrieve updated cycle counters and noise
floor value of current operating channel (bss channel).

Signed-off-by: Rajkumar Manoharan 
---
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 21 +
 drivers/net/wireless/ath/ath10k/wmi.c | 25 -
 drivers/net/wireless/ath/ath10k/wmi.h | 10 ++
 3 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 7fb00dcc03b8..64ebd304f907 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -191,6 +191,9 @@ struct wmi_ops {
   u32 fw_feature_bitmap);
int (*get_vdev_subtype)(struct ath10k *ar,
enum wmi_vdev_subtype subtype);
+   struct sk_buff *(*gen_pdev_bss_chan_info_req)
+   (struct ath10k *ar,
+enum wmi_bss_survey_req_type type);
 };
 
 int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id);
@@ -1361,4 +1364,22 @@ ath10k_wmi_get_vdev_subtype(struct ath10k *ar, enum 
wmi_vdev_subtype subtype)
return ar->wmi.ops->get_vdev_subtype(ar, subtype);
 }
 
+static inline int
+ath10k_wmi_pdev_bss_chan_info_request(struct ath10k *ar,
+ enum wmi_bss_survey_req_type type)
+{
+   struct ath10k_wmi *wmi = >wmi;
+   struct sk_buff *skb;
+
+   if (!wmi->ops->gen_pdev_bss_chan_info_req)
+   return -EOPNOTSUPP;
+
+   skb = wmi->ops->gen_pdev_bss_chan_info_req(ar, type);
+   if (IS_ERR(skb))
+   return PTR_ERR(skb);
+
+   return ath10k_wmi_cmd_send(ar, skb,
+  wmi->cmd->pdev_bss_chan_info_request_cmdid);
+}
+
 #endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index adb31e188ebd..d6157d3587c5 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -521,7 +521,8 @@ static struct wmi_cmd_map wmi_10_2_4_cmd_map = {
.vdev_filter_neighbor_rx_packets_cmdid = WMI_CMD_UNSUPPORTED,
.mu_cal_start_cmdid = WMI_CMD_UNSUPPORTED,
.set_cca_params_cmdid = WMI_CMD_UNSUPPORTED,
-   .pdev_bss_chan_info_request_cmdid = WMI_CMD_UNSUPPORTED,
+   .pdev_bss_chan_info_request_cmdid =
+   WMI_10_2_PDEV_BSS_CHAN_INFO_REQUEST_CMDID,
 };
 
 /* 10.4 WMI cmd track */
@@ -6639,6 +6640,26 @@ ath10k_wmi_10_2_op_gen_pdev_get_temperature(struct 
ath10k *ar)
return skb;
 }
 
+static struct sk_buff *
+ath10k_wmi_10_2_op_gen_pdev_bss_chan_info(struct ath10k *ar,
+ enum wmi_bss_survey_req_type type)
+{
+   struct wmi_pdev_chan_info_req_cmd *cmd;
+   struct sk_buff *skb;
+
+   skb = ath10k_wmi_alloc_skb(ar, sizeof(*cmd));
+   if (!skb)
+   return ERR_PTR(-ENOMEM);
+
+   cmd = (struct wmi_pdev_chan_info_req_cmd *)skb->data;
+   cmd->type = __cpu_to_le32(type);
+
+   ath10k_dbg(ar, ATH10K_DBG_WMI,
+  "wmi pdev bss info request type %d\n", type);
+
+   return skb;
+}
+
 /* This function assumes the beacon is already DMA mapped */
 static struct sk_buff *
 ath10k_wmi_op_gen_beacon_dma(struct ath10k *ar, u32 vdev_id, const void *bcn,
@@ -7738,6 +7759,7 @@ static const struct wmi_ops wmi_10_2_4_ops = {
.gen_init = ath10k_wmi_10_2_op_gen_init,
.gen_peer_assoc = ath10k_wmi_10_2_op_gen_peer_assoc,
.gen_pdev_get_temperature = ath10k_wmi_10_2_op_gen_pdev_get_temperature,
+   .gen_pdev_bss_chan_info_req = ath10k_wmi_10_2_op_gen_pdev_bss_chan_info,
 
/* shared with 10.1 */
.map_svc = wmi_10x_svc_map,
@@ -7864,6 +7886,7 @@ static const struct wmi_ops wmi_10_4_ops = {
.gen_request_stats = ath10k_wmi_op_gen_request_stats,
.gen_pdev_get_temperature = ath10k_wmi_10_2_op_gen_pdev_get_temperature,
.get_vdev_subtype = ath10k_wmi_10_4_op_get_vdev_subtype,
+   .gen_pdev_bss_chan_info_req = ath10k_wmi_10_2_op_gen_pdev_bss_chan_info,
 };
 
 int ath10k_wmi_attach(struct ath10k *ar)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 40bd08d246af..4cdf216ae999 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6487,6 +6487,16 @@ enum wmi_host_platform_type {
WMI_HOST_PLATFORM_LOW_PERF,
 };
 
+enum wmi_bss_survey_req_type {
+   WMI_BSS_SURVEY_REQ_TYPE_READ = 1,
+   WMI_BSS_SURVEY_REQ_TYPE_READ_CLEAR,
+};
+
+struct wmi_pdev_chan_info_req_cmd {
+   __le32 type;
+   __le32 reserved;
+} __packed;
+
 struct ath10k;
 struct ath10k_vif;
 struct ath10k_fw_stats_pdev;
-- 
2.8.0

--
To unsubscribe from this list: send the 

[PATCH 3/4] ath10k: handle pdev_chan_info wmi event

[Rajkumar Manoharan]

Add handler to process bss channel information wmi event that
will be received upon sending pdev_chan_info_request wmi command.

Signed-off-by: Rajkumar Manoharan 
---
 drivers/net/wireless/ath/ath10k/wmi.c | 32 
 drivers/net/wireless/ath/ath10k/wmi.h | 11 +++
 2 files changed, 43 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index d6157d3587c5..0f6b8c73a562 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -4796,6 +4796,32 @@ static int ath10k_wmi_event_temperature(struct ath10k 
*ar, struct sk_buff *skb)
return 0;
 }
 
+static int ath10k_wmi_event_pdev_bss_chan_info(struct ath10k *ar,
+  struct sk_buff *skb)
+{
+   struct wmi_pdev_bss_chan_info_event *ev;
+   u64 busy, total, tx, rx, rx_bss;
+   u32 freq, noise_floor;
+
+   ev = (struct wmi_pdev_bss_chan_info_event *)skb->data;
+   if (WARN_ON(skb->len < sizeof(*ev)))
+   return -EPROTO;
+
+   freq= __le32_to_cpu(ev->freq);
+   noise_floor = __le32_to_cpu(ev->noise_floor);
+   busy= __le64_to_cpu(ev->cycle_busy);
+   total   = __le64_to_cpu(ev->cycle_total);
+   tx  = __le64_to_cpu(ev->cycle_tx);
+   rx  = __le64_to_cpu(ev->cycle_rx);
+   rx_bss  = __le64_to_cpu(ev->cycle_rx_bss);
+
+   ath10k_dbg(ar, ATH10K_DBG_WMI,
+  "wmi event pdev bss chan info:\n freq: %d noise: %d cycle: 
busy %llu total %llu tx %llu rx %llu rx_bss %llu\n",
+  freq, noise_floor, busy, total, tx, rx, rx_bss);
+
+   return 0;
+}
+
 static void ath10k_wmi_op_rx(struct ath10k *ar, struct sk_buff *skb)
 {
struct wmi_cmd_hdr *cmd_hdr;
@@ -5139,6 +5165,9 @@ static void ath10k_wmi_10_2_op_rx(struct ath10k *ar, 
struct sk_buff *skb)
case WMI_10_2_PDEV_TEMPERATURE_EVENTID:
ath10k_wmi_event_temperature(ar, skb);
break;
+   case WMI_10_2_PDEV_BSS_CHAN_INFO_EVENTID:
+   ath10k_wmi_event_pdev_bss_chan_info(ar, skb);
+   break;
case WMI_10_2_RTT_KEEPALIVE_EVENTID:
case WMI_10_2_GPIO_INPUT_EVENTID:
case WMI_10_2_PEER_RATECODE_LIST_EVENTID:
@@ -5225,6 +5254,9 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, 
struct sk_buff *skb)
case WMI_10_4_PDEV_TEMPERATURE_EVENTID:
ath10k_wmi_event_temperature(ar, skb);
break;
+   case WMI_10_4_PDEV_BSS_CHAN_INFO_EVENTID:
+   ath10k_wmi_event_pdev_bss_chan_info(ar, skb);
+   break;
default:
ath10k_warn(ar, "Unknown eventid: %d\n", id);
break;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 4cdf216ae999..e1043b81a6e6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6284,6 +6284,17 @@ struct wmi_pdev_temperature_event {
__le32 temperature;
 } __packed;
 
+struct wmi_pdev_bss_chan_info_event {
+   __le32 freq;
+   __le32 noise_floor;
+   __le64 cycle_busy;
+   __le64 cycle_total;
+   __le64 cycle_tx;
+   __le64 cycle_rx;
+   __le64 cycle_rx_bss;
+   __le32 reserved;
+} __packed;
+
 /* WOW structures */
 enum wmi_wow_wakeup_event {
WOW_BMISS_EVENT = 0,
-- 
2.8.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] NFC: trf7970a:

[Mark Greer]

On Mon, Apr 18, 2016 at 03:48:37PM -0400, Geoff Lansberry wrote:

Hi Geoff.

> The current version of the trf7970a driver is missing support for several 
> features that we needed to operate a custom board. 
> We feel that these features will be useful to others as well, and we want to 
> share them.
> 
> 1: Support for using a gpio as Slave-Select. Our processor has several 
> devices on the spi bus, and we ran out of ss lines.  This patch gives 
> TRF7970A the ability to
>  drive the ss line of the chip from a gpio that is defined in the device tree.
> 
> 2. When reviewing problems we were having in our implementation with TI 
> support staff, they recommended that during initialization, address 0x18 
> should be written to zero.  This patch adds that change
> 
> 3. This existing version of the driver assumes that the crystal driving the 
> trf7970a is 13.56 MHz, because there are several places in the driver code 
> where the rel
> ated register is re-written, there is clean way to change to 27.12 MHz.  This 
> patch adds a device tree option for 27 MHz and properly or's in changes in 
> locations w
> here the register is changed.
> 
> 4. the existing version of the driver assumes that 3.3 volt io is used. The 
> trf7970a has a special register where you can configure it for 1.8 volt io.  
> This patch
> adds a device tree option to select that this setting should be made.
> 
>  [PATCH 1/4] NFC: trf7970a: Add support for gpio as SS
>  [PATCH 2/4] NFC: trf7970a: add TI recommended write of zero to
>  [PATCH 3/4] NFC: trf7970a: add device tree option for 27MHz clock
>  [PATCH 4/4] NFC: trf7970a: Add device tree option of 1.8 Volt IO

I'm on vacation this week but will be back next week.  I'll take a
look once I'm back.

In the meantime, for emails sent to public (techie) list always keep
the lines less than 80 characters and always bottom-post (i.e., put
your text *underneath* the text that you are responding to).  Also,
when you change one or more patches in a series, re-submit the entire
series with the version number incremented (.e.g., v2, v3, ...) even
when you change only one of them.  It is a easier for others to know
what the latest versions are that way.

Thanks,

Mark
--
--
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] wcn36xx: Set SMD timeout to 10 seconds

[John Stultz]

On Thu, Apr 21, 2016 at 2:09 PM, Bjorn Andersson
 wrote:
> After booting the wireless subsystem and uploading the NV blob to the
> WCNSS_CTRL service the remote continues to do things and will not start
> servicing wlan-requests for another 2-5 seconds (measured).
>
> The downstream code does not have any special handling for this case,
> but has a timeout of 10 seconds for the communication layer. By
> extending the wcn36xx timeout to match this we follows the same flow for
> the boot procedure and can successfully configure WiFi as wlan0 is
> registered.
>
> Signed-off-by: Bjorn Andersson 

I've been using this with my nexus7 tree, and its avoided issues I was
seeing without it.

Tested-by: John Stultz 

thanks
-john
--
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] wcn36xx: Set SMD timeout to 10 seconds

[Bjorn Andersson]

After booting the wireless subsystem and uploading the NV blob to the
WCNSS_CTRL service the remote continues to do things and will not start
servicing wlan-requests for another 2-5 seconds (measured).

The downstream code does not have any special handling for this case,
but has a timeout of 10 seconds for the communication layer. By
extending the wcn36xx timeout to match this we follows the same flow for
the boot procedure and can successfully configure WiFi as wlan0 is
registered.

Signed-off-by: Bjorn Andersson 
---
 drivers/net/wireless/ath/wcn36xx/smd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h 
b/drivers/net/wireless/ath/wcn36xx/smd.h
index e6aadd273c46..6310560901f0 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -24,7 +24,7 @@
 
 #define WCN36XX_HAL_BUF_SIZE   4096
 
-#define HAL_MSG_TIMEOUT 500
+#define HAL_MSG_TIMEOUT 1
 #define WCN36XX_SMSM_WLAN_TX_ENABLE0x0400
 #define WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY   0x0200
 /* The PNO version info be contained in the rsp msg */
-- 
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

ATTACHMENT FROM: DR. CALEB MARTINS

[calebmartins]

ATTACHMENT FROM: DR. CALEB MARTINS

DR CALEB MARTINS.pdf
Description: Adobe PDF document

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Seth Forshee]

On Thu, Apr 21, 2016 at 10:13:14PM +0200, Anne Marcel Roorda wrote:
> 
> On 21 Apr 2016, Seth Forshee wrote:
> > On Thu, Apr 21, 2016 at 08:08:46PM +0200, Maximilian Engelhardt wrote:
> >
> >> The comments to my initial mail indicated that the statement in the ERC 
> >> recommendation I linked are alone not enough to add this frequency ranges 
> >> for 
> >> other countries. Unfortunately I don't have the possibility to do these 
> >> checks 
> >> for countries other than Germany.
> >
> >Yep, I understand and am in agreement. I know how challenging it can be
> >to try to track down this information.
> 
>   I could do the same for NL.

That would be great, if anything about the current rules is incorrect or
out of date.

>   At the moment entries for NL are listed as center frequencies
> (almost, 5490 - 5710 @ 160 should be 5550 - 5645 @ 160), while for DE
> the whole band is listed (5470 - 5725 @ 160).

There's no reason per se to limit it to only the range for currently
defined wifi channels if the regulatory body allows unlicensed use of a
wider range. But the rule should include the entire channel bandwith and
not stop at the center frequencies.

>   Power budget is listed in db while the law specifies mW.
> 
>   What is the prefered format, and would a rewrite for NL listing the band
> and power in mW be acceptable ?

It's a direct conversion between the dBm and mW values (in fact mW
values in the text database are converted to dBm values for the binary
database), so the units in the text file don't matter all that much. But
I don't really like changing the units just for the sake of changing
them when the values are already correct; there's always the chance that
some mistake will slip in.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Anne Marcel Roorda]

On 21 Apr 2016, Seth Forshee wrote:
> On Thu, Apr 21, 2016 at 08:08:46PM +0200, Maximilian Engelhardt wrote:
>
>> The comments to my initial mail indicated that the statement in the ERC 
>> recommendation I linked are alone not enough to add this frequency ranges 
>> for 
>> other countries. Unfortunately I don't have the possibility to do these 
>> checks 
>> for countries other than Germany.
>
>Yep, I understand and am in agreement. I know how challenging it can be
>to try to track down this information.

  I could do the same for NL.

  At the moment entries for NL are listed as center frequencies
(almost, 5490 - 5710 @ 160 should be 5550 - 5645 @ 160), while for DE
the whole band is listed (5470 - 5725 @ 160).

  Power budget is listed in db while the law specifies mW.

  What is the prefered format, and would a rewrite for NL listing the band
and power in mW be acceptable ?

Thanks,

- 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

Re: wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Seth Forshee]

On Thu, Apr 21, 2016 at 08:08:46PM +0200, Maximilian Engelhardt wrote:
> On Thursday 21 April 2016 08:19:38 Seth Forshee wrote:
> > On Tue, Apr 19, 2016 at 08:03:16PM +0200, Maximilian Engelhardt wrote:
> > > Hi,
> > > 
> > > In Europe ETSI standardized the used for short range devices (SRD) [1] in
> > > ETSI EN 300 440-1 [2].
> > > According to this standard generic use equipment is allowed to transmit in
> > > the frequency range form 5725 MHz to 5875 MHz with a maximum output power
> > > of 25 mW e.i.r.p. This generic allocation also allows transmission of
> > > 802.11 devices.
> > > 
> > > [3] has a list of countries and their status about the implementation of
> > > the SRD frequency bands. For the 5 GHz band this can be seen on page 38
> > > in the paragraph ANNEX 1 and the entry Annex j.
> > > 
> > > Attached is a patch that adds the 5 GHz SRD band to db.txt for Germany.
> > > 
> > > If it is acceptable I can provide a patch adding the 5 GHz SRD band for
> > > the
> > > other countries listed in [3].
> > 
> > The changes seem okay as far as I can tell. You do need to include your
> > signed-off-by tag on the patch however, see
> > https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/tre
> > e/CONTRIBUTING.
> > 
> > Thanks,
> > Seth
> 
> Hi Seth,
> 
> Thanks for your reply. You can find my signed-off-by tag below together with 
> the unchanged patch.

Thanks, that will work. I'll leave it for a few days and see if anyone
else has comments.

> I can affirm I did check this carefully with the official documents of the 
> German administration for radio equipment (Bundesnetzagentur für 
> Elektrizität, 
> Gas, Telekommunikation, Post und Eisenbahnen).
> 
> I noticed that the links to the other entries for Germany are broken, as the 
> website design was changed and thus all old link became non functional. I can 
> provide a patch fixing this if it is something that's considered useful.

Yes, that would be useful, so please do.

> The comments to my initial mail indicated that the statement in the ERC 
> recommendation I linked are alone not enough to add this frequency ranges for 
> other countries. Unfortunately I don't have the possibility to do these 
> checks 
> for countries other than Germany.

Yep, I understand and am in agreement. I know how challenging it can be
to try to track down this information.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Maximilian Engelhardt]

On Thursday 21 April 2016 08:19:38 Seth Forshee wrote:
> On Tue, Apr 19, 2016 at 08:03:16PM +0200, Maximilian Engelhardt wrote:
> > Hi,
> > 
> > In Europe ETSI standardized the used for short range devices (SRD) [1] in
> > ETSI EN 300 440-1 [2].
> > According to this standard generic use equipment is allowed to transmit in
> > the frequency range form 5725 MHz to 5875 MHz with a maximum output power
> > of 25 mW e.i.r.p. This generic allocation also allows transmission of
> > 802.11 devices.
> > 
> > [3] has a list of countries and their status about the implementation of
> > the SRD frequency bands. For the 5 GHz band this can be seen on page 38
> > in the paragraph ANNEX 1 and the entry Annex j.
> > 
> > Attached is a patch that adds the 5 GHz SRD band to db.txt for Germany.
> > 
> > If it is acceptable I can provide a patch adding the 5 GHz SRD band for
> > the
> > other countries listed in [3].
> 
> The changes seem okay as far as I can tell. You do need to include your
> signed-off-by tag on the patch however, see
> https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/tre
> e/CONTRIBUTING.
> 
> Thanks,
> Seth

Hi Seth,

Thanks for your reply. You can find my signed-off-by tag below together with 
the unchanged patch.

I can affirm I did check this carefully with the official documents of the 
German administration for radio equipment (Bundesnetzagentur für Elektrizität, 
Gas, Telekommunikation, Post und Eisenbahnen).

I noticed that the links to the other entries for Germany are broken, as the 
website design was changed and thus all old link became non functional. I can 
provide a patch fixing this if it is something that's considered useful.


The comments to my initial mail indicated that the statement in the ERC 
recommendation I linked are alone not enough to add this frequency ranges for 
other countries. Unfortunately I don't have the possibility to do these checks 
for countries other than Germany.

If there is anything I can do to help adding the SRD entries for more 
countries please let me know.

Thanks,
Maxi


Signed-off-by: Maximilian Engelhardt 
--

diff --git a/db.txt b/db.txt
index e9ba21a..38a9340 100644
--- a/db.txt
+++ b/db.txt
@@ -319,6 +319,9 @@ country CZ: DFS-ETSI
 # limit is used here as the non-interference with radar and satellite
 # apps relies on the attenuation by the building walls only in the
 # absence of DFS; the neighbour countries have 100mW limit here as well.
+# The ETSI EN 300 440-1 standard for short range devices in the 5 GHz band has
+# been implemented in Germany:
+# 
https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2014_69_SRD_pdf.pdf
 
 country DE: DFS-ETSI
# entries 279004 and 280006
@@ -329,6 +332,8 @@ country DE: DFS-ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
# entries 308002, 309001 and 310003
(5470 - 5725 @ 160), (500 mW), DFS
+   # short range devices (ETSI EN 300 440-1)
+   (5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Ben Greear]

On 04/21/2016 06:17 AM, Kalle Valo wrote:

From: Johannes Berg 

According to the spec, VHT doesn't exist in 2.4GHz.

There are vendor extensions to allow a subset of VHT to work
(notably 256-QAM), but since mac80211 doesn't support those
advertising VHT capability on 2.4GHz leads to the behaviour
of reporting VHT capabilities but not being able to use any
of them due to mac80211's code requiring 80 MHz support.

Remove the VHT capabilities from 2.4GHz for now. If mac80211
gets extended to use the (likely Broadcom) vendor IEs for it
and handles the lack of 80 MHz support, it can be added back.

Signed-off-by: Johannes Berg 
Signed-off-by: Kalle Valo 


The thing is, it actually works just fine with the patch I posted
to fix mac80211, and at any rate, even if the mac80211 patch isn't
applied, the ath10k driver works just fine in HT mode.

Have you actually found any case where the existing behaviour causes
a real problem?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

--
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/3] mwifiex: report wowlan wakeup reasons correctly

[Amitkumar Karwar]

It's been observed that wakeup on GTK rekey failure wasn't reported
to cfg80211. This patch corrects the check so that all valid wakeup
reasons are reported.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 369ea06..734cf67 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3344,6 +3344,7 @@ static int mwifiex_cfg80211_resume(struct wiphy *wiphy)
struct mwifiex_ds_wakeup_reason wakeup_reason;
struct cfg80211_wowlan_wakeup wakeup_report;
int i;
+   bool report_wakeup_reason = true;
 
for (i = 0; i < adapter->priv_num; i++) {
priv = adapter->priv[i];
@@ -3386,20 +3387,16 @@ static int mwifiex_cfg80211_resume(struct wiphy *wiphy)
if (wiphy->wowlan_config->n_patterns)
wakeup_report.pattern_idx = 1;
break;
-   case CONTROL_FRAME_MATCHED:
-   break;
-   case MANAGEMENT_FRAME_MATCHED:
-   break;
case GTK_REKEY_FAILURE:
if (wiphy->wowlan_config->gtk_rekey_failure)
wakeup_report.gtk_rekey_failure = true;
break;
default:
+   report_wakeup_reason = false;
break;
}
 
-   if ((wakeup_reason.hs_wakeup_reason > 0) &&
-   (wakeup_reason.hs_wakeup_reason <= 7))
+   if (report_wakeup_reason)
cfg80211_report_wowlan_wakeup(>wdev, _report,
  GFP_KERNEL);
 
-- 
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 3/3] mwifiex: avoid querying wakeup reason when wowlan is disabled

[Amitkumar Karwar]

In cfg80211 resume handler, we query wakeup reason from firmware and
report to cfg80211. if wowlan is disabled, connection is already
terminated during suspend. We don't need to query wakeup reason in this
case.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 734cf67..ff948a9 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3355,6 +3355,9 @@ static int mwifiex_cfg80211_resume(struct wiphy *wiphy)
}
}
 
+   if (!wiphy->wowlan_config)
+   goto done;
+
priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA);
mwifiex_get_wakeup_reason(priv, HostCmd_ACT_GEN_GET, MWIFIEX_SYNC_CMD,
  _reason);
@@ -3400,6 +3403,7 @@ static int mwifiex_cfg80211_resume(struct wiphy *wiphy)
cfg80211_report_wowlan_wakeup(>wdev, _report,
  GFP_KERNEL);
 
+done:
if (adapter->nd_info) {
for (i = 0 ; i < adapter->nd_info->n_matches ; i++)
kfree(adapter->nd_info->matches[i]);
-- 
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 1/3] mwifiex: fix coding style

[Amitkumar Karwar]

Redundant space in case statement is removed.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 6db202f..369ea06 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3388,7 +3388,7 @@ static int mwifiex_cfg80211_resume(struct wiphy *wiphy)
break;
case CONTROL_FRAME_MATCHED:
break;
-   caseMANAGEMENT_FRAME_MATCHED:
+   case MANAGEMENT_FRAME_MATCHED:
break;
case GTK_REKEY_FAILURE:
if (wiphy->wowlan_config->gtk_rekey_failure)
-- 
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

Re: [PATCH v7 1/2] dt: bindings: add MARVELL's sd8xxx wireless device

[Rob Herring]

On Mon, Apr 18, 2016 at 05:22:22AM -0700, Amitkumar Karwar wrote:
> From: Xinming Hu 
> 
> Add device tree binding documentation for MARVELL's sd8xxx
> (sd8897 and sd8997) wlan chip.
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 
> ---
> Listing changelist for both 1/2 and 2/2 patches
> v3: Don't update adapter->dt_node if mwifiex_plt_dev is NULL
> 
> v4: a)Corrected the 'name' and 'compatible' property names.(Arnd Bergmann and 
> Rob
> Herring)
> b)Patch description wraped in 72 columns(Rob Herring)
> c)Moved DT binding file to bindings/net/wireless/(Rob Herring)
> d)Renamed "mwifiex,chip-gpio" to "marvell,wakeup-gpios"(Rob Herring/
> Arnd Bergmann)
> e)Replaced #ifdef with __maybe_unused(Arnd Bergmann)
> 
> v5: a)Removed wildcards from compatible string(Arnd Bergmann)
> b)Prepared single patch for all binding changes(Rob Herring)
> c)Specified our node as a subnode of SDIO controller. With this approach, 
> we
> don't need to register new platform driver. (Rob herring)
> 
> v6: a)List out the specific property names for marvell,caldata* and size of 
> the data(Rob Herring)
> b)Use sdio function number for both the unit address and reg(Rob Herring)
> 
> v7: a)Use suggested specific marvell,caldata property name and generic node 
> name(Rob Herring)
> ---
>  .../bindings/net/wireless/marvell-sd8xxx.txt   | 63 
> ++
>  1 file changed, 63 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt

Acked-by: Rob Herring 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless-regdb: Update regulatory rules for Germany (DE) on 5GHz

[Seth Forshee]

On Tue, Apr 19, 2016 at 08:03:16PM +0200, Maximilian Engelhardt wrote:
> Hi,
> 
> In Europe ETSI standardized the used for short range devices (SRD) [1] in 
> ETSI 
> EN 300 440-1 [2].
> According to this standard generic use equipment is allowed to transmit in 
> the 
> frequency range form 5725 MHz to 5875 MHz with a maximum output power of 
> 25 mW e.i.r.p. This generic allocation also allows transmission of 802.11 
> devices.
> 
> [3] has a list of countries and their status about the implementation of the 
> SRD frequency bands. For the 5 GHz band this can be seen on page 38 in the 
> paragraph ANNEX 1 and the entry Annex j.
> 
> Attached is a patch that adds the 5 GHz SRD band to db.txt for Germany.
> 
> If it is acceptable I can provide a patch adding the 5 GHz SRD band for the 
> other countries listed in [3].

The changes seem okay as far as I can tell. You do need to include your
signed-off-by tag on the patch however, see
https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/tree/CONTRIBUTING.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Kalle Valo]

From: Johannes Berg 

According to the spec, VHT doesn't exist in 2.4GHz.

There are vendor extensions to allow a subset of VHT to work
(notably 256-QAM), but since mac80211 doesn't support those
advertising VHT capability on 2.4GHz leads to the behaviour
of reporting VHT capabilities but not being able to use any
of them due to mac80211's code requiring 80 MHz support.

Remove the VHT capabilities from 2.4GHz for now. If mac80211
gets extended to use the (likely Broadcom) vendor IEs for it
and handles the lack of 80 MHz support, it can be added back.

Signed-off-by: Johannes Berg 
Signed-off-by: Kalle Valo 
---

v2:

* Cc ath...@lists.infradead.org

 drivers/net/wireless/ath/ath10k/mac.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index bcf025f51310..d2a852805b07 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4276,9 +4276,6 @@ static void ath10k_mac_setup_ht_vht_cap(struct ath10k *ar)
if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY) {
band = >mac.sbands[NL80211_BAND_2GHZ];
band->ht_cap = ht_cap;
-
-   /* Enable the VHT support at 2.4 GHz */
-   band->vht_cap = vht_cap;
}
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
band = >mac.sbands[NL80211_BAND_5GHZ];
-- 
1.7.9.5

--
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] ath10k: remove VHT capabilities from 2.4GHz

[Kalle Valo]

Johannes Berg  writes:

> From: Johannes Berg 
>
> According to the spec, VHT doesn't exist in 2.4GHz.
>
> There are vendor extensions to allow a subset of VHT to work
> (notably 256-QAM), but since mac80211 doesn't support those
> advertising VHT capability on 2.4GHz leads to the behaviour
> of reporting VHT capabilities but not being able to use any
> of them due to mac80211's code requiring 80 MHz support.
>
> Remove the VHT capabilities from 2.4GHz for now. If mac80211
> gets extended to use the (likely Broadcom) vendor IEs for it
> and handles the lack of 80 MHz support, it can be added back.
>
> Signed-off-by: Johannes Berg 

I'll resend this and CC ath10k list.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rtl8xxxu: hide unused tables

[Kalle Valo]

> The references to some arrays in the rtl8xxxu driver were moved inside
> of an #ifdef, but the symbols remain outside, resulting in build warnings:
> 
> rtl8xxxu/rtl8xxxu.c:1506:33: error: 'rtl8188ru_radioa_1t_highpa_table' 
> defined but not used
> rtl8xxxu/rtl8xxxu.c:1431:33: error: 'rtl8192cu_radioa_1t_init_table' defined 
> but not used
> rtl8xxxu/rtl8xxxu.c:1407:33: error: 'rtl8192cu_radiob_2t_init_table' defined 
> but not used
> rtl8xxxu/rtl8xxxu.c:1332:33: error: 'rtl8192cu_radioa_2t_init_table' defined 
> but not used
> rtl8xxxu/rtl8xxxu.c:239:35: error: 'rtl8192c_power_base' defined but not used
> rtl8xxxu/rtl8xxxu.c:217:35: error: 'rtl8188r_power_base' defined but not used
> 
> This adds an extra #ifdef around them to shut up the warnings.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 2fc0b8e5a17d ("rtl8xxxu: Add TX power base values for gen1 parts")
> Fixes: 4062b8ffec36 ("rtl8xxxu: Move PHY RF init into device specific 
> functions")

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi 2016-04-12

[Kalle Valo]

"Grumbach, Emmanuel"  writes:

> On Tue, 2016-04-12 at 11:14 +0300, Emmanuel Grumbach wrote:
>> Hi Kalle,
>> 
>> I have here a pull request for 4.6. There is patch in this pull
>> request
>> that has been sent to -next already but should really have been
>> included in the current cycle. Sorry for the mess.
>> 
>> The commit appears in -next as:
>> 
>> commit a0b09f13036cedfd67c9cb4b9d05138e7022723d
>> Author: Ayala Beker 
>> Date:   Wed Feb 3 15:36:52 2016 +0200
>> 
>> iwlwifi: mvm: update GSCAN capabilities
>> 
>> Gscan capabilities were updated with new capabilities supported
>> by the device. Update GSCAN capabilities TLV.
>> 
>> I modified the commit message to better emphasis the need to have it
>> in
>> the current release. You'll see it in this pull request as:
>> 
>> commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
>> Author: Ayala Beker 
>> Date:   Wed Feb 3 15:36:52 2016 +0200
>> 
>> iwlwifi: mvm: avoid to WARN about gscan capabilities
>> 
>> Gscan capabilities were updated with new capabilities supported
>> by the device. Update GSCAN capabilities TLV and avoid to WARN
>> if the firmware does not have the new capabilities.
>> 
>> Besides this, all is fairly normal.
>> Please pull, thanks!
>> 
>> 
>> The following changes since commit
>> 7fdf9663261cc77a516396fec82cee8a8ea07e76:
>> 
>>   iwlwifi: mvm: fix memory leak in paging (2016-03-20 23:01:54 +0200)
>> 
>> are available in the git repository at:
>> 
>>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fix
>> es.git tags/iwlwifi-for-kalle-2016-04-12
>> 
>> for you to fetch changes up to
>> 2d25fb8b3a138706b63bd26ad72a95c58029954a:
>> 
>>   iwlwifi: mvm: fix accessing Null pointer during fw dump collection
>> (2016-04-12 10:03:17 +0300)
>> 
>
> Sara found an embarrassing last minute issue.
> New tag is iwlwifi-for-kalle-2016-04-12_2.

Pulled, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi 2016-04-12

[Valo, Kalle]

Kalle Valo  writes:

> "Grumbach, Emmanuel"  writes:
>
>> I have here a pull request for 4.6. There is patch in this pull request
>> that has been sent to -next already but should really have been
>> included in the current cycle. Sorry for the mess.
>>
>> The commit appears in -next as:
>>
>> commit a0b09f13036cedfd67c9cb4b9d05138e7022723d
>> Author: Ayala Beker 
>> Date:   Wed Feb 3 15:36:52 2016 +0200
>>
>> iwlwifi: mvm: update GSCAN capabilities
>> 
>> Gscan capabilities were updated with new capabilities supported
>> by the device. Update GSCAN capabilities TLV.
>>
>> I modified the commit message to better emphasis the need to have it in
>> the current release. You'll see it in this pull request as:
>>
>> commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
>> Author: Ayala Beker 
>> Date:   Wed Feb 3 15:36:52 2016 +0200
>>
>> iwlwifi: mvm: avoid to WARN about gscan capabilities
>> 
>> Gscan capabilities were updated with new capabilities supported
>> by the device. Update GSCAN capabilities TLV and avoid to WARN
>> if the firmware does not have the new capabilities.
>
> I feel uneasy having the same commit on both trees, but that might just
> me. Dave, how do you suggest to handle cases like this when we want to
> get a fix from -next to the current release -rc release?

Dave replied privately that this is ok. So I'll pull this shortly.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] wlcore: spi: add wl18xx support

[Mark Brown]

On Thu, Apr 21, 2016 at 11:07:37AM +, Reizer, Eyal wrote:

> * (i) If the transfer isn't the last one in the message, this flag is
> * used to make the chipselect briefly go inactive in the middle of the
> * message.  Toggling chipselect in this way may be needed to terminate
> * a chip command, letting a single spi_message perform all of group of
> * chip transactions together.

> Now, in my case I need the CS pin to go inactive and stay inactive during the 
> transfer 
> of the next byte for completing the SPI init correctly (sending the extra 
> clock cycles while CS is inactive)
> If I read the above correctly, CS will only briefly go inactive but will when 
> the next byte 
> is sent it will be active again.
> What am I missing?

No, it changes the state.  The main use case is a brief bounce but
you can use it for other things.


signature.asc
Description: PGP signature

RE: [PATCHv2] wlcore: spi: add wl18xx support

[Reizer, Eyal]

> 
> > Thanks! Glad the illustration helped.
> > I will try it out again as if i recall cotrectly, i did try that l, and it 
> > didnt produce
> the correct waveform, but perhaps i didnt understand the usage of
> .cs_change correctly.
> > Will double check anyway.
> 
> It could also be a bug in your controller driver, it's common for them to not
> handle cs_change correctly (at least those that open code the message loop,
> obviously modern ones just factor this out into the core).

Tried looking into using cs_change and not sure I understand how it would do 
what I need.
According to, include/linux/spi/spi.h:

* All SPI transfers start with the relevant chipselect active.  Normally
* it stays selected until after the last transfer in a message.  Drivers
* can affect the chipselect signal using cs_change.
*
* (i) If the transfer isn't the last one in the message, this flag is
* used to make the chipselect briefly go inactive in the middle of the
* message.  Toggling chipselect in this way may be needed to terminate
* a chip command, letting a single spi_message perform all of group of
* chip transactions together.

Now, in my case I need the CS pin to go inactive and stay inactive during the 
transfer 
of the next byte for completing the SPI init correctly (sending the extra clock 
cycles while CS is inactive)
If I read the above correctly, CS will only briefly go inactive but will when 
the next byte 
is sent it will be active again.
What am I missing?

Best Regards,
Eyal

Re: [PATCH v2] rt2800lib: enable MFP if hw crypt is disabled

[Stanislaw Gruszka]

On Thu, Apr 21, 2016 at 12:41:34AM +0800, Chun-Yeow Yeoh wrote:
> If rt2800usb is loaded with nohwcrypt=1, mac80211 takes
> care of the crypto with software encryption/decryption
> and thus, MFP can be used.
> 
> Tested for secured mesh using ath9k_htc and ath9k.
> 
> Signed-off-by: Chun-Yeow Yeoh 

Acked-by: Stanislaw Gruszka 
--
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