Re: [PATCH 0/3] Add mcast event when hwsim radios are created and removed

[Luca Coelho]

On Mon, 2014-10-27 at 16:14 -0700, Marcel Holtmann wrote:
> Hi Luca,

Hi Marcel,


> > That's not particularly hard to figure out, for example by looking at
> > sysfs.
> > 
> > Is this really so time-constrained/important/... that you can't do that?
>  
>  It does not seem very practical to dig this information from sysfs as
>  the same information can be easily get via netlink as this patch shows.
> >>> 
> >>> Well, that's a slippery slope. I'd consider it more practical to use
> >>> existing APIs instead of (gratuitously) inventing new ones. It'll even
> >>> work on older kernels as an added benefit.
> >> 
> >> I see that different. The component that handles the emulation of the new 
> >> wireless device should be independent from the component driving it. I 
> >> prefer to have a race free way of obtaining the needed information without 
> >> having to monitor nl80211 and sysfs for this. Especially with the use 
> >> cases that we have in mind it has no business with these other interfaces.
> >> 
> >> We have been down this route with the bridge interface where people had to 
> >> dig out information from sysfs and it did not work out nicely. So now 
> >> everything moves to netlink.
> > 
> > Why does hwsim have to be treated differently from any other device?
> > Unlike bridging, HW emulation doesn't seem to be a real life use case.
> > 
> > But I'm probably missing something. ;)
> 
> this is the controlling side. The thing that I call emulator. It is the 
> component that creates/destroys the hwsim wiphy. It can also be the one that 
> handles the packet processing similar to wmediumd.
> 
> The nl80211/cfg80211 is not treated differently here. This is purely for the 
> MAC80211_HWSIM netlink family side of things. Makes sense?

Ah, okay, I was confused.  Makes total sense to me then, I don't see why
we shouldn't have this API to provide the needed information totally
independently from nl80211.

--
Luca.

--
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.16 0/7] Backort firmware monitor to 3.16

[Greg KH]

On Tue, Oct 28, 2014 at 08:11:19AM +0200, Emmanuel Grumbach wrote:
> This patch series allows to use the firmware debugging features
> of iwlwifi on 3.16. These features are already in 3.17.
> 
> I know that this patch series is not compliant with Greg's
> rules for stable patches. It is unlikely that these patches
> will be applied on vanilla 3.16 - I know that.

Good, because I just released the last 3.16-stable-rc kernel, so even if
I wanted to, I wouldn't take these :)

thanks,

greg k-h
--
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.16 2/7] iwlwifi: rename iwl_mvm_fw_error_next_data

[Emmanuel Grumbach]

commit 1fa1605648d15d42f350807279b6c6e8d33b6382 upstream.

This is not related to mvm. Rename to iwl_fw_error_next_data.

Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h | 4 ++--
 drivers/net/wireless/iwlwifi/mvm/ops.c   | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h 
b/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
index aa0f85e..3584a75 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
@@ -145,12 +145,12 @@ struct iwl_fw_error_dump_info {
 } __packed;
 
 /**
- * iwl_mvm_fw_error_next_data - advance fw error dump data pointer
+ * iwl_fw_error_next_data - advance fw error dump data pointer
  * @data: previous data block
  * Returns: next data block
  */
 static inline struct iwl_fw_error_dump_data *
-iwl_mvm_fw_error_next_data(struct iwl_fw_error_dump_data *data)
+iwl_fw_error_next_data(struct iwl_fw_error_dump_data *data)
 {
return (void *)(data->data + le32_to_cpu(data->len));
 }
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c 
b/drivers/net/wireless/iwlwifi/mvm/ops.c
index d2fdd9f..2910f6d 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -869,12 +869,12 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
strncpy(dump_info->bus_human_readable, mvm->dev->bus->name,
sizeof(dump_info->bus_human_readable));
 
-   dump_data = iwl_mvm_fw_error_next_data(dump_data);
+   dump_data = iwl_fw_error_next_data(dump_data);
dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_RXF);
dump_data->len = cpu_to_le32(mvm->fw_error_rxf_len);
memcpy(dump_data->data, mvm->fw_error_rxf, mvm->fw_error_rxf_len);
 
-   dump_data = iwl_mvm_fw_error_next_data(dump_data);
+   dump_data = iwl_fw_error_next_data(dump_data);
dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_SRAM);
dump_data->len = cpu_to_le32(mvm->fw_error_sram_len);
 
@@ -894,7 +894,7 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
mvm->fw_error_sram_len = 0;
 
if (trans_len) {
-   void *buf = iwl_mvm_fw_error_next_data(dump_data);
+   void *buf = iwl_fw_error_next_data(dump_data);
u32 real_trans_len = iwl_trans_dump_data(mvm->trans, buf,
 trans_len);
dump_data = (void *)((u8 *)buf + real_trans_len);
-- 
1.9.1

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

[PATCH 3.16 1/7] iwlwifi: add device / firmware to fw-error-dump file

[Emmanuel Grumbach]

commit 06ddbf5adac1fd2a031eade8a92239abfa6db93a upstream.

This can be useful later for parsing since the parsing may
differ based on the device's family / bus.
Also add the human readable version of the firmware.

Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/iwl-drv.c   |  2 ++
 drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h | 24 
 drivers/net/wireless/iwlwifi/iwl-fw-file.h   |  5 +++--
 drivers/net/wireless/iwlwifi/iwl-fw.h|  3 +++
 drivers/net/wireless/iwlwifi/mvm/ops.c   | 24 +---
 5 files changed, 53 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/iwlwifi/iwl-drv.c
index f2a5c12..2967fce 100644
--- a/drivers/net/wireless/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/iwlwifi/iwl-drv.c
@@ -565,6 +565,8 @@ static int iwl_parse_tlv_firmware(struct iwl_drv *drv,
}
 
drv->fw.ucode_ver = le32_to_cpu(ucode->ver);
+   memcpy(drv->fw.human_readable, ucode->human_readable,
+  sizeof(drv->fw.human_readable));
build = le32_to_cpu(ucode->build);
 
if (build)
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h 
b/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
index 2953ffc..aa0f85e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
@@ -74,12 +74,15 @@
  * @IWL_FW_ERROR_DUMP_RXF:
  * @IWL_FW_ERROR_DUMP_TXCMD: last TX command data, structured as
  * &struct iwl_fw_error_dump_txcmd packets
+ * @IWL_FW_ERROR_DUMP_DEV_FW_INFO:  struct %iwl_fw_error_dump_info
+ * info on the device / firmware.
  */
 enum iwl_fw_error_dump_type {
IWL_FW_ERROR_DUMP_SRAM = 0,
IWL_FW_ERROR_DUMP_REG = 1,
IWL_FW_ERROR_DUMP_RXF = 2,
IWL_FW_ERROR_DUMP_TXCMD = 3,
+   IWL_FW_ERROR_DUMP_DEV_FW_INFO = 4,
 
IWL_FW_ERROR_DUMP_MAX,
 };
@@ -120,6 +123,27 @@ struct iwl_fw_error_dump_txcmd {
u8 data[];
 } __packed;
 
+enum iwl_fw_error_dump_family {
+   IWL_FW_ERROR_DUMP_FAMILY_7 = 7,
+   IWL_FW_ERROR_DUMP_FAMILY_8 = 8,
+};
+
+/**
+ * struct iwl_fw_error_dump_info - info on the device / firmware
+ * @device_family: the family of the device (7 / 8)
+ * @hw_step: the step of the device
+ * @fw_human_readable: human readable FW version
+ * @dev_human_readable: name of the device
+ * @bus_human_readable: name of the bus used
+ */
+struct iwl_fw_error_dump_info {
+   __le32 device_family;
+   __le32 hw_step;
+   u8 fw_human_readable[FW_VER_HUMAN_READABLE_SZ];
+   u8 dev_human_readable[64];
+   u8 bus_human_readable[8];
+} __packed;
+
 /**
  * iwl_mvm_fw_error_next_data - advance fw error dump data pointer
  * @data: previous data block
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw-file.h 
b/drivers/net/wireless/iwlwifi/iwl-fw-file.h
index b45e576..dc1b913 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw-file.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw-file.h
@@ -136,7 +136,8 @@ struct iwl_ucode_tlv {
u8 data[0];
 };
 
-#define IWL_TLV_UCODE_MAGIC0x0a4c5749
+#define IWL_TLV_UCODE_MAGIC0x0a4c5749
+#define FW_VER_HUMAN_READABLE_SZ   64
 
 struct iwl_tlv_ucode_header {
/*
@@ -147,7 +148,7 @@ struct iwl_tlv_ucode_header {
 */
__le32 zero;
__le32 magic;
-   u8 human_readable[64];
+   u8 human_readable[FW_VER_HUMAN_READABLE_SZ];
__le32 ver; /* major/minor/API/serial */
__le32 build;
__le64 ignore;
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw.h 
b/drivers/net/wireless/iwlwifi/iwl-fw.h
index b1a3332..663a91a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw.h
@@ -65,6 +65,8 @@
 #include 
 #include 
 
+#include "iwl-fw-file.h"
+
 /**
  * enum iwl_ucode_tlv_flag - ucode API flags
  * @IWL_UCODE_TLV_FLAGS_PAN: This is PAN capable microcode; this previously
@@ -312,6 +314,7 @@ struct iwl_fw {
bool mvm_fw;
 
struct ieee80211_cipher_scheme cs[IWL_UCODE_MAX_CS];
+   u8 human_readable[FW_VER_HUMAN_READABLE_SZ];
 };
 
 #endif  /* __iwl_fw_h__ */
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c 
b/drivers/net/wireless/iwlwifi/mvm/ops.c
index cc2f7de..d2fdd9f 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -826,6 +826,7 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
 {
struct iwl_fw_error_dump_file *dump_file;
struct iwl_fw_error_dump_data *dump_data;
+   struct iwl_fw_error_dump_info *dump_info;
u32 file_len;
u32 trans_len;
 
@@ -834,10 +835,11 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
if (mvm->fw_error_dump)
return;
 
-   file_len = mvm->fw_error_sram_len +
+   file_len = sizeof(*dump_file) +
+  sizeof(*dump_data) * 3 +
+  mvm->fw_error_sram_len +
   mvm->fw_err

[PATCH 3.16 7/7] iwlwifi: mvm: update layout of firmware error dump

[Emmanuel Grumbach]

commit 5bfe6f53283de44855ee45a102210abbfac995f9 upstream.

The memory was not zeroed - fix that. Also update the
iwl_fw_error_dump_info structure.

Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/mac80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index ed10e55..83ab42a 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -678,7 +678,7 @@ static void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
if (trans_len)
file_len += trans_len;
 
-   dump_file = vmalloc(file_len);
+   dump_file = vzalloc(file_len);
if (!dump_file)
return;
 
-- 
1.9.1

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

[PATCH 3.16 0/7] Backort firmware monitor to 3.16

[Emmanuel Grumbach]

This patch series allows to use the firmware debugging features
of iwlwifi on 3.16. These features are already in 3.17.

I know that this patch series is not compliant with Greg's
rules for stable patches. It is unlikely that these patches
will be applied on vanilla 3.16 - I know that.
I send them here so that distros can apply them if they want
to.
I know there are distros shipping 3.16, and having these
patches in can greatly help our ability to debug nasty
issues.

Emmanuel Grumbach (7):
  iwlwifi: add device / firmware to fw-error-dump file
  iwlwifi: rename iwl_mvm_fw_error_next_data
  iwlwifi: pcie: add firmware monitor capabilities
  iwlwifi: remove wrong comment about alignment in iwl-fw-error-dump.h
  iwlwifi: mvm: don't collect logs in the interrupt thread
  iwlwifi: mvm: kill iwl_mvm_fw_error_rxf_dump
  iwlwifi: mvm: update layout of firmware error dump

 drivers/net/wireless/iwlwifi/iwl-drv.c   |   6 ++
 drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h |  50 -
 drivers/net/wireless/iwlwifi/iwl-fw-file.h   |   5 +-
 drivers/net/wireless/iwlwifi/iwl-fw.h|   3 +
 drivers/net/wireless/iwlwifi/iwl-modparams.h |   2 +
 drivers/net/wireless/iwlwifi/iwl-prph.h  |   6 ++
 drivers/net/wireless/iwlwifi/mvm/mac80211.c  | 100 ++
 drivers/net/wireless/iwlwifi/mvm/mvm.h   |   9 --
 drivers/net/wireless/iwlwifi/mvm/ops.c   |  72 -
 drivers/net/wireless/iwlwifi/mvm/utils.c |  65 
 drivers/net/wireless/iwlwifi/pcie/internal.h |   7 ++
 drivers/net/wireless/iwlwifi/pcie/trans.c| 125 ++-
 12 files changed, 294 insertions(+), 156 deletions(-)

-- 
1.9.1

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

[PATCH 3.16 3/7] iwlwifi: pcie: add firmware monitor capabilities

[Emmanuel Grumbach]

commit c2d202017da18ebd6567862bd9a50392970f048f upstream

This allows to use the firmware monitor. This capability
uses a lot of contiguous memory (up to 64MB), so make its
usage module parameter dependent.

The driver will try to allocate as much contiguous memory
as possible downgrading its requirements until the
allocation succeeds.

Dump this data into the fw-error dump file when an error
happens.

Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/iwl-drv.c   |   4 +
 drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h |  18 
 drivers/net/wireless/iwlwifi/iwl-modparams.h |   2 +
 drivers/net/wireless/iwlwifi/iwl-prph.h  |   6 ++
 drivers/net/wireless/iwlwifi/pcie/internal.h |   7 ++
 drivers/net/wireless/iwlwifi/pcie/trans.c| 125 ++-
 6 files changed, 158 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/iwlwifi/iwl-drv.c
index 2967fce..32e334a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/iwlwifi/iwl-drv.c
@@ -1396,3 +1396,7 @@ module_param_named(power_level, 
iwlwifi_mod_params.power_level,
int, S_IRUGO);
 MODULE_PARM_DESC(power_level,
 "default power save level (range from 1 - 5, default: 1)");
+
+module_param_named(fw_monitor, iwlwifi_mod_params.fw_monitor, bool, S_IRUGO);
+MODULE_PARM_DESC(fw_monitor,
+"firmware monitor - to debug FW (default: false - needs lots 
of memory)");
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h 
b/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
index 3584a75..ced5ba9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
@@ -76,6 +76,7 @@
  * &struct iwl_fw_error_dump_txcmd packets
  * @IWL_FW_ERROR_DUMP_DEV_FW_INFO:  struct %iwl_fw_error_dump_info
  * info on the device / firmware.
+ * @IWL_FW_ERROR_DUMP_FW_MONITOR: firmware monitor
  */
 enum iwl_fw_error_dump_type {
IWL_FW_ERROR_DUMP_SRAM = 0,
@@ -83,6 +84,7 @@ enum iwl_fw_error_dump_type {
IWL_FW_ERROR_DUMP_RXF = 2,
IWL_FW_ERROR_DUMP_TXCMD = 3,
IWL_FW_ERROR_DUMP_DEV_FW_INFO = 4,
+   IWL_FW_ERROR_DUMP_FW_MONITOR = 5,
 
IWL_FW_ERROR_DUMP_MAX,
 };
@@ -145,6 +147,22 @@ struct iwl_fw_error_dump_info {
 } __packed;
 
 /**
+ * struct iwl_fw_error_fw_mon - FW monitor data
+ * @fw_mon_wr_ptr: the position of the write pointer in the cyclic buffer
+ * @fw_mon_base_ptr: base pointer of the data
+ * @fw_mon_cycle_cnt: number of wrap arounds
+ * @reserved: for future use
+ * @data: captured data
+ */
+struct iwl_fw_error_fw_mon {
+   __le32 fw_mon_wr_ptr;
+   __le32 fw_mon_base_ptr;
+   __le32 fw_mon_cycle_cnt;
+   __le32 reserved[3];
+   u8 data[];
+} __packed;
+
+/**
  * iwl_fw_error_next_data - advance fw error dump data pointer
  * @data: previous data block
  * Returns: next data block
diff --git a/drivers/net/wireless/iwlwifi/iwl-modparams.h 
b/drivers/net/wireless/iwlwifi/iwl-modparams.h
index d051857..f2d39cb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-modparams.h
+++ b/drivers/net/wireless/iwlwifi/iwl-modparams.h
@@ -103,6 +103,7 @@ enum iwl_disable_11n {
  * @power_level: power level, default = 1
  * @debug_level: levels are IWL_DL_*
  * @ant_coupling: antenna coupling in dB, default = 0
+ * @fw_monitor: allow to use firmware monitor
  */
 struct iwl_mod_params {
int sw_crypto;
@@ -120,6 +121,7 @@ struct iwl_mod_params {
int ant_coupling;
char *nvm_file;
bool uapsd_disable;
+   bool fw_monitor;
 };
 
 #endif /* #__iwl_modparams_h__ */
diff --git a/drivers/net/wireless/iwlwifi/iwl-prph.h 
b/drivers/net/wireless/iwlwifi/iwl-prph.h
index 4997e27..47033a3 100644
--- a/drivers/net/wireless/iwlwifi/iwl-prph.h
+++ b/drivers/net/wireless/iwlwifi/iwl-prph.h
@@ -359,4 +359,10 @@ enum secure_load_status_reg {
 #define RXF_LD_FENCE_OFFSET_ADDR   (0xa00c10)
 #define RXF_FIFO_RD_FENCE_ADDR (0xa00c0c)
 
+/* FW monitor */
+#define MON_BUFF_BASE_ADDR (0xa03c3c)
+#define MON_BUFF_END_ADDR  (0xa03c40)
+#define MON_BUFF_WRPTR (0xa03c44)
+#define MON_BUFF_CYCLE_CNT (0xa03c48)
+
 #endif /* __iwl_prph_h__ */
diff --git a/drivers/net/wireless/iwlwifi/pcie/internal.h 
b/drivers/net/wireless/iwlwifi/pcie/internal.h
index 6c22b23..78f72c3 100644
--- a/drivers/net/wireless/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/iwlwifi/pcie/internal.h
@@ -260,6 +260,9 @@ iwl_pcie_get_scratchbuf_dma(struct iwl_txq *txq, int idx)
  * @wd_timeout: queue watchdog timeout (jiffies)
  * @reg_lock: protect hw register access
  * @cmd_in_flight: true when we have a host command in flight
+ * @fw_mon_phys: physical address of the buffer for the firmware monitor
+ * @fw_mon_page: points to the first page of the buffer for the firmware 
monitor
+ * @fw_mon_size: size of the buffer for 

[PATCH 3.16 6/7] iwlwifi: mvm: kill iwl_mvm_fw_error_rxf_dump

[Emmanuel Grumbach]

commit 655e6d6db21b0c0d411aef9d816816fb68b0496c upstream.

Its content can move to the caller.
While at it, move iwl_mvm_fw_error_rxf_dump to caller.

Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/mac80211.c | 100 
 drivers/net/wireless/iwlwifi/mvm/mvm.h  |   6 --
 drivers/net/wireless/iwlwifi/mvm/ops.c  |  83 ---
 drivers/net/wireless/iwlwifi/mvm/utils.c|  43 
 4 files changed, 100 insertions(+), 132 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 98556d0..ed10e55 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -80,6 +80,8 @@
 #include "fw-api-scan.h"
 #include "iwl-phy-db.h"
 #include "testmode.h"
+#include "iwl-fw-error-dump.h"
+#include "iwl-prph.h"
 
 static const struct ieee80211_iface_limit iwl_mvm_limits[] = {
{
@@ -637,6 +639,104 @@ static void iwl_mvm_cleanup_iterator(void *data, u8 *mac,
mvmvif->phy_ctxt = NULL;
 }
 
+#ifdef CONFIG_IWLWIFI_DEBUGFS
+static void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
+{
+   struct iwl_fw_error_dump_file *dump_file;
+   struct iwl_fw_error_dump_data *dump_data;
+   struct iwl_fw_error_dump_info *dump_info;
+   const struct fw_img *img;
+   u32 sram_len, sram_ofs;
+   u32 file_len, rxf_len;
+   unsigned long flags;
+   u32 trans_len;
+   int reg_val;
+
+   lockdep_assert_held(&mvm->mutex);
+
+   if (mvm->fw_error_dump)
+   return;
+
+   img = &mvm->fw->img[mvm->cur_ucode];
+   sram_ofs = img->sec[IWL_UCODE_SECTION_DATA].offset;
+   sram_len = img->sec[IWL_UCODE_SECTION_DATA].len;
+
+   /* reading buffer size */
+   reg_val = iwl_trans_read_prph(mvm->trans, RXF_SIZE_ADDR);
+   rxf_len = (reg_val & RXF_SIZE_BYTE_CNT_MSK) >> RXF_SIZE_BYTE_CND_POS;
+
+   /* the register holds the value divided by 128 */
+   rxf_len = rxf_len << 7;
+
+   file_len = sizeof(*dump_file) +
+  sizeof(*dump_data) * 3 +
+  sram_len +
+  rxf_len +
+  sizeof(*dump_info);
+
+   trans_len = iwl_trans_dump_data(mvm->trans, NULL, 0);
+   if (trans_len)
+   file_len += trans_len;
+
+   dump_file = vmalloc(file_len);
+   if (!dump_file)
+   return;
+
+   mvm->fw_error_dump = dump_file;
+
+   dump_file->barker = cpu_to_le32(IWL_FW_ERROR_DUMP_BARKER);
+   dump_file->file_len = cpu_to_le32(file_len);
+   dump_data = (void *)dump_file->data;
+
+   dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_DEV_FW_INFO);
+   dump_data->len = cpu_to_le32(sizeof(*dump_info));
+   dump_info = (void *) dump_data->data;
+   dump_info->device_family =
+   mvm->cfg->device_family == IWL_DEVICE_FAMILY_7000 ?
+   cpu_to_le32(IWL_FW_ERROR_DUMP_FAMILY_7) :
+   cpu_to_le32(IWL_FW_ERROR_DUMP_FAMILY_8);
+   memcpy(dump_info->fw_human_readable, mvm->fw->human_readable,
+  sizeof(dump_info->fw_human_readable));
+   strncpy(dump_info->dev_human_readable, mvm->cfg->name,
+   sizeof(dump_info->dev_human_readable));
+   strncpy(dump_info->bus_human_readable, mvm->dev->bus->name,
+   sizeof(dump_info->bus_human_readable));
+
+   dump_data = iwl_fw_error_next_data(dump_data);
+   dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_RXF);
+   dump_data->len = cpu_to_le32(rxf_len);
+
+   if (iwl_trans_grab_nic_access(mvm->trans, false, &flags)) {
+   u32 *rxf = (void *)dump_data->data;
+   int i;
+
+   for (i = 0; i < (rxf_len / sizeof(u32)); i++) {
+   iwl_trans_write_prph(mvm->trans,
+RXF_LD_FENCE_OFFSET_ADDR,
+i * sizeof(u32));
+   rxf[i] = iwl_trans_read_prph(mvm->trans,
+RXF_FIFO_RD_FENCE_ADDR);
+   }
+   iwl_trans_release_nic_access(mvm->trans, &flags);
+   }
+
+   dump_data = iwl_fw_error_next_data(dump_data);
+   dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_SRAM);
+   dump_data->len = cpu_to_le32(sram_len);
+   iwl_trans_read_mem_bytes(mvm->trans, sram_ofs, dump_data->data,
+sram_len);
+
+   if (trans_len) {
+   void *buf = iwl_fw_error_next_data(dump_data);
+   u32 real_trans_len = iwl_trans_dump_data(mvm->trans, buf,
+trans_len);
+   dump_data = (void *)((u8 *)buf + real_trans_len);
+   dump_file->file_len =
+   cpu_to_le32(file_len - trans_len + real_trans_len);
+   }
+}
+#endif
+
 static void iwl_mvm_restart_cleanup(struct iwl_m

[PATCH 3.16 4/7] iwlwifi: remove wrong comment about alignment in iwl-fw-error-dump.h

[Emmanuel Grumbach]

commit d4849277f92a0bfa08a988545ea527fc8e0c9571 upstream.

The chunks of data do not need to be multipliers of 4 nor
4-bytes aligned.

Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h 
b/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
index ced5ba9..9fd860f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h
@@ -92,8 +92,8 @@ enum iwl_fw_error_dump_type {
 /**
  * struct iwl_fw_error_dump_data - data for one type
  * @type: %enum iwl_fw_error_dump_type
- * @len: the length starting from %data - must be a multiplier of 4.
- * @data: the data itself padded to be a multiplier of 4.
+ * @len: the length starting from %data
+ * @data: the data itself
  */
 struct iwl_fw_error_dump_data {
__le32 type;
-- 
1.9.1

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

[PATCH 3.16 5/7] iwlwifi: mvm: don't collect logs in the interrupt thread

[Emmanuel Grumbach]

commit 78dae98fab85f4cd2d38cfc3474dea6e87e7b53a upstream.

Instead of reading all the data in the context of the
interrupt thread, collect the data in the restart flow
before the actual restart takes place so that the device
still has all the information.
Remove iwl_mvm_fw_error_sram_dump and move its content to
iwl_mvm_fw_error_dump.

Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/mvm/mvm.h   |  3 ---
 drivers/net/wireless/iwlwifi/mvm/ops.c   | 31 ---
 drivers/net/wireless/iwlwifi/mvm/utils.c | 22 --
 3 files changed, 12 insertions(+), 44 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h 
b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index fcc6c29..e084fc6 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -586,8 +586,6 @@ struct iwl_mvm {
/* -1 for always, 0 for never, >0 for that many times */
s8 restart_fw;
void *fw_error_dump;
-   void *fw_error_sram;
-   u32 fw_error_sram_len;
u32 *fw_error_rxf;
u32 fw_error_rxf_len;
 
@@ -721,7 +719,6 @@ u8 iwl_mvm_mac80211_idx_to_hwrate(int rate_idx);
 void iwl_mvm_dump_nic_error_log(struct iwl_mvm *mvm);
 #ifdef CONFIG_IWLWIFI_DEBUGFS
 void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm);
-void iwl_mvm_fw_error_sram_dump(struct iwl_mvm *mvm);
 void iwl_mvm_fw_error_rxf_dump(struct iwl_mvm *mvm);
 #endif
 u8 first_antenna(u8 mask);
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c 
b/drivers/net/wireless/iwlwifi/mvm/ops.c
index 2910f6d..94506ec 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -549,7 +549,6 @@ static void iwl_op_mode_mvm_stop(struct iwl_op_mode 
*op_mode)
 
kfree(mvm->scan_cmd);
vfree(mvm->fw_error_dump);
-   kfree(mvm->fw_error_sram);
kfree(mvm->fw_error_rxf);
kfree(mvm->mcast_filter_cmd);
mvm->mcast_filter_cmd = NULL;
@@ -827,6 +826,8 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
struct iwl_fw_error_dump_file *dump_file;
struct iwl_fw_error_dump_data *dump_data;
struct iwl_fw_error_dump_info *dump_info;
+   const struct fw_img *img;
+   u32 sram_len, sram_ofs;
u32 file_len;
u32 trans_len;
 
@@ -835,9 +836,13 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
if (mvm->fw_error_dump)
return;
 
+   img = &mvm->fw->img[mvm->cur_ucode];
+   sram_ofs = img->sec[IWL_UCODE_SECTION_DATA].offset;
+   sram_len = img->sec[IWL_UCODE_SECTION_DATA].len;
+
file_len = sizeof(*dump_file) +
   sizeof(*dump_data) * 3 +
-  mvm->fw_error_sram_len +
+  sram_len +
   mvm->fw_error_rxf_len +
   sizeof(*dump_info);
 
@@ -869,6 +874,8 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
strncpy(dump_info->bus_human_readable, mvm->dev->bus->name,
sizeof(dump_info->bus_human_readable));
 
+   iwl_mvm_fw_error_rxf_dump(mvm);
+
dump_data = iwl_fw_error_next_data(dump_data);
dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_RXF);
dump_data->len = cpu_to_le32(mvm->fw_error_rxf_len);
@@ -876,23 +883,14 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
 
dump_data = iwl_fw_error_next_data(dump_data);
dump_data->type = cpu_to_le32(IWL_FW_ERROR_DUMP_SRAM);
-   dump_data->len = cpu_to_le32(mvm->fw_error_sram_len);
-
-   /*
-* No need for lock since at the stage the FW isn't loaded. So it
-* can't assert - we are the only one who can possibly be accessing
-* mvm->fw_error_sram right now.
-*/
-   memcpy(dump_data->data, mvm->fw_error_sram, mvm->fw_error_sram_len);
+   dump_data->len = cpu_to_le32(sram_len);
+   iwl_trans_read_mem_bytes(mvm->trans, sram_ofs, dump_data->data,
+sram_len);
 
kfree(mvm->fw_error_rxf);
mvm->fw_error_rxf = NULL;
mvm->fw_error_rxf_len = 0;
 
-   kfree(mvm->fw_error_sram);
-   mvm->fw_error_sram = NULL;
-   mvm->fw_error_sram_len = 0;
-
if (trans_len) {
void *buf = iwl_fw_error_next_data(dump_data);
u32 real_trans_len = iwl_trans_dump_data(mvm->trans, buf,
@@ -910,11 +908,6 @@ static void iwl_mvm_nic_error(struct iwl_op_mode *op_mode)
 
iwl_mvm_dump_nic_error_log(mvm);
 
-#ifdef CONFIG_IWLWIFI_DEBUGFS
-   iwl_mvm_fw_error_sram_dump(mvm);
-   iwl_mvm_fw_error_rxf_dump(mvm);
-#endif
-
iwl_mvm_nic_restart(mvm);
 }
 
diff --git a/drivers/net/wireless/iwlwifi/mvm/utils.c 
b/drivers/net/wireless/iwlwifi/mvm/utils.c
index aa9fc77..15db97c 100644
--- a/drivers/net/wireless/iwlwifi/mvm/utils.c
+++ b/drivers/net/wireless/iwlwifi/mvm/utils.c
@@ -520,28 +520,6 @@ void iwl_mvm_dump_nic_error_log(struct iwl_mvm *mvm)
 }
 
 #ifdef CONFIG_IWLWIFI_DEBUGFS
-void iwl_mvm_fw_error_sram_dump(struct iw

[PATCH] mac80211_hwsim: release driver when ieee80211_register_hw fails

[Junjie Mao]

The driver is not released when ieee80211_register_hw fails in
mac80211_hwsim_create_radio, leading to the access to the unregistered (and
possibly freed) device in platform_driver_unregister:

[0.447547] mac80211_hwsim: ieee80211_register_hw failed (-2)
[0.448292] [ cut here ]
[0.448854] WARNING: CPU: 0 PID: 1 at ../include/linux/kref.h:47 
kobject_get+0x33/0x50()
[0.449839] CPU: 0 PID: 1 Comm: swapper Not tainted 
3.17.0-1-gdd46990-dirty #2
[0.450813] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[0.451512]    78025e38 7967c6c6 78025e68 7905e09b 7988b480 

[0.452579]  0001 79887d62 002f 79170bb3 79170bb3 78397008 79ac9d74 
0001
[0.453614]  78025e78 7905e15d 0009  78025e84 79170bb3 78397000 
78025e8c
[0.454632] Call Trace:
[0.454921]  [<7967c6c6>] dump_stack+0x16/0x18
[0.455453]  [<7905e09b>] warn_slowpath_common+0x6b/0x90
[0.456067]  [<79170bb3>] ? kobject_get+0x33/0x50
[0.456612]  [<79170bb3>] ? kobject_get+0x33/0x50
[0.457155]  [<7905e15d>] warn_slowpath_null+0x1d/0x20
[0.457748]  [<79170bb3>] kobject_get+0x33/0x50
[0.458274]  [<7925824f>] get_device+0xf/0x20
[0.458779]  [<7925b5cd>] driver_detach+0x3d/0xa0
[0.459331]  [<7925a3ff>] bus_remove_driver+0x8f/0xb0
[0.459927]  [<7925bf80>] ? class_unregister+0x40/0x80
[0.460660]  [<7925bad7>] driver_unregister+0x47/0x50
[0.461248]  [<7925c033>] ? class_destroy+0x13/0x20
[0.461824]  [<7925d07b>] platform_driver_unregister+0xb/0x10
[0.462507]  [<79b51ba0>] init_mac80211_hwsim+0x3e8/0x3f9
[0.463161]  [<79b30c58>] do_one_initcall+0x106/0x1a9
[0.463758]  [<79b517b8>] ? if_spi_init_module+0xac/0xac
[0.464393]  [<79b517b8>] ? if_spi_init_module+0xac/0xac
[0.465001]  [<79071935>] ? parse_args+0x2f5/0x480
[0.465569]  [<7906b41e>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[0.466345]  [<79b30dd9>] kernel_init_freeable+0xde/0x17d
[0.466972]  [<79b304d6>] ? do_early_param+0x7a/0x7a
[0.467546]  [<79677b1b>] kernel_init+0xb/0xe0
[0.468072]  [<79075f42>] ? schedule_tail+0x12/0x40
[0.468658]  [<79686580>] ret_from_kernel_thread+0x20/0x30
[0.469303]  [<79677b10>] ? rest_init+0xc0/0xc0
[0.469829] ---[ end trace ad8ac403ff8aef5c ]---
[0.470509] [ cut here ]
[0.471047] WARNING: CPU: 0 PID: 1 at ../kernel/locking/lockdep.c:3161 
__lock_acquire.isra.22+0x7aa/0xb00()
[0.472163] DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS)
[0.472774] CPU: 0 PID: 1 Comm: swapper Tainted: GW  
3.17.0-1-gdd46990-dirty #2
[0.473815] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[0.474492]  78025de0 78025de0 78025da0 7967c6c6 78025dd0 7905e09b 79888931 
78025dfc
[0.475515]  0001 79888a93 0c59 7907f33a 7907f33a 78028000 fffe9d09 

[0.476519]  78025de8 7905e10e 0009 78025de0 79888931 78025dfc 78025e24 
7907f33a
[0.477523] Call Trace:
[0.477821]  [<7967c6c6>] dump_stack+0x16/0x18
[0.478352]  [<7905e09b>] warn_slowpath_common+0x6b/0x90
[0.478976]  [<7907f33a>] ? __lock_acquire.isra.22+0x7aa/0xb00
[0.479658]  [<7907f33a>] ? __lock_acquire.isra.22+0x7aa/0xb00
[0.480417]  [<7905e10e>] warn_slowpath_fmt+0x2e/0x30
[0.480479]  [<7907f33a>] __lock_acquire.isra.22+0x7aa/0xb00
[0.480479]  [<79078aa5>] ? sched_clock_cpu+0xb5/0xf0
[0.480479]  [<7907fd06>] lock_acquire+0x56/0x70
[0.480479]  [<7925b5e8>] ? driver_detach+0x58/0xa0
[0.480479]  [<79682d11>] mutex_lock_nested+0x61/0x2a0
[0.480479]  [<7925b5e8>] ? driver_detach+0x58/0xa0
[0.480479]  [<7925b5e8>] ? driver_detach+0x58/0xa0
[0.480479]  [<7925b5e8>] driver_detach+0x58/0xa0
[0.480479]  [<7925a3ff>] bus_remove_driver+0x8f/0xb0
[0.480479]  [<7925bf80>] ? class_unregister+0x40/0x80
[0.480479]  [<7925bad7>] driver_unregister+0x47/0x50
[0.480479]  [<7925c033>] ? class_destroy+0x13/0x20
[0.480479]  [<7925d07b>] platform_driver_unregister+0xb/0x10
[0.480479]  [<79b51ba0>] init_mac80211_hwsim+0x3e8/0x3f9
[0.480479]  [<79b30c58>] do_one_initcall+0x106/0x1a9
[0.480479]  [<79b517b8>] ? if_spi_init_module+0xac/0xac
[0.480479]  [<79b517b8>] ? if_spi_init_module+0xac/0xac
[0.480479]  [<79071935>] ? parse_args+0x2f5/0x480
[0.480479]  [<7906b41e>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[0.480479]  [<79b30dd9>] kernel_init_freeable+0xde/0x17d
[0.480479]  [<79b304d6>] ? do_early_param+0x7a/0x7a
[0.480479]  [<79677b1b>] kernel_init+0xb/0xe0
[0.480479]  [<79075f42>] ? schedule_tail+0x12/0x40
[0.480479]  [<79686580>] ret_from_kernel_thread+0x20/0x30
[0.480479]  [<79677b10>] ? rest_init+0xc0/0xc0
[0.480479] ---[ end trace ad8ac403ff8aef5d ]---
[0.495478] BUG: unable to handle kernel paging request at 00200200
[0.496257] IP: [<79682de5>] mutex_lock_nested+0x135/0x2a0
[0.496923] *pde = 
[0.497290] Oops: 0002 [#1]
[  

wireless-regdb: Update regulatory rules for New Zealand (NZ) on 5GHz and 60 GHz [UNCLASSIFIED]

[Peter Gent]

Hi,

We wish to note the following changes should be made to the wireless regulatory 
database to reflect some recent changes to the 60 GHz band here in New Zealand. 
In additional there are some inaccuracies when compared to our current 
licencing for the 5 GHz "Wi-Fi" band.

The updated entry for New Zealand should read:

5150 MHz  - 5250 MHz  80MHz channels, indoor use only at -7.0 dBW EIRP TPC 
enabled
5250 MHz -  5350 MHz  80 MHz channels, indoor use at -7.0 dBW EIRP, outdoor use 
at 0 dBW EIRP with DFS and TPC enabled* 
5470 MHz  - 5725 MHz  80 MHz channels, 0 dBW EIRP with DFS and TPC enabled*
5725 MHz  - 5875 MHz  80 MHz channels, 6.0 dBW EIRP with frequency hopping 
enabled  
57000 MHz - 66000 MHz, indoor use only at 13.0 dBW EIRP 

*if TPC is not enabled, than transmit power must be reduced by 3dB

Further information on SRD licencing rules can be found at 
http://www.rsm.govt.nz/cms/licensees/types-of-licence/general-user-licences/short-range-devices
 

Regards

Peter




Peter Gent
PLANNING ANALYST

Radio Spectrum Management, Infrastructure & Resource Markets Group
Ministry of Business, Innovation & Employment

peter.g...@mbie.govt.nz | DDI:  +64 4 462 4279  |  Ext 44279  
Free Phone: 0508 RSM INFO (776 463) | Website: www.rsm.govt.nz 
15 Stout Street, PO Box 2847, Wellington, New Zealand





newzealand.govt.nz - connecting you to New Zealand central & local government 
services

Any opinions expressed in this message are not necessarily those of the 
Ministry of Business, Innovation and Employment. This message and any files 
transmitted with it are confidential and solely for the use of the intended 
recipient. If you are not the intended recipient or the person responsible for 
delivery to the intended recipient, be advised that you have received this 
message in error and that any use is strictly prohibited. Please contact the 
sender and delete the message and any attachment from your computer.

--
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: Kernel module(r8712u) reload - suspend/resume - systemd

[poma]

On 28.10.2014 00:15, Lennart Poettering wrote:
> On Mon, 27.10.14 23:43, poma (pomidorabelis...@gmail.com) wrote:
> 
>> but is there a better way to do it?
> 
> This appears to be a kernel driver bug. Please report this issue
> against the kernel driver in question, systemd is not the right place
> to work around that.
> 
> Lennart
> 

It's not a bug, it's a feature, just as true for the systemd. :)
Given the condition of the entire Linux Wireless LAN stack this can go actually.


poma

--
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 0/3] Add mcast event when hwsim radios are created and removed

[Ben Greear]

On 10/27/2014 04:14 PM, Marcel Holtmann wrote:
> Hi Luca,
> 
>> That's not particularly hard to figure out, for example by looking at
>> sysfs.
>>
>> Is this really so time-constrained/important/... that you can't do that?
>
> It does not seem very practical to dig this information from sysfs as
> the same information can be easily get via netlink as this patch shows.

 Well, that's a slippery slope. I'd consider it more practical to use
 existing APIs instead of (gratuitously) inventing new ones. It'll even
 work on older kernels as an added benefit.
>>>
>>> I see that different. The component that handles the emulation of the new 
>>> wireless device should be independent from the component driving it. I 
>>> prefer to have a race free way of obtaining the needed information without 
>>> having to monitor nl80211 and sysfs for this. Especially with the use cases 
>>> that we have in mind it has no business with these other interfaces.
>>>
>>> We have been down this route with the bridge interface where people had to 
>>> dig out information from sysfs and it did not work out nicely. So now 
>>> everything moves to netlink.
>>
>> Why does hwsim have to be treated differently from any other device?
>> Unlike bridging, HW emulation doesn't seem to be a real life use case.
>>
>> But I'm probably missing something. ;)
> 
> this is the controlling side. The thing that I call emulator. It is the 
> component that creates/destroys the hwsim wiphy. It can also be the one that 
> handles the packet processing similar to wmediumd.
> 
> The nl80211/cfg80211 is not treated differently here. This is purely for the 
> MAC80211_HWSIM netlink family side of things. Makes sense?

I just got some patches accepted upstream that allow you to name the phy upon 
creation
(and to suppress wlanX creation in case that is desired).

If your control tool is creating the phys, then it can know ahead of time the 
names
and match the events that way.

I'm not taking sides on your particular patch, but those features made my
tool a lot easier to write and more efficient.

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

Re: [PATCH 0/3] Add mcast event when hwsim radios are created and removed

[Marcel Holtmann]

Hi Luca,

> That's not particularly hard to figure out, for example by looking at
> sysfs.
> 
> Is this really so time-constrained/important/... that you can't do that?
 
 It does not seem very practical to dig this information from sysfs as
 the same information can be easily get via netlink as this patch shows.
>>> 
>>> Well, that's a slippery slope. I'd consider it more practical to use
>>> existing APIs instead of (gratuitously) inventing new ones. It'll even
>>> work on older kernels as an added benefit.
>> 
>> I see that different. The component that handles the emulation of the new 
>> wireless device should be independent from the component driving it. I 
>> prefer to have a race free way of obtaining the needed information without 
>> having to monitor nl80211 and sysfs for this. Especially with the use cases 
>> that we have in mind it has no business with these other interfaces.
>> 
>> We have been down this route with the bridge interface where people had to 
>> dig out information from sysfs and it did not work out nicely. So now 
>> everything moves to netlink.
> 
> Why does hwsim have to be treated differently from any other device?
> Unlike bridging, HW emulation doesn't seem to be a real life use case.
> 
> But I'm probably missing something. ;)

this is the controlling side. The thing that I call emulator. It is the 
component that creates/destroys the hwsim wiphy. It can also be the one that 
handles the packet processing similar to wmediumd.

The nl80211/cfg80211 is not treated differently here. This is purely for the 
MAC80211_HWSIM netlink family side of things. Makes sense?

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

Kernel module(r8712u) reload - suspend/resume - systemd

[poma]

It is tested and works, 

# systemctl suspend

[  144.218876] PM: Entering mem sleep
[  144.219249] r8712u 2-3:1.0 wlp0s4f1u3: Suspending...
[  144.219255] r8712u 2-3:1.0 wlp0s4f1u3: Unable to suspend

& RESUME

[  146.844240] r8712u 2-3:1.0 wlp0s4f1u3: Resuming...
[  146.844241] r8712u 2-3:1.0 wlp0s4f1u3: Unable to resume
[  147.015962] PM: Finishing wakeup.
[  154.029573] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  177.489082] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  200.499708] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  233.514654] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  276.498402] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  329.498037] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  392.507363] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  455.559545] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  518.540179] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
[  581.533404] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1

~~

# nmcli device 
DEVICE  TYPE  STATE CONNECTION 
wlp0s4f1u3  wifi  disconnected  -- 

~

/etc/systemd/system/r8712u-reload.service
[Unit]
Description=Reload rtl871x wireless lan driver after system resume
After=hibernate.target suspend.target hybrid-sleep.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/modprobe -r r8712u
ExecStart=/usr/sbin/modprobe r8712u

[Install]
WantedBy=hibernate.target suspend.target hybrid-sleep.target



# systemctl enable r8712u-reload.service

~~~

# systemctl suspend

[  616.251430] PM: Entering mem sleep
[  616.251962] r8712u 2-3:1.0 wlp0s4f1u3: Suspending...
[  616.251965] r8712u 2-3:1.0 wlp0s4f1u3: Unable to suspend

& RESUME

[  619.008122] r8712u 2-3:1.0 wlp0s4f1u3: Resuming...
[  619.008124] r8712u 2-3:1.0 wlp0s4f1u3: Unable to resume
[  619.195001] PM: Finishing wakeup.
[  620.073126] usb 2-3: reset high-speed USB device number 3 using ehci-pci
[  620.209187] r8712u: module is from the staging directory, the quality is 
unknown, you have been warned.
[  620.209785] r8712u: Staging version
[  620.209802] r8712u: register rtl8712_netdev_ops to netdev_ops
[  620.209807] usb 2-3: r8712u: USB_SPEED_HIGH with 4 endpoints
[  620.210253] usb 2-3: r8712u: Boot from EFUSE: Autoload OK
[  620.583476] usb 2-3: r8712u: CustomerID = 0x
[  620.583489] usb 2-3: r8712u: MAC Address from efuse = 00:01:02:03:04:05
[  620.583498] usb 2-3: r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
[  620.584238] usbcore: registered new interface driver r8712u
[  620.589721] r8712u 2-3:1.0 wlp0s4f1u3: renamed from wlan0
[  627.183840] r8712u 2-3:1.0 wlp0s4f1u3: 1 RCR=0x153f00e
[  627.184345] r8712u 2-3:1.0 wlp0s4f1u3: 2 RCR=0x553f00e
[  627.288231] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready
[  627.592219] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready
[  627.896222] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready
[  628.201217] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready
[  648.740663] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s4f1u3: link becomes ready

~~

# nmcli device 
DEVICE  TYPE  STATE CONNECTION 
wlp0s4f1u3  wifi  connected AP 


but is there a better way to do it?


poma
--
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] mac80211-hwsim: add frequency attribute to netlink pkts

[greearb]

From: Ben Greear 

Add frequency attribute when sending to user-space over
netlink socket.  The frequency is currently ignored when
receiving from user-space.

Signed-off-by: Ben Greear 
---
 drivers/net/wireless/mac80211_hwsim.c | 7 +++
 drivers/net/wireless/mac80211_hwsim.h | 4 +++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 270f8cd..b40435c 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -906,6 +906,9 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw 
*hw,
if (nla_put_u32(skb, HWSIM_ATTR_FLAGS, hwsim_flags))
goto nla_put_failure;
 
+   if (nla_put_u32(skb, HWSIM_ATTR_FREQ, data->channel->center_freq))
+   goto nla_put_failure;
+
/* We get the tx control (rate and retries) info*/
 
for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
@@ -2421,6 +2424,7 @@ static int hwsim_cloned_frame_received_nl(struct sk_buff 
*skb_2,
int frame_data_len;
void *frame_data;
struct sk_buff *skb = NULL;
+   u32 freq;
 
if (info->snd_portid != wmediumd_portid) {
printk(KERN_DEBUG "mac80211-hwsim: port-id mismatch: %d %d\n",
@@ -2468,6 +2472,9 @@ static int hwsim_cloned_frame_received_nl(struct sk_buff 
*skb_2,
 
/* A frame is received from user space */
memset(&rx_status, 0, sizeof(rx_status));
+   /* TODO: Check ATTR_FREQ if it exists, and maybe throw away off-channel
+* packets?
+*/
rx_status.freq = data2->channel->center_freq;
rx_status.band = data2->channel->band;
rx_status.rate_idx = nla_get_u32(info->attrs[HWSIM_ATTR_RX_RATE]);
diff --git a/drivers/net/wireless/mac80211_hwsim.h 
b/drivers/net/wireless/mac80211_hwsim.h
index e614a20..85da35a 100644
--- a/drivers/net/wireless/mac80211_hwsim.h
+++ b/drivers/net/wireless/mac80211_hwsim.h
@@ -60,7 +60,7 @@ enum hwsim_tx_control_flags {
  * space, uses:
  * %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_ADDR_RECEIVER,
  * %HWSIM_ATTR_FRAME, %HWSIM_ATTR_FLAGS, %HWSIM_ATTR_RX_RATE,
- * %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE
+ * %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE, %HWSIM_ATTR_FREQ (optional)
  * @HWSIM_CMD_TX_INFO_FRAME: Transmission info report from user space to
  * kernel, uses:
  * %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_FLAGS,
@@ -113,6 +113,7 @@ enum {
  * single channel is supported
  * @HWSIM_ATTR_RADIO_NAME: Name of radio, e.g. phy666
  * @HWSIM_ATTR_NO_VIF:  Do not create vif (wlanX) when creating radio.
+ * @HWSIM_ATTR_FREQ: Frequency at which packet is transmitted or received.
  * @__HWSIM_ATTR_MAX: enum limit
  */
 
@@ -137,6 +138,7 @@ enum {
HWSIM_ATTR_DESTROY_RADIO_ON_CLOSE,
HWSIM_ATTR_RADIO_NAME,
HWSIM_ATTR_NO_VIF,
+   HWSIM_ATTR_FREQ,
__HWSIM_ATTR_MAX,
 };
 #define HWSIM_ATTR_MAX (__HWSIM_ATTR_MAX - 1)
-- 
1.7.11.7

--
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: Questions regarding ath9k and new EN 300 328 regulation

[Adrien Decostre]

Dear Zefir,

Thanks a lot for these precisions, This makes thing more clear.

There is still one thing unclear to me. If we do not consider working
on the DFS channels and that we only want to operate on channels 36,
40, 44 and 48 in EU. Do we still need to enable DFS flags in ath9k to
comply with EN 300 328 v1.8.1. I mean, is the same pulse detector
algorithm used for DFS and for the adaptivity tests on channels 36 to
48?

Many thanks in advance for your answer.

Best regards

Adrien


On Mon, Oct 27, 2014 at 3:50 PM, Zefir Kurtisi
 wrote:
> On 10/27/2014 03:18 PM, Adrien Decostre wrote:
>> Hello Zefir,
>>
>> Thanks a lot for your answer. This helps me a lot.
>> If I correctly understand, the ability of ath9k to detect all pulses
>> may also depend of the platform performances. So on an embedded
>> platform with limited performances, we may observe more pulses losses
>> than on a more powerful platform. Is this a right statement?
>>
> No, there is no bottleneck in the platform performance. Presumed radar pulses 
> are
> reported as RX_ERROR descriptors and even lower end embedded systems are able 
> to
> handle the load. What makes the difference with the minimum pulse width is the
> chip DFS engine's ability to isolate and identify very short spikes as 
> potential
> radar pulses.
>
> This goes very deeply into material I had available under NDA while 
> implementing
> the DFS support for ath9k. If you intend to work on that topic, I encourage 
> you to
> contact the folks at QCA and join their 'NDA for Developers' program. The 
> document
> you want to read is 'Baseband DFS 2 (Radar) Micro-Architecture'.
>
>> What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need it
>> to enable the detection of 0.5usec. pulses?
>>
> Yes, this driver specific flag (also available for 10k) you need to set to 
> get the
> DFS detector built (not related to pulse width). It essentially shifts the
> responsibility of the product working in restricted bands to you / the 
> manufacturer.
>
>
>> Thanks in advance for your answer.
>>
>> Best regards
>>
>> Adrien
>>
>
> Good Luck,
> Zefir
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MediaTek WiFi hardware support in upstream kernel

[Oleksij Rempel]

Am 27.10.2014 um 16:20 schrieb John W. Linville:
> On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
>> I am not a developer, but I stumbled upon this just a couple of days ago in
>> the OpenWRT forums:
>>
>> https://forum.openwrt.org/viewtopic.php?id=53215
>>
>> In short, MediaTek is looking for volunteers to help get their drivers
>> mainlined in the upstream kernels; this includes drivers for their USB and
>> PCI wifi hardware under both the MediaTek and Ralink brands. They are
>> willing to provide "chip info, reference driver, dev board, etc" and even
>> some degree of sponsorship, apparently subject to their management's
>> approval.
>>
>> In exchange, they require that the volunteers fulfill the following
>> requirements:
>> - skilled in wifi driver development
>> - provide a suitable schedule / roadmap
>> - be able to get the code mainlined in the official linux kernel.
>>
>> Those who are keen on taking up the task can contact the original poster at
>> hua.shao[AT]mediatek.com
>>
>> **Disclaimer: I am in no way related to, or under the employ of MediaTek or
>> Ralink. I am only posting this here because I have a handful of MT wifi
>> chips which I hope to see being supported in the upstream kernel so that I
>> can actually use them under Linux,
> 
> Well, this is mostly good to see.  I hope there is someone that wants
> to take-up the cause!
> 
> If someone is interested in working-on the project above but for
> whatever reason doesn't want to deal with MediaTek on their own,
> feel free to contact me.  I'll try to be helpful however I can.
> 
> Thanks,
> 
> John


Sounds interesting and as perfect possibility to learn. I would like to
do it, but i have two concerns:
- i never wrote an wifi driver from scratch.
- i'm seeking for a job. It means if i will find one, this project will
get lower priority.

If nobody has problems with this two points, then i'm ok.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Pull request: ath 20141024

[John W. Linville]

On Fri, Oct 24, 2014 at 02:44:32PM +0300, Kalle Valo wrote:
> Hi John,
> 
> here are the latest ath10k patches plus a small logging change to ath6kl
> and wil6210. Unfortunately this time there's a small conflict in
> drivers/net/wireless/ath/wil6210/wil6210.h but luckily it's easy to fix.
> Here's an example how I propose to resolve it:
> 
> --
> #define wil_to_ndev(i) (wil_to_wdev(i)->netdev)
> #define ndev_to_wil(n) (wdev_to_wil(n->ieee80211_ptr))
> #define wil_to_pcie_dev(i) (&i->pdev->dev)
> 
> __printf(2, 3)
> void wil_dbg_trace(struct wil6210_priv *wil, const char *fmt, ...);
> __printf(2, 3)
> void wil_err(struct wil6210_priv *wil, const char *fmt, ...);
> __printf(2, 3)
> void wil_info(struct wil6210_priv *wil, const char *fmt, ...);
> #define wil_dbg(wil, fmt, arg...) do { \
>   netdev_dbg(wil_to_ndev(wil), fmt, ##arg); \
>   wil_dbg_trace(wil, fmt, ##arg); \
> } while (0)
> 
> #define wil_dbg_irq(wil, fmt, arg...) wil_dbg(wil, "DBG[ IRQ]" fmt, ##arg)
> #define wil_dbg_txrx(wil, fmt, arg...) wil_dbg(wil, "DBG[TXRX]" fmt, ##arg)
> --
> 
> I think a lesson learned here is that I should not apply patches which
> touch wil6210 and instead ask the submitter to split the patch. Sorry
> for this.
> 
> Here's a changelog for the pull request:
> 
> --
> Major changes are:
> 
> o ethtool support (Ben)
> 
> o print dev string prefix with debug hex buffers dump (Michal)
> 
> o debugfs file to read calibration data from the firmware verification
>   purposes (me)
> 
> o fix fw_stats debugfs file, now results are more reliable (Michal)
> 
> o firmware crash counters via debugfs (Ben&me)
> 
> o various tracing points to debug firmware (Rajkumar)
> 
> o make it possible to provide firmware calibration data via a file (me)
> 
> And we have quite a lot of smaller fixes and clean up.
> --
> 
> Please pull and let me know if you have any problems.
> 
> Kalle
> 
> --
> 
> The following changes since commit b25f32cb02155d68c690255ba846796a1c248fd3:
> 
>   ath10k: use ether_addr_copy() (2014-09-18 10:47:03 +0300)
> 
> are available in the git repository at:
> 
>   git://github.com/kvalo/ath.git tags/for-linville-20141024
> 
> for you to fetch changes up to 84cbf3a7592879810f80cece6c7f736f099ab163:
> 
>   ath10k: split ce pipe init/alloc further (2014-10-23 16:41:32 +0300)

Pulling now...

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 11/13] ath5k: revert AHB bus support removing

[John W. Linville]

On Wed, Oct 22, 2014 at 03:03:49AM +0400, Sergey Ryazanov wrote:
> This reverts commit 093ec3c5337434f40d77c1af06c139da3e5ba6dc.
> 
> AHB bus code has been removed, since we did not have support Atheros
> AR231x SoC, required for building the AHB version of ath5k. Now that
> support WiSoC chips added we can restore functionality back.
> 
> Singed-off-by: Sergey Ryazanov 
> Cc: Jiri Slaby 
> Cc: Nick Kossifidis 
> Cc: "Luis R. Rodriguez" 
> Cc: linux-wireless@vger.kernel.org
> Cc: ath5k-de...@lists.ath5k.org

Acked-by: John W. Linville 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 12/13] ath5k: update dependencies

[John W. Linville]

On Wed, Oct 22, 2014 at 03:03:50AM +0400, Sergey Ryazanov wrote:
> - Use config symbol defined in the driver instead of arch specific one for
>   conditional compilation.
> - Rename the ATHEROS_AR231X config symbol to ATH25.
> - Fix include (ar231x_platform.h -> ath25_platform.h).
> - Some of AR231x SoCs (e.g. AR2315) have PCI bus support, so remove !PCI
>   dependency, which block AHB support build.
> 
> Signed-off-by: Sergey Ryazanov 
> Cc: Jiri Slaby 
> Cc: Nick Kossifidis 
> Cc: "Luis R. Rodriguez" 
> Cc: linux-wireless@vger.kernel.org
> Cc: ath5k-de...@lists.ath5k.org

Acked-by: John W. Linville 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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 2014-10-21

[John W. Linville]

On Thu, Oct 23, 2014 at 09:24:33PM +0300, Emmanuel Grumbach wrote:
> On Thu, Oct 23, 2014 at 8:48 PM, John W. Linville
>  wrote:
> > I do not have the 3.18-rc1 tag, because Dave doesn't have it yet in
> > the net.git tre.  Please rebase.
> >
> 
> Done - new tag:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git
> tags/iwlwifi-for-john-2014-10-23

Pulling now...
 
> > Thanks,
> >
> > John
> >
> > On Tue, Oct 21, 2014 at 12:29:08PM +0300, Emmanuel Grumbach wrote:
> >> Hi John,
> >>
> >> Here is a first pull request for 3.18. This time I chose to work with
> >> signed tags instead of signing emails.
> >> Let me know if this is an issue for you.
> >> Description of the content below.
> >>
> >> Note that this you haven't updated your trees yet and Linus released
> >> 3.18-rc1 already,
> >> I decided to base my trees on Linus's tag. Let me know you want me to
> >> change this.
> >>
> >> Thanks!
> >>
> >> The following changes since commit 
> >> f114040e3ea6e07372334ade75d1ee0775c355e1:
> >>
> >>   Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git
> >> tags/iwlwifi-for-john-2014-10-21
> >>
> >> for you to fetch changes up to ae35aee606d0ea5678c75fa058ea6eb048fc1d79:
> >>
> >>   Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
> >> (2014-10-21 09:00:27 +0300)
> >>
> >> 
> >> I revert here a patch that caused interoperability issues.
> >> dvm gets a fix for a bug that was reported by many users.
> >> Two minor fixes for BT Coex and platform power fix that helps
> >> reducing latency when the PCIe link goes to low power states.
> >>
> >> 
> >> Emmanuel Grumbach (5):
> >>   iwlwifi: configure the LTR
> >>   iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
> >>   iwlwifi: mvm: BT coex - fix BT prio for probe requests
> >>   iwlwifi: dvm: drop non VO frames when flushing
> >>   Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
> >>
> >> Haim Dreyfuss (1):
> >>   iwlwifi: mvm: Add tx power condition to bss_info_changed_ap_ibss
> >>
> >> Liad Kaufman (1):
> >>   iwlwifi: 8000: fix string given to MODULE_FIRMWARE
> >>
> >> Matti Gottlieb (1):
> >>   iwlwifi: mvm: ROC - bug fixes around time events and locking
> >>
> >>  drivers/net/wireless/iwlwifi/dvm/mac80211.c | 24 
> >> +---
> >>  drivers/net/wireless/iwlwifi/iwl-8000.c |  3 ++-
> >>  drivers/net/wireless/iwlwifi/iwl-trans.h|  2 ++
> >>  drivers/net/wireless/iwlwifi/mvm/coex.c |  4 ++--
> >>  drivers/net/wireless/iwlwifi/mvm/coex_legacy.c  |  4 ++--
> >>  drivers/net/wireless/iwlwifi/mvm/fw-api-power.h | 35
> >> ++-
> >>  drivers/net/wireless/iwlwifi/mvm/fw-api.h   |  1 +
> >>  drivers/net/wireless/iwlwifi/mvm/fw.c   |  9 +
> >>  drivers/net/wireless/iwlwifi/mvm/mac80211.c | 32
> >> +++-
> >>  drivers/net/wireless/iwlwifi/mvm/ops.c  |  1 +
> >>  drivers/net/wireless/iwlwifi/mvm/scan.c |  3 ++-
> >>  drivers/net/wireless/iwlwifi/mvm/time-event.c   |  2 +-
> >>  drivers/net/wireless/iwlwifi/mvm/tx.c   |  8 ++--
> >>  drivers/net/wireless/iwlwifi/pcie/trans.c   | 16 +---
> >>  14 files changed, 103 insertions(+), 41 deletions(-)
> >> --
> >> 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
> >>
> >
> > --
> > John W. LinvilleSomeday the world will need a hero, and you
> > linvi...@tuxdriver.com  might be all we have.  Be ready.
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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/1] wireless-regdb: Update rules for Australia (AU) to align with class licence

[John W. Linville]

I'm always a bit cautious about merging regdb patches that loosen
the rules.  Would anyone with more expertise on such regulations care
to comment on this one?

On Sun, Oct 12, 2014 at 09:56:51PM +1100, Michael Harris wrote:
> I am not sure where the existing regdb rules for Australia were derived from
> (perhaps some default template?) but they are a lot more restrictive than the
> actual class licence requirements.
> 
> I have updated to the best of my ability according to the "Radiocommunications
> (Low Interference Potential Devices) Class Licence 2000" which can be found 
> here:
> 
> http://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class-licences/class-licences
> 
> There is also a useful FAQ for 2.4GHz WLANs here:
> http://www.acma.gov.au/Citizen/Consumer-info/My-connected-home/Wireless-local-area-networks/wireless-lans-in-the-24-ghz-band-faqs
> 
> Signed-off-by: Michael Harris 
> ---
>  db.txt | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index f0e4312..94c7010 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -78,12 +78,22 @@ country AT: DFS-ETSI
>   # 60 gHz band channels 1-4, ref: Etsi En 302 567
>   (57240 - 65880 @ 2160), (40), NO-OUTDOOR
>  
> +# Reference: Radiocommunications (Low Interference Potential Devices) Class 
> Licence 2000
> +# 
> http://www.acma.gov.au/Industry/Spectrum/Radiocomms-licensing/Class-licences/class-licences
>  country AU:
> - (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (17)
> - (5250 - 5330 @ 80), (24), DFS
> - (5490 - 5710 @ 80), (24), DFS
> - (5735 - 5835 @ 80), (30)
> + # Item 45A
> + (2400 - 2483 @ 40), (36)
> + # Item 44
> + (5150 - 5250 @ 80), (23), NO-OUTDOOR
> + # Item 44A (assuminging no TPC implemented).
> + # If TPC implemented then 23dBm allowed.
> + (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS
> + # Item 46 (assuming no TPC implemented)
> + # If TPC implemented then 30dBm allowed
> + (5470 - 5600 @ 80), (27), DFS
> + (5650 - 5725 @ 40), (27), DFS
> + # Item 45B
> + (5725 - 5850 @ 80), (36)
>  
>  country AW: DFS-ETSI
>   (2402 - 2482 @ 40), (20)
> -- 
> 1.8.3.1
> 
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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: mac80211 2014-10-23

[John W. Linville]

On Thu, Oct 23, 2014 at 08:35:36PM +0200, Johannes Berg wrote:
> John,
> 
> Please pull the below changes for the current 3.18 preparations. More
> details below.
> 
> Thanks,
> johannes
> 
> ---
> 
> The following changes since commit
> 35a9ad8af0bb0fa3525e6d0d20e32551d226f38e:
> 
>   Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next 
> (2014-10-08 21:40:54 -0400)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
> tags/mac80211-for-john-2014-10-23
> 
> for you to fetch changes up to 11b2357d5dbce999803e9055f8c09829a8a87db4:
> 
>   mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats
> (2014-10-20 16:37:01 +0200)
> 
> 
> Here are a few fixes for the wireless stack: one fixes the
> RTS rate, one for a debugfs file, one to return the correct
> channel to userspace, a sanity check for a userspace value
> and the remaining two are just documentation fixes.
> 
> 
> Fabian Frederick (1):
>   net: rfkill: kernel-doc warning fixes
> 
> Karl Beldan (2):
>   mac80211: fix typo in starting baserate for rts_cts_rate_idx
>   mac80211: minstrels: fix buffer overflow in HT debugfs rc_stats
> 
> Liad Kaufman (1):
>   mac80211: fix warning on htmldocs for last_tdls_pkt_time
> 
> Luciano Coelho (2):
>   mac80211: return the vif's chandef in ieee80211_cfg_get_channel()
>   nl80211: sanity check the channel switch counter value
> 
>  net/mac80211/cfg.c |  2 +-
>  net/mac80211/rate.c|  2 +-
>  net/mac80211/rc80211_minstrel_debugfs.c| 12 +++-
>  net/mac80211/rc80211_minstrel_ht_debugfs.c | 13 -
>  net/mac80211/sta_info.h|  1 +
>  net/rfkill/core.c  |  4 ++--
>  net/wireless/nl80211.c | 10 +-
>  7 files changed, 29 insertions(+), 15 deletions(-)

Pulling now...

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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 0/3] Add mcast event when hwsim radios are created and removed

[Luca Coelho]

On Mon, 2014-10-27 at 07:19 -0700, Marcel Holtmann wrote:
> Hi Johannes,
> 
> >>> That's not particularly hard to figure out, for example by looking at
> >>> sysfs.
> >>> 
> >>> Is this really so time-constrained/important/... that you can't do that?
> >> 
> >> It does not seem very practical to dig this information from sysfs as
> >> the same information can be easily get via netlink as this patch shows.
> > 
> > Well, that's a slippery slope. I'd consider it more practical to use
> > existing APIs instead of (gratuitously) inventing new ones. It'll even
> > work on older kernels as an added benefit.
> 
> I see that different. The component that handles the emulation of the new 
> wireless device should be independent from the component driving it. I prefer 
> to have a race free way of obtaining the needed information without having to 
> monitor nl80211 and sysfs for this. Especially with the use cases that we 
> have in mind it has no business with these other interfaces.
> 
> We have been down this route with the bridge interface where people had to 
> dig out information from sysfs and it did not work out nicely. So now 
> everything moves to netlink.

Why does hwsim have to be treated differently from any other device?
Unlike bridging, HW emulation doesn't seem to be a real life use case.

But I'm probably missing something. ;)

--
Luca.

--
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] wireless-regdb: add regulatory rule for ETSI members on 60GHz band

[John W. Linville]

On Sun, Oct 19, 2014 at 09:49:52AM +0300, Vladimir Kondratiev wrote:
> On Tuesday, October 14, 2014 02:28:58 PM Xose Vazquez Perez wrote:
> > "(57240 - 65880 @ 2160), (40), NO-OUTDOOR" should(must) be replaced by:
> > "(57000 - 66000 @ 2160), (40)"
> > 
> 
> Yes, looks like you are right. I used draft that I don't see on its location 
> any more,
> and final document indeed says what you wrote.

Would someone like to post a patch to that effect?

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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] bcma: fix build when CONFIG_OF_ADDRESS is not set

[Guenter Roeck]

On Mon, Oct 27, 2014 at 11:15:09AM -0400, John W. Linville wrote:
> Yes, I have it queued.  Things have been delayed due to my recent
> travels, etc.
> 
Thanks!

Guenter

> On Sat, Oct 25, 2014 at 01:36:53PM -0700, Guenter Roeck wrote:
> > On Thu, Oct 09, 2014 at 11:39:41PM +0200, Hauke Mehrtens wrote:
> > > Commit 2101e533f41a ("bcma: register bcma as device tree driver")
> > > introduces a hard dependency on OF_ADDRESS into the bcma driver.
> > > OF_ADDRESS is specifically disabled for the sparc architecture.
> > > This results in the following error when building sparc64:allmodconfig.
> > > 
> > > drivers/bcma/main.c: In function 'bcma_of_find_child_device':
> > > drivers/bcma/main.c:150:3: error: implicit declaration of function 
> > > 'of_translate_address'
> > > 
> > > Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
> > > Reported-by: Guenter Roeck 
> > > Signed-off-by: Hauke Mehrtens 
> > 
> > The upstream kernel still does not include this patch, and the sparc64 build
> > is still broken.
> > 
> > Is this patch on its way upstream ?
> > 
> > Guenter
> > 
> > > ---
> > >  drivers/bcma/main.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> > > index d1656c2..1000955 100644
> > > --- a/drivers/bcma/main.c
> > > +++ b/drivers/bcma/main.c
> > > @@ -132,7 +132,7 @@ static bool bcma_is_core_needed_early(u16 core_id)
> > >   return false;
> > >  }
> > >  
> > > -#ifdef CONFIG_OF
> > > +#if defined(CONFIG_OF) && defined(CONFIG_OF_ADDRESS)
> > >  static struct device_node *bcma_of_find_child_device(struct 
> > > platform_device *parent,
> > >struct bcma_device *core)
> > >  {
> > > -- 
> > > 1.9.1
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > > 
> > > 
> > 
> 
> -- 
> John W. Linville  Someday the world will need a hero, and you
> linvi...@tuxdriver.commight be all we have.  Be ready.
--
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] bcma: fix build when CONFIG_OF_ADDRESS is not set

[John W. Linville]

Yes, I have it queued.  Things have been delayed due to my recent
travels, etc.

On Sat, Oct 25, 2014 at 01:36:53PM -0700, Guenter Roeck wrote:
> On Thu, Oct 09, 2014 at 11:39:41PM +0200, Hauke Mehrtens wrote:
> > Commit 2101e533f41a ("bcma: register bcma as device tree driver")
> > introduces a hard dependency on OF_ADDRESS into the bcma driver.
> > OF_ADDRESS is specifically disabled for the sparc architecture.
> > This results in the following error when building sparc64:allmodconfig.
> > 
> > drivers/bcma/main.c: In function 'bcma_of_find_child_device':
> > drivers/bcma/main.c:150:3: error: implicit declaration of function 
> > 'of_translate_address'
> > 
> > Fixes: 2101e533f41a ("bcma: register bcma as device tree driver")
> > Reported-by: Guenter Roeck 
> > Signed-off-by: Hauke Mehrtens 
> 
> The upstream kernel still does not include this patch, and the sparc64 build
> is still broken.
> 
> Is this patch on its way upstream ?
> 
> Guenter
> 
> > ---
> >  drivers/bcma/main.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> > index d1656c2..1000955 100644
> > --- a/drivers/bcma/main.c
> > +++ b/drivers/bcma/main.c
> > @@ -132,7 +132,7 @@ static bool bcma_is_core_needed_early(u16 core_id)
> > return false;
> >  }
> >  
> > -#ifdef CONFIG_OF
> > +#if defined(CONFIG_OF) && defined(CONFIG_OF_ADDRESS)
> >  static struct device_node *bcma_of_find_child_device(struct 
> > platform_device *parent,
> >  struct bcma_device *core)
> >  {
> > -- 
> > 1.9.1
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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] net: rfkill: gpio: Add default GPIO driver mappings for ACPI

[John W. Linville]

On Mon, Oct 27, 2014 at 12:23:55PM +0100, Johannes Berg wrote:
> On Mon, 2014-10-27 at 12:15 +0200, Mika Westerberg wrote:
> > The driver uses devm_gpiod_get_index(..., index) so that the index refers
> > directly to the GpioIo resource under the ACPI device. The problem with
> > this is that if the ordering changes we get wrong GPIOs.
> > 
> > With ACPI 5.1 _DSD we can now use names instead to reference GPIOs
> > analogous to Device Tree. However, we still have systems out there that do
> > not provide _DSD at all. These systems must be supported as well.
> > 
> > Luckily we now have acpi_dev_add_driver_gpios() that can be used to provide
> > mappings for systems where _DSD is not provided and still take advantage of
> > _DSD if it exists.
> > 
> > This patch changes the driver to create default GPIO mappings if we are
> > running on ACPI system.
> > 
> > While there we can drop the indices completely and use devm_gpiod_get()
> > with name instead.
> > 
> > Signed-off-by: Mika Westerberg 
> > ---
> > Hi,
> > 
> > This patch is based on top of linux-pm/device-properties [1] and following
> > patch from Rafael [2].
> > 
> > Johannes, John,
> > 
> > If you are happy with the patch, can you ACK it so that we can merge it
> > with the rest of the device-properties patches. Thanks.
> 
> Acked-by: Johannes Berg 
> Reviewed-by: Johannes Berg 

Acked-by: John W. Linville 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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: MediaTek WiFi hardware support in upstream kernel

[John W. Linville]

On Mon, Oct 27, 2014 at 11:02:00AM +0800, Etna wrote:
> I am not a developer, but I stumbled upon this just a couple of days ago in
> the OpenWRT forums:
> 
> https://forum.openwrt.org/viewtopic.php?id=53215
> 
> In short, MediaTek is looking for volunteers to help get their drivers
> mainlined in the upstream kernels; this includes drivers for their USB and
> PCI wifi hardware under both the MediaTek and Ralink brands. They are
> willing to provide "chip info, reference driver, dev board, etc" and even
> some degree of sponsorship, apparently subject to their management's
> approval.
> 
> In exchange, they require that the volunteers fulfill the following
> requirements:
> - skilled in wifi driver development
> - provide a suitable schedule / roadmap
> - be able to get the code mainlined in the official linux kernel.
> 
> Those who are keen on taking up the task can contact the original poster at
> hua.shao[AT]mediatek.com
> 
> **Disclaimer: I am in no way related to, or under the employ of MediaTek or
> Ralink. I am only posting this here because I have a handful of MT wifi
> chips which I hope to see being supported in the upstream kernel so that I
> can actually use them under Linux,

Well, this is mostly good to see.  I hope there is someone that wants
to take-up the cause!

If someone is interested in working-on the project above but for
whatever reason doesn't want to deal with MediaTek on their own,
feel free to contact me.  I'll try to be helpful however I can.

Thanks,

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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] ipw2x00: shift wrap bugs setting ->rt_tsf

[Dan Carpenter]

Gar...  I am stupid.  The original shift can't wrap.  I don't know what
I was thinking.  Sorry for the noise...

Thanks for checking me on this Joe.

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: [patch] ipw2x00: shift wrap bugs setting ->rt_tsf

[Joe Perches]

On Mon, 2014-10-27 at 12:52 +0300, Dan Carpenter wrote:
> On Fri, Oct 24, 2014 at 02:43:31AM -0700, Joe Perches wrote:
> > On Fri, 2014-10-24 at 11:15 +0300, Dan Carpenter wrote:
> > > @@ -8028,10 +8028,10 @@ static void ipw_handle_promiscuous_rx(struct 
> > > ipw_priv *priv,
> > >  
> > >   /* Zero the flags, we'll add to them as we go */
> > >   ipw_rt->rt_flags = 0;
> > > - ipw_rt->rt_tsf = (u64)(frame->parent_tsf[3] << 24 |
> > > -frame->parent_tsf[2] << 16 |
> > > -frame->parent_tsf[1] << 8  |
> > > -frame->parent_tsf[0]);
> > > + ipw_rt->rt_tsf = (u64)frame->parent_tsf[3] << 24 |
> > > +   frame->parent_tsf[2] << 16 |
> > > +   frame->parent_tsf[1] << 8  |
> > > +   frame->parent_tsf[0];
> > >  
> > >   /* Convert to DBM */
> > >   ipw_rt->rt_dbmsignal = signal;
> > 
> > struct ipw_rt_hdr {
> > struct ieee80211_radiotap_header rt_hdr;
> > u64 rt_tsf;  /* TSF */  /* XXX */
> > u8 rt_flags;/* radiotap packet flags *
> > u8 rt_rate; /* rate in 500kb/s */
> > __le16 rt_channel;  /* channel in mhz */
> > __le16 rt_chbitmask;/* channel bitfield */
> > s8 rt_dbmsignal;/* signal in dbM, kluged to signed */
> > s8 rt_dbmnoise;
> > u8 rt_antenna;  /* antenna number */
> > u8 payload[0];  /* payload... */
> > } __packed;
> > 
> > Maybe rt_tsf (which is otherwise unused in this code),
> > should be __le64 so maybe use (u32) ?
> > 
> > ipw_rt->rt_txf = cpu_to_le64((u32)(frame->parent_tsf[3] << 24 |
> >frame->parent_tsf[2] << 16 |
> >frame->parent_tsf[1] << 8  |
> >frame->parent_tsf[0]));
> > 
> 
> Hm...  It don't think it makes sense to truncate the top bits away by
> truncating to u32.  You may be right though that there is some larger
> bugs here than just the truncation.

  It'd be a tad faster than using multiple 64 bit
operations on a 32 bit machine.

> Both the "frame" and the "ipw_rt" struct seem to hold little endian
> values generally so probably ->rt_txf should be an __le64 like you say.
>   
> Perhaps the maintainers know what should be done?

Are there any maintainers left?

Likely this was only ever tested/used on x86 hardware.


--
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] staging:rtl8723au: core: Fix error reported by checkpatch.

[Joe Perches]

On Mon, 2014-10-27 at 09:43 +0100, Jes Sorensen wrote:
> Sanjeev Sharma  writes:
> > This is a patch to the rtw_cmd.c file that fixes
> > Error reported by checkpatch.
[]
> > diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
> > b/drivers/staging/rtl8723au/core/rtw_cmd.c
[]
> > @@ -957,7 +957,7 @@ static void traffic_status_watchdog(struct rtw_adapter 
> > *padapter)
> > /*  check traffic for  powersaving. */
> > if (((pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod +
> >   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod) > 8) ||
> > -   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod >2)
> > +   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod > 
> > 2)
> > bEnterPS = false;
> > else
> > bEnterPS = true;
> 
> This makes the line longer than 80 characters, that is worse than the
> 'problem' you are fixing.

The code already has dozens of long lines already.

This is generally a problem because the variable names
are pretty long so strict 80 column adherence generally
isn't possible.

A possible way to shorten these relatively long variable
name/line lengths is to use a temporary for

pmlmeprv->LinkDetectInfo

struct rt_link_detect *ldi = &pmlmeprv->LinkDetectInfo;

so:

 drivers/staging/rtl8723au/core/rtw_cmd.c | 46 
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index d2d7edf..1b24945 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -922,34 +922,33 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
u8 bHigherBusyTxTraffic = false;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
int BusyThreshold = 100;
+   struct rt_link_detect *ldi = &pmlmepriv->LinkDetectInfo;
+
/*  */
/*  Determine if our traffic is busy now */
/*  */
if (check_fwstate(pmlmepriv, _FW_LINKED)) {
if (rtl8723a_BT_coexist(padapter))
BusyThreshold = 50;
-   else if (pmlmepriv->LinkDetectInfo.bBusyTraffic)
+   else if (ldi->bBusyTraffic)
BusyThreshold = 75;
/*  if we raise bBusyTraffic in last watchdog, using
lower threshold. */
-   if (pmlmepriv->LinkDetectInfo.NumRxOkInPeriod > BusyThreshold ||
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod > BusyThreshold) {
+   if (ldi->NumRxOkInPeriod > BusyThreshold ||
+   ldi->NumTxOkInPeriod > BusyThreshold) {
bBusyTraffic = true;
 
-   if (pmlmepriv->LinkDetectInfo.NumRxOkInPeriod >
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod)
+   if (ldi->NumRxOkInPeriod > ldi->NumTxOkInPeriod)
bRxBusyTraffic = true;
else
bTxBusyTraffic = true;
}
 
/*  Higher Tx/Rx data. */
-   if (pmlmepriv->LinkDetectInfo.NumRxOkInPeriod > 4000 ||
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod > 4000) {
+   if (ldi->NumRxOkInPeriod > 4000 ||
+   ldi->NumTxOkInPeriod > 4000) {
bHigherBusyTraffic = true;
-
-   if (pmlmepriv->LinkDetectInfo.NumRxOkInPeriod >
-   pmlmepriv->LinkDetectInfo.NumTxOkInPeriod)
+   if (ldi->NumRxOkInPeriod > ldi->NumTxOkInPeriod)
bHigherBusyRxTraffic = true;
else
bHigherBusyTxTraffic = true;
@@ -958,9 +957,9 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
if (!rtl8723a_BT_coexist(padapter) ||
!rtl8723a_BT_using_antenna_1(padapter)) {
/*  check traffic for  powersaving. */
-   if (((pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod +
- pmlmepriv->LinkDetectInfo.NumTxOkInPeriod) > 8) ||
-   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod >2)
+   if (((ldi->NumRxUnicastOkInPeriod +
+ ldi->NumTxOkInPeriod) > 8) ||
+   ldi->NumRxUnicastOkInPeriod > 2)
bEnterPS = false;
else
bEnterPS = true;
@@ -971,18 +970,19 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
else
LPS_Leave23a(padapter);
}
-   } else
+   } else {
LPS_Leave23a(padapter);
+

Re: Questions regarding ath9k and new EN 300 328 regulation

[Zefir Kurtisi]

On 10/27/2014 03:18 PM, Adrien Decostre wrote:
> Hello Zefir,
> 
> Thanks a lot for your answer. This helps me a lot.
> If I correctly understand, the ability of ath9k to detect all pulses
> may also depend of the platform performances. So on an embedded
> platform with limited performances, we may observe more pulses losses
> than on a more powerful platform. Is this a right statement?
> 
No, there is no bottleneck in the platform performance. Presumed radar pulses 
are
reported as RX_ERROR descriptors and even lower end embedded systems are able to
handle the load. What makes the difference with the minimum pulse width is the
chip DFS engine's ability to isolate and identify very short spikes as potential
radar pulses.

This goes very deeply into material I had available under NDA while implementing
the DFS support for ath9k. If you intend to work on that topic, I encourage you 
to
contact the folks at QCA and join their 'NDA for Developers' program. The 
document
you want to read is 'Baseband DFS 2 (Radar) Micro-Architecture'.

> What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need it
> to enable the detection of 0.5usec. pulses?
> 
Yes, this driver specific flag (also available for 10k) you need to set to get 
the
DFS detector built (not related to pulse width). It essentially shifts the
responsibility of the product working in restricted bands to you / the 
manufacturer.


> Thanks in advance for your answer.
> 
> Best regards
> 
> Adrien
> 

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

Re: [PATCH 0/3] Add mcast event when hwsim radios are created and removed

[Marcel Holtmann]

Hi Johannes,

>>> That's not particularly hard to figure out, for example by looking at
>>> sysfs.
>>> 
>>> Is this really so time-constrained/important/... that you can't do that?
>> 
>> It does not seem very practical to dig this information from sysfs as
>> the same information can be easily get via netlink as this patch shows.
> 
> Well, that's a slippery slope. I'd consider it more practical to use
> existing APIs instead of (gratuitously) inventing new ones. It'll even
> work on older kernels as an added benefit.

I see that different. The component that handles the emulation of the new 
wireless device should be independent from the component driving it. I prefer 
to have a race free way of obtaining the needed information without having to 
monitor nl80211 and sysfs for this. Especially with the use cases that we have 
in mind it has no business with these other interfaces.

We have been down this route with the bridge interface where people had to dig 
out information from sysfs and it did not work out nicely. So now everything 
moves to netlink.

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

Re: Questions regarding ath9k and new EN 300 328 regulation

[Adrien Decostre]

Hello Zefir,

Thanks a lot for your answer. This helps me a lot.
If I correctly understand, the ability of ath9k to detect all pulses
may also depend of the platform performances. So on an embedded
platform with limited performances, we may observe more pulses losses
than on a more powerful platform. Is this a right statement?

What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need it
to enable the detection of 0.5usec. pulses?

Thanks in advance for your answer.

Best regards

Adrien

On Mon, Oct 27, 2014 at 11:43 AM, Zefir Kurtisi
 wrote:
> On 10/24/2014 05:23 PM, Adrien Decostre wrote:
>>
>> I am looking for information about the compliancy of the ath9k driver
>> to the EN 300 328 ETSI regulation.
>>
>> Would someone know if ath9k has already been tested for this regulation?
>>
>> Is it needed to enable any specific flag in ath9k to guarantee
>> compliancy to the adaptivity tests described in EN 300 328?
>>
>>
> The pattern detector currently used in ath was initially developed for ath9k 
> when
> EN 300.328 v1.5.1 was released. It passed the ETSI certification in a German 
> lab
> and the source code (besides moving it up in the tree to be also available for
> 10k) was basically not touched ever since.
>
> I did not track all the DFS requirement changes up to the latest v1.9.1 
> draft, but
> afaik the sole difference relevant for the detector is the reduction of the
> shortest pulses width in the test pattern specification from 0.7 to 0.5us. 
> With
> that, the chance of the current implementation to pass a v1.8 certification
> depends on ath9k's ability to detect the shorter pulses. I did some initial
> measurements years ago to get a rough picture, which showed that the ath9k is
> losing like 30% of the 0.5us pulses (as compared to .7us).
>
> With the patches you referred, YMMV - you would need to perform thorough
> statistical analyses to get an estimate on whether it would pass.
>
> As for the adaptivity tests, they are not part of DFS (see note in 4.9.1) and
> maybe would best fit within the ACS module
> (http://wireless.kernel.org/en/users/Documentation/acs). The current DFS 
> support
> available in ath9k is limited to bare radar detection, which is enabled 
> through
> CONFIG_CFG80211_CERTIFICATION_ONUS.
>
>
> Cheers,
> Zefir
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] wireless: nl80211: Broadcast CMD_NEW_INTERFACE and CMD_DEL_INTERFACE

[Tomasz Bursztyka]

Let the other listeners being notified when a new or del interface
command has been issued, thus reducing later necessary request to be in
sync with current context.

Signed-off-by: Tomasz Bursztyka 
---

Hi, 

In order not to change current API behavior for the command issuer, I kept
the reply for NEW_INTERFACE unicasted, as well as the returned status for
DEL_INTERFACE. This patch only add the notification for all other listeners.

It bloats a bit nl80211_send_iface() function (I wanted to reuse its logic
for both commands). Tell me if you would prefer a better way to do this.

Tomasz

 net/wireless/nl80211.c | 82 +-
 1 file changed, 67 insertions(+), 15 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cb9f5a4..b555c26 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2336,12 +2336,18 @@ static int nl80211_send_chandef(struct sk_buff *msg,
 
 static int nl80211_send_iface(struct sk_buff *msg, u32 portid, u32 seq, int 
flags,
  struct cfg80211_registered_device *rdev,
- struct wireless_dev *wdev)
+ struct wireless_dev *wdev,
+ enum nl80211_iftype iftype, u64 wdev_id,
+ u8 *wdev_address, struct net_device *dev,
+ u8 ssid_len, u8 *ssid, bool new)
 {
-   struct net_device *dev = wdev->netdev;
+   u8 cmd = NL80211_CMD_NEW_INTERFACE;
void *hdr;
 
-   hdr = nl80211hdr_put(msg, portid, seq, flags, 
NL80211_CMD_NEW_INTERFACE);
+   if (!new)
+   cmd = NL80211_CMD_DEL_INTERFACE;
+
+   hdr = nl80211hdr_put(msg, portid, seq, flags, cmd);
if (!hdr)
return -1;
 
@@ -2351,15 +2357,15 @@ static int nl80211_send_iface(struct sk_buff *msg, u32 
portid, u32 seq, int flag
goto nla_put_failure;
 
if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
-   nla_put_u32(msg, NL80211_ATTR_IFTYPE, wdev->iftype) ||
-   nla_put_u64(msg, NL80211_ATTR_WDEV, wdev_id(wdev)) ||
-   nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, wdev_address(wdev)) ||
+   nla_put_u32(msg, NL80211_ATTR_IFTYPE, iftype) ||
+   nla_put_u64(msg, NL80211_ATTR_WDEV, wdev_id) ||
+   nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, wdev_address) ||
nla_put_u32(msg, NL80211_ATTR_GENERATION,
rdev->devlist_generation ^
(cfg80211_rdev_list_generation << 2)))
goto nla_put_failure;
 
-   if (rdev->ops->get_channel) {
+   if (wdev && rdev->ops->get_channel) {
int ret;
struct cfg80211_chan_def chandef;
 
@@ -2370,10 +2376,8 @@ static int nl80211_send_iface(struct sk_buff *msg, u32 
portid, u32 seq, int flag
}
}
 
-   if (wdev->ssid_len) {
-   if (nla_put(msg, NL80211_ATTR_SSID, wdev->ssid_len, wdev->ssid))
+   if (ssid_len && nla_put(msg, NL80211_ATTR_SSID, ssid_len, ssid))
goto nla_put_failure;
-   }
 
return genlmsg_end(msg, hdr);
 
@@ -2382,6 +2386,28 @@ static int nl80211_send_iface(struct sk_buff *msg, u32 
portid, u32 seq, int flag
return -EMSGSIZE;
 }
 
+static void nl80211_notify_iface(struct cfg80211_registered_device *rdev,
+struct wireless_dev *wdev,
+enum nl80211_iftype iftype, u64 wdev_id,
+u8 *wdev_address, struct net_device *dev,
+u8 ssid_len, u8 *ssid, bool new, u32 portid)
+{
+   struct sk_buff *msg;
+
+   msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+   if (!msg)
+   return;
+
+   if (nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, iftype, wdev_id,
+  wdev_address, dev, ssid_len, ssid, new) < 0) {
+   nlmsg_free(msg);
+   return;
+   }
+
+   genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy),
+   msg, portid, NL80211_MCGRP_CONFIG, GFP_KERNEL);
+}
+
 static int nl80211_dump_interface(struct sk_buff *skb, struct netlink_callback 
*cb)
 {
int wp_idx = 0;
@@ -2408,7 +2434,11 @@ static int nl80211_dump_interface(struct sk_buff *skb, 
struct netlink_callback *
}
if (nl80211_send_iface(skb, NETLINK_CB(cb->skb).portid,
   cb->nlh->nlmsg_seq, NLM_F_MULTI,
-  rdev, wdev) < 0) {
+  rdev, wdev, wdev->iftype,
+  wdev_id(wdev),
+  wdev_address(wdev),
+  wdev->netdev, wdev->ssid_len,
+ 

[PATCH] wireless-regdb: Add 5490-5710 MHz to Bulgaria (BG)

[Jouni Malinen]

Source is QCA's regulatory team's efforts.

Signed-off-by: Jouni Malinen 
---
 db.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/db.txt b/db.txt
index 1df0b4c..43afa5c 100644
--- a/db.txt
+++ b/db.txt
@@ -133,6 +133,7 @@ country BG: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+   (5490 - 5710 @ 160), (27), DFS
# 60 gHz band channels 1-4, ref: Etsi En 302 567
(57240 - 65880 @ 2160), (40), NO-OUTDOOR
 
-- 
1.9.1


-- 
Jouni MalinenPGP id EFC895FA
--
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] wireless-regdb: Add 160 MHz channel bandwidth for China (CN)

[Jouni Malinen]

This extends regulatory rules for China to allow 160 MHz VHT channels to
be used in 5.15-5.25 GHz, 5.25-5.35 GHz. Since the rules between
5.15-5.25 and 5.25-5.35 GHz ranges are different (e.g., DFS
requirement), the AUTO-BW flag needs to be used to allow the maximum
channel bandwidth to be determined automatically based on two rules.

Signed-off-by: Jouni Malinen 
---
 db.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/db.txt b/db.txt
index b58cc8d..1df0b4c 100644
--- a/db.txt
+++ b/db.txt
@@ -223,8 +223,8 @@ country CL: DFS-JP
 
 country CN: DFS-FCC
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (23)
-   (5250 - 5330 @ 80), (23), DFS
+   (5170 - 5250 @ 80), (23), AUTO-BW
+   (5250 - 5330 @ 80), (23), DFS, AUTO-BW
(5735 - 5835 @ 80), (30)
# 60 gHz band channels 1,4: 28dBm, channels 2,3: 44dBm
# ref: 
http://www.miit.gov.cn/n11293472/n11505629/n11506593/n11960250/n11960606/n11960700/n12330791.files/n12330790.pdf
-- 
1.9.1


-- 
Jouni MalinenPGP id EFC895FA
--
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 0/3] Add mcast event when hwsim radios are created and removed

[Johannes Berg]

On Mon, 2014-10-27 at 13:55 +0200, Jukka Rissanen wrote:

> > That's not particularly hard to figure out, for example by looking at
> > sysfs.
> > 
> > Is this really so time-constrained/important/... that you can't do that?
> 
> It does not seem very practical to dig this information from sysfs as
> the same information can be easily get via netlink as this patch shows.

Well, that's a slippery slope. I'd consider it more practical to use
existing APIs instead of (gratuitously) inventing new ones. It'll even
work on older kernels as an added benefit.

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: [ath9k-devel] strange MPDU loss pattern

[Felix Fietkau]

Hi Seongho,

that paper looks quite interesting.
Are you planning to publish code/patches for your implementation as well?
It would be nice to have dynamic A-MPDU limiting integrated in minstrel_ht.

Thanks,

- Felix

On 26/10/2014 12:14 AM, Seongho Byeon wrote:
>
> Hi, I am Ph.d. student in Seoul National University , Korea.
> Recently, we have dealt with the problem you observe, and we published
> a paper into CoNEXT 2014 which is a major conference in our field.
>
> Title of the paper 'MoFa: Mobility-aware Frame Aggregation in WiFi
> networks'.
> You can download it a site below.
> http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/14-CONEXT-BYEON.pdf
> 
> If you have a question please contact me anytime.
>
> Best regards,
> Seongho Byeon.
>
> Thank you for sharing the story.
> Even if I consider interference as a possibility, still I can't
> justify the higher
> chance of frame loss in the second half of the aggregate frame.
>
> We use
>
> PCI-express 3 antenna dual band cards
> product: AR93xx Wireless Network Adapter
> and/or
> Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop
>
> we also tried TP-LINK TL-WDN4200 N900as the receiver.
>
> However we see the same results.
> we mostly use MCS 20-23, sgi = 0, 20 MHz channels.
>
> The loss pattern is something like this
> (each line is an imaginary aggregated frame and each bit is the fate
> of the MPDU)
>
> 00011
> 11100011010110100
> 1
> 111010100
> 110010101
>
> The interesting part is that with the start of the next frame error
> rate goes down initially
> then it goes up again in the second portion of the packet.
>
> Best,
> Ali
>
>
> On 25/10/2014 2:30 PM, Adrian Chadd wrote:
>
> On 25 October 2014 08:28, Ali Abedi
> wrote:
>
> Hi Adrian, We have a high end spectrum analyzer. So we are
> sure there is no background interference We run our
> experiments in the 5 GHZ spectrum. The channel conditions can
> still vary due to the movement of the people in the vicinity
> of the experiment setup. We select a rate that experiences at
> least 20% error on average. Since if the error is 100% or 0%
> it's not interesting for us. My point is if the channel
> conditions change the distribution of failed packets should be
> uniform. The first and second half of the packets have the
> same chance to be received successfully.
>
> Here's a little story. My first wifi contract had me spend months
> trying to figure out why an AP was losing its mind. It'd get stuck
> in a "stuck beacon" loop and only a hard powercycle of /all/ of
> the access points in an area would clear it. It turned out that
> the PCB design had some non-grounded / non-populated tracks that
> just "happened" to form a 2GHz resonator. Once we grounded those
> tracks, the APs started behaving themselves. The company in
> question spent months with high end spectrum analysis kit in the
> lab (where it never happened) and underground (where it did
> happen.) It's only after they stuck the spectrum analyser probe
> _inside the access point_ right up close to the NIC did they see
> it. Here's the spectrum analyser traces. You can see the
> peak.http://www.creative.net.au/ath/So, weirder crap has happened.
> Which NICs and which MCS rates are you using? -adrian
>
> ___
> ath9k-devel mailing list
> ath9k-de...@lists.ath9k.org 
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
--
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 0/3] Add mcast event when hwsim radios are created and removed

[Jukka Rissanen]

On ma, 2014-10-27 at 12:31 +0100, Johannes Berg wrote:
> On Mon, 2014-10-27 at 13:29 +0200, Jukka Rissanen wrote:
> 
> > Yes, but from generic nl80211 event you cannot know if event is from
> > hwsim radio or not. With this patch, the listener can know that the
> > radio new/del event is specifically related to hwsim radio.
> 
> That's not particularly hard to figure out, for example by looking at
> sysfs.
> 
> Is this really so time-constrained/important/... that you can't do that?

It does not seem very practical to dig this information from sysfs as
the same information can be easily get via netlink as this patch shows.


Cheers,
Jukka


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

Re: [PATCH v2 01/10] ath9k_hw: make support for PC-OEM cards optional

[Felix Fietkau]

On 2014-10-27 12:40, Sujith Manoharan wrote:
> Hi,
> 
> This series looks good to me...
Thanks for the review

- 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 v2 01/10] ath9k_hw: make support for PC-OEM cards optional

[Sujith Manoharan]

Hi,

This series looks good to me...

Sujith

Felix Fietkau wrote:
> The initvals use up quite a bit of space, and PC-OEM support is
> typically not needed on embedded systems
> 
> Signed-off-by: Felix Fietkau 
> ---
>  drivers/net/wireless/ath/ath9k/Kconfig  |  5 
>  drivers/net/wireless/ath/ath9k/Makefile |  3 ++-
>  drivers/net/wireless/ath/ath9k/ar9003_rtt.h | 36 
> +
>  drivers/net/wireless/ath/ath9k/hw.h | 17 ++
>  drivers/net/wireless/ath/ath9k/init.c   |  3 +++
>  drivers/net/wireless/ath/ath9k/pci.c|  6 +
>  drivers/net/wireless/ath/ath9k/reg.h| 33 +++---
>  7 files changed, 84 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
> b/drivers/net/wireless/ath/ath9k/Kconfig
> index 896e632..ca101d7 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -148,6 +148,11 @@ config ATH9K_CHANNEL_CONTEXT
>for multi-channel concurrency. Enable this if P2P PowerSave support
>is required.
>  
> +config ATH9K_PCOEM
> + bool "Atheros ath9k support for PC OEM cards" if EXPERT
> + depends on ATH9K
> + default y
> +
>  config ATH9K_HTC
> tristate "Atheros HTC based wireless cards support"
> depends on USB && MAC80211
> diff --git a/drivers/net/wireless/ath/ath9k/Makefile 
> b/drivers/net/wireless/ath/ath9k/Makefile
> index 73704c1..22b934b 100644
> --- a/drivers/net/wireless/ath/ath9k/Makefile
> +++ b/drivers/net/wireless/ath/ath9k/Makefile
> @@ -32,7 +32,6 @@ ath9k_hw-y:=\
>   ar5008_phy.o \
>   ar9002_calib.o \
>   ar9003_calib.o \
> - ar9003_rtt.o \
>   calib.o \
>   eeprom.o \
>   eeprom_def.o \
> @@ -50,6 +49,8 @@ ath9k_hw-$(CONFIG_ATH9K_WOW) += ar9003_wow.o
>  ath9k_hw-$(CONFIG_ATH9K_BTCOEX_SUPPORT) += btcoex.o \
>  ar9003_mci.o
>  
> +ath9k_hw-$(CONFIG_ATH9K_PCOEM) += ar9003_rtt.o
> +
>  ath9k_hw-$(CONFIG_ATH9K_DYNACK) += dynack.o
>  
>  obj-$(CONFIG_ATH9K_HW) += ath9k_hw.o
> diff --git a/drivers/net/wireless/ath/ath9k/ar9003_rtt.h 
> b/drivers/net/wireless/ath/ath9k/ar9003_rtt.h
> index a43b30d..6290467 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9003_rtt.h
> +++ b/drivers/net/wireless/ath/ath9k/ar9003_rtt.h
> @@ -17,6 +17,7 @@
>  #ifndef AR9003_RTT_H
>  #define AR9003_RTT_H
>  
> +#ifdef CONFIG_ATH9K_PCOEM
>  void ar9003_hw_rtt_enable(struct ath_hw *ah);
>  void ar9003_hw_rtt_disable(struct ath_hw *ah);
>  void ar9003_hw_rtt_set_mask(struct ath_hw *ah, u32 rtt_mask);
> @@ -25,5 +26,40 @@ void ar9003_hw_rtt_load_hist(struct ath_hw *ah);
>  void ar9003_hw_rtt_fill_hist(struct ath_hw *ah);
>  void ar9003_hw_rtt_clear_hist(struct ath_hw *ah);
>  bool ar9003_hw_rtt_restore(struct ath_hw *ah, struct ath9k_channel *chan);
> +#else
> +static inline void ar9003_hw_rtt_enable(struct ath_hw *ah)
> +{
> +}
> +
> +static inline void ar9003_hw_rtt_disable(struct ath_hw *ah)
> +{
> +}
> +
> +static inline void ar9003_hw_rtt_set_mask(struct ath_hw *ah, u32 rtt_mask)
> +{
> +}
> +
> +static inline bool ar9003_hw_rtt_force_restore(struct ath_hw *ah)
> +{
> + return false;
> +}
> +
> +static inline void ar9003_hw_rtt_load_hist(struct ath_hw *ah)
> +{
> +}
> +
> +static inline void ar9003_hw_rtt_fill_hist(struct ath_hw *ah)
> +{
> +}
> +
> +static inline void ar9003_hw_rtt_clear_hist(struct ath_hw *ah)
> +{
> +}
> +
> +static inline bool ar9003_hw_rtt_restore(struct ath_hw *ah, struct 
> ath9k_channel *chan)
> +{
> + return false;
> +}
> +#endif
>  
>  #endif
> diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
> b/drivers/net/wireless/ath/ath9k/hw.h
> index 975074f..7a81f5b 100644
> --- a/drivers/net/wireless/ath/ath9k/hw.h
> +++ b/drivers/net/wireless/ath/ath9k/hw.h
> @@ -244,13 +244,20 @@ enum ath9k_hw_caps {
>   ATH9K_HW_CAP_2GHZ   = BIT(11),
>   ATH9K_HW_CAP_5GHZ   = BIT(12),
>   ATH9K_HW_CAP_APM= BIT(13),
> +#ifdef CONFIG_ATH9K_PCOEM
>   ATH9K_HW_CAP_RTT= BIT(14),
>   ATH9K_HW_CAP_MCI= BIT(15),
> - ATH9K_HW_CAP_DFS= BIT(16),
> - ATH9K_HW_WOW_DEVICE_CAPABLE = BIT(17),
> - ATH9K_HW_CAP_PAPRD  = BIT(18),
> - ATH9K_HW_CAP_FCC_BAND_SWITCH= BIT(19),
> - ATH9K_HW_CAP_BT_ANT_DIV = BIT(20),
> + ATH9K_HW_WOW_DEVICE_CAPABLE = BIT(16),
> + ATH9K_HW_CAP_BT_ANT_DIV = BIT(17),
> +#else
> + ATH9K_HW_CAP_RTT= 0,
> + ATH9K_HW_CAP_MCI= 0,
> + ATH9K_HW_WOW_DEVICE_CAPABLE = 0,
> + ATH9K_HW_CAP_BT_ANT_DIV = 0,
> +#endif
> + ATH9K_HW_CAP_DFS= BIT(18),
> + ATH9K_HW_CAP_PAPRD

Re: [PATCH 0/3] Add mcast event when hwsim radios are created and removed

[Johannes Berg]

On Mon, 2014-10-27 at 13:29 +0200, Jukka Rissanen wrote:

> Yes, but from generic nl80211 event you cannot know if event is from
> hwsim radio or not. With this patch, the listener can know that the
> radio new/del event is specifically related to hwsim radio.

That's not particularly hard to figure out, for example by looking at
sysfs.

Is this really so time-constrained/important/... that you can't do that?

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: [PATCH 0/3] Add mcast event when hwsim radios are created and removed

[Jukka Rissanen]

Hi Johannes,

On ma, 2014-10-27 at 12:20 +0100, Johannes Berg wrote:
> On Mon, 2014-10-27 at 12:44 +0200, Jukka Rissanen wrote:
> > Hi,
> > 
> > patch 1 renames HWSIM_CMD_CREATE_RADIO to HWSIM_CMD_NEW_RADIO and
> > HWSIM_CMD_DESTROY_RADIO to HWSIM_CMD_DEL_RADIO. They are more
> > fitting on how other pieces of the wireless system work. A define
> > to old name is provided for backward compatibility.
> 
> That seems reasonable, if a little gratuitous.
> 
> > Patches 2 and 3 use the newly named enums and provide a way to inform
> > the listeners on the multicast group "config" when new radio is created
> > and existing radio is deleted.
> 
> Why bother? There are nl80211 events for this already, no?

Yes, but from generic nl80211 event you cannot know if event is from
hwsim radio or not. With this patch, the listener can know that the
radio new/del event is specifically related to hwsim radio.


Cheers,
Jukka


--
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] net: rfkill: gpio: Add default GPIO driver mappings for ACPI

[Johannes Berg]

On Mon, 2014-10-27 at 12:15 +0200, Mika Westerberg wrote:
> The driver uses devm_gpiod_get_index(..., index) so that the index refers
> directly to the GpioIo resource under the ACPI device. The problem with
> this is that if the ordering changes we get wrong GPIOs.
> 
> With ACPI 5.1 _DSD we can now use names instead to reference GPIOs
> analogous to Device Tree. However, we still have systems out there that do
> not provide _DSD at all. These systems must be supported as well.
> 
> Luckily we now have acpi_dev_add_driver_gpios() that can be used to provide
> mappings for systems where _DSD is not provided and still take advantage of
> _DSD if it exists.
> 
> This patch changes the driver to create default GPIO mappings if we are
> running on ACPI system.
> 
> While there we can drop the indices completely and use devm_gpiod_get()
> with name instead.
> 
> Signed-off-by: Mika Westerberg 
> ---
> Hi,
> 
> This patch is based on top of linux-pm/device-properties [1] and following
> patch from Rafael [2].
> 
> Johannes, John,
> 
> If you are happy with the patch, can you ACK it so that we can merge it
> with the rest of the device-properties patches. Thanks.

Acked-by: Johannes Berg 
Reviewed-by: Johannes Berg 

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: [PATCH 0/3] Add mcast event when hwsim radios are created and removed

[Johannes Berg]

On Mon, 2014-10-27 at 12:44 +0200, Jukka Rissanen wrote:
> Hi,
> 
> patch 1 renames HWSIM_CMD_CREATE_RADIO to HWSIM_CMD_NEW_RADIO and
> HWSIM_CMD_DESTROY_RADIO to HWSIM_CMD_DEL_RADIO. They are more
> fitting on how other pieces of the wireless system work. A define
> to old name is provided for backward compatibility.

That seems reasonable, if a little gratuitous.

> Patches 2 and 3 use the newly named enums and provide a way to inform
> the listeners on the multicast group "config" when new radio is created
> and existing radio is deleted.

Why bother? There are nl80211 events for this already, no?

johannes

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

[PATCH 3.18] mac80211: flush keys for AP mode on ieee80211_do_stop

[Felix Fietkau]

Userspace can add keys to an AP mode interface before start_ap has been
called. If there have been no calls to start_ap/stop_ap in the mean
time, the keys will still be around when the interface is brought down.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/iface.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index af23722..b8efd5b 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -931,9 +931,6 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data 
*sdata,
 * another CPU.
 */
ieee80211_free_keys(sdata, true);
-
-   /* fall through */
-   case NL80211_IFTYPE_AP:
skb_queue_purge(&sdata->skb_queue);
}
 
-- 
2.1.2

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

Re: Questions regarding ath9k and new EN 300 328 regulation

[Zefir Kurtisi]

On 10/24/2014 05:23 PM, Adrien Decostre wrote:
> 
> I am looking for information about the compliancy of the ath9k driver
> to the EN 300 328 ETSI regulation.
> 
> Would someone know if ath9k has already been tested for this regulation?
> 
> Is it needed to enable any specific flag in ath9k to guarantee
> compliancy to the adaptivity tests described in EN 300 328?
> 
> 
The pattern detector currently used in ath was initially developed for ath9k 
when
EN 300.328 v1.5.1 was released. It passed the ETSI certification in a German lab
and the source code (besides moving it up in the tree to be also available for
10k) was basically not touched ever since.

I did not track all the DFS requirement changes up to the latest v1.9.1 draft, 
but
afaik the sole difference relevant for the detector is the reduction of the
shortest pulses width in the test pattern specification from 0.7 to 0.5us. With
that, the chance of the current implementation to pass a v1.8 certification
depends on ath9k's ability to detect the shorter pulses. I did some initial
measurements years ago to get a rough picture, which showed that the ath9k is
losing like 30% of the 0.5us pulses (as compared to .7us).

With the patches you referred, YMMV - you would need to perform thorough
statistical analyses to get an estimate on whether it would pass.

As for the adaptivity tests, they are not part of DFS (see note in 4.9.1) and
maybe would best fit within the ACS module
(http://wireless.kernel.org/en/users/Documentation/acs). The current DFS support
available in ath9k is limited to bare radar detection, which is enabled through
CONFIG_CFG80211_CERTIFICATION_ONUS.


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

[PATCH 2/3] mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO

[Jukka Rissanen]

When adding new radio via HWSIM_CMD_NEW_RADIO then listeners on the
multicast group "config" are informed.

Signed-off-by: Jukka Rissanen 
---
 drivers/net/wireless/mac80211_hwsim.c | 141 +-
 1 file changed, 123 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index babbdc1..74bc1db 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -476,6 +476,14 @@ static struct genl_family hwsim_genl_family = {
.maxattr = HWSIM_ATTR_MAX,
 };
 
+enum hwsim_multicast_groups {
+   HWSIM_MCGRP_CONFIG,
+};
+
+static const struct genl_multicast_group hwsim_mcgrps[] = {
+   [HWSIM_MCGRP_CONFIG] = { .name = "config", },
+};
+
 /* MAC80211_HWSIM netlink policy */
 
 static const struct nla_policy hwsim_genl_policy[HWSIM_ATTR_MAX + 1] = {
@@ -1943,10 +1951,101 @@ static const struct ieee80211_ops mac80211_hwsim_ops = 
{
 
 static struct ieee80211_ops mac80211_hwsim_mchan_ops;
 
-static int mac80211_hwsim_create_radio(int channels, const char *reg_alpha2,
-  const struct ieee80211_regdomain *regd,
-  bool reg_strict, bool p2p_device,
-  bool use_chanctx)
+static void mcast_msg(struct sk_buff *mcast_skb, struct genl_info *info)
+{
+   if (info)
+   genl_notify(&hwsim_genl_family, mcast_skb,
+   genl_info_net(info), info->snd_portid,
+   HWSIM_MCGRP_CONFIG, info->nlhdr, GFP_KERNEL);
+   else
+   genlmsg_multicast(&hwsim_genl_family, mcast_skb, 0,
+ HWSIM_MCGRP_CONFIG, GFP_KERNEL);
+}
+
+static void mcast_new_radio(int id, struct genl_info *info,
+   int channels, const char *reg_alpha2,
+   const struct ieee80211_regdomain *regd,
+   bool reg_strict, bool p2p_device,
+   bool use_chanctx)
+{
+   struct sk_buff *mcast_skb;
+   void *data;
+   int ret;
+
+   mcast_skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_KERNEL);
+   if (!mcast_skb)
+   return;
+
+   data = genlmsg_put(mcast_skb, 0, 0, &hwsim_genl_family, 0,
+  HWSIM_CMD_NEW_RADIO);
+   if (!data)
+   goto error;
+
+   ret = nla_put_u32(mcast_skb, HWSIM_ATTR_RADIO_ID, id);
+   if (ret < 0)
+   goto error;
+
+   if (channels) {
+   ret = nla_put_u32(mcast_skb, HWSIM_ATTR_CHANNELS, channels);
+   if (ret < 0)
+   goto error;
+   }
+
+   if (reg_alpha2) {
+   ret = nla_put(mcast_skb, HWSIM_ATTR_REG_HINT_ALPHA2, 2,
+ reg_alpha2);
+   if (ret < 0)
+   goto error;
+   }
+
+   if (regd) {
+   int i;
+
+   for (i = 0; hwsim_world_regdom_custom[i] != regd &&
+i < ARRAY_SIZE(hwsim_world_regdom_custom); i++)
+   ;
+
+   if (i < ARRAY_SIZE(hwsim_world_regdom_custom)) {
+   ret = nla_put_u32(mcast_skb, HWSIM_ATTR_REG_CUSTOM_REG,
+ i);
+   if (ret < 0)
+   goto error;
+   }
+   }
+
+   if (reg_strict) {
+   ret = nla_put_flag(mcast_skb, HWSIM_ATTR_REG_STRICT_REG);
+   if (ret < 0)
+   goto error;
+   }
+
+   if (p2p_device) {
+   ret = nla_put_flag(mcast_skb, HWSIM_ATTR_SUPPORT_P2P_DEVICE);
+   if (ret < 0)
+   goto error;
+   }
+
+   if (use_chanctx) {
+   ret = nla_put_flag(mcast_skb, HWSIM_ATTR_USE_CHANCTX);
+   if (ret < 0)
+   goto error;
+   }
+
+   genlmsg_end(mcast_skb, data);
+
+   mcast_msg(mcast_skb, info);
+
+   return;
+
+error:
+   nlmsg_free(mcast_skb);
+}
+
+static int mac80211_hwsim_new_radio(struct genl_info *info,
+   int channels, const char *reg_alpha2,
+   const struct ieee80211_regdomain *regd,
+   bool reg_strict, bool p2p_device,
+   bool use_chanctx)
 {
int err;
u8 addr[ETH_ALEN];
@@ -2180,6 +2279,10 @@ static int mac80211_hwsim_create_radio(int channels, 
const char *reg_alpha2,
list_add_tail(&data->list, &hwsim_radios);
spin_unlock_bh(&hwsim_radio_lock);
 
+   if (idx > 0)
+   mcast_new_radio(idx, info, channels, reg_alpha2,
+   regd, reg_strict, p2p_device, use_chanctx);
+
return idx;
 
 failed_hw:
@@ -2427,7 +2530,7 @@ static int hwsim_register_received_nl(struct sk_buff 
*skb_2,
r

[PATCH 1/3] mac80211-hwsim: Rename CREATE and DESTROY radio to NEW and DEL radio

[Jukka Rissanen]

Using the name HWSIM_CMD_NEW_RADIO and HWSIM_CMD_DEL_RADIO is more
fitting on how other pieces of the wireless system work.

Signed-off-by: Jukka Rissanen 
---
 drivers/net/wireless/mac80211_hwsim.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.h 
b/drivers/net/wireless/mac80211_hwsim.h
index c9d0315..1f4f790 100644
--- a/drivers/net/wireless/mac80211_hwsim.h
+++ b/drivers/net/wireless/mac80211_hwsim.h
@@ -65,9 +65,10 @@ enum hwsim_tx_control_flags {
  * kernel, uses:
  * %HWSIM_ATTR_ADDR_TRANSMITTER, %HWSIM_ATTR_FLAGS,
  * %HWSIM_ATTR_TX_INFO, %HWSIM_ATTR_SIGNAL, %HWSIM_ATTR_COOKIE
- * @HWSIM_CMD_CREATE_RADIO: create a new radio with the given parameters,
- * returns the radio ID (>= 0) or negative on errors
- * @HWSIM_CMD_DESTROY_RADIO: destroy a radio
+ * @HWSIM_CMD_NEW_RADIO: create a new radio with the given parameters,
+ * returns the radio ID (>= 0) or negative on errors, if successful
+ * then multicast the result
+ * @HWSIM_CMD_DEL_RADIO: destroy a radio, reply is multicasted
  * @__HWSIM_CMD_MAX: enum limit
  */
 enum {
@@ -75,12 +76,15 @@ enum {
HWSIM_CMD_REGISTER,
HWSIM_CMD_FRAME,
HWSIM_CMD_TX_INFO_FRAME,
-   HWSIM_CMD_CREATE_RADIO,
-   HWSIM_CMD_DESTROY_RADIO,
+   HWSIM_CMD_NEW_RADIO,
+   HWSIM_CMD_DEL_RADIO,
__HWSIM_CMD_MAX,
 };
 #define HWSIM_CMD_MAX (_HWSIM_CMD_MAX - 1)
 
+#define HWSIM_CMD_CREATE_RADIO   HWSIM_CMD_NEW_RADIO
+#define HWSIM_CMD_DESTROY_RADIO  HWSIM_CMD_DEL_RADIO
+
 /**
  * enum hwsim_attrs - hwsim netlink attributes
  *
-- 
1.8.3.1

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

[PATCH 3/3] mac80211-hwsim: Provide multicast event for HWSIM_CMD_DEL_RADIO

[Jukka Rissanen]

When deleting old radio via HWSIM_CMD_DEL_RADIO then listeners on the
multicast group "config" are informed.

Signed-off-by: Jukka Rissanen 
---
 drivers/net/wireless/mac80211_hwsim.c | 43 ++-
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 74bc1db..b50a739 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2293,8 +2293,39 @@ failed:
return err;
 }
 
-static void mac80211_hwsim_destroy_radio(struct mac80211_hwsim_data *data)
+static void mcast_del_radio(int id, struct genl_info *info)
 {
+   struct sk_buff *mcast_skb;
+   void *data;
+   int ret;
+
+   mcast_skb = genlmsg_new(GENLMSG_DEFAULT_SIZE, GFP_KERNEL);
+   if (!mcast_skb)
+   return;
+
+   data = genlmsg_put(mcast_skb, 0, 0, &hwsim_genl_family, 0,
+  HWSIM_CMD_DEL_RADIO);
+   if (!data)
+   goto error;
+
+   ret = nla_put_u32(mcast_skb, HWSIM_ATTR_RADIO_ID, id);
+   if (ret < 0)
+   goto error;
+
+   genlmsg_end(mcast_skb, data);
+
+   mcast_msg(mcast_skb, info);
+
+   return;
+
+error:
+   nlmsg_free(mcast_skb);
+}
+
+static void mac80211_hwsim_del_radio(struct mac80211_hwsim_data *data,
+struct genl_info *info)
+{
+   mcast_del_radio(data->idx, info);
debugfs_remove_recursive(data->debugfs);
ieee80211_unregister_hw(data->hw);
device_release_driver(data->dev);
@@ -2312,7 +2343,7 @@ static void mac80211_hwsim_free(void)
list))) {
list_del(&data->list);
spin_unlock_bh(&hwsim_radio_lock);
-   mac80211_hwsim_destroy_radio(data);
+   mac80211_hwsim_del_radio(data, NULL);
spin_lock_bh(&hwsim_radio_lock);
}
spin_unlock_bh(&hwsim_radio_lock);
@@ -2562,7 +2593,7 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, struct 
genl_info *info)
p2p_device, use_chanctx);
 }
 
-static int hwsim_destroy_radio_nl(struct sk_buff *msg, struct genl_info *info)
+static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
 {
struct mac80211_hwsim_data *data;
int idx;
@@ -2577,7 +2608,7 @@ static int hwsim_destroy_radio_nl(struct sk_buff *msg, 
struct genl_info *info)
continue;
list_del(&data->list);
spin_unlock_bh(&hwsim_radio_lock);
-   mac80211_hwsim_destroy_radio(data);
+   mac80211_hwsim_del_radio(data, info);
return 0;
}
spin_unlock_bh(&hwsim_radio_lock);
@@ -2610,9 +2641,9 @@ static const struct genl_ops hwsim_ops[] = {
.flags = GENL_ADMIN_PERM,
},
{
-   .cmd = HWSIM_CMD_DESTROY_RADIO,
+   .cmd = HWSIM_CMD_DEL_RADIO,
.policy = hwsim_genl_policy,
-   .doit = hwsim_destroy_radio_nl,
+   .doit = hwsim_del_radio_nl,
.flags = GENL_ADMIN_PERM,
},
 };
-- 
1.8.3.1

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

[PATCH 0/3] Add mcast event when hwsim radios are created and removed

[Jukka Rissanen]

Hi,

patch 1 renames HWSIM_CMD_CREATE_RADIO to HWSIM_CMD_NEW_RADIO and
HWSIM_CMD_DESTROY_RADIO to HWSIM_CMD_DEL_RADIO. They are more
fitting on how other pieces of the wireless system work. A define
to old name is provided for backward compatibility.

Patches 2 and 3 use the newly named enums and provide a way to inform
the listeners on the multicast group "config" when new radio is created
and existing radio is deleted.


Cheers,
Jukka


Jukka Rissanen (3):
  mac80211-hwsim: Rename CREATE and DESTROY radio to NEW and DEL radio
  mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO
  mac80211-hwsim: Provide multicast event for HWSIM_CMD_DEL_RADIO

 drivers/net/wireless/mac80211_hwsim.c | 184 +-
 drivers/net/wireless/mac80211_hwsim.h |  14 ++-
 2 files changed, 169 insertions(+), 29 deletions(-)

-- 
1.8.3.1

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

[PATCH] net: rfkill: gpio: Add default GPIO driver mappings for ACPI

[Mika Westerberg]

The driver uses devm_gpiod_get_index(..., index) so that the index refers
directly to the GpioIo resource under the ACPI device. The problem with
this is that if the ordering changes we get wrong GPIOs.

With ACPI 5.1 _DSD we can now use names instead to reference GPIOs
analogous to Device Tree. However, we still have systems out there that do
not provide _DSD at all. These systems must be supported as well.

Luckily we now have acpi_dev_add_driver_gpios() that can be used to provide
mappings for systems where _DSD is not provided and still take advantage of
_DSD if it exists.

This patch changes the driver to create default GPIO mappings if we are
running on ACPI system.

While there we can drop the indices completely and use devm_gpiod_get()
with name instead.

Signed-off-by: Mika Westerberg 
---
Hi,

This patch is based on top of linux-pm/device-properties [1] and following
patch from Rafael [2].

Johannes, John,

If you are happy with the patch, can you ACK it so that we can merge it
with the rest of the device-properties patches. Thanks.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
[2] https://lkml.org/lkml/2014/10/24/690

 net/rfkill/rfkill-gpio.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 0f62326c0f5e..2a4717967502 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -63,6 +63,15 @@ static const struct rfkill_ops rfkill_gpio_ops = {
.set_block = rfkill_gpio_set_power,
 };
 
+static const struct acpi_gpio_params reset_gpios = { 0, 0, false };
+static const struct acpi_gpio_params shutdown_gpios = { 1, 0, false };
+
+static const struct acpi_gpio_mapping acpi_rfkill_default_gpios[] = {
+   { "reset-gpios", &reset_gpios, 1 },
+   { "shutdown-gpios", &shutdown_gpios, 1 },
+   { },
+};
+
 static int rfkill_gpio_acpi_probe(struct device *dev,
  struct rfkill_gpio_data *rfkill)
 {
@@ -75,7 +84,8 @@ static int rfkill_gpio_acpi_probe(struct device *dev,
rfkill->name = dev_name(dev);
rfkill->type = (unsigned)id->driver_data;
 
-   return 0;
+   return acpi_dev_add_driver_gpios(ACPI_COMPANION(dev),
+acpi_rfkill_default_gpios);
 }
 
 static int rfkill_gpio_probe(struct platform_device *pdev)
@@ -102,7 +112,7 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
 
rfkill->clk = devm_clk_get(&pdev->dev, NULL);
 
-   gpio = devm_gpiod_get_index(&pdev->dev, "reset", 0);
+   gpio = devm_gpiod_get(&pdev->dev, "reset");
if (!IS_ERR(gpio)) {
ret = gpiod_direction_output(gpio, 0);
if (ret)
@@ -110,7 +120,7 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
rfkill->reset_gpio = gpio;
}
 
-   gpio = devm_gpiod_get_index(&pdev->dev, "shutdown", 1);
+   gpio = devm_gpiod_get(&pdev->dev, "shutdown");
if (!IS_ERR(gpio)) {
ret = gpiod_direction_output(gpio, 0);
if (ret)
@@ -150,6 +160,8 @@ static int rfkill_gpio_remove(struct platform_device *pdev)
rfkill_unregister(rfkill->rfkill_dev);
rfkill_destroy(rfkill->rfkill_dev);
 
+   acpi_dev_remove_driver_gpios(ACPI_COMPANION(&pdev->dev));
+
return 0;
 }
 
-- 
2.1.1

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

Darlehen

[SPRING FINANCE LOAN]

Sehr geehrter Herr / Frau,

 SPRING FINANCE ist ein britisches Consulting Group, der internationale Eigen- 
und Fremdkapital Projektfinanzierung, gewerbliche Immobilienfinanzierung in den 
globalen Markt. Wir werden durch den Kreditgeber zertifiziert und bieten 
besicherte Kredite an Privatpersonen und Unternehmen bei niedrigen Zinssatz von 
2%.Wir bieten lang-und kurzfristigen Darlehen. Unser Unternehmen verzeichnete 
Entdeckung vieler erstklassige Finanzdienstleistungen für Kunden, vor allem in 
die Syndizierung von Krediten und Kapital für Einzelpersonen und 
enterprises.For Weitere Informationen finden Sie, einen Kredit bei uns zu 
kaufen: Bitte antworten Sie sofort auf diese E-Mail: spring-...@admin.in.th or 
gretchenmorgan...@gmail.com Also, wenn Sie Interesse haben, freundlicherweise 
angeboten, um das Darlehen Antragsformular unten ausfüllen.

Vollständiger Name: 
Adresse: 
Darlehensbetrag: 
Kreditzweck 
Dauer: 
Land: 
 
respekt

Gretchen Morgan
--
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] ipw2x00: shift wrap bugs setting ->rt_tsf

[Dan Carpenter]

On Fri, Oct 24, 2014 at 02:43:31AM -0700, Joe Perches wrote:
> On Fri, 2014-10-24 at 11:15 +0300, Dan Carpenter wrote:
> > @@ -8028,10 +8028,10 @@ static void ipw_handle_promiscuous_rx(struct 
> > ipw_priv *priv,
> >  
> > /* Zero the flags, we'll add to them as we go */
> > ipw_rt->rt_flags = 0;
> > -   ipw_rt->rt_tsf = (u64)(frame->parent_tsf[3] << 24 |
> > -  frame->parent_tsf[2] << 16 |
> > -  frame->parent_tsf[1] << 8  |
> > -  frame->parent_tsf[0]);
> > +   ipw_rt->rt_tsf = (u64)frame->parent_tsf[3] << 24 |
> > + frame->parent_tsf[2] << 16 |
> > + frame->parent_tsf[1] << 8  |
> > + frame->parent_tsf[0];
> >  
> > /* Convert to DBM */
> > ipw_rt->rt_dbmsignal = signal;
> 
> struct ipw_rt_hdr {
>   struct ieee80211_radiotap_header rt_hdr;
>   u64 rt_tsf;  /* TSF */  /* XXX */
>   u8 rt_flags;/* radiotap packet flags *
>   u8 rt_rate; /* rate in 500kb/s */
>   __le16 rt_channel;  /* channel in mhz */
>   __le16 rt_chbitmask;/* channel bitfield */
>   s8 rt_dbmsignal;/* signal in dbM, kluged to signed */
>   s8 rt_dbmnoise;
>   u8 rt_antenna;  /* antenna number */
>   u8 payload[0];  /* payload... */
> } __packed;
> 
> Maybe rt_tsf (which is otherwise unused in this code),
> should be __le64 so maybe use (u32) ?
> 
>   ipw_rt->rt_txf = cpu_to_le64((u32)(frame->parent_tsf[3] << 24 |
>  frame->parent_tsf[2] << 16 |
>  frame->parent_tsf[1] << 8  |
>  frame->parent_tsf[0]));
> 

Hm...  It don't think it makes sense to truncate the top bits away by
truncating to u32.  You may be right though that there is some larger
bugs here than just the truncation.

Both the "frame" and the "ipw_rt" struct seem to hold little endian
values generally so probably ->rt_txf should be an __le64 like you say.

Perhaps the maintainers know what should be done?

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: [PATCH] ath10k: fix pm resume after suspend

[Bartosz Markowski]

On 23 October 2014 17:10, Kalle Valo  wrote:
> Bartosz Markowski  writes:
>
>> Firmware was crashing when we were trying to warm reset it
>> after suspend. This was due to the fact that target registeres
>> can be accessed only if the hardware is awaken.
>>
>> This patch makes sure to awake the device also on the hif up,
>> not only in case of probe call path.
>>
>> Signed-off-by: Bartosz Markowski 
>
> This one has non-trivial conflicts. Can you rebase, please?

Sure, I've sent a PATCH v2.

-- 
Bartosz
--
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] staging:rtl8723au: core: Fix error reported by checkpatch.

[Jes Sorensen]

Sanjeev Sharma  writes:
> This is a patch to the rtw_cmd.c file that fixes
> Error reported by checkpatch.
>
> Signed-off-by: Sanjeev Sharma 
> ---
>  drivers/staging/rtl8723au/core/rtw_cmd.c | 83 
> +++-
>  1 file changed, 40 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
> b/drivers/staging/rtl8723au/core/rtw_cmd.c
> index 4eaa502..c1f6254 100644
> --- a/drivers/staging/rtl8723au/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
> @@ -957,7 +957,7 @@ static void traffic_status_watchdog(struct rtw_adapter 
> *padapter)
>   /*  check traffic for  powersaving. */
>   if (((pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod +
> pmlmepriv->LinkDetectInfo.NumTxOkInPeriod) > 8) ||
> - pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod >2)
> + pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod > 
> 2)
>   bEnterPS = false;
>   else
>   bEnterPS = true;

This makes the line longer than 80 characters, that is worse than the
'problem' you are fixing.

Jes
--
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: fix pm resume after suspend

[Bartosz Markowski]

Firmware was crashing when we were trying to warm reset it
after suspend. This was due to the fact that target registeres
can be accessed only if the hardware is awaken.

This patch makes sure to awake the device also on the hif up,
not only in case of probe call.

Signed-off-by: Bartosz Markowski 
---
 drivers/net/wireless/ath/ath10k/pci.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index 4a4740b..d31488b 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1877,10 +1877,16 @@ static int ath10k_pci_hif_power_up_warm(struct ath10k 
*ar)
 
 static int ath10k_pci_hif_power_up(struct ath10k *ar)
 {
-   int ret;
+   int ret = 0;
 
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif power up\n");
 
+   ret = ath10k_pci_wake(ar);
+   if (ret) {
+   ath10k_err(ar, "failed to wake up target: %d\n", ret);
+   return ret;
+   }
+
/*
 * Hardware CUS232 version 2 has some issues with cold reset and the
 * preferred (and safer) way to perform a device reset is through a
@@ -1895,7 +1901,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
ret);
 
if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
-   return ret;
+   goto err_sleep;
 
ath10k_warn(ar, "trying cold reset\n");
 
@@ -1903,11 +1909,15 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
if (ret) {
ath10k_err(ar, "failed to power up target using cold 
reset too (%d)\n",
   ret);
-   return ret;
+   goto err_sleep;
}
}
 
-   return 0;
+   return ret;
+
+err_sleep:
+   ath10k_pci_sleep(ar);
+   return ret;
 }
 
 static void ath10k_pci_hif_power_down(struct ath10k *ar)
@@ -1915,6 +1925,7 @@ static void ath10k_pci_hif_power_down(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif power down\n");
 
ath10k_pci_warm_reset(ar);
+   ath10k_pci_sleep(ar);
 }
 
 #ifdef CONFIG_PM
@@ -2516,6 +2527,8 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
goto err_deinit_irq;
}
 
+   ath10k_pci_sleep(ar);
+
ret = ath10k_core_register(ar, chip_id);
if (ret) {
ath10k_err(ar, "failed to register driver core: %d\n", ret);
@@ -2567,7 +2580,6 @@ static void ath10k_pci_remove(struct pci_dev *pdev)
ath10k_pci_deinit_irq(ar);
ath10k_pci_ce_deinit(ar);
ath10k_pci_free_pipes(ar);
-   ath10k_pci_sleep(ar);
ath10k_pci_release(ar);
ath10k_core_destroy(ar);
 }
-- 
1.8.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] staging:rtl8723au: core: Fix error reported by checkpatch.

[Sanjeev Sharma]

This is a patch to the rtw_cmd.c file that fixes
Error reported by checkpatch.

Signed-off-by: Sanjeev Sharma 
---
 drivers/staging/rtl8723au/core/rtw_cmd.c | 83 +++-
 1 file changed, 40 insertions(+), 43 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c 
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index 4eaa502..c1f6254 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -957,7 +957,7 @@ static void traffic_status_watchdog(struct rtw_adapter 
*padapter)
/*  check traffic for  powersaving. */
if (((pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod +
  pmlmepriv->LinkDetectInfo.NumTxOkInPeriod) > 8) ||
-   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod >2)
+   pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod > 
2)
bEnterPS = false;
else
bEnterPS = true;
@@ -1017,46 +1017,44 @@ static void lps_ctrl_wk_hdl(struct rtw_adapter 
*padapter, u8 lps_ctrl_type)
check_fwstate(pmlmepriv, WIFI_ADHOC_STATE))
return;
 
-   switch (lps_ctrl_type)
-   {
-   case LPS_CTRL_SCAN:
-   rtl8723a_BT_wifiscan_notify(padapter, true);
-   if (!rtl8723a_BT_using_antenna_1(padapter)) {
-   if (check_fwstate(pmlmepriv, _FW_LINKED))
-   LPS_Leave23a(padapter);
-   }
-   break;
-   case LPS_CTRL_JOINBSS:
+   switch (lps_ctrl_type) {
+   case LPS_CTRL_SCAN:
+   rtl8723a_BT_wifiscan_notify(padapter, true);
+   if (!rtl8723a_BT_using_antenna_1(padapter)) {
+   if (check_fwstate(pmlmepriv, _FW_LINKED))
LPS_Leave23a(padapter);
-   break;
-   case LPS_CTRL_CONNECT:
-   mstatus = 1;/* connect */
-   /*  Reset LPS Setting */
-   padapter->pwrctrlpriv.LpsIdleCount = 0;
-   rtl8723a_set_FwJoinBssReport_cmd(padapter, 1);
-   rtl8723a_BT_mediastatus_notify(padapter, mstatus);
-   break;
-   case LPS_CTRL_DISCONNECT:
-   mstatus = 0;/* disconnect */
-   rtl8723a_BT_mediastatus_notify(padapter, mstatus);
-   if (!rtl8723a_BT_using_antenna_1(padapter))
-   LPS_Leave23a(padapter);
-   rtl8723a_set_FwJoinBssReport_cmd(padapter, 0);
-   break;
-   case LPS_CTRL_SPECIAL_PACKET:
-   pwrpriv->DelayLPSLastTimeStamp = jiffies;
-   rtl8723a_BT_specialpacket_notify(padapter);
-   if (!rtl8723a_BT_using_antenna_1(padapter))
-   LPS_Leave23a(padapter);
-   break;
-   case LPS_CTRL_LEAVE:
-   rtl8723a_BT_lps_leave(padapter);
-   if (!rtl8723a_BT_using_antenna_1(padapter))
-   LPS_Leave23a(padapter);
-   break;
-
-   default:
-   break;
+   }
+   break;
+   case LPS_CTRL_JOINBSS:
+   LPS_Leave23a(padapter);
+   break;
+   case LPS_CTRL_CONNECT:
+   mstatus = 1;/* connect */
+   /*  Reset LPS Setting */
+   padapter->pwrctrlpriv.LpsIdleCount = 0;
+   rtl8723a_set_FwJoinBssReport_cmd(padapter, 1);
+   rtl8723a_BT_mediastatus_notify(padapter, mstatus);
+   break;
+   case LPS_CTRL_DISCONNECT:
+   mstatus = 0;/* disconnect */
+   rtl8723a_BT_mediastatus_notify(padapter, mstatus);
+   if (!rtl8723a_BT_using_antenna_1(padapter))
+   LPS_Leave23a(padapter);
+   rtl8723a_set_FwJoinBssReport_cmd(padapter, 0);
+   break;
+   case LPS_CTRL_SPECIAL_PACKET:
+   pwrpriv->DelayLPSLastTimeStamp = jiffies;
+   rtl8723a_BT_specialpacket_notify(padapter);
+   if (!rtl8723a_BT_using_antenna_1(padapter))
+   LPS_Leave23a(padapter);
+   break;
+   case LPS_CTRL_LEAVE:
+   rtl8723a_BT_lps_leave(padapter);
+   if (!rtl8723a_BT_using_antenna_1(padapter))
+   LPS_Leave23a(padapter);
+   break;
+   default:
+   break;
}
 }
 
@@ -1152,7 +1150,7 @@ static void rtw_chk_hi_queue_hdl(struct rtw_adapter 
*padapter)
 
cnt++;
 
-   if (cnt>10)
+   if (cnt > 10)