Re: [Outreachy kernel] [PATCH v4 1/3] staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer

[Julia Lawall]

On Fri, 24 Feb 2017, Tahia Khan wrote:

> Rename struct tstrRSSI to rssi_history_buffer for clarity
> and to remove camel casing.
>
> Signed-off-by: Tahia Khan 

Acked-by: Julia Lawall 


> ---
>  drivers/staging/wilc1000/coreconfigurator.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.h 
> b/drivers/staging/wilc1000/coreconfigurator.h
> index cff1698..1c77529 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.h
> +++ b/drivers/staging/wilc1000/coreconfigurator.h
> @@ -70,7 +70,7 @@ enum connect_status {
>   CONNECT_STS_FORCE_16_BIT = 0x
>  };
>
> -struct tstrRSSI {
> +struct rssi_history_buffer {
>   u8 u8Full;
>   u8 u8Index;
>   s8 as8RSSI[NUM_RSSI];
> @@ -93,7 +93,7 @@ struct network_info {
>   u8 *ies;
>   u16 ies_len;
>   void *join_params;
> - struct tstrRSSI str_rssi;
> + struct rssi_history_buffer str_rssi;
>   u64 tsf_hi;
>  };
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/da73d1aef379243ba94a5c1a4e1d6663160451fd.1487947616.git.tahia.khan%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

[PATCH v3] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

[Ryan Mounce]

Sourced from the current legislation at
https://www.legislation.gov.au/Details/F2016C00432

The current rules exceed legal limits between 5250-5330MHz, and permit
illegal operation in 5600-5650MHz (disallowed regardless of DFS).

Frequency ranges and EIRP limits for all ranges have been updated to
match items 59-63, 65 in the linked document. As the rules for AU have
never previously mirrored local regulations, changes include a
significant increase in the allowable 2.4GHz EIRP and smaller increases
in most other bands.

In order to allow 80MHz operation between 5650-5730MHz (bordering two
bands) the lower, more restrictive band has been rounded up by 5MHz.

Signed-off-by: Ryan Mounce 
---
 db.txt | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/db.txt b/db.txt
index 05108e0..0f1e151 100644
--- a/db.txt
+++ b/db.txt
@@ -85,12 +85,20 @@ country AT: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
+# Source:
+# https://www.legislation.gov.au/Details/F2016C00432
+# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B.
+# The EIRP for DFS bands can be increased by 3dB if TPC is implemented.
+# In order to allow 80MHz operation between 5650-5730MHz the upper boundary
+# of this more restrictive band has been shifted up by 5MHz from 5725MHz.
 country AU: DFS-ETSI
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (17), AUTO-BW
-   (5250 - 5330 @ 80), (24), DFS, AUTO-BW
-   (5490 - 5710 @ 160), (24), DFS
-   (5735 - 5835 @ 80), (30)
+   (2400 - 2483.5 @ 40), (36)
+   (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
+   (5250 - 5350 @ 80), (20), NO-OUTDOOR, AUTO-BW, DFS
+   (5470 - 5600 @ 80), (27), DFS
+   (5650 - 5730 @ 80), (27), DFS
+   (5730 - 5850 @ 80), (36)
+   (57000 - 66000 @ 2160), (43), NO-OUTDOOR
 
 country AW: DFS-ETSI
(2402 - 2482 @ 40), (20)
-- 
2.11.0

[no subject]

[Mark Coste]

hi Linux


http://blog.iconversity.com/product.php?action=24kyew6ae2vhk5




Mark Coste

[PATCH v4] ath10k: search SMBIOS for OEM board file extension

[Waldemar Rymarkiewicz]

Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified, among others, by device and sybsystem ids.

The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
board data file.

To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name
Extension to specify the extension/variant name. The driver will take the
extension suffix into consideration and will load the right (non-default)
board data file if necessary.

If it is unnecessary to use extension board data file, please leave the
SMBIOS field blank and default configuration will be used.

Example:
If a default board data file for a specific board is identified by a string
  "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
   subsystem-device=0310"
then the OEM specific data file, if used, could be identified by variant
suffix:
  "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
   subsystem-device=0310,variant=DE_1AB"

If board data file name extension is set but board-2.bin does not contain
board data file for the variant, the driver will fallback to the default
board data file not to break backward compatibility.

Signed-off-by: Waldemar Rymarkiewicz 
---
 drivers/net/wireless/ath/ath10k/core.c | 101 -
 drivers/net/wireless/ath/ath10k/core.h |  19 +++
 2 files changed, 117 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index dd902b43f8f7..0a8e29e9a0eb 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "core.h"
@@ -711,6 +713,72 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k 
*ar)
return 0;
 }
 
+static void ath10k_core_check_bdfext(const struct dmi_header *hdr, void *data)
+{
+   struct ath10k *ar = data;
+   const char *bdf_ext;
+   const char *magic = ATH10K_SMBIOS_BDF_EXT_MAGIC;
+   u8 bdf_enabled;
+   int i;
+
+   if (hdr->type != ATH10K_SMBIOS_BDF_EXT_TYPE)
+   return;
+
+   if (hdr->length != ATH10K_SMBIOS_BDF_EXT_LENGTH) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "wrong smbios bdf ext type length (%d).\n",
+  hdr->length);
+   return;
+   }
+
+   bdf_enabled = *((u8 *)hdr + ATH10K_SMBIOS_BDF_EXT_OFFSET);
+   if (!bdf_enabled) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not 
found.\n");
+   return;
+   }
+
+   /* Only one string exists (per spec) */
+   bdf_ext = (char *)hdr + hdr->length;
+
+   if (memcmp(bdf_ext, magic, strlen(magic)) != 0) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "bdf variant magic does not match.\n");
+   return;
+   }
+
+   for (i = 0; i < strlen(bdf_ext); i++) {
+   if (!isascii(bdf_ext[i]) || !isprint(bdf_ext[i])) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "bdf variant name contains non ascii 
chars.\n");
+   return;
+   }
+   }
+
+   /* Copy extension name without magic suffix */
+   if (strscpy(ar->id.bdf_ext, bdf_ext + strlen(magic),
+   sizeof(ar->id.bdf_ext)) < 0) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "bdf variant string is longer than the buffer can 
accommodate (variant: %s)\n",
+   bdf_ext);
+   return;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "found and validated bdf variant smbios_type 0x%x bdf %s\n",
+  ATH10K_SMBIOS_BDF_EXT_TYPE, bdf_ext);
+}
+
+static int ath10k_core_check_smbios(struct ath10k *ar)
+{
+   ar->id.bdf_ext[0] = '\0';
+   dmi_walk(ath10k_core_check_bdfext, ar);
+
+   if (ar->id.bdf_ext[0] == '\0')
+   return -ENODATA;
+
+   return 0;
+}
+
 static int ath10k_download_and_run_otp(struct ath10k *ar)
 {
u32 result, address = ar->hw_params.patch_load_addr;
@@ -1020,6 +1088,23 @@ static int ath10k_core_fetch_board_data_api_n(struct 
ath10k *ar,
case ATH10K_BD_IE_BOARD:
ret = ath10k_core_parse_bd_ie_board(ar, data, ie_len,
boardname);
+   if (ret == -ENOENT && ar->id.bdf_ext[0] != '\0') {
+   /* try default bdf if variant was not found */
+   char *s, *v = ",variant=";
+   char boardname2[100];
+
+   strlcpy(boardname2, boardname,
+   

[PATCH v4 3/3] staging: wilc1000: Rename network_info member str_rssi to rssi_history

[Tahia Khan]

Change name of str_rssi to rssi_history within the network_info 
struct for clarity.

Signed-off-by: Tahia Khan 
Acked-by: Julia Lawall 
---
 drivers/staging/wilc1000/coreconfigurator.h   |  2 +-
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.h 
b/drivers/staging/wilc1000/coreconfigurator.h
index 9712d89..10101f8 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -93,7 +93,7 @@ struct network_info {
u8 *ies;
u16 ies_len;
void *join_params;
-   struct rssi_history_buffer str_rssi;
+   struct rssi_history_buffer rssi_history;
u64 tsf_hi;
 };
 
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 9601ab8..4a6fe90 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -205,11 +205,11 @@ static u32 get_rssi_avg(struct network_info *network_info)
 {
u8 i;
int rssi_v = 0;
-   u8 num_rssi = (network_info->str_rssi.full) ?
-  NUM_RSSI : (network_info->str_rssi.index);
+   u8 num_rssi = (network_info->rssi_history.full) ?
+  NUM_RSSI : (network_info->rssi_history.index);
 
for (i = 0; i < num_rssi; i++)
-   rssi_v += network_info->str_rssi.samples[i];
+   rssi_v += network_info->rssi_history.samples[i];
 
rssi_v /= num_rssi;
return rssi_v;
@@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info 
*pstrNetworkInfo,
} else {
ap_index = ap_found;
}
-   rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
-   last_scanned_shadow[ap_index].str_rssi.samples[rssi_index++] = 
pstrNetworkInfo->rssi;
+   rssi_index = last_scanned_shadow[ap_index].rssi_history.index;
+   last_scanned_shadow[ap_index].rssi_history.samples[rssi_index++] = 
pstrNetworkInfo->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
-   last_scanned_shadow[ap_index].str_rssi.full = true;
+   last_scanned_shadow[ap_index].rssi_history.full = true;
}
-   last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
+   last_scanned_shadow[ap_index].rssi_history.index = rssi_index;
last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
-- 
2.7.4

[PATCH v4 2/3] staging: wilc1000: Rename tstrRSSI members and change type of u8Full to bool

[Tahia Khan]

Remove Hungarian notation and camel casing from all tstrRSSI members' 
names. Additionally, change type of u8Full to bool since it only takes 
values 1 or 0.

Signed-off-by: Tahia Khan 
Acked-by: Julia Lawall 
---
 drivers/staging/wilc1000/coreconfigurator.h   |  6 +++---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++---
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.h 
b/drivers/staging/wilc1000/coreconfigurator.h
index 1c77529..9712d89 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -71,9 +71,9 @@ enum connect_status {
 };
 
 struct rssi_history_buffer {
-   u8 u8Full;
-   u8 u8Index;
-   s8 as8RSSI[NUM_RSSI];
+   bool full;
+   u8 index;
+   s8 samples[NUM_RSSI];
 };
 
 struct network_info {
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index f7ce47c..9601ab8 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -205,11 +205,11 @@ static u32 get_rssi_avg(struct network_info *network_info)
 {
u8 i;
int rssi_v = 0;
-   u8 num_rssi = (network_info->str_rssi.u8Full) ?
-  NUM_RSSI : (network_info->str_rssi.u8Index);
+   u8 num_rssi = (network_info->str_rssi.full) ?
+  NUM_RSSI : (network_info->str_rssi.index);
 
for (i = 0; i < num_rssi; i++)
-   rssi_v += network_info->str_rssi.as8RSSI[i];
+   rssi_v += network_info->str_rssi.samples[i];
 
rssi_v /= num_rssi;
return rssi_v;
@@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info 
*pstrNetworkInfo,
} else {
ap_index = ap_found;
}
-   rssi_index = last_scanned_shadow[ap_index].str_rssi.u8Index;
-   last_scanned_shadow[ap_index].str_rssi.as8RSSI[rssi_index++] = 
pstrNetworkInfo->rssi;
+   rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
+   last_scanned_shadow[ap_index].str_rssi.samples[rssi_index++] = 
pstrNetworkInfo->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
-   last_scanned_shadow[ap_index].str_rssi.u8Full = 1;
+   last_scanned_shadow[ap_index].str_rssi.full = true;
}
-   last_scanned_shadow[ap_index].str_rssi.u8Index = rssi_index;
+   last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
-- 
2.7.4

[PATCH v4 1/3] staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer

[Tahia Khan]

Rename struct tstrRSSI to rssi_history_buffer for clarity 
and to remove camel casing.

Signed-off-by: Tahia Khan 
---
 drivers/staging/wilc1000/coreconfigurator.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/coreconfigurator.h 
b/drivers/staging/wilc1000/coreconfigurator.h
index cff1698..1c77529 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -70,7 +70,7 @@ enum connect_status {
CONNECT_STS_FORCE_16_BIT = 0x
 };
 
-struct tstrRSSI {
+struct rssi_history_buffer {
u8 u8Full;
u8 u8Index;
s8 as8RSSI[NUM_RSSI];
@@ -93,7 +93,7 @@ struct network_info {
u8 *ies;
u16 ies_len;
void *join_params;
-   struct tstrRSSI str_rssi;
+   struct rssi_history_buffer str_rssi;
u64 tsf_hi;
 };
 
-- 
2.7.4

[PATCH v4 0/3] staging: wilc1000: multiple coding style changes to struct tstrRSSI

[Tahia Khan]

Multiple coding style changes to struct tstrRSSI. Initially reported by 
checkpath.pl: 

Avoid CamelCase:  
Avoid CamelCase:  
Avoid CamelCase:  

Changes since v3: Reformatting commit messages, as requested by
Julia Lawall 

Tahia Khan (3):
  staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer for
clarity and to remove camel casing.
  staging: wilc1000: Remove Hungarian notation and camel casing from all
tstrRSSI members’ names. Additionally, change type of u8Full to bool
since it only takes values 1 or 0.
  staging: wilc1000: Change name of str_rssi to rssi_history within the
network_info struct for clarity.

 drivers/staging/wilc1000/coreconfigurator.h   | 10 +-
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

-- 
2.7.4

Re: [PATCH] NFC: remove TI nfcwilink driver

[Marcel Holtmann]

Hi Rob,

>>> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
>>> shipped. The only information I found were announcements in Feb
>>> 2012 about the parts. There's been no activity on this driver besided
>>> common changes since initially added in Jan 2012. There's also no in
>>> users that instantiate the platform device (nor DT bindings).
>>> 
>>> This is a first step in removing TI ST (shared transport) driver in
>>> favor of extending the BT hci_ll driver to support WL183x chips.
>> 
>> since the firmware files TINfcInit_* also never made it into the 
>> linux-firmware tree, I have no idea who is using this driver. I am actually 
>> fine with removing it since it would be easy enough to bring back based on 
>> hci_ll driver once there is hardware to test this on.
> 
> Ping. Someone going to pick up this patch?

if Samuel does not have anything pending for his tree, I can take it through 
bluetooth-next tree.

Regards

Marcel

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Am 24.02.2017 um 20:37 schrieb Johannes Berg:
> So let's see. The error *isn't* generated by mac80211 or iwlwifi, but
> it's still returned through wiphy_suspend(). That function just calls
> mac80211 though, and never generates any error conditions by itself. As
> a consequence, this must be generated in some callee of wiphy_suspend()
> that *isn't* in mac80211/iwlwifi...
> 
> __ieee80211_suspend() also doesn't generate any error codes by itself,
> let's take a look at iwlmvm's suspend (called through drv_suspend()),
> that's iwl_mvm_suspend().
> 
> Oh. Can you see if you have CONFIG_IWLWIFI_PCIE_RTPM enabled in your
> configuration? If you do, please turn it off and see if that fixes it.
Indeed, you got it! 
I had it on, and turning that off lets me suspend just fine after activating 
WoWLAN!

See here, the syslog is now clean (I removed the EBUSY-WARNONs for now):
[12383.757181] PM: Syncing filesystems ... done.
[12383.924701] PM: Preparing system for sleep (mem)
[12384.249363] ACPI Warning: \_SB.PCI0.PEG0.DGPU._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)
[12385.323377] Freezing user space processes ... (elapsed 0.001 seconds) done.
[12385.325193] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[12385.326602] PM: Suspending system (mem)
[12385.326619] Suspending console(s) (use no_console_suspend to debug)
[12385.326989] sd 5:0:0:0: [sdb] Synchronizing SCSI cache
[12385.327076] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[12385.327199] sd 0:0:0:0: [sda] Stopping disk
[12385.329952] sd 5:0:0:0: [sdb] Stopping disk
[12385.335474] iwlwifi :0a:00.0: L1 Enabled - LTR Enabled
[12385.335737] iwlwifi :0a:00.0: L1 Enabled - LTR Enabled
[12385.426964] ACPI : EC: event blocked
[12385.637708] ACPI Warning: \_SB.PCI0.PEG0.DGPU._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20160930/nsarguments-95)
[12385.678281] nvidia-modeset: WARNING: GPU:0: Failed to determine which 
devices were hotplugged: 0x11

[12385.892099] PM: suspend of devices complete after 565.370 msecs
[12385.892586] PM: late suspend of devices complete after 0.484 msecs
[12385.892942] ACPI : EC: interrupt blocked
[12385.893495] ehci-pci :00:1d.0: System wakeup enabled by ACPI
[12385.893568] iwlwifi :0a:00.0: System wakeup enabled by ACPI
[12385.893685] ehci-pci :00:1a.0: System wakeup enabled by ACPI
[12385.893754] xhci_hcd :00:14.0: System wakeup enabled by ACPI
[12385.905567] PM: noirq suspend of devices complete after 12.970 msecs
[12385.905967] ACPI: Preparing to enter system sleep state S3
[12385.906505] ACPI : EC: EC stopped
[12385.906505] PM: Saving platform NVS memory
[12385.906511] Disabling non-boot CPUs ...
[12385.908459] smpboot: CPU 1 is now offline
[12385.919596] smpboot: CPU 2 is now offline
[12385.928100] smpboot: CPU 3 is now offline
[12385.939661] smpboot: CPU 4 is now offline
[12385.952240] smpboot: CPU 5 is now offline
[12385.965252] smpboot: CPU 6 is now offline
[12385.975465] smpboot: CPU 7 is now offline


The problem is that it seems I cannot actually wake the machine anymore 
afterwards... 
While in the suspend procedure, I see:
[12385.893568] iwlwifi :0a:00.0: System wakeup enabled by ACPI
as expected, I could neither get it to make a tcp connection in tcp-connection 
mode,
nor could I wake the machine via magic packet in magic-packet mode. 

Could that be some hardware / system firmware limitation, e.g. if my UEFI does 
not support actually powering
the WiFi hardware if I am in S3? I have yet to (re)check the UEFI config, but 
since the options are
extremely limited on this Alienware laptop, I guess I will not find anything 
related to that. 

At least, the suspend problem seems to be clearly related to some path only 
used if CONFIG_IWLWIFI_PCIE_RTPM is on. 

> 
> This still looks fishy in the code though, but let's see if that's the
> problem first.
> 
> johannes
> 

Re: [PATCH] NFC: remove TI nfcwilink driver

[Rob Herring]

On Wed, Jan 25, 2017 at 11:54 PM, Marcel Holtmann  wrote:
> Hi Rob,
>
>> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
>> shipped. The only information I found were announcements in Feb
>> 2012 about the parts. There's been no activity on this driver besided
>> common changes since initially added in Jan 2012. There's also no in
>> users that instantiate the platform device (nor DT bindings).
>>
>> This is a first step in removing TI ST (shared transport) driver in
>> favor of extending the BT hci_ll driver to support WL183x chips.
>
> since the firmware files TINfcInit_* also never made it into the 
> linux-firmware tree, I have no idea who is using this driver. I am actually 
> fine with removing it since it would be easy enough to bring back based on 
> hci_ll driver once there is hardware to test this on.

Ping. Someone going to pick up this patch?

Rob

[PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

[Alexis Green]

From: Jesse Jones 

Changes since v1: Only flush tx queue if interface is mesh mode.
  This prevents kernel panics due to uninitialized spin_lock.

When more than one station hears a broadcast request, it is possible that
multiple devices will reply at the same time, potentially causing
collision. This patch helps reduce this issue.

Signed-off-by: Alexis Green 
Signed-off-by: Benjamin Morgan 
---
 net/mac80211/ieee80211_i.h |  11 
 net/mac80211/iface.c   |  61 ++
 net/mac80211/mesh.c|   2 +
 net/mac80211/mesh_hwmp.c   | 124 +++--
 4 files changed, 171 insertions(+), 27 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159a1a7..f422897 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -330,6 +330,11 @@ struct mesh_preq_queue {
u8 flags;
 };
 
+struct mesh_tx_queue {
+   struct list_head list;
+   struct sk_buff *skb;
+};
+
 struct ieee80211_roc_work {
struct list_head list;
 
@@ -670,6 +675,11 @@ struct ieee80211_if_mesh {
spinlock_t mesh_preq_queue_lock;
struct mesh_preq_queue preq_queue;
int preq_queue_len;
+   /* Spinlock for trasmitted MPATH frames */
+   spinlock_t mesh_tx_queue_lock;
+   struct mesh_tx_queue tx_queue;
+   int tx_queue_len;
+
struct mesh_stats mshstats;
struct mesh_config mshcfg;
atomic_t estab_plinks;
@@ -919,6 +929,7 @@ struct ieee80211_sub_if_data {
 
struct work_struct work;
struct sk_buff_head skb_queue;
+   struct delayed_work tx_work;
 
u8 needed_rx_chains;
enum ieee80211_smps_mode smps_mode;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 40813dd..d5b4bf4 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -778,6 +778,59 @@ static int ieee80211_open(struct net_device *dev)
return ieee80211_do_open(>wdev, true);
 }
 
+static void flush_tx_skbs(struct ieee80211_sub_if_data *sdata)
+{
+   struct ieee80211_if_mesh *ifmsh = >u.mesh;
+   struct mesh_tx_queue *tx_node;
+
+   spin_lock_bh(>mesh_tx_queue_lock);
+
+   /* Note that this check is important because of the two-stage
+* way that ieee80211_if_mesh is initialized.
+*/
+   if (ifmsh->tx_queue_len > 0) {
+   mhwmp_dbg(sdata, "flushing %d skbs", ifmsh->tx_queue_len);
+
+   while (!list_empty(>tx_queue.list)) {
+   tx_node = list_last_entry(>tx_queue.list,
+ struct mesh_tx_queue, list);
+   kfree_skb(tx_node->skb);
+   list_del(_node->list);
+   kfree(tx_node);
+   }
+   ifmsh->tx_queue_len = 0;
+   }
+
+   spin_unlock_bh(>mesh_tx_queue_lock);
+}
+
+static void mesh_jittered_tx(struct work_struct *wk)
+{
+   struct ieee80211_sub_if_data *sdata =
+   container_of(
+wk, struct ieee80211_sub_if_data,
+tx_work.work);
+
+   struct ieee80211_if_mesh *ifmsh = >u.mesh;
+   struct mesh_tx_queue *tx_node;
+
+   spin_lock_bh(>mesh_tx_queue_lock);
+
+   list_for_each_entry(tx_node, >tx_queue.list, list) {
+   ieee80211_tx_skb(sdata, tx_node->skb);
+   }
+
+   while (!list_empty(>tx_queue.list)) {
+   tx_node = list_last_entry(>tx_queue.list,
+ struct mesh_tx_queue, list);
+   list_del(_node->list);
+   kfree(tx_node);
+   }
+   ifmsh->tx_queue_len = 0;
+
+   spin_unlock_bh(>mesh_tx_queue_lock);
+}
+
 static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
  bool going_down)
 {
@@ -881,6 +934,12 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data 
*sdata,
 
cancel_delayed_work_sync(>dfs_cac_timer_work);
 
+   /* Nothing to flush if the interface is not in mesh mode */
+   if (sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
+   flush_tx_skbs(sdata);
+
+   cancel_delayed_work_sync(>tx_work);
+
if (sdata->wdev.cac_started) {
chandef = sdata->vif.bss_conf.chandef;
WARN_ON(local->suspended);
@@ -1846,6 +1905,8 @@ int ieee80211_if_add(struct ieee80211_local *local, const 
char *name,
  ieee80211_dfs_cac_timer_work);
INIT_DELAYED_WORK(>dec_tailroom_needed_wk,
  ieee80211_delayed_tailroom_dec);
+   INIT_DELAYED_WORK(>tx_work,
+ mesh_jittered_tx);
 
for (i = 0; i < NUM_NL80211_BANDS; i++) {
struct ieee80211_supported_band *sband;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index c28b0af..f0d3cd9 100644
--- a/net/mac80211/mesh.c
+++ 

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Johannes Berg]

On Fri, 2017-02-24 at 19:51 +0100, Oliver Freyermuth wrote:
> 
> Thanks for your reply and the suggestion! I have put the two lines
> directly after the last #include
> in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
> and net/mac80211/ieee80211_i.h . 
> Sadly, none of them triggers when trying to enter suspend. 
> 
> I still get:
> [   85.308756] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
> returns -16
> [   85.308757] PM: Device phy0 failed to suspend async: error -16
> [   85.310518] sd 5:0:0:0: [sdb] Stopping disk
> [   85.857976] PM: Some devices failed to suspend, or early wake
> event detected
> with nothing in between. 

I'd have expected the message to show up *before* the first one
(dpm_run_callback) you quoted, because this one already has the -16
return value printed, and it must've been generated before that.

I just tried on one of my systems, but it's not exactly the same kernel
version (would be difficult to install right now), and it works just
fine for me. Perhaps there's something going on with your system.

> Just to make sure, I can confirm the change is effective, since I get
> many of:
> [   57.819114] WARNING: CPU: 4 PID: 4092 at
> drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1503
> iwl_mvm_rx_tx_cmd+0x51e/0x579 [iwlmvm]
> (with the tracebacks) for example when connecting to a different
> network. But none of these when trying to suspend...

Oops. I didn't see this instance of EBUSY in the success path - it's
used for a comparison that probably never triggered. Anyway, no harm
done apart from logging lots of useless stack traces :)

> Any other ideas on where I could look, or how I could trace the
> origin of this -16? 

(see below)

> You are right about the bug report - I provided the wrong link,
> sorry. 
> The report I meant is here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1362311
> for a 7260 similar to mine. 

Yes, that one looks like the same as yours.

> I believe that 
>  https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
> i.e. comment 25 was made by the same person who just hijacked that
> kernel
> bug report even though it was indeed for a very different hardware. 

Ok, that's possible.

So let's see. The error *isn't* generated by mac80211 or iwlwifi, but
it's still returned through wiphy_suspend(). That function just calls
mac80211 though, and never generates any error conditions by itself. As
a consequence, this must be generated in some callee of wiphy_suspend()
that *isn't* in mac80211/iwlwifi...

__ieee80211_suspend() also doesn't generate any error codes by itself,
let's take a look at iwlmvm's suspend (called through drv_suspend()),
that's iwl_mvm_suspend().

Oh. Can you see if you have CONFIG_IWLWIFI_PCIE_RTPM enabled in your
configuration? If you do, please turn it off and see if that fixes it.

This still looks fishy in the code though, but let's see if that's the
problem first.

johannes

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Oliver Freyermuth]

Am 24.02.2017 um 13:11 schrieb Johannes Berg:
>> However, when trying to suspend to RAM ( echo mem > /sys/power/state
>> ), I get:
>> [46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
>> returns -16
>> [46656.403769] PM: Device phy0 failed to suspend async: error -16
>>
> 
> However, I don't see EBUSY anywhere there in the driver.
> 
> Can you recompile the kernel and run a quick experiment?
> 
> Open drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and put something
> like this after the includes:
> 
> #undef EBUSY
> #define EBUSY ({ WARN_ON(1); 16; })
> 
> that should trigger a warning at the place where the EBUSY came from,
> assuming it did in fact come from the driver. You could repeat it for
> net/mac80211/ieee80211_i.h if that doesn't trigger.

Thanks for your reply and the suggestion! I have put the two lines directly 
after the last #include
in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and 
net/mac80211/ieee80211_i.h . 
Sadly, none of them triggers when trying to enter suspend. 

I still get:
[   85.308756] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211] returns -16
[   85.308757] PM: Device phy0 failed to suspend async: error -16
[   85.310518] sd 5:0:0:0: [sdb] Stopping disk
[   85.857976] PM: Some devices failed to suspend, or early wake event detected
with nothing in between. 

Just to make sure, I can confirm the change is effective, since I get many of:
[   57.819114] WARNING: CPU: 4 PID: 4092 at 
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1503 iwl_mvm_rx_tx_cmd+0x51e/0x579 
[iwlmvm]
(with the tracebacks) for example when connecting to a different network. But 
none of these when trying to suspend...

Any other ideas on where I could look, or how I could trace the origin of this 
-16? 

> 
>> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
> 
> That device is like mine, afaict, so this seems to be a different bug.
You are right about the bug report - I provided the wrong link, sorry. 
The report I meant is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1362311
for a 7260 similar to mine. 

I believe that 
 https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
i.e. comment 25 was made by the same person who just hijacked that kernel
bug report even though it was indeed for a very different hardware. 

I'm open for any other suggestions, let me know if anything comes to mind. 

Cheers and thanks for your reply, 
Oliver

[PATCH RFC] brcmfmac: shutdown interfaces on PSM's watchdog fire

[Rafał Miłecki]

From: Rafał Miłecki 

When PSM's watchdog fires hardware / firmware is not operational. It
seems there isn't a way to restart firmware & reapply all settings so
instead shut all interfaces down. This is at least some signal for the
user things went wrong and allows reacting to it.

Signed-off-by: Rafał Miłecki 
---
This patch is RFC as I'm wondering if there is any other way to handle
such errors. I couldn't find anything except for that
cfg80211_shutdown_all_interfaces.

Unfortunately hostapd doesn't seem to react to this except for sth like:
Fri Feb 24 13:41:07 2017 daemon.notice hostapd: wlan0: INTERFACE-DISABLED

Shall we introduce some nl80211 even for such cases maybe?

Or maybe I'm totally wrong and there is some simple way for a driver to
request reconfiguration of all interfaces?
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 1 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 
 3 files changed, 10 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 10098b7586f3..520d397bb963 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6981,3 +6981,8 @@ void brcmf_cfg80211_detach(struct brcmf_cfg80211_info 
*cfg)
wl_deinit_priv(cfg);
brcmf_free_wiphy(cfg->wiphy);
 }
+
+void brcmf_cfg80211_shutdown(struct brcmf_cfg80211_info *cfg)
+{
+   cfg80211_shutdown_all_interfaces(cfg->wiphy);
+}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
index 8f19d95d4175..77dafe03bb31 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
@@ -385,6 +385,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct 
brcmf_pub *drvr,
  struct device *busdev,
  bool p2pdev_forced);
 void brcmf_cfg80211_detach(struct brcmf_cfg80211_info *cfg);
+void brcmf_cfg80211_shutdown(struct brcmf_cfg80211_info *cfg);
 s32 brcmf_cfg80211_up(struct net_device *ndev);
 s32 brcmf_cfg80211_down(struct net_device *ndev);
 enum nl80211_iftype brcmf_cfg80211_get_iftype(struct brcmf_if *ifp);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 2f2f3a5ad86a..c6c0f3e8ef00 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -753,6 +753,10 @@ static int brcmf_psm_watchdog_notify(struct brcmf_if *ifp,
if (err)
brcmf_err("Failed to get memory dump, %d\n", err);
 
+   brcmf_cfg80211_shutdown(ifp->drvr->config);
+
+   /* TODO: Stop the firmware */
+
return err;
 }
 
-- 
2.11.0

[PATCH] brcmfmac: always print error when PSM's watchdog fires

[Rafał Miłecki]

From: Rafał Miłecki 

So far we were attaching BRCMF_E_PSM_WATCHDOG event listener in
brcmf_debug_attach which gets compiled only with CONFIG_BRCMDBG. This
event means something went wrong and firmware / hardware usually can't
be expected to work (reliably).

Such a problem is significant for user experience so I believe we should
print an error unconditionally (even with debugging disabled). What can
be indeed optional is dumping bus memory as this is clearly part of
debugging process.

In the future we may also try to extend this listener by trying to
recover from the error or at least signal it to the cfg80211.

Signed-off-by: Rafał Miłecki 
---
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 22 ++
 .../wireless/broadcom/brcm80211/brcmfmac/debug.c   | 26 +++---
 .../wireless/broadcom/brcm80211/brcmfmac/debug.h   |  9 
 3 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 60da86a8d95b..2f2f3a5ad86a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -738,6 +738,24 @@ void brcmf_remove_interface(struct brcmf_if *ifp, bool 
rtnl_locked)
brcmf_del_if(ifp->drvr, ifp->bsscfgidx, rtnl_locked);
 }
 
+static int brcmf_psm_watchdog_notify(struct brcmf_if *ifp,
+const struct brcmf_event_msg *evtmsg,
+void *data)
+{
+   int err;
+
+   brcmf_dbg(TRACE, "enter: bsscfgidx=%d\n", ifp->bsscfgidx);
+
+   brcmf_err("PSM's watchdog has fired!\n");
+
+   err = brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
+evtmsg->datalen);
+   if (err)
+   brcmf_err("Failed to get memory dump, %d\n", err);
+
+   return err;
+}
+
 #ifdef CONFIG_INET
 #define ARPOL_MAX_ENTRIES  8
 static int brcmf_inetaddr_changed(struct notifier_block *nb,
@@ -917,6 +935,10 @@ int brcmf_attach(struct device *dev, struct 
brcmf_mp_device *settings)
goto fail;
}
 
+   /* Attach to events important for core code */
+   brcmf_fweh_register(drvr, BRCMF_E_PSM_WATCHDOG,
+   brcmf_psm_watchdog_notify);
+
/* attach firmware event handler */
brcmf_fweh_attach(drvr);
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
index f4644cf371c7..1447a8352383 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
@@ -27,8 +27,8 @@
 
 static struct dentry *root_folder;
 
-static int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
- size_t len)
+int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
+  size_t len)
 {
void *dump;
size_t ramsize;
@@ -54,24 +54,6 @@ static int brcmf_debug_create_memdump(struct brcmf_bus *bus, 
const void *data,
return 0;
 }
 
-static int brcmf_debug_psm_watchdog_notify(struct brcmf_if *ifp,
-  const struct brcmf_event_msg *evtmsg,
-  void *data)
-{
-   int err;
-
-   brcmf_dbg(TRACE, "enter: bsscfgidx=%d\n", ifp->bsscfgidx);
-
-   brcmf_err("PSM's watchdog has fired!\n");
-
-   err = brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
-evtmsg->datalen);
-   if (err)
-   brcmf_err("Failed to get memory dump, %d\n", err);
-
-   return err;
-}
-
 void brcmf_debugfs_init(void)
 {
root_folder = debugfs_create_dir(KBUILD_MODNAME, NULL);
@@ -99,9 +81,7 @@ int brcmf_debug_attach(struct brcmf_pub *drvr)
if (IS_ERR(drvr->dbgfs_dir))
return PTR_ERR(drvr->dbgfs_dir);
 
-
-   return brcmf_fweh_register(drvr, BRCMF_E_PSM_WATCHDOG,
-  brcmf_debug_psm_watchdog_notify);
+   return 0;
 }
 
 void brcmf_debug_detach(struct brcmf_pub *drvr)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
index 066126123e96..389166abb520 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
@@ -99,6 +99,7 @@ do {  
\
 
 extern int brcmf_msg_level;
 
+struct brcmf_bus;
 struct brcmf_pub;
 #ifdef DEBUG
 void brcmf_debugfs_init(void);
@@ -108,6 +109,8 @@ void brcmf_debug_detach(struct brcmf_pub *drvr);
 struct dentry *brcmf_debugfs_get_devdir(struct brcmf_pub *drvr);
 int brcmf_debugfs_add_entry(struct brcmf_pub *drvr, const char *fn,

Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.

[Ben Greear]

On 02/23/2017 10:36 PM, Johannes Berg wrote:




+   msg_head = genlmsg_put(skb, 0, 0, _genl_family, 0,
+  HWSIM_CMD_NOTIFY);


I think you should use a more specific command name.


My idea was that other attributes could be added over time without
having to add a new cmd-id, so that is why I left it general.  If you
still want a different command, do you want it to be something like
'HWSIM_CMD_CHANNEL_CHANGE' ?

Thanks,
Ben




+   if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
+   ETH_ALEN, data->addresses[1].addr))
+   goto nla_put_failure;


and at least also add a more specific identifier like the radio ID.


+   if (data->channel)
+   center_freq = data->channel->center_freq;
+
+   if (nla_put_u32(skb, HWSIM_ATTR_FREQ, center_freq))
+   goto nla_put_failure;


and have the full channel definition


Also the indentation in the documentation didn't match the convention
used there.

johannes



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

什么情况下用人单位需支付两倍的经济补偿

[盛向添]

422:25:31

新《劳动合同法》、《社会保险法》、《工伤保险条例》实操
应对策略与有效调岗调薪、裁员解雇及违纪问题员工处理技巧 

2017年3月3--4日---上海（A单元）
2017年3月10--11日-深圳（A单元）
2017年3月17--18日-北京（A单元）
2017年3月24--25日-广州（A单元）
2017年3月31-4月1日上海（B单元）
2017年4月14--15日-深圳（B单元）
2017年4月21--22日-北京（B单元）
2017年4月28--29日-广州（B单元）
2
【注明】该课程2天为一个单元，A单元与B单元内容是完全独立的不分先后顺序

【学员对象】董事长、总经理、副总经理、人力资源总监/经理/专员及人事行政管理人员、工会干部、
法务人员及相关管理人员、相关律师等。

【费用】参加A单元：3200元/1人，5800元/2人；参加B单元：3200元/1人，5800元/2人，参加AB单元
：5800元/人

【報名】13725429828、021－51099856、QQ：1512435036

●课程大纲：
A单元内容（共2天，20个以上经典案例）
专题一：招聘入职
专题二：劳动合同订立
专题三：试用期
专题四：无固定期限劳动合同
专题五：培训、保密与竞业限制
专题六：劳动关系解除终止
专题七：社会保险法
专题八：劳动争议处理
━━━
B单元内容（共2天，20个以上经典案例）
专题一：违纪违规问题员工处理
专题二：绩效管理与岗位调整
专题三：劳动报酬、薪酬福利
专题四：经济补偿
专题五：规章制度、员工手册
专题六：工伤保险条例
专题七：劳务派遣

●【授课专家介绍】F
资深劳动法专家 钟永棣
国内著名劳动法与员工关系管理实战专家、劳动仲裁员、企业劳动争议预防应对专家、高级人力资源管
理师、高级劳动关系协调师，国内第一批倡导、传播、实施“国家劳动法与企业薪酬绩效有机整合”的
先行者；国内原创型、实战型、顾问型的培训师。 

现任“劳律通(中国)顾问中心”、中华创世纪培训网首席顾问，上海成通律师事务所投资合伙人；兼任
时代光华、深圳外商投资企业协会、广州市劳动保障学会、广州市人力资源市场服务中心、广东省人力
资源管理协会、香港工业总会、中山大学、浙江大学、华南理工大学等100多家培训公司、行业协会、有
关机构的签约讲师、特聘专家顾问。 

钟老师精通劳动政策法律法规和劳动仲裁、诉讼程序，擅长劳动用工风险的有效预防与劳动争议案件的
精准应对，善于把劳动法律法规与企业人力资源管理有机整合，通晓企业劳动争议防范机制的构建和劳
动用工管理体系的修正完善。钟老师经常在客户办公现场、培训现场为客户、学员即时起草、审查、修
改相关制度、合同、文书，或分析具体案件的应对思路；钟老师独到的现场的专业功底，每次都赢得广
大客户、学员发自内心的好评与100%的信服！ 
linux-wireless什么情况下用人单位需支付两倍的经济补偿

Re: [PATCH 160/306] mac80211-hwsim: add rate-limited debugging for rx-netlink

[Ben Greear]

On 02/23/2017 10:39 PM, Johannes Berg wrote:



+   !info->attrs[HWSIM_ATTR_SIGNAL]) {
+   if (net_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: Missing
required attribute\n");


I'm not convinced net_ratelimit() is a good idea, that's a global rate
limiter.


Is there a better rate-limiter w/out hand-crafting something?

Thanks,
Ben

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

Re: [PATCH 161/306] mac80211-hwsim: Improve logging.

[Ben Greear]

On 02/23/2017 10:42 PM, Johannes Berg wrote:



+   static unsigned int cnt = 0;
+   /* This is fairly common, and usually not a
bug.  So, print errors
+  rarely. */
+   if (((cnt++ & 0x3FF) == 0x3FF) && net_ratelimit())
+   printk(KERN_DEBUG " hwsim rx-nl: radio %pM
idle: %d or not started: %d cnt: %d\n",
+  dst, data2->idle, !data2->started,
cnt);
goto out;
}


You just added that in the previous patch...

Please take a bit more care, or I'll eventually stop looking at your
patches since things like that seem to happen over and over again. I
don't get a feeling that you actually care about getting things
upstream much anyway.


I wrote these patches over a long period of time.  Some, like the binary
API things I already knew you did not want, but I posted them since
it seems several people are looking at this sort of thing and maybe
they will have a good idea how to add similar behaviour in an efficient
manner.  I think your previous suggestion was that I should map each
flag in some translate code and/or bloat up netlink API, and neither
of those options seemed like an efficient use of CPU time.

I'll work to fix the cosmetic problems and squash these logging patches
and re-submit those.

Thanks,
Ben

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

Re: [PATCH v2] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

[Seth Forshee]

On Fri, Feb 24, 2017 at 01:20:24PM +1030, Ryan Mounce wrote:
> On 24 February 2017 at 02:05, Seth Forshee  wrote:
> > On Fri, Feb 24, 2017 at 12:22:53AM +1030, Ryan Mounce wrote:
> >> Sourced from the current legislation at
> >> https://www.legislation.gov.au/Details/F2016C00432
> >>
> >> The current rules exceed legal limits between 5250-5330MHz, and permit
> >> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
> >>
> >> Frequency ranges and EIRP limits for all ranges have been updated to
> >> match items 59-63, 65 in the linked document. As the rules for AU have
> >> never previously mirrored local regulations, changes include a
> >> significant increase in the allowable 2.4GHz EIRP and smaller increases
> >> in most other bands.
> >>
> >> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> >> bands) the lower, more restrictive band has been rounded up by 5MHz.
> >>
> >> Signed-off-by: Ryan Mounce 
> >> ---
> >>  db.txt | 15 ++-
> >>  1 file changed, 10 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/db.txt b/db.txt
> >> index 05108e0..00e81b6 100644
> >> --- a/db.txt
> >> +++ b/db.txt
> >> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
> >>   # 60 GHz band channels 1-4, ref: Etsi En 302 567
> >>   (57000 - 66000 @ 2160), (40)
> >>
> >> +# Source:
> >> +# https://www.legislation.gov.au/Details/F2016C00432
> >> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
> >>  country AU: DFS-ETSI
> >> - (2402 - 2482 @ 40), (20)
> >> - (5170 - 5250 @ 80), (17), AUTO-BW
> >> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
> >> - (5490 - 5710 @ 160), (24), DFS
> >> - (5735 - 5835 @ 80), (30)
> >> + (2400 - 2483.5 @ 40), (36)
> >
> > The mention of ETSI EN 300 328 in item 55 (a) leads me to believe that
> > this is the limit we should be using, i.e. 500 mW. It is a bit confusing
> > though since it seems like such devices would also fall under "digital
> > modulation transmitters."
> 
> Item 55 applies only to frequency hopping transmitters e.g. Bluetooth.
> As a local, I can say with some degree of certainty that 4W/36dBm is
> the correct 2.4GHz ISM EIRP for Australia. It is advertised as the
> EIRP in the 802.11d IE of commercial devices e.g. Cisco Aironet APs
> and widely deployed ISP gateways in Australia, among other devices
> that have received relevant approvals.

Okay, looking at that section again that makes sense.

> >> + (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
> >
> > This looks correct.
> >
> >> + (5250 - 5350 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
> >
> > Since this range requires TPC we need to set the power limit at 100 mW.
> >
> >> + (5470 - 5600 @ 80), (30), DFS
> >> + (5650 - 5730 @ 80), (30), DFS
> >
> > These ranges also require TPC so we need to set the limit at 500 mW.
> 
> I was unsure about this one. Setting this to 27dBm also affects the
> 802.11d country information IE, however when the DFS flag is set a 3dB
> 802.11h power constraint IE is also advertised so stations will limit
> themselves to (27-3)=24dBm/250mW.
> 
> Given the choice between unnecessarily halving transmit power on
> stations and potentially transmitting at twice the permissible power
> on APs without TPC I agree that the conservative approach should be
> taken for now. Ideally I think that the actual EIRP limits should be
> in the regdb and a 3dB constraint should be applied automatically on
> APs that cannot support TPC when the DFS flag is set.
> 
> >> + (5730 - 5850 @ 80), (36)
> >
> > In the document the ranges are 5650-5725 MHz and 5725-5850 MHz. I
> > suspect that the existing rules fudge that to line up with the wifi
> > channels, which technically is okay because the rules in the former
> > range are more restrictive. I wonder if we shouldn't be recording them
> > here as per the document and adding AUTO-BW. Johannes, any thoughts?
> 
> I've tested with AUTO-BW and it doesn't work in this case as channel
> 144 will be disabled if it doesn't exist entirely within one band.
> Fudging the more restrictive rules by a mere 5MHz to fit 802.11
> channels seems to be the status quo.

I wonder why AUTO-BW doesn't work. In that case it's certainly fine to
keep those ranges as they are.

Thanks,
Seth

Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.

[Ben Greear]

On 02/24/2017 12:45 AM, Andrew Zaborowski wrote:

On 24 February 2017 at 01:28,   wrote:

Modify the receive-from-user-space logic to do length
and 'is-down' checks before trying to allocate an skb.

And, if we are going to ignore the pkt due to radio idle,
then do not return an error code to user-space.  User-space
cannot reliably know exactly when a radio is idle or not.


You probably want to return some error code anyway because 0, if you
compare to the kernel medium, currently maps to the ack returned bit
and is possibly the only way for userspace to set the
HWSIM_TX_STAT_ACK flag in a meaningful way.


Maybe there is a way to return a specific error code so that
the user-space doesn't get concerned when radio is idle.  I
didn't want to spam logs in user-space app...

Thanks,
Ben

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

Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset

[Rafał Miłecki]

On 2017-02-24 14:21, Arend Van Spriel wrote:

On 24-2-2017 13:27, Rafał Miłecki wrote:

From: Rafał Miłecki 

43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
brcmfmac there is support for 43602a1 and from what I know supporting
43602a0 would require loading a different firmware.


This is not necessarily true. It depends on whether the rom image is
different or not and there is no way to tell up front. So if a0 has 
same
rom image as a1 the firmware is compatible and no distinction is 
needed.

This tends to be the case for chips that only change the digit and not
the letter in the chip revision. Anyway, I do not know if a0 has
different rom image, but the a0 was never sold so there is no harm in
keeping it as is.


Just to be sure (I don't have such a good hardware knowledge):
1) Does ROM image mean some code that is permanently on the device?
2) Does firmware mean code we upload from the host driver?

I'm not sure if I understand the rest of your description.

AFAIU first you said ROM image tends to be the same on chipset 
variations using
the same letter. If this is so, why we need different firmware for 
43602a0 and

43602a1? Or different firmware for 43570a0 and 43570a2?

Also if what you said about sharing one ROM image between chip 
variations using
the same letter was correct, shouldn't you expect the same ROM image on 
43602a0

and 43602a1?

Forgive me if something of this is obvious for you, I just don't have 
access to

any Broadcom internal documentation :)

Re: [PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once

[Rafał Miłecki]

On 2017-02-24 14:31, Arend Van Spriel wrote:

On 24-2-2017 14:10, Rafał Miłecki wrote:

From: Rafał Miłecki 

It avoids some unnecessary work. Most likely there wasn't much sense 
in

doing this before bus reset anyway, as reset is supposed to put chip
into default state. In PCIe code (only bus implementing reset) we e.g.
use watchdog to perform a chip "reboot".


Sorry, but removing the fisrt passive call will cause chip lockups for
sure on certain systems. We learned the hard way :-p


OK, acknowledged! ;) I just tested it on my BCM43602 doing warm reboots 
(they

were causing problems earlier) and it worked fine.

It also seems I don't use SDK recent enough as my reference :)

Kalle please drop this patch.

[PATCH] mwifiex: fix kernel crash after shutdown command timeout

[Amitkumar Karwar]

We observed a SHUTDOWN command timeout during reboot stress test due
to a corner case firmware bug. It leads to use-after-free on adapter
structure pointer and crash.

We already have a cancel_work_sync() call in teardown thread. This
issue is fixed by having this call just before mwifiex_remove_card().
At this point no further work will be scheduled.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Cathy Luo 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 3 +--
 drivers/net/wireless/marvell/mwifiex/sdio.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index a0d9180..f31c5ea 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -294,8 +294,6 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
 
-   cancel_work_sync(>work);
-
reg = card->pcie.reg;
if (reg)
ret = mwifiex_read_reg(adapter, reg->fw_status, _status);
@@ -312,6 +310,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
mwifiex_init_shutdown_fw(priv, MWIFIEX_FUNC_SHUTDOWN);
}
 
+   cancel_work_sync(>work);
mwifiex_remove_card(adapter);
 }
 
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index a4b356d..9534b47 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -387,8 +387,6 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
if (!adapter || !adapter->priv_num)
return;
 
-   cancel_work_sync(>work);
-
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
 
ret = mwifiex_sdio_read_fw_status(adapter, _stat);
@@ -400,6 +398,7 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
mwifiex_init_shutdown_fw(priv, MWIFIEX_FUNC_SHUTDOWN);
}
 
+   cancel_work_sync(>work);
mwifiex_remove_card(adapter);
 }
 
-- 
1.9.1

Re: [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table

[Arend Van Spriel]

On 24-2-2017 13:27, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or
> 4366c0. Cutting name at the letter isn't a good idea as sometimes we may
> have e.g. a0 and a1.

As explained in 1/2, the revision may change but if rom image is
unchanged the firmware stays compatible. As predicting chip development
is impossible initially we choose a common name as entry ID. So if there
would come a 4366c1 with incompatible rom image it would be time to
change the entry ID.

Regards,
Arend

> This is just a cosmetic change, a trivial cleanup. It obviously doesn't
> change fw filenames as we don't want to break user space.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 2a171479b42b..7039f7f09653 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -46,7 +46,7 @@ enum brcmf_pcie_state {
>   BRCMFMAC_PCIE_STATE_UP
>  };
>  
> -BRCMF_FW_NVRAM_DEF(43602, "brcmfmac43602-pcie.bin", 
> "brcmfmac43602-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(43602a1, "brcmfmac43602-pcie.bin", 
> "brcmfmac43602-pcie.txt");
>  BRCMF_FW_NVRAM_DEF(4350, "brcmfmac4350-pcie.bin", "brcmfmac4350-pcie.txt");
>  BRCMF_FW_NVRAM_DEF(4350C, "brcmfmac4350c2-pcie.bin", 
> "brcmfmac4350c2-pcie.txt");
>  BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-pcie.bin", "brcmfmac4356-pcie.txt");
> @@ -55,13 +55,13 @@ BRCMF_FW_NVRAM_DEF(4358, "brcmfmac4358-pcie.bin", 
> "brcmfmac4358-pcie.txt");
>  BRCMF_FW_NVRAM_DEF(4359, "brcmfmac4359-pcie.bin", "brcmfmac4359-pcie.txt");
>  BRCMF_FW_NVRAM_DEF(4365B, "brcmfmac4365b-pcie.bin", 
> "brcmfmac4365b-pcie.txt");
>  BRCMF_FW_NVRAM_DEF(4365C, "brcmfmac4365c-pcie.bin", 
> "brcmfmac4365c-pcie.txt");
> -BRCMF_FW_NVRAM_DEF(4366B, "brcmfmac4366b-pcie.bin", 
> "brcmfmac4366b-pcie.txt");
> -BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", 
> "brcmfmac4366c-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(4366b1, "brcmfmac4366b-pcie.bin", 
> "brcmfmac4366b-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(4366c0, "brcmfmac4366c-pcie.bin", 
> "brcmfmac4366c-pcie.txt");
>  BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
>  
>  static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFE, 43602),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFF0, 4366C),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFE, 43602a1),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFF0, 4366c0),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x00FF, 4350C),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFF00, 4350),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43525_CHIP_ID, 0xFFF0, 4365C),
> @@ -73,8 +73,8 @@ static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = 
> {
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4359_CHIP_ID, 0x, 4359),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0x000F, 4365B),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFF0, 4365C),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x000F, 4366B),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFF0, 4366C),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x000F, 4366b1),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFF0, 4366c0),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4371_CHIP_ID, 0x, 4371),
>  };
>  
> 

Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset

[Arend Van Spriel]

On 24-2-2017 13:27, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
> brcmfmac there is support for 43602a1 and from what I know supporting
> 43602a0 would require loading a different firmware.

This is not necessarily true. It depends on whether the rom image is
different or not and there is no way to tell up front. So if a0 has same
rom image as a1 the firmware is compatible and no distinction is needed.
This tends to be the case for chips that only change the digit and not
the letter in the chip revision. Anyway, I do not know if a0 has
different rom image, but the a0 was never sold so there is no harm in
keeping it as is.

Regards,
Arend

> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 6fae4cf3f6ab..2a171479b42b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -60,7 +60,7 @@ BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", 
> "brcmfmac4366c-pcie.txt");
>  BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
>  
>  static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0x, 43602),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFE, 43602),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFF0, 4366C),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x00FF, 4350C),
>   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFF00, 4350),
> 

[PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once

[Rafał Miłecki]

From: Rafał Miłecki 

It avoids some unnecessary work. Most likely there wasn't much sense in
doing this before bus reset anyway, as reset is supposed to put chip
into default state. In PCIe code (only bus implementing reset) we e.g.
use watchdog to perform a chip "reboot".

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 05f22ff81d60..670f2f50f9e5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -967,16 +967,14 @@ static int brcmf_chip_recognition(struct brcmf_chip_priv 
*ci)
if (ret)
return ret;
 
-   /* assure chip is passive for core access */
-   brcmf_chip_set_passive(>pub);
-
/* Call bus specific reset function now. Cores have been determined
 * but further access may require a chip specific reset at this point.
 */
-   if (ci->ops->reset) {
+   if (ci->ops->reset)
ci->ops->reset(ci->ctx, >pub);
-   brcmf_chip_set_passive(>pub);
-   }
+
+   /* assure chip is passive for core access */
+   brcmf_chip_set_passive(>pub);
 
return brcmf_chip_get_raminfo(ci);
 }
-- 
2.11.0

Re: Regression with Intel 3160 AP: client not reconnecting

[Jarek Kamiński]

W dniu 24.02.2017 o 13:13, Johannes Berg pisze:
> Hi Jarek,

Hello Johannes,

>> What might be the cause? Is there anything I can do to help debug or
>> fix this?
> 
> Thanks for the detailed bug report and analysis! I can't analyse this
> in depth right now, can you please file a bug on bugzilla.kernel.org?

Sure, I'll do that during the weekend. Thanks for response!


-- 
pozdr(); // Jarek

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

[Johannes Berg]

> I have been trying to get basic WoWLAN to work with the following
> configuration:
> - Intel Corporation Wireless 7260 (rev 73) with in-tree iwlwifi
> driver

So I just tried on 4.9 with a 6205 NIC and it works there. The
difference must be somewhere in mvm/d3.c then, I guess. I got a lot of
warnings at resume time though, not sure why.

> However, when trying to suspend to RAM ( echo mem > /sys/power/state
> ), I get:
> [46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
> returns -16
> [46656.403769] PM: Device phy0 failed to suspend async: error -16
> 

However, I don't see EBUSY anywhere there in the driver.

Can you recompile the kernel and run a quick experiment?

Open drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and put something
like this after the includes:

#undef EBUSY
#define EBUSY ({ WARN_ON(1); 16; })

that should trigger a warning at the place where the EBUSY came from,
assuming it did in fact come from the driver. You could repeat it for
net/mac80211/ieee80211_i.h if that doesn't trigger.

> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25

That device is like mine, afaict, so this seems to be a different bug.

johannes

[PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table

[Rafał Miłecki]

From: Rafał Miłecki 

Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or
4366c0. Cutting name at the letter isn't a good idea as sometimes we may
have e.g. a0 and a1.

This is just a cosmetic change, a trivial cleanup. It obviously doesn't
change fw filenames as we don't want to break user space.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 2a171479b42b..7039f7f09653 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -46,7 +46,7 @@ enum brcmf_pcie_state {
BRCMFMAC_PCIE_STATE_UP
 };
 
-BRCMF_FW_NVRAM_DEF(43602, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt");
+BRCMF_FW_NVRAM_DEF(43602a1, "brcmfmac43602-pcie.bin", 
"brcmfmac43602-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4350, "brcmfmac4350-pcie.bin", "brcmfmac4350-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4350C, "brcmfmac4350c2-pcie.bin", 
"brcmfmac4350c2-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-pcie.bin", "brcmfmac4356-pcie.txt");
@@ -55,13 +55,13 @@ BRCMF_FW_NVRAM_DEF(4358, "brcmfmac4358-pcie.bin", 
"brcmfmac4358-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4359, "brcmfmac4359-pcie.bin", "brcmfmac4359-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4365B, "brcmfmac4365b-pcie.bin", "brcmfmac4365b-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4365C, "brcmfmac4365c-pcie.bin", "brcmfmac4365c-pcie.txt");
-BRCMF_FW_NVRAM_DEF(4366B, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
-BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
+BRCMF_FW_NVRAM_DEF(4366b1, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
+BRCMF_FW_NVRAM_DEF(4366c0, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
 
 static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
-   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFE, 43602),
-   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFF0, 4366C),
+   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFE, 43602a1),
+   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFF0, 4366c0),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x00FF, 4350C),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFF00, 4350),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43525_CHIP_ID, 0xFFF0, 4365C),
@@ -73,8 +73,8 @@ static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4359_CHIP_ID, 0x, 4359),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0x000F, 4365B),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFF0, 4365C),
-   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x000F, 4366B),
-   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFF0, 4366C),
+   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x000F, 4366b1),
+   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFF0, 4366c0),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4371_CHIP_ID, 0x, 4371),
 };
 
-- 
2.11.0

[PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset

[Rafał Miłecki]

From: Rafał Miłecki 

43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
brcmfmac there is support for 43602a1 and from what I know supporting
43602a0 would require loading a different firmware.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 6fae4cf3f6ab..2a171479b42b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -60,7 +60,7 @@ BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", 
"brcmfmac4366c-pcie.txt");
 BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
 
 static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
-   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0x, 43602),
+   BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFE, 43602),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFF0, 4366C),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x00FF, 4350C),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFF00, 4350),
-- 
2.11.0

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

[Jörg Krause]

Hi Arend,

On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote:
> On 24-2-2017 10:43, Jörg Krause wrote:
> > Hi Arend,
> > 
> > On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
> > > 
> > > On 23-2-2017 21:21, Jörg Krause wrote:
> > > > Hi,
> > > > 
> > > > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When
> > > > running
> > > > 'wpa_cli wps_pin any', the following messages are printed:
> > > > 
> > > > """
> > > > > wps_pin any 
> > > > 
> > > > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
> > > > error :
> > > > -30
> > > > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > > > Failed
> > > > """
> > > > 
> > > > .. and nothing happens. The data sheet for the BCM43362 states
> > > > that
> > > > the
> > > > module supports WPS.
> > > 
> > > Hi Jörg,
> > > 
> > > We have never tested WPS with brcmfmac. Most of it is in firmware
> > > so
> > > it
> > > might work. We had some fixes related to setting management IE,
> > > but
> > > it
> > > should be in 4.9. I did not check it (yet).
> > 
> > As it turns out, WPS does not work if a network configuration in
> > wpa_supplicant has the flag `mode=2` (access point mode) set:
> > 
> > """
> > ctrl_interface=/var/run/wpa_supplicant
> > update_config=1
> > 
> > network={
> > ssid="AP"
> > key_mgmt=NONE
> > mode=2
> > id_str="ap"
> > }
> > """
> > 
> > Setting mode=2 for a network and having ap_scan=1 (default) means
> > if no
> > APs matching to the currently enabled networks are found, a new
> > network
> >  (IBSS or AP mode operation) may be initialized (if configured).
> > 
> > So, WPS does not work if the interface is operating in AP mode. I
> > wonder, if this is a desired behavior? At least, wpa_supplicant
> > does
> > not complain, but prints "WPS-PBC-ACTIVE", but no messages are
> > following, until "WPS-TIMEOUT".
> 
> So what do you expect exactly? Are you trying to connect with some
> other
> device to this AP interface?

Sorry, I got confused. The device operating in AP mode shall be
connected to some other AP as a station. Of course, WPS cannot be used
to do so as long as the interface is operation in AP mode, as the
device should be the WPS enrollee and not the registrar. My bad! Thanks
for pointing that out.

So, to use WPS for connecting the device to another AP I have to bring
the interface into an non-AP mode first.

So, I can confirm that using WPS works when the interface is
unconfigured. However, if the in the interface is in AP mode and WPS is
started the error messages pop up.

Jörg

Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq

[jeffy]

Hi Kalle,

On 02/24/2017 07:01 PM, Kalle Valo wrote:

Jeffy Chen  writes:


Currrently we are disabling this wake irq after receiving it. If this
happens before we finish suspend and the pm event check is disabled,
the system will continue suspending, and this irq would not work again.

We may need to abort system suspend to avoid that.

Signed-off-by: Jeffy Chen 

I only see patch 3 in patchwork. Where are patches 1 and 2?




the other two are much like this one, but for bluetooth :)

please check:

https://patchwork.kernel.org/patch/9589455 New  [1/3] btusb: 
wake system up when receives a wake irq
https://patchwork.kernel.org/patch/9589453 New  [2/3] btmrvl: 
wake system up when receives a wake irq
https://patchwork.kernel.org/patch/9589457 New  [3/3] mwifiex: 
wake system up when receives a wake irq




(sorry, this is a resent mail, because the last one was rejected due to 
wrong format)

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

[Arend Van Spriel]

On 24-2-2017 11:26, Jörg Krause wrote:
> Hi Arend,
> 
> On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote:
>> On 24-2-2017 10:43, Jörg Krause wrote:
>>> Hi Arend,
>>>
>>> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:

 On 23-2-2017 21:21, Jörg Krause wrote:
> Hi,
>
> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When
> running
> 'wpa_cli wps_pin any', the following messages are printed:
>
> """
>> wps_pin any 
>
> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
> error :
> -30
> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> Failed
> """
>
> .. and nothing happens. The data sheet for the BCM43362 states
> that
> the
> module supports WPS.

 Hi Jörg,

 We have never tested WPS with brcmfmac. Most of it is in firmware
 so
 it
 might work. We had some fixes related to setting management IE,
 but
 it
 should be in 4.9. I did not check it (yet).
>>>
>>> As it turns out, WPS does not work if a network configuration in
>>> wpa_supplicant has the flag `mode=2` (access point mode) set:
>>>
>>> """
>>> ctrl_interface=/var/run/wpa_supplicant
>>> update_config=1
>>>
>>> network={
>>> ssid="AP"
>>> key_mgmt=NONE
>>> mode=2
>>> id_str="ap"
>>> }
>>> """
>>>
>>> Setting mode=2 for a network and having ap_scan=1 (default) means
>>> if no
>>> APs matching to the currently enabled networks are found, a new
>>> network
>>>  (IBSS or AP mode operation) may be initialized (if configured).
>>>
>>> So, WPS does not work if the interface is operating in AP mode. I
>>> wonder, if this is a desired behavior? At least, wpa_supplicant
>>> does
>>> not complain, but prints "WPS-PBC-ACTIVE", but no messages are
>>> following, until "WPS-TIMEOUT".
>>
>> So what do you expect exactly? Are you trying to connect with some
>> other
>> device to this AP interface?
> 
> Sorry, I got confused. The device operating in AP mode shall be
> connected to some other AP as a station. Of course, WPS cannot be used
> to do so as long as the interface is operation in AP mode, as the
> device should be the WPS enrollee and not the registrar. My bad! Thanks
> for pointing that out.
> 
> So, to use WPS for connecting the device to another AP I have to bring
> the interface into an non-AP mode first.
> 
> So, I can confirm that using WPS works when the interface is
> unconfigured. However, if the in the interface is in AP mode and WPS is
> started the error messages pop up.

You mean the message you emailed earlier as below?

[ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
error :
-30
[ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
Failed

You get firmware error -30 which is BCME_NOTFOUND. This can happen in
firmware upon deleting an IE. However, it is hard to say what is exactly
happening without knowing the message content that goes to firmware. You
can enable firmware console logging to see if you get any message
regarding this, eg. "wlc_del_ie: IE not in list". Do insmod with
debug=0x0010.

if (total_ie_buf_len) {
err  = brcmf_fil_bsscfg_data_set(ifp, "vndr_ie", iovar_ie_buf,
 total_ie_buf_len);
if (err)
brcmf_err("vndr ie set error : %d\n", err);
}

If this happens in the .start_ap() callback the error is ignored so it
should not affect AP operation although beacon may not be setup properly.

Regards,
Arend

Re: Regression with Intel 3160 AP: client not reconnecting

[Johannes Berg]

Hi Jarek,

[snip]

> What might be the cause? Is there anything I can do to help debug or
> fix this?

Thanks for the detailed bug report and analysis! I can't analyse this
in depth right now, can you please file a bug on bugzilla.kernel.org?

Thanks,
johannes

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

[Jörg Krause]

Hi Arend,

On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
> 
> On 23-2-2017 21:21, Jörg Krause wrote:
> > Hi,
> > 
> > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> > 'wpa_cli wps_pin any', the following messages are printed:
> > 
> > """
> > > wps_pin any 
> > 
> > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
> > -30
> > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > Failed
> > """
> > 
> > .. and nothing happens. The data sheet for the BCM43362 states that
> > the
> > module supports WPS.
> 
> Hi Jörg,
> 
> We have never tested WPS with brcmfmac. Most of it is in firmware so
> it
> might work. We had some fixes related to setting management IE, but
> it
> should be in 4.9. I did not check it (yet).

As it turns out, WPS does not work if a network configuration in
wpa_supplicant has the flag `mode=2` (access point mode) set:

"""
ctrl_interface=/var/run/wpa_supplicant
update_config=1

network={
ssid="AP"
key_mgmt=NONE
mode=2
id_str="ap"
}
"""

Setting mode=2 for a network and having ap_scan=1 (default) means if no
APs matching to the currently enabled networks are found, a new network
 (IBSS or AP mode operation) may be initialized (if configured).

So, WPS does not work if the interface is operating in AP mode. I
wonder, if this is a desired behavior? At least, wpa_supplicant does
not complain, but prints "WPS-PBC-ACTIVE", but no messages are
following, until "WPS-TIMEOUT".

Jörg

Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq

[Kalle Valo]

Jeffy Chen  writes:

> Currrently we are disabling this wake irq after receiving it. If this
> happens before we finish suspend and the pm event check is disabled,
> the system will continue suspending, and this irq would not work again.
>
> We may need to abort system suspend to avoid that.
>
> Signed-off-by: Jeffy Chen 

I only see patch 3 in patchwork. Where are patches 1 and 2?

-- 
Kalle Valo

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

[Jörg Krause]

Hi Arend,

On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
> 
> On 23-2-2017 21:21, Jörg Krause wrote:
> > Hi,
> > 
> > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> > 'wpa_cli wps_pin any', the following messages are printed:
> > 
> > """
> > > wps_pin any 
> > 
> > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
> > -30
> > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > Failed
> > """
> > 
> > .. and nothing happens. The data sheet for the BCM43362 states that
> > the
> > module supports WPS.
> 
> Hi Jörg,
> 
> We have never tested WPS with brcmfmac. Most of it is in firmware so
> it
> might work. We had some fixes related to setting management IE, but
> it
> should be in 4.9. I did not check it (yet).

I've tested WPS on another board, the Banana Pro, which also has the
BCM43362 and it works with Linux v4.9.12. So, I'll look why it does not
work on my custom board.

Jörg

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

[Arend Van Spriel]

On 24-2-2017 10:43, Jörg Krause wrote:
> Hi Arend,
> 
> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>>
>> On 23-2-2017 21:21, Jörg Krause wrote:
>>> Hi,
>>>
>>> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
>>> 'wpa_cli wps_pin any', the following messages are printed:
>>>
>>> """
 wps_pin any 
>>>
>>> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
>>> -30
>>> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
>>> Failed
>>> """
>>>
>>> .. and nothing happens. The data sheet for the BCM43362 states that
>>> the
>>> module supports WPS.
>>
>> Hi Jörg,
>>
>> We have never tested WPS with brcmfmac. Most of it is in firmware so
>> it
>> might work. We had some fixes related to setting management IE, but
>> it
>> should be in 4.9. I did not check it (yet).
> 
> As it turns out, WPS does not work if a network configuration in
> wpa_supplicant has the flag `mode=2` (access point mode) set:
> 
> """
> ctrl_interface=/var/run/wpa_supplicant
> update_config=1
> 
> network={
>   ssid="AP"
>   key_mgmt=NONE
>   mode=2
>   id_str="ap"
> }
> """
> 
> Setting mode=2 for a network and having ap_scan=1 (default) means if no
> APs matching to the currently enabled networks are found, a new network
>  (IBSS or AP mode operation) may be initialized (if configured).
> 
> So, WPS does not work if the interface is operating in AP mode. I
> wonder, if this is a desired behavior? At least, wpa_supplicant does
> not complain, but prints "WPS-PBC-ACTIVE", but no messages are
> following, until "WPS-TIMEOUT".

So what do you expect exactly? Are you trying to connect with some other
device to this AP interface?

Regards,
Arend

Re: Request for brcmfmac4366c-pcie.bin

[Arend Van Spriel]

On 23-2-2017 21:53, Rafał Miłecki wrote:
> Hi guys,
> 
> On 12 September 2016 at 07:22, Rafał Miłecki  wrote:
>> Few months ago Hante added support for 4366c0 to the brcmfmac. There
>> are already few devices with this chipset on the market. We even have
>> some related bug report at kernel:
>> https://bugzilla.kernel.org/show_bug.cgi?id=135321
>>
>> Unfortunately the firmware for this chipset is still missing. Can you
>> build it and submit to linux-firmware.git, please?
> 
> Last answer I got from Arend was "Router group still working on a
> solution. Will ask about status again :-(" in December.
> Are there any news on 4366c1 firmware?

There have been some firmware changes being made, but these need to be
validated. As the validation is in DFS area it may take some time and we
have to free up resources to actually do the validation.

Regards,
Arend

Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.

[Andrew Zaborowski]

On 24 February 2017 at 01:28,   wrote:
> Modify the receive-from-user-space logic to do length
> and 'is-down' checks before trying to allocate an skb.
>
> And, if we are going to ignore the pkt due to radio idle,
> then do not return an error code to user-space.  User-space
> cannot reliably know exactly when a radio is idle or not.

You probably want to return some error code anyway because 0, if you
compare to the kernel medium, currently maps to the ack returned bit
and is possibly the only way for userspace to set the
HWSIM_TX_STAT_ACK flag in a meaningful way.

Best regards

Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362

[Arend Van Spriel]

On 23-2-2017 21:21, Jörg Krause wrote:
> Hi,
> 
> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> 'wpa_cli wps_pin any', the following messages are printed:
> 
> """
>> wps_pin any 
> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error : -30
> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE Failed
> """
> 
> .. and nothing happens. The data sheet for the BCM43362 states that the
> module supports WPS.

Hi Jörg,

We have never tested WPS with brcmfmac. Most of it is in firmware so it
might work. We had some fixes related to setting management IE, but it
should be in 4.9. I did not check it (yet).

Regards,
Arend

Re: [RFC v2 2/2] cfg80211: support 4-way handshake offloading for 802.1X

[Arend Van Spriel]

On 21-2-2017 13:37, Johannes Berg wrote:
> From: Avraham Stern 
> 
> Add API for setting the PMK to the driver. For FT support, allow
> setting also the PMK-R0 Name.
> 
> This can be used by drivers that support 4-Way handshake offload
> while IEEE802.1X authentication is managed by upper layers.
> 
> Signed-off-by: Avraham Stern 
> Signed-off-by: Johannes Berg 
> ---
>  include/linux/ieee80211.h|  3 ++
>  include/net/cfg80211.h   | 27 
>  include/uapi/linux/nl80211.h | 24 ++-
>  net/wireless/core.c  |  5 +++
>  net/wireless/nl80211.c   | 99 
> 
>  net/wireless/rdev-ops.h  | 25 +++
>  net/wireless/trace.h | 60 +++
>  7 files changed, 241 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index 2049e983a994..fb1f533e75b3 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -2356,8 +2356,11 @@ enum ieee80211_sa_query_action {
>  
>  #define WLAN_MAX_KEY_LEN 32
>  
> +#define WLAN_PMK_NAME_LEN16
>  #define WLAN_PMKID_LEN   16
> +#define WLAN_PMK_LEN_EAP_LEAP16
>  #define WLAN_PMK_LEN 32
> +#define WLAN_PMK_LEN_SUITE_B_192 48
>  
>  #define WLAN_OUI_WFA 0x506f9a
>  #define WLAN_OUI_TYPE_WFA_P2P9
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 4ca968927d60..a68c6db6ac55 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2507,6 +2507,23 @@ struct cfg80211_nan_func {
>  };
>  
>  /**
> + * struct cfg80211_pmk_conf - PMK configuration
> + *
> + * @aa: authenticator address
> + * @pmk_len: PMK length in bytes.
> + * @pmk: the PMK material
> + * @pmk_r0_name: PMK-R0 Name. NULL if not applicable (i.e., the PMK
> + *   is not PMK-R0). When pmk_r0_name is not NULL, the pmk field
> + *   holds PMK-R0.
> + */
> +struct cfg80211_pmk_conf {
> + const u8 *aa;
> + u8 pmk_len;
> + const u8 *pmk;
> + const u8 *pmk_r0_name;
> +};
> +
> +/**
>   * struct cfg80211_ops - backend description for wireless configuration
>   *
>   * This struct is registered by fullmac card drivers and/or wireless stacks
> @@ -2823,6 +2840,11 @@ struct cfg80211_nan_func {
>   *   All other parameters must be ignored.
>   *
>   * @set_multicast_to_unicast: configure multicast to unicast conversion for 
> BSS
> + *
> + * @set_pmk: configure the PMK to be used for offloaded 4-Way handshake.
> + *   (invoked with the wireless_dev mutex held)
> + * @del_pmk: delete the previously configured PMK for the given 
> authenticator.
> + *   (invoked with the wireless_dev mutex held)
>   */
>  struct cfg80211_ops {
>   int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
> @@ -3111,6 +3133,11 @@ struct cfg80211_ops {
>   int (*set_multicast_to_unicast)(struct wiphy *wiphy,
>   struct net_device *dev,
>   const bool enabled);
> +
> + int (*set_pmk)(struct wiphy *wiphy, struct net_device *dev,
> +const struct cfg80211_pmk_conf *conf);
> + int (*del_pmk)(struct wiphy *wiphy, struct net_device *dev,
> +const u8 *aa);

Minor nit, but prefer clr_pmk to clear the pmk.

>  };
>  
>  /*
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index bb5e1904a107..89295fc2336b 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -901,6 +901,14 @@
>   *   does not result in a change for the current association. Currently,
>   *   only the %NL80211_ATTR_IE data is used and updated with this command.
>   *
> + * @NL80211_CMD_SET_PMK: For offloaded 4-Way handshake, set the PMK or PMK-R0
> + *   for the given authenticator address (specified with _ATTR_MAC).
> + *   When _ATTR_PMKR0_NAME is set, _ATTR_PMK specifies the
> + *   PMK-R0, otherwise it specifies the PMK.
> + * @NL80211_CMD_DEL_PMK: For offloaded 4-Way handshake, delete the previously
> + *   configured PMK for the authenticator address identified by
> + *   _ATTR_MAC.

Maybe better to indicate it is for 802.1X. Here also preference for
NL80211_CMD_CLR_PMK.

> + *
>   * @NL80211_CMD_MAX: highest used command number
>   * @__NL80211_CMD_AFTER_LAST: internal use
>   */
> @@ -1100,6 +1108,9 @@ enum nl80211_commands {
>  
>   NL80211_CMD_UPDATE_CONNECT_PARAMS,
>  
> + NL80211_CMD_SET_PMK,
> + NL80211_CMD_DEL_PMK,
> +
>   /* add new commands above here */
>  
>   /* used to define NL80211_CMD_MAX below */
> @@ -2012,8 +2023,12 @@ enum nl80211_commands {
>   *   u32 attribute with an  nl80211_timeout_reason value. This is used,
>   *   e.g., with %NL80211_CMD_CONNECT event.
>   *
> - * @NL80211_ATTR_PMK: PSK for offloaded 4-Way