Re: [PATCH 5.4 regression fix] brcmfmac: Fix brcmf_cfg80211_get_channel returning uninitialized fields

[Arend Van Spriel]

On 10/3/2019 10:08 PM, Hans de Goede wrote:

With the new edmg support struct cfg80211_chan_def has been extended
with a number of new members. brcmf_cfg80211_get_channel() was not setting
(clearing) these causing the cfg80211_edmg_chandef_valid() check in
cfg80211_chandef_valid() to fail. Triggering a WARN_ON and, worse, causing
brcmfmac based wifi cards to not work.

This commit fixes this by clearing the entire passed struct to 0 before
setting the members used by the brcmfmac code. This solution also makes
sure that this problem will not repeat itself in the future if further
members are added to the struct.


Guess this warrants a Fixes: tag and ...

Acked-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index e3ebb7abbdae..480c05f66ebd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5041,10 +5041,10 @@ static int brcmf_cfg80211_get_channel(struct wiphy 
*wiphy,
}
  
  	freq = ieee80211_channel_to_frequency(ch.control_ch_num, band);

+   memset(chandef, 0, sizeof(*chandef));
chandef->chan = ieee80211_get_channel(wiphy, freq);
chandef->width = width;
chandef->center_freq1 = ieee80211_channel_to_frequency(ch.chnum, band);
-   chandef->center_freq2 = 0;
  
  	return 0;

  }

Re: [PATCH V3 0/8] nl80211: add 6GHz band support

[Arend Van Spriel]

+ linux-wireless

On September 19, 2019 8:25:57 PM Jeff Johnson  
wrote:



On 2019-08-02 04:30, Arend van Spriel wrote:

Changing to formal patch series instead of RFC.


In 802.11ax D4.0 a new band has been proposed. This series contains
changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
was no overlap in channel number. However, this new band has channel
numbers with a range from 1 up to 253. The only place I could find an
issue with this is in cfg80211_wext_freq(). Not sure how to deal with
that so it is not part of this series.


The series applies to the master branch of the mac80211-next
repository.


Arend van Spriel (8):
nl80211: add 6GHz band definition to enum nl80211_band
cfg80211: add 6GHz UNII band definitions
cfg80211: util: add 6GHz channel to freq conversion and vice versa
cfg80211: extend ieee80211_operating_class_to_band() for 6GHz
cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS
entries
cfg80211: use same IR permissive rules for 6GHz band
cfg80211: ibss: use 11a mandatory rates for 6GHz band operation
cfg80211: apply same mandatory rate flags for 5GHz and 6GHz


include/uapi/linux/nl80211.h |  2 ++
net/mac80211/tx.c|  1 +
net/wireless/chan.c  |  3 ++-
net/wireless/ibss.c  | 16 +++-
net/wireless/nl80211.c   |  1 +
net/wireless/reg.c   | 21 +++--
net/wireless/trace.h |  3 ++-
net/wireless/util.c  | 14 +-
8 files changed, 51 insertions(+), 10 deletions(-)


Curious how you are populating the wiphy->bands[6 GHz].
If we don't set ht_cap.ht_supported and/or vht_cap.vht_supported then
cfg80211_chandef_usable() fails, but setting those flags on 6 GHz seems
broken.


Hi Jeff,

Good point. Actually, for 6GHz a couple of (v)ht capabilities are still 
applicable and exchanged using HE extended capabilities element. My idea 
was that these (v)ht capabilities would be reported to user-space same 
as for the other bands so that would imply those flags are also set for 
6GHz. This may look odd as the statement "6G is HE only" applies, but 
still some (v)ht functionality is used in HE. Despite this it may be 
good to extend the cfg80211_chandef_usable() for HE in general and cover 
the 6G case as well. The intended driver implementation in brcmfmac is 
still being worked on so issues might arise.


Regards,
Arend

Re: [PATCH 04/11] wil6210: fix PTK re-key race

[Arend Van Spriel]

On 9/12/2019 11:04 PM, Alexander Wetzel wrote:

Hi Denis,

I don't know anything about the driver here but in mac80211 the idea 
to avoid the race is to simply flush the queues prior deleting the 
outgoing key.


Maybe a silly question, but what does flushing the queue mean in this 
context?  Is it waiting for all the packets to be sent or dropping 
them on the floor?




It's stopping them to make sure nothing can be added and then sends out 
all MPDUs in the queues.




Now wpa_supplicant is not yet bypassing qdisks, but adding the socket 
parameter PACKET_QDISC_BYPASS is basically a one-liner in 
wpa_supplicant and should allow a generic way for drivers to avoid 
the race with a simple queue flush...


Can you expand on this actually?  What would the sequence of events be?



1) wpa_supplicant hands over eapol #4 to the kernel.
    When bypassing the QDISC the frame is directly added to a driver
    queue or directly send out. When the send call returns the driver
    has eapol 4 either in the queuem already send it or the send command
    has failed.

2) wpa_supplicant deletes the old key (NL80211_CMD_DEL_KEY)

3) The driver stops all hw queues and sends out all MPDUs queued up to
    that time

4) Driver makes sure no traffic can be send with no/wrong key or PN to
    STA

5) the driver really removes the key from the HW/installs the new and
    resumes normal operation

I've just posted my hostpad patch to use PACKET_QDISC_BYPASS for eapol 
frames; It's probably too optimistic and need more code to retry a 
transmit to compensate for the missing QDISC buffers.



Also, how would this be made to work with CONTROL_PORT over NL80211 ?



Control port is an optional feature drivers can provide. wpa_supplicant 
should just use it when available or fall back to the "traditional" path 
when not. Now the driver don't has to flush all queues when using 
control port, as long as it makes sure the control port frame will be 
send out prior to deleting the key.


But then the driver must know that eapol frames will really be handed 
over via control port; So I guess flushing all queues is still the 
simpler solution. So I guess it will change next to nothing...


Well, in the steps you describe (maybe its just how you describe it) it 
relies on how the driver is handling it all. I mean step 4) seems more 
the goal of the whole approach.


Basically, we now have two bypass methods dealing with the same/similar 
issue:


1) bypass the QDISC.
2) bypass network stack entirely with CONTROL_PORT.

How does option 1) work for drivers that skip the QDISC for all traffic 
and rely on mac80211 to schedule the packets? Guess mac80211 can control 
that, right?


Regards,
Arend

Re: [PATCH 04/11] wil6210: fix PTK re-key race

[Arend Van Spriel]

On 9/10/2019 3:23 PM, Kalle Valo wrote:

Maya Erez  wrote:


Fix a race between cfg80211 add_key call and transmitting of 4/4 EAP
packet. In case the transmit is delayed until after the add key takes
place, message 4/4 will be encrypted with the new key, and the
receiver side (AP) will drop it due to MIC error.

Wil6210 will monitor and look for the transmitted packet 4/4 eap key.
In case add_key takes place before the transmission completed, then
wil6210 will let the FW store the key and wil6210 will notify the FW
to use the PTK key only after 4/4 eap packet transmission was
completed.


This is rather ugly but I guess still ok. Or what do people think?


The idea is similar to what we have in brcmfmac although it looks like a 
lot more code. So there seems precedent for the approach.



But for a proper fix you should look at:

[PATCH v2] wpa_supplicant: Send EAPoL-Key frames over NL80211 where available

http://lists.infradead.org/pipermail/hostap/2019-September/040516.html


However, I agree that Denis did a better job with this and we should aim 
to use it. It is on my largish TODO list for brcmfmac.


Regards,
Arend

Re: [PATCH 3/3] brcmfmac: don't realloc wiphy during PCIe reset

[Arend Van Spriel]

On 9/3/2019 6:29 AM, Rafał Miłecki wrote:

From: Rafał Miłecki 

Providing a new wiphy on every PCIe reset was confusing and was causing
configuration problems for some users (supplicant and authenticators).
Sticking to the existing wiphy should make error recovery much simpler
and more reliable.


Acked-by: Arend van Spriel 

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

Re: [PATCH 2/3] brcmfmac: split brcmf_attach() and brcmf_detach() functions

[Arend Van Spriel]

On 9/3/2019 6:29 AM, Rafał Miłecki wrote:

From: Rafał Miłecki 

Move code allocating/freeing wiphy out of above functions. This will
allow reinitializing the driver (e.g. on some error) without allocating
a new wiphy.


Acked-by: Arend van Spriel 

Signed-off-by: Rafał Miłecki 
---
  .../broadcom/brcm80211/brcmfmac/bus.h |  4 ++-
  .../broadcom/brcm80211/brcmfmac/core.c| 33 ++
  .../broadcom/brcm80211/brcmfmac/pcie.c| 13 +--
  .../broadcom/brcm80211/brcmfmac/sdio.c| 15 ++--
  .../broadcom/brcm80211/brcmfmac/usb.c | 34 +++
  5 files changed, 80 insertions(+), 19 deletions(-)

Re: [PATCH 1/3] brcmfmac: move "cfg80211_ops" pointer to another struct

[Arend Van Spriel]

On 9/3/2019 6:29 AM, Rafał Miłecki wrote:

From: Rafał Miłecki 

This moves "ops" pointer from "struct brcmf_cfg80211_info" to the
"struct brcmf_pub". This movement makes it possible to allocate wiphy
without attaching cfg80211 (brcmf_cfg80211_attach()). It's required for
later separation of wiphy allocation and driver initialization.

While at it fix also an unlikely memory leak in the brcmf_attach().


Always good ;-)

I recall there is some fiddling with the callback ops in cfg80211.c. Is 
that broken by this reorg. Need to look into that.


Regards,
Arend

Re: [PATCH 0/3] brcmfmac: keep wiphy during PCIe driver lifetime

[Arend Van Spriel]

On 9/3/2019 6:29 AM, Rafał Miłecki wrote:

From: Rafał Miłecki 

Driver's main init/attach function brcmf_attach() was handling both:
wiphy allocation and driver initialization. It meant getting a new wiphy
on every init (initial, resume, error recovery).

For supplicants/authenticators and Linux users it's move convenient to
have the same wiphy over driver's lifetime. It allows e.g. automatic
recovery after a firmware crash.


Typo: 'move' should be 'more'.

Regards,
Arend

[PATCH] cfg80211: fix boundary value in ieee80211_frequency_to_channel()

[Arend van Spriel]

The boundary value used for the 6G band was incorrect as it would
result in invalid 6G channel number for certain frequencies.

Reported-by: Amar Singhal 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index c999390..006f3ea 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -116,7 +116,7 @@ int ieee80211_frequency_to_channel(int freq)
return (freq - 2407) / 5;
else if (freq >= 4910 && freq <= 4980)
return (freq - 4000) / 5;
-   else if (freq < 5940)
+   else if (freq < 5945)
return (freq - 5000) / 5;
else if (freq <= 45000) /* DMG band lower limit */
/* see 802.11ax D4.1 27.3.22.2 */
-- 
1.9.1

Re: [PATCH] cfg80211: Add new helper function for channels

[Arend Van Spriel]

On 8/30/2019 12:41 PM, Johannes Berg wrote:

On Fri, 2019-08-30 at 12:40 +0200, Arend Van Spriel wrote:


+EXPORT_SYMBOL(ieee80211_channel_op_class_to_frequency);


The function ieee80211_operating_class_to_band() uses ranges within
switch statement, eg.:

  case 128 ... 130:
  *band = NL80211_BAND_5GHZ;
  return true;


No that you remind me - how is this new function not just a composition
of the existing ones?

i.e. just convert the op_class to band first, and then (band, channel)
to freq?


yup. that would have my preference actually.

Regards,
Arend

Re: [PATCH] cfg80211: Convert 6 GHz channel frequency to channel number

[Arend Van Spriel]

On 8/30/2019 12:32 PM, Johannes Berg wrote:

On Thu, 2019-08-29 at 15:21 -0700, Amar Singhal wrote:

Enhance function ieee80211_frequency_to_channel by adding 6 GHz
channels.


Wait, this is already supported, no? Just implemented slightly
differently?


It is Johannes, but I was unaware as well. Did you forget to email that 
it was applied or is there some automated stuff that failed on you? ;-)


Regards,
Arend

Re: [PATCH] cfg80211: Convert 6 GHz channel frequency to channel number

[Arend Van Spriel]

On 8/30/2019 12:21 AM, Amar Singhal wrote:

Enhance function ieee80211_frequency_to_channel by adding 6 GHz
channels.


This look very similar to what I submitted earlier:

https://patchwork.kernel.org/patch/11073197/

Regards,
Arend

Re: [PATCH] cfg80211: Add new helper function for channels

[Arend Van Spriel]

On 8/29/2019 11:49 PM, Amar Singhal wrote:

Add new helper function to convert (chan_number, oper_class) pair to
frequency. Call this function ieee80211_channel_op_class_to_frequency.
This function would be very useful in the context of 6 GHz channels,
where channel number is not unique.


That 'unique' statement does not apply to 6GHz by itself. The addition 
of 6GHz channels makes channel numbers across bands not unique.


The funcion

Signed-off-by: Amar Singhal 
---
  include/net/cfg80211.h | 10 ++
  net/wireless/util.c| 23 +++
  2 files changed, 33 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 6467b60..decafba 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4914,1 +4914,1 @@ static inline void *wdev_priv(struct wireless_dev *wdev)
  int ieee80211_channel_to_frequency(int chan, enum nl80211_band band);

  /**
+ * ieee80211_channel_op_class_to_frequency - convert
+ * (channel, operating class) to frequency
+ * @chan_num: channel number
+ * @global_op_class: global operating class
+ *
+ * Return: The corresponding frequency, or 0 if the conversion failed.
+ */
+int ieee80211_channel_op_class_to_frequency(u8 chan_num, u8 global_op_class);
+
+/**
   * ieee80211_frequency_to_channel - convert frequency to channel number
   * @freq: center frequency
   * Return: The corresponding channel, or 0 if the conversion failed.
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 9aba8d54..7f64b4a 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -144,6 +144,29 @@ struct ieee80211_channel *ieee80211_get_channel(struct 
wiphy *wiphy, int freq)
  }
  EXPORT_SYMBOL(ieee80211_get_channel);

+int ieee80211_channel_op_class_to_frequency(u8 chan_num, u8 global_op_class)
+{
+   if (global_op_class >= 131 && global_op_class <= 135)
+   return (5940 + 5 * chan_num);
+   else if (global_op_class >= 115 && global_op_class <= 130)
+   return (5000 + 5 * chan_num);
+   else if (global_op_class >= 112 && global_op_class <= 113)
+   return (5000 + 5 * chan_num);
+   else if (global_op_class >= 109 && global_op_class <= 110)
+   return (4000 + 5 * chan_num);
+   else if (global_op_class >= 83 && global_op_class <= 84)
+   return (2407 + 5 * chan_num);
+   else if (global_op_class == 81)
+   return (2407 + 5 * chan_num);
+   else if (global_op_class == 82)
+   return (2414 + 5 * chan_num);
+   else if (global_op_class == 180)
+   return (56160 + 5 * chan_num);
+   else
+   return 0;
+}
+EXPORT_SYMBOL(ieee80211_channel_op_class_to_frequency);


The function ieee80211_operating_class_to_band() uses ranges within 
switch statement, eg.:


case 128 ... 130:
*band = NL80211_BAND_5GHZ;
return true;

For consistency it might be good to do the same here.

Regards,
Arend

Re: [PATCH] brcmfmac: replace strncpy() by strscpy()

[Arend Van Spriel]

On 8/23/2019 9:47 AM, Xulin Sun wrote:

The strncpy() may truncate the copied string,
replace it by the safer strscpy().

To avoid below compile warning with gcc 8.2:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function 
'brcmf_vndr_ie':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2:
warning: 'strncpy' output truncated before terminating nul copying 3 bytes from 
a string of the same length [-Wstringop-truncation]
   strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
   ^~~~


Acked-by: Arend van Spriel 

Signed-off-by: Xulin Sun 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

Re: [PATCH v7 2/2] nl support for dmtool

[Arend Van Spriel]

On 8/18/2019 4:15 PM, Alexei Avshalom Lazar wrote:

Signed-off-by: Alexei Avshalom Lazar 
---
  drivers/net/wireless/ath/wil6210/Kconfig   |  11 ++
  drivers/net/wireless/ath/wil6210/Makefile  |   1 +
  drivers/net/wireless/ath/wil6210/ioctl.c   | 245 +
  drivers/net/wireless/ath/wil6210/netdev.c  |   8 +
  drivers/net/wireless/ath/wil6210/wil6210.h |   1 +
  include/uapi/linux/wil6210_uapi.h  |  77 +
  6 files changed, 343 insertions(+)
  create mode 100644 drivers/net/wireless/ath/wil6210/ioctl.c
  create mode 100644 include/uapi/linux/wil6210_uapi.h

diff --git a/drivers/net/wireless/ath/wil6210/Kconfig 
b/drivers/net/wireless/ath/wil6210/Kconfig
index 0d1a8da..48b14de 100644
--- a/drivers/net/wireless/ath/wil6210/Kconfig
+++ b/drivers/net/wireless/ath/wil6210/Kconfig
@@ -53,3 +53,14 @@ config WIL6210_DEBUGFS
  option if you are interested in debugging the driver.
  
  	  If unsure, say Y to make it easier to debug problems.

+
+config WIL6210_WRITE_IOCTL
+   bool "wil6210 write ioctl to the device"
+   depends on WIL6210
+   default y
+   help
+ Say Y here to allow write-access from user-space to
+ the device memory through ioctl. This is useful for
+ debugging purposes only.
+
+ If unsure, say N.


I was about to scream in horror seeing this patch, but noticed you 
rectified it in v8. *Phew*


Regards,
Arend

Re: [PATCH v2 2/2] rtw88: RTL8822C: add WoW firmware v7.3

[Arend Van Spriel]

On 8/7/2019 11:53 AM, Tony Chuang wrote:

From: Arend Van Spriel [mailto:arend.vanspr...@broadcom.com]

On 8/7/2019 10:48 AM, yhchu...@realtek.com wrote:

From: Yan-Hsuan Chuang 

Add WoW firmware to support entering Wake on WirelessLAN mode

Signed-off-by: Yan-Hsuan Chuang 
---

v1 -> v2
 * update WHENCE file for new added firmware

   WHENCE|   1 +
   rtw88/rtw8822c_wow_fw.bin | Bin 0 -> 138720 bytes
   2 files changed, 1 insertion(+)
   create mode 100755 rtw88/rtw8822c_wow_fw.bin


Just wondering: Is this a good approach? What firmware should distros
pick? Is there a trade-off affecting other wifi functionality when using
WoW firmware?



If distros want to use WOW, they should pick both.

For Realtek devices such as RTL8822CE, it needs to "change/re-download"
the wow firmware to suspend with WOW functionalities. When resume,
switch back to normal firmware to run "normally".

I think the reason is the firmware size restriction. For newer devices,
maybe there is a larger space for firmware, and we don't need to swap
the FW like this :)


Interesting approach and I would mention this in the commit message or 
add a README in rtw88 folder explaining it. Not sure whether distros 
look at commit messages.


Regards,
Arend

Re: [PATCH v2 2/2] rtw88: RTL8822C: add WoW firmware v7.3

[Arend Van Spriel]

On 8/7/2019 10:48 AM, yhchu...@realtek.com wrote:

From: Yan-Hsuan Chuang 

Add WoW firmware to support entering Wake on WirelessLAN mode

Signed-off-by: Yan-Hsuan Chuang 
---

v1 -> v2
* update WHENCE file for new added firmware

  WHENCE|   1 +
  rtw88/rtw8822c_wow_fw.bin | Bin 0 -> 138720 bytes
  2 files changed, 1 insertion(+)
  create mode 100755 rtw88/rtw8822c_wow_fw.bin


Just wondering: Is this a good approach? What firmware should distros 
pick? Is there a trade-off affecting other wifi functionality when using 
WoW firmware?


Regards,
Arend

[PATCH V3 5/8] cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS entries

[Arend van Spriel]

In nl80211.c there is a policy for all bands in NUM_NL80211_BANDS and
in trace.h there is a callback trace for multicast rates which is per
band in NUM_NL80211_BANDS. Both need to be extended for the new
NL80211_BAND_6GHZ.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/nl80211.c | 1 +
 net/wireless/trace.h   | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1a107f2..d28d745 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -677,6 +677,7 @@ static int validate_ie_attr(const struct nlattr *attr,
 nl80211_match_band_rssi_policy[NUM_NL80211_BANDS] = {
[NL80211_BAND_2GHZ] = { .type = NLA_S32 },
[NL80211_BAND_5GHZ] = { .type = NLA_S32 },
+   [NL80211_BAND_6GHZ] = { .type = NLA_S32 },
[NL80211_BAND_60GHZ] = { .type = NLA_S32 },
 };
 
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 4fbb91a..d98ad2b 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2446,10 +2446,11 @@
   sizeof(int) * NUM_NL80211_BANDS);
),
TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", "
- "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 60GHz=0x%x]",
+ "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 6GHz=0x%x, 
60GHz=0x%x]",
  WIPHY_PR_ARG, NETDEV_PR_ARG,
  __entry->mcast_rate[NL80211_BAND_2GHZ],
  __entry->mcast_rate[NL80211_BAND_5GHZ],
+ __entry->mcast_rate[NL80211_BAND_6GHZ],
  __entry->mcast_rate[NL80211_BAND_60GHZ])
 );
 
-- 
1.9.1

[PATCH V3 6/8] cfg80211: use same IR permissive rules for 6GHz band

[Arend van Spriel]

The function cfg80211_ir_permissive_chan() is applicable for
6GHz band as well so make sure it is handled.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/chan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 7dc1bbd..7c9d204 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -894,7 +894,8 @@ static bool cfg80211_ir_permissive_chan(struct wiphy *wiphy,
if (chan == other_chan)
return true;
 
-   if (chan->band != NL80211_BAND_5GHZ)
+   if (chan->band != NL80211_BAND_5GHZ &&
+   chan->band != NL80211_BAND_6GHZ)
continue;
 
r1 = cfg80211_get_unii(chan->center_freq);
-- 
1.9.1

[PATCH V3 1/8] nl80211: add 6GHz band definition to enum nl80211_band

[Arend van Spriel]

In the 802.11ax specification a new band is introduced, which
is also proposed by FCC for unlicensed use. This band is referred
to as 6GHz spanning frequency range from 5925 to 7125 MHz.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
changes:
  - V2
fix ABI breakage by appending the new band definition.
  - V3
fix warning (-Wswitch) in mac80211.
---
 include/uapi/linux/nl80211.h | 2 ++
 net/mac80211/tx.c| 1 +
 2 files changed, 3 insertions(+)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 822851d..4d5988f 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4543,6 +4543,7 @@ enum nl80211_txrate_gi {
  * @NL80211_BAND_2GHZ: 2.4 GHz ISM band
  * @NL80211_BAND_5GHZ: around 5 GHz band (4.9 - 5.7 GHz)
  * @NL80211_BAND_60GHZ: around 60 GHz band (58.32 - 69.12 GHz)
+ * @NL80211_BAND_6GHZ: around 6 GHz band (5.9 - 7.2 GHz)
  * @NUM_NL80211_BANDS: number of bands, avoid using this in userspace
  * since newer kernel versions may support more bands
  */
@@ -4550,6 +4551,7 @@ enum nl80211_band {
NL80211_BAND_2GHZ,
NL80211_BAND_5GHZ,
NL80211_BAND_60GHZ,
+   NL80211_BAND_6GHZ,
 
NUM_NL80211_BANDS,
 };
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 235c637..1fa4227 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -162,6 +162,7 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data 
*tx,
break;
}
case NL80211_BAND_5GHZ:
+   case NL80211_BAND_6GHZ:
if (r->flags & IEEE80211_RATE_MANDATORY_A)
mrate = r->bitrate;
break;
-- 
1.9.1

[PATCH V3 3/8] cfg80211: util: add 6GHz channel to freq conversion and vice versa

[Arend van Spriel]

Extend the functions ieee80211_channel_to_frequency() and
ieee80211_frequency_to_channel() to support 6GHz band according
specification in 802.11ax D4.1 27.3.22.2.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 1c39d6a..4e633d4 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -91,6 +91,11 @@ int ieee80211_channel_to_frequency(int chan, enum 
nl80211_band band)
else
return 5000 + chan * 5;
break;
+   case NL80211_BAND_6GHZ:
+   /* see 802.11ax D4.1 27.3.22.2 */
+   if (chan <= 253)
+   return 5940 + chan * 5;
+   break;
case NL80211_BAND_60GHZ:
if (chan < 7)
return 56160 + chan * 2160;
@@ -111,8 +116,11 @@ int ieee80211_frequency_to_channel(int freq)
return (freq - 2407) / 5;
else if (freq >= 4910 && freq <= 4980)
return (freq - 4000) / 5;
-   else if (freq <= 45000) /* DMG band lower limit */
+   else if (freq < 5940)
return (freq - 5000) / 5;
+   else if (freq <= 45000) /* DMG band lower limit */
+   /* see 802.11ax D4.1 27.3.22.2 */
+   return (freq - 5940) / 5;
else if (freq >= 58320 && freq <= 70200)
return (freq - 56160) / 2160;
else
-- 
1.9.1

[PATCH V3 8/8] cfg80211: apply same mandatory rate flags for 5GHz and 6GHz

[Arend van Spriel]

For the new 6GHz band the same rules apply for mandatory rates so
add it to set_mandatory_flags_band() function.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4462837..f0558e7 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -156,6 +156,7 @@ static void set_mandatory_flags_band(struct 
ieee80211_supported_band *sband)
 
switch (sband->band) {
case NL80211_BAND_5GHZ:
+   case NL80211_BAND_6GHZ:
want = 3;
for (i = 0; i < sband->n_bitrates; i++) {
if (sband->bitrates[i].bitrate == 60 ||
-- 
1.9.1

[PATCH V3 0/8] nl80211: add 6GHz band support

[Arend van Spriel]

Changing to formal patch series instead of RFC.

In 802.11ax D4.0 a new band has been proposed. This series contains
changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
was no overlap in channel number. However, this new band has channel
numbers with a range from 1 up to 253. The only place I could find an
issue with this is in cfg80211_wext_freq(). Not sure how to deal with
that so it is not part of this series.

The series applies to the master branch of the mac80211-next repository.

Arend van Spriel (8):
  nl80211: add 6GHz band definition to enum nl80211_band
  cfg80211: add 6GHz UNII band definitions
  cfg80211: util: add 6GHz channel to freq conversion and vice versa
  cfg80211: extend ieee80211_operating_class_to_band() for 6GHz
  cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS
entries
  cfg80211: use same IR permissive rules for 6GHz band
  cfg80211: ibss: use 11a mandatory rates for 6GHz band operation
  cfg80211: apply same mandatory rate flags for 5GHz and 6GHz

 include/uapi/linux/nl80211.h |  2 ++
 net/mac80211/tx.c|  1 +
 net/wireless/chan.c  |  3 ++-
 net/wireless/ibss.c  | 16 +++-
 net/wireless/nl80211.c   |  1 +
 net/wireless/reg.c   | 21 +++--
 net/wireless/trace.h |  3 ++-
 net/wireless/util.c  | 14 +-
 8 files changed, 51 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH V3 2/8] cfg80211: add 6GHz UNII band definitions

[Arend van Spriel]

For the new 6GHz there are new UNII band definitions as listed
in the FCC notice [1].

[1] https://docs.fcc.gov/public/attachments/FCC-18-147A1_Rcd.pdf

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/reg.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 4831ad74..646107a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3806,8 +3806,9 @@ void wiphy_regulatory_deregister(struct wiphy *wiphy)
 }
 
 /*
- * See http://www.fcc.gov/document/5-ghz-unlicensed-spectrum-unii, for
- * UNII band definitions
+ * See FCC notices for UNII band definitions
+ *  5GHz: https://www.fcc.gov/document/5-ghz-unlicensed-spectrum-unii
+ *  6GHz: 
https://www.fcc.gov/document/fcc-proposes-more-spectrum-unlicensed-use-0
  */
 int cfg80211_get_unii(int freq)
 {
@@ -3831,6 +3832,22 @@ int cfg80211_get_unii(int freq)
if (freq > 5725 && freq <= 5825)
return 4;
 
+   /* UNII-5 */
+   if (freq > 5925 && freq <= 6425)
+   return 5;
+
+   /* UNII-6 */
+   if (freq > 6425 && freq <= 6525)
+   return 6;
+
+   /* UNII-7 */
+   if (freq > 6525 && freq <= 6875)
+   return 7;
+
+   /* UNII-8 */
+   if (freq > 6875 && freq <= 7125)
+   return 8;
+
return -EINVAL;
 }
 
-- 
1.9.1

[PATCH V3 7/8] cfg80211: ibss: use 11a mandatory rates for 6GHz band operation

[Arend van Spriel]

The default mandatory rates, ie. when not specified by user-space, is
determined by the band. Select 11a rateset for 6GHz band.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/ibss.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index d1743e6..ae8fe66 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -104,13 +104,19 @@ int __cfg80211_join_ibss(struct 
cfg80211_registered_device *rdev,
* use the mandatory rate set for 11b or
* 11a for maximum compatibility.
*/
-   struct ieee80211_supported_band *sband =
-   rdev->wiphy.bands[params->chandef.chan->band];
+   struct ieee80211_supported_band *sband;
+   enum nl80211_band band;
+   u32 flag;
int j;
-   u32 flag = params->chandef.chan->band == NL80211_BAND_5GHZ ?
-   IEEE80211_RATE_MANDATORY_A :
-   IEEE80211_RATE_MANDATORY_B;
 
+   band = params->chandef.chan->band;
+   if (band == NL80211_BAND_5GHZ ||
+   band == NL80211_BAND_6GHZ)
+   flag = IEEE80211_RATE_MANDATORY_A;
+   else
+   flag = IEEE80211_RATE_MANDATORY_B;
+
+   sband = rdev->wiphy.bands[band];
for (j = 0; j < sband->n_bitrates; j++) {
if (sband->bitrates[j].flags & flag)
params->basic_rates |= BIT(j);
-- 
1.9.1

[PATCH V3 4/8] cfg80211: extend ieee80211_operating_class_to_band() for 6GHz

[Arend van Spriel]

Add 6GHz operating class range as defined in 802.11ax D4.1 Annex E.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4e633d4..4462837 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1474,6 +1474,9 @@ bool ieee80211_operating_class_to_band(u8 operating_class,
case 128 ... 130:
*band = NL80211_BAND_5GHZ;
return true;
+   case 131 ... 135:
+   *band = NL80211_BAND_6GHZ;
+   return true;
case 81:
case 82:
case 83:
-- 
1.9.1

Re: [RFC V2 0/8] nl80211: add 6GHz band support

[Arend Van Spriel]

On July 24, 2019 11:35:14 AM Johannes Berg  wrote:


Hi Arend,




After all the discussion, I think we want this?


I think so yes. Even if it is just informational for user-space it seems to 
make sense for kernel side.



Care to resend?


Will do.


I think I want it at least because we shouldn't advertise HT/VHT on 6
GHz as is (just as part of HE) and that's easier if we have a different
band enum, for the capability storage...


Right.




The only place I could find an
issue with this is in cfg80211_wext_freq(). Not sure how to deal with
that so it is not part of this series.


Just finally break wext and say if you want to use 6 GHz you need to use
nl80211? :)


Probably is true for he support as well. Not sure. Have not been using wext 
for the last decade ;-)


Regards,
Arend

Re: [PATCH] brcmfmac: don't net_ratelimit() CONSOLE messages on firmware crash

[Arend Van Spriel]

On 7/21/2019 9:52 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

Firmware crash is a pretty rare event and can't happen too frequently as
it has to be followed by a hardware reinitialization and config reload.
It should be safe to don't use net_ratelimit() when it happens.

For reporting & debugging purposes it's important to provide a complete
log as the last lines are actually the most important. This change
modifies brcmfmac to print all messages in an unlimited way in that
specific case. With this change there should be finally a backtrace of
firmware finally visible after a crash.


Acked-by: Arend van Spriel 

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

Re: [PATCH] brcmfmac: change the order of things in brcmf_detach()

[Arend Van Spriel]

On July 20, 2019 6:26:30 PM Rafał Miłecki  wrote:


On 30.04.2019 12:10, Arend Van Spriel wrote:

On 4/30/2019 10:11 AM, Piotr Figiel wrote:

Hi Arend,

On Mon, Apr 29, 2019 at 12:09:21PM +0200, Arend van Spriel wrote:

When brcmf_detach() from the bus layer upon rmmod we can no longer
communicate. Hence we will set the bus state to DOWN and cleanup
the event and protocol layer. The network interfaces need to be
deleted before brcmf_cfg80211_detach() because the latter does the
wiphy_unregister() which issues a warning if there are still network
devices linked to the wiphy instance.


This seems to already happen - brcmf_cfg80211_detach() is called after the
interfaces are removed.


Right. This was just to remind me why brcmf_cfg80211_detach() must be 
called after removing the interfaces.



This change solves a null pointer dereference issue which happened
upon issueing rmmod while there are packets queued in bus protocol
layer.


Reported-by: Rafał Miłecki 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
Hi Piotr,


While working on an issue with msgbuf protocol (used for PCIe devices)
your change 5cdb0ef6144f ("brcmfmac: fix NULL pointer derefence during
USB disconnect") conflicted. I suspect my reordering stuff in
brcmf_detach() also fixes your issue so could you retest this patch,
which basically reverts your change and applies my reordering, and see
whether my suspicion can be confirmed.


Does the issue reported by Rafał you are trying to solve with this patch occur
on current linux-next?


Looking at you patch I suspect it does, because brcmf_proto_msgbuf_detach() 
is invoked in brcmf_proto_detach_post_delif(). However, I could not 
reproduce it with or without the patch.


Rafał,

Do you know whether your reported issue, ie. calling brcmf_tx_finalize() 
after interfaces were removed, still exists in wireless-testing (or 
linux-next).


Sorry for a terribly late reply. It took me many attempts to crash a
firmware in a fully reproducible way.

I can say for sure this patch fixes crashes in brcmf_txfinalize() I saw
when unloading brcmfmac after a crash.


Thanks, Rafał

There was no deadline so no need to feel sorry.

Regards,
Arend

Re: [PATCH v3 2/3] nl80211: Limit certain commands to interface owner

[Arend Van Spriel]

On 7/1/2019 5:33 PM, Denis Kenzior wrote:

If the wdev object has been created (via NEW_INTERFACE) with
SOCKET_OWNER attribute set, then limit certain commands only to the
process that created that wdev.

This can be used to make sure no other process on the system interferes
by sending unwanted scans, action frames or any other funny business.

This patch introduces a new internal flag, and checks that flag in the
pre_doit hook.

Signed-off-by: Denis Kenzior 
---
  net/wireless/nl80211.c | 80 --
  1 file changed, 61 insertions(+), 19 deletions(-)

Changes in v3:
   - Fix minor locking mistake reported by kernel test robot

Changes in v2:
   - None

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ff760ba83449..ebf5eab1f9b2 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c


[snip]

  
-	return 0;

+   ret = 0;


I suggest to keep the return 0 here for success path and only do the 
below for failure case (and obviously dropping '&& ret < 0'). Maybe 
rename label 'done' to 'fail' as well.



+done:
+   if (rtnl && ret < 0)
+   rtnl_unlock();
+
+   return ret;
  }


Regards,
Arend

Re: [RFC 0/8] nl80211: add 6GHz band support

[Arend Van Spriel]

On 7/12/2019 11:30 AM, Johannes Berg wrote:

On Thu, 2019-07-11 at 13:30 +0200, Arend Van Spriel wrote:


I assume user-space does not necessarily need the band, but hostapd
needs to be aware that it is operating in 6GHz to setup the correct
(information) elements in the beacon. Obviously the operating classes
can be used there, but I don't think there is any issue with nl80211
exposing a 6G band.


Yeah, I don't really see any *issue* with it, in many places we don't
really even care about the band enum.

In a sense, *most* of the places that consider the channel don't
actually care about the band, the channel num/freq conversion helpers
are a bit of the odd ones out in that regard. In the chandef, for
example, we don't have the band.

Really the original use for the band enum was mostly around the
advertising if capabilities. As you pointed out, 6GHz actually *does*
have different capabilities, though it's not clear to me what exactly
the behaviour differences are. Scanning is a big area, of course.


For starters a 6G STA has to add "HE extended capabilities" element. 
This contains capabilities that are taken from HT/VHT. Reason being that 
there is following requirement (clause 26.17.2.1):


"""
A 6 GHz HE STA shall not transmit an HT Capabilities element, VHT 
Capabilities element, HT Operation
element, VHT Operation element or an HE Operation element that contains 
a VHT Operation Information

field.
"""

The inclusion of the "HE extended capabilities" element is determined by 
the dot116GOptionImplemented option. (band[6G] != NULL) provides that 
condition although there are other ways to solve that I guess :-p
Come to think of it. Does mac80211 need that. Guess IEs are provided by 
user-space, right?



When we discussed splitting up or not the band, I think what we mostly
considered was the channel num/freq conversion helpers, and Jouni
pointed out that really what we should be doing for those isn't to
consider the band but the operating class instead.

So I'm starting to think that perhaps the decision we came to in Prague
was a little hasty, without considering the full impact?

I do completely agree that we should have knowledge about the operating
classes in the kernel eventually, and probably we will need to have it
here if we need to parse reduced neighbor reports etc. OTOH, we have
already ieee80211_operating_class_to_band(), and that seems sufficient,
though probably we should consider a combined helper that takes
opclass/chan# instead of having to call two functions?

However, from a feature advertisement point of view, we might very well
consider 6 GHz to be a separate nl80211 band, in particular if there
*are* indeed differences around what rates are permitted? Which is
really the only place where we care. Or maybe, thinking about this more,
if there could be devices that have different capabilities in 6 GHz than
in 5 GHz, in the sense of HT/VHT/HE capabilities?


Regarding rates the answer seem to be in clause 26.17.2.1 as well:

"""
A STA shall not transmit an HT PPDU in the 6 GHz band. A STA shall not 
transmit a VHT PPDU in the
6 GHz band. A STA shall not transmit a DSSS, HR/DSSS, or ERP-OFDM PPDU 
in the 6 GHz band.

"""

I may be wrong but that seems to say only HE rates are allowed.


Can somebody do the legwork and really go look at the spec to figure out
what the differences are? I'm not even sure now legacy rates are
permitted or not - you (Arend) seemed to imply they're not, and Igor
said only for beacons ...


Regarding beacons the rate requirement is in clause 26.15.6, which 
basically states that beacons have to be transmitted with HE rate where 
NSS equals 1.



I tend to think that this would be the deciding factor. For example, if
we do end up sending a probe request on 6 GHz, would we include a
different supported rates element than on 5 GHz? Or might there even be
devices that have different PHY paths and thus possibly different
capabilities for 5 and 6 GHz, essentially requiring a new place (a new
band enumerator) to store those capabilities, so we don't have to try to
figure out the difference in code later?

I'm almost tempted to say that given all these possibilities we should
in fact add a new value to the band enum, worst case we just duplicate
some data, but if there do end up being differences we can handle them
much more gracefully than if we put everything into 5 GHz.

Jouni, what do you think?


Regards,
Arend

Re: [RFC 0/8] nl80211: add 6GHz band support

[Arend Van Spriel]

On 6/28/2019 3:04 PM, Johannes Berg wrote:

Hi Arend, all,

Sorry. No, my thoughts aren't really more concrete, but Tova is starting
to work on this now.


This came up in discussion with my colleagues today and I would say from
mac80211 perspective there is more to it than just scanning. In short
the 6GHz band is for HE-only operation so for example only HE rates may
be used. As the bitrates are in ieee80211_supported_band having a
separate 6GHz band seems to have a (slight?) advantage.


Hmm, that's a good point too, I hadn't really looked _too_ much at 6GHz
stuff.

Jouni, what do you think?

Perhaps we should just have both. I mean, we can treat this as a
separate band, and still have code to handle operating classes properly,
right?


I assume user-space does not necessarily need the band, but hostapd 
needs to be aware that it is operating in 6GHz to setup the correct 
(information) elements in the beacon. Obviously the operating classes 
can be used there, but I don't think there is any issue with nl80211 
exposing a 6G band.


Regards,
Arend

[PATCH 2/7] brcmfmac: change the order of things in brcmf_detach()

[Arend van Spriel]

When brcmf_detach() from the bus layer upon rmmod we can no longer
communicate. Hence we will set the bus state to DOWN and cleanup
the event and protocol layer. The network interfaces need to be
deleted before brcmf_cfg80211_detach() because the latter does the
wiphy_unregister() which issues a warning if there are still network
devices linked to the wiphy instance.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 27 +++---
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index fda6044..80d54d2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -1307,25 +1307,26 @@ void brcmf_detach(struct device *dev)
unregister_inet6addr_notifier(&drvr->inet6addr_notifier);
 #endif
 
-   /* stop firmware event handling */
-   brcmf_fweh_detach(drvr);
-   if (drvr->config)
-   brcmf_p2p_detach(&drvr->config->p2p);
-
brcmf_bus_change_state(bus_if, BRCMF_BUS_DOWN);
-
-   /* make sure primary interface removed last */
-   for (i = BRCMF_MAX_IFS-1; i > -1; i--)
-   brcmf_remove_interface(drvr->iflist[i], false);
-
-   brcmf_cfg80211_detach(drvr->config);
-   drvr->config = NULL;
-
brcmf_bus_stop(drvr->bus_if);
 
+   brcmf_fweh_detach(drvr);
brcmf_proto_detach(drvr);
 
+   /* make sure primary interface removed last */
+   for (i = BRCMF_MAX_IFS - 1; i > -1; i--) {
+   if (drvr->iflist[i])
+   brcmf_del_if(drvr, drvr->iflist[i]->bsscfgidx, false);
+   }
+
+   if (drvr->config) {
+   brcmf_p2p_detach(&drvr->config->p2p);
+   brcmf_cfg80211_detach(drvr->config);
+   drvr->config = NULL;
+   }
+
bus_if->drvr = NULL;
+
wiphy_free(drvr->wiphy);
 }
 
-- 
1.9.1

[PATCH 7/7] brcmfmac: remove unnecessary strlcpy() upon obtaining "ver" iovar

[Arend van Spriel]

Recently a strcpy() was replaced by strlcpy(). However, the strcpy()
was not needed in the first place. So removing that line of code.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index aa89d62..dec25e4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -258,7 +258,6 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
 
/* query for 'ver' to get version info from firmware */
memset(buf, 0, sizeof(buf));
-   strlcpy(buf, "ver", sizeof(buf));
err = brcmf_fil_iovar_data_get(ifp, "ver", buf, sizeof(buf));
if (err < 0) {
bphy_err(drvr, "Retrieving version information failed, %d\n",
-- 
1.9.1

[PATCH 6/7] brcmfmac: simply remove flowring if bus is down

[Arend van Spriel]

When the bus is down, eg. due to rmmod, there is no need to
attempt to inform firmware about it.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index 241747b..8428be8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -1398,6 +1398,13 @@ void brcmf_msgbuf_delete_flowring(struct brcmf_pub 
*drvr, u16 flowid)
u8 ifidx;
int err;
 
+   /* no need to submit if firmware can not be reached */
+   if (drvr->bus_if->state != BRCMF_BUS_UP) {
+   brcmf_dbg(MSGBUF, "bus down, flowring will be removed\n");
+   brcmf_msgbuf_remove_flowring(msgbuf, flowid);
+   return;
+   }
+
commonring = msgbuf->commonrings[BRCMF_H2D_MSGRING_CONTROL_SUBMIT];
brcmf_commonring_lock(commonring);
ret_ptr = brcmf_commonring_reserve_for_write(commonring);
-- 
1.9.1

[PATCH 5/7] brcmfmac: avoid firmware commands when bus is down

[Arend van Spriel]

Upon rmmod a few attempts are made to inform firmware, but there is
no point as the bus is down and these will fail. Avoid them to keep
the logs clean.

Reported-by: Stefan Wahren 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 23 --
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b6d0df3..4e3e9d44 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1267,17 +1267,21 @@ static void brcmf_link_down(struct brcmf_cfg80211_vif 
*vif, u16 reason)
 {
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(vif->wdev.wiphy);
struct brcmf_pub *drvr = cfg->pub;
+   bool bus_up = drvr->bus_if->state == BRCMF_BUS_UP;
s32 err = 0;
 
brcmf_dbg(TRACE, "Enter\n");
 
if (test_and_clear_bit(BRCMF_VIF_STATUS_CONNECTED, &vif->sme_state)) {
-   brcmf_dbg(INFO, "Call WLC_DISASSOC to stop excess roaming\n");
-   err = brcmf_fil_cmd_data_set(vif->ifp,
-BRCMF_C_DISASSOC, NULL, 0);
-   if (err) {
-   bphy_err(drvr, "WLC_DISASSOC failed (%d)\n", err);
+   if (bus_up) {
+   brcmf_dbg(INFO, "Call WLC_DISASSOC to stop excess 
roaming\n");
+   err = brcmf_fil_cmd_data_set(vif->ifp,
+BRCMF_C_DISASSOC, NULL, 0);
+   if (err)
+   bphy_err(drvr, "WLC_DISASSOC failed (%d)\n",
+err);
}
+
if ((vif->wdev.iftype == NL80211_IFTYPE_STATION) ||
(vif->wdev.iftype == NL80211_IFTYPE_P2P_CLIENT))
cfg80211_disconnected(vif->wdev.netdev, reason, NULL, 0,
@@ -1287,7 +1291,8 @@ static void brcmf_link_down(struct brcmf_cfg80211_vif 
*vif, u16 reason)
clear_bit(BRCMF_SCAN_STATUS_SUPPRESS, &cfg->scan_status);
brcmf_btcoex_set_mode(vif, BRCMF_BTCOEX_ENABLED, 0);
if (vif->profile.use_fwsup != BRCMF_PROFILE_FWSUP_NONE) {
-   brcmf_set_pmk(vif->ifp, NULL, 0);
+   if (bus_up)
+   brcmf_set_pmk(vif->ifp, NULL, 0);
vif->profile.use_fwsup = BRCMF_PROFILE_FWSUP_NONE;
}
brcmf_dbg(TRACE, "Exit\n");
@@ -4985,18 +4990,16 @@ static int brcmf_cfg80211_get_channel(struct wiphy 
*wiphy,
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
struct net_device *ndev = wdev->netdev;
struct brcmf_pub *drvr = cfg->pub;
-   struct brcmf_if *ifp;
struct brcmu_chan ch;
enum nl80211_band band = 0;
enum nl80211_chan_width width = 0;
u32 chanspec;
int freq, err;
 
-   if (!ndev)
+   if (!ndev || drvr->bus_if->state != BRCMF_BUS_UP)
return -ENODEV;
-   ifp = netdev_priv(ndev);
 
-   err = brcmf_fil_iovar_int_get(ifp, "chanspec", &chanspec);
+   err = brcmf_fil_iovar_int_get(netdev_priv(ndev), "chanspec", &chanspec);
if (err) {
bphy_err(drvr, "chanspec failed (%d)\n", err);
return err;
-- 
1.9.1

[PATCH 0/7] brcmfmac: rework probe/attach sequence

[Arend van Spriel]

The brcmfmac driver spews some error message upon unloading and Stefan
Wahren was wondering whether it could be cleaned up. Related to this
was a recent fix for NULL pointer deref. That fix introduced a construct
that added to the itch to rework the probe sequence. So this series
reverts commit 5cdb0ef6144f ("brcmfmac: fix NULL pointer derefence during
USB disconnect").

The changes in this series are:
 * reorder brcmf_detach() code.
 * avoid firmware interaction when bus is down.
 * remove strlcpy() before issueing firmware version iovar.

This series applies to the master branch of the wireless-drivers-next
repository.

Arend van Spriel (7):
  Revert "brcmfmac: fix NULL pointer derefence during USB disconnect"
  brcmfmac: change the order of things in brcmf_detach()
  brcmfmac: avoid firmware command in brcmf_netdev_open() when bus is
down
  brcmfmac: clear events in brcmf_fweh_detach() will always fail
  brcmfmac: avoid firmware commands when bus is down
  brcmfmac: simply remove flowring if bus is down
  brcmfmac: remove unnecessary strlcpy() upon obtaining "ver" iovar

 .../wireless/broadcom/brcm80211/brcmfmac/bcdc.c| 11 ++--
 .../wireless/broadcom/brcm80211/brcmfmac/bcdc.h|  6 ++---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 23 +
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  |  1 -
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 30 +++---
 .../wireless/broadcom/brcm80211/brcmfmac/fweh.c|  9 ---
 .../broadcom/brcm80211/brcmfmac/fwsignal.c | 16 +++-
 .../broadcom/brcm80211/brcmfmac/fwsignal.h |  3 +--
 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c  |  7 +
 .../wireless/broadcom/brcm80211/brcmfmac/proto.c   | 10 ++--
 .../wireless/broadcom/brcm80211/brcmfmac/proto.h   |  3 +--
 11 files changed, 47 insertions(+), 72 deletions(-)

--
1.9.1

[PATCH 3/7] brcmfmac: avoid firmware command in brcmf_netdev_open() when bus is down

[Arend van Spriel]

No point in sending a firmware command when bus is down so make it
conditional checking the state.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 80d54d2..705b8cc 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -579,7 +579,8 @@ static int brcmf_netdev_stop(struct net_device *ndev)
 
brcmf_cfg80211_down(ndev);
 
-   brcmf_fil_iovar_data_set(ifp, "arp_hostip_clear", NULL, 0);
+   if (ifp->drvr->bus_if->state == BRCMF_BUS_UP)
+   brcmf_fil_iovar_data_set(ifp, "arp_hostip_clear", NULL, 0);
 
brcmf_net_setcarrier(ifp, false);
 
-- 
1.9.1

[PATCH 4/7] brcmfmac: clear events in brcmf_fweh_detach() will always fail

[Arend van Spriel]

Clearing firmware events in brcmf_fweh_detach() is always failing
because it is called only upon driver remove and communication
with firmware is no longer possible.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
index adedd4f..79c8a85 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
@@ -303,16 +303,7 @@ void brcmf_fweh_attach(struct brcmf_pub *drvr)
 void brcmf_fweh_detach(struct brcmf_pub *drvr)
 {
struct brcmf_fweh_info *fweh = &drvr->fweh;
-   struct brcmf_if *ifp = brcmf_get_ifp(drvr, 0);
-   s8 eventmask[BRCMF_EVENTING_MASK_LEN];
 
-   if (ifp) {
-   /* clear all events */
-   memset(eventmask, 0, BRCMF_EVENTING_MASK_LEN);
-   (void)brcmf_fil_iovar_data_set(ifp, "event_msgs",
-  eventmask,
-  BRCMF_EVENTING_MASK_LEN);
-   }
/* cancel the worker */
cancel_work_sync(&fweh->event_work);
WARN_ON(!list_empty(&fweh->event_q));
-- 
1.9.1

[PATCH 1/7] Revert "brcmfmac: fix NULL pointer derefence during USB disconnect"

[Arend van Spriel]

This reverts commit 5cdb0ef6144f47440850553579aa923c20a63f23. Subsequent
changes make rework the driver code fixing the issue differently.

Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c  | 11 ++-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h  |  6 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c  |  4 +---
 .../net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c  | 16 
 .../net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h  |  3 +--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c | 10 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h |  3 +--
 7 files changed, 13 insertions(+), 40 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
index 322e913..2c95a08 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c
@@ -479,18 +479,11 @@ int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr)
return -ENOMEM;
 }
 
-void brcmf_proto_bcdc_detach_pre_delif(struct brcmf_pub *drvr)
-{
-   struct brcmf_bcdc *bcdc = drvr->proto->pd;
-
-   brcmf_fws_detach_pre_delif(bcdc->fws);
-}
-
-void brcmf_proto_bcdc_detach_post_delif(struct brcmf_pub *drvr)
+void brcmf_proto_bcdc_detach(struct brcmf_pub *drvr)
 {
struct brcmf_bcdc *bcdc = drvr->proto->pd;
 
drvr->proto->pd = NULL;
-   brcmf_fws_detach_post_delif(bcdc->fws);
+   brcmf_fws_detach(bcdc->fws);
kfree(bcdc);
 }
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h
index 102e693..b051d28 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h
@@ -7,16 +7,14 @@
 
 #ifdef CONFIG_BRCMFMAC_PROTO_BCDC
 int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr);
-void brcmf_proto_bcdc_detach_pre_delif(struct brcmf_pub *drvr);
-void brcmf_proto_bcdc_detach_post_delif(struct brcmf_pub *drvr);
+void brcmf_proto_bcdc_detach(struct brcmf_pub *drvr);
 void brcmf_proto_bcdc_txflowblock(struct device *dev, bool state);
 void brcmf_proto_bcdc_txcomplete(struct device *dev, struct sk_buff *txp,
 bool success);
 struct brcmf_fws_info *drvr_to_fws(struct brcmf_pub *drvr);
 #else
 static inline int brcmf_proto_bcdc_attach(struct brcmf_pub *drvr) { return 0; }
-static void brcmf_proto_bcdc_detach_pre_delif(struct brcmf_pub *drvr) {};
-static inline void brcmf_proto_bcdc_detach_post_delif(struct brcmf_pub *drvr) 
{}
+static inline void brcmf_proto_bcdc_detach(struct brcmf_pub *drvr) {}
 #endif
 
 #endif /* BRCMFMAC_BCDC_H */
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index bf18491..fda6044 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -1314,8 +1314,6 @@ void brcmf_detach(struct device *dev)
 
brcmf_bus_change_state(bus_if, BRCMF_BUS_DOWN);
 
-   brcmf_proto_detach_pre_delif(drvr);
-
/* make sure primary interface removed last */
for (i = BRCMF_MAX_IFS-1; i > -1; i--)
brcmf_remove_interface(drvr->iflist[i], false);
@@ -1325,7 +1323,7 @@ void brcmf_detach(struct device *dev)
 
brcmf_bus_stop(drvr->bus_if);
 
-   brcmf_proto_detach_post_delif(drvr);
+   brcmf_proto_detach(drvr);
 
bus_if->drvr = NULL;
wiphy_free(drvr->wiphy);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index b8452cb..2bd892d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2432,25 +2432,17 @@ struct brcmf_fws_info *brcmf_fws_attach(struct 
brcmf_pub *drvr)
return fws;
 
 fail:
-   brcmf_fws_detach_pre_delif(fws);
-   brcmf_fws_detach_post_delif(fws);
+   brcmf_fws_detach(fws);
return ERR_PTR(rc);
 }
 
-void brcmf_fws_detach_pre_delif(struct brcmf_fws_info *fws)
+void brcmf_fws_detach(struct brcmf_fws_info *fws)
 {
if (!fws)
return;
-   if (fws->fws_wq) {
-   destroy_workqueue(fws->fws_wq);
-   fws->fws_wq = NULL;
-   }
-}
 
-void brcmf_fws_detach_post_delif(struct brcmf_fws_info *fws)
-{
-   if (!fws)
-   return;
+   if (fws->fws_wq)
+   destroy_workqueue(fws->fws_wq);
 
/* cleanup */
brcmf_fws_lock(fws);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
index 10184ee..b486d57 100644
--- a/drivers/net/wireless/broadcom/brcm8021

[PATCH 1/3] brcmfmac: add 160MHz in chandef_to_chanspec()

[Arend van Spriel]

The function chandef_to_chanspec() was not handling 160MHz bandwidth
resulting in wrong encoding of the channel. That resulting in firmware
rejecting the provided channel specification.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b6d0df3..5168d42 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -276,8 +276,26 @@ static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf,
else
ch_inf.sb = BRCMU_CHAN_SB_UU;
break;
-   case NL80211_CHAN_WIDTH_80P80:
case NL80211_CHAN_WIDTH_160:
+   ch_inf.bw = BRCMU_CHAN_BW_160;
+   if (primary_offset == -70)
+   ch_inf.sb = BRCMU_CHAN_SB_LLL;
+   else if (primary_offset == -50)
+   ch_inf.sb = BRCMU_CHAN_SB_LLU;
+   else if (primary_offset == -30)
+   ch_inf.sb = BRCMU_CHAN_SB_LUL;
+   else if (primary_offset == -10)
+   ch_inf.sb = BRCMU_CHAN_SB_LUU;
+   else if (primary_offset == 10)
+   ch_inf.sb = BRCMU_CHAN_SB_ULL;
+   else if (primary_offset == 30)
+   ch_inf.sb = BRCMU_CHAN_SB_ULU;
+   else if (primary_offset == 50)
+   ch_inf.sb = BRCMU_CHAN_SB_UUL;
+   else
+   ch_inf.sb = BRCMU_CHAN_SB_UUU;
+   break;
+   case NL80211_CHAN_WIDTH_80P80:
case NL80211_CHAN_WIDTH_5:
case NL80211_CHAN_WIDTH_10:
default:
@@ -296,6 +314,7 @@ static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf,
}
d11inf->encchspec(&ch_inf);
 
+   brcmf_dbg(TRACE, "chanspec: 0x%x\n", ch_inf.chspec);
return ch_inf.chspec;
 }
 
-- 
1.9.1

[PATCH 3/3] brcmfmac: allow 160MHz in custom regulatory rules

[Arend van Spriel]

The driver has custom regulatory rules which had maximum bandwidth
for 5GHz channels set to 80MHz. As a consequence the driver can
not use 160MHz in AP mode even when the device supports it. So
relax the rules allowing 160MHz. After wiphy_register() the channel
flags are updated according what the device actually supports.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 3f72dc1..b692689 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -189,9 +189,9 @@ static bool check_vif_up(struct brcmf_cfg80211_vif *vif)
 */
REG_RULE(2484-10, 2484+10, 20, 6, 20, 0),
/* IEEE 802.11a, channel 36..64 */
-   REG_RULE(5150-10, 5350+10, 80, 6, 20, 0),
+   REG_RULE(5150-10, 5350+10, 160, 6, 20, 0),
/* IEEE 802.11a, channel 100..165 */
-   REG_RULE(5470-10, 5850+10, 80, 6, 20, 0), }
+   REG_RULE(5470-10, 5850+10, 160, 6, 20, 0), }
 };
 
 /* Note: brcmf_cipher_suites is an array of int defining which cipher suites
-- 
1.9.1

[PATCH 0/3] brcmfmac: 160MHz fixes and DFS offload

[Arend van Spriel]

The 160MHz AP mode was not properly working and limited due to lack of
DFS offload. So this series include following changes:

 * encode 160MHz channel definition to firmware format.
 * adapt custom regulatory rule allowing 160MHz.
 * enable DFS offloading for firmwares supporting it.

The series applies to the master branch of the wireless-drivers-next
repository.

Arend van Spriel (3):
  brcmfmac: add 160MHz in chandef_to_chanspec()
  brcmfmac: enable DFS_OFFLOAD extended feature if supported
  brcmfmac: allow 160MHz in custom regulatory rules

 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 30 +++---
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c |  1 +
 .../wireless/broadcom/brcm80211/brcmfmac/feature.h |  4 ++-
 3 files changed, 31 insertions(+), 4 deletions(-)

--
1.9.1

[PATCH 2/3] brcmfmac: enable DFS_OFFLOAD extended feature if supported

[Arend van Spriel]

If the firmware supports 802.11h and the device can operate in 5GHz
band we can enable DFS_OFFLOAD extended feature.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c  | 1 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h  | 4 +++-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 5168d42..3f72dc1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6733,6 +6733,11 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct 
brcmf_if *ifp)
}
}
 
+   if (wiphy->bands[NL80211_BAND_5GHZ] &&
+   brcmf_feat_is_enabled(ifp, BRCMF_FEAT_DOT11H))
+   wiphy_ext_feature_set(wiphy,
+ NL80211_EXT_FEATURE_DFS_OFFLOAD);
+
wiphy_read_of_freq_limits(wiphy);
 
return 0;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index 73aff4e..2c3526a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -39,6 +39,7 @@ struct brcmf_feat_fwcap {
{ BRCMF_FEAT_P2P, "p2p" },
{ BRCMF_FEAT_MONITOR, "monitor" },
{ BRCMF_FEAT_MONITOR_FMT_RADIOTAP, "rtap" },
+   { BRCMF_FEAT_DOT11H, "802.11h" }
 };
 
 #ifdef DEBUG
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
index f127eb2..736a817 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
@@ -25,6 +25,7 @@
  * MONITOR: firmware can pass monitor packets to host.
  * MONITOR_FMT_RADIOTAP: firmware provides monitor packets with radiotap header
  * MONITOR_FMT_HW_RX_HDR: firmware provides monitor packets with hw/ucode 
header
+ * DOT11H: firmware supports 802.11h
  */
 #define BRCMF_FEAT_LIST \
BRCMF_FEAT_DEF(MBSS) \
@@ -43,7 +44,8 @@
BRCMF_FEAT_DEF(FWSUP) \
BRCMF_FEAT_DEF(MONITOR) \
BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP) \
-   BRCMF_FEAT_DEF(MONITOR_FMT_HW_RX_HDR)
+   BRCMF_FEAT_DEF(MONITOR_FMT_HW_RX_HDR) \
+   BRCMF_FEAT_DEF(DOT11H)
 
 /*
  * Quirks:
-- 
1.9.1

Re: [PATCH 3/7] brcmsmac: switch source files to using SPDX license identifier

[Arend Van Spriel]

+ Alan

On 5/17/2019 8:07 PM, Rafał Miłecki wrote:

Another option could be MIT license which is in the preferred folder.
Will have to consult our legal department about it though.

Hey, if your legal department is going to get asked this, why not just
switch it to GPLv2?  That would make everything much simpler.

Hah. Because I already know the answer to that.;-)

It's not that obvious to me, sorry. Does your legal department require
something more permissive than GPLv2? Is that worth asking them about
dual-licensing? Something like
GPL-2.0 OR MIT
? That assures driver is compatible with Linux, no matter what's the
current lawyers interpretation of MIT vs. GPL 2.0. I believe Alan Cox
once told/suggested that dual-licensing is safer for legal reasons.


Hi Alan,

Rafał mentioned your name a while ago when I was struggling with the 
SPDX identifiers. The drivers sources I want to modify for this 
originally had a license text in the header that matches ISC. However,
one of the files did not have that and it was marked in bulk to GPLv2. 
So now the question is whether I can change it to ISC like the rest or 
should I make it dual like Rafał suggested.


Can you elaborate the pros and cons of dual license?

Regards,
Arend

[RFC V2 7/8] cfg80211: ibss: use 11a mandatory rates for 6GHz band operation

[Arend van Spriel]

The default mandatory rates, ie. when not specified by user-space, is
determined by the band. Select 11a rateset for 6GHz band.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/ibss.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index d1743e6..ae8fe66 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -104,13 +104,19 @@ int __cfg80211_join_ibss(struct 
cfg80211_registered_device *rdev,
* use the mandatory rate set for 11b or
* 11a for maximum compatibility.
*/
-   struct ieee80211_supported_band *sband =
-   rdev->wiphy.bands[params->chandef.chan->band];
+   struct ieee80211_supported_band *sband;
+   enum nl80211_band band;
+   u32 flag;
int j;
-   u32 flag = params->chandef.chan->band == NL80211_BAND_5GHZ ?
-   IEEE80211_RATE_MANDATORY_A :
-   IEEE80211_RATE_MANDATORY_B;
 
+   band = params->chandef.chan->band;
+   if (band == NL80211_BAND_5GHZ ||
+   band == NL80211_BAND_6GHZ)
+   flag = IEEE80211_RATE_MANDATORY_A;
+   else
+   flag = IEEE80211_RATE_MANDATORY_B;
+
+   sband = rdev->wiphy.bands[band];
for (j = 0; j < sband->n_bitrates; j++) {
if (sband->bitrates[j].flags & flag)
params->basic_rates |= BIT(j);
-- 
1.9.1

[RFC V2 1/8] nl80211: add 6GHz band definition to enum nl80211_band

[Arend van Spriel]

In the 802.11ax specification a new band is introduced, which
is also proposed by FCC for unlicensed use. This band is referred
to as 6GHz spanning frequency range from 5925 to 7125 MHz.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
changes:
  - V2
fix ABI breakage by appending the new band definition.
---
 include/uapi/linux/nl80211.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 8fc3a43..45b9117 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4536,6 +4536,7 @@ enum nl80211_txrate_gi {
  * @NL80211_BAND_2GHZ: 2.4 GHz ISM band
  * @NL80211_BAND_5GHZ: around 5 GHz band (4.9 - 5.7 GHz)
  * @NL80211_BAND_60GHZ: around 60 GHz band (58.32 - 69.12 GHz)
+ * @NL80211_BAND_6GHZ: around 6 GHz band (5.9 - 7.2 GHz)
  * @NUM_NL80211_BANDS: number of bands, avoid using this in userspace
  * since newer kernel versions may support more bands
  */
@@ -4543,6 +4544,7 @@ enum nl80211_band {
NL80211_BAND_2GHZ,
NL80211_BAND_5GHZ,
NL80211_BAND_60GHZ,
+   NL80211_BAND_6GHZ,
 
NUM_NL80211_BANDS,
 };
-- 
1.9.1

[RFC V2 5/8] cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS entries

[Arend van Spriel]

In nl80211.c there is a policy for all bands in NUM_NL80211_BANDS and
in trace.h there is a callback trace for multicast rates which is per
band in NUM_NL80211_BANDS. Both need to be extended for the new
NL80211_BAND_6GHZ.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/nl80211.c | 1 +
 net/wireless/trace.h   | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fc83dd1..57bc35a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -667,6 +667,7 @@ static int validate_ie_attr(const struct nlattr *attr,
 nl80211_match_band_rssi_policy[NUM_NL80211_BANDS] = {
[NL80211_BAND_2GHZ] = { .type = NLA_S32 },
[NL80211_BAND_5GHZ] = { .type = NLA_S32 },
+   [NL80211_BAND_6GHZ] = { .type = NLA_S32 },
[NL80211_BAND_60GHZ] = { .type = NLA_S32 },
 };
 
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 4fbb91a..d98ad2b 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2446,10 +2446,11 @@
   sizeof(int) * NUM_NL80211_BANDS);
),
TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", "
- "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 60GHz=0x%x]",
+ "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 6GHz=0x%x, 
60GHz=0x%x]",
  WIPHY_PR_ARG, NETDEV_PR_ARG,
  __entry->mcast_rate[NL80211_BAND_2GHZ],
  __entry->mcast_rate[NL80211_BAND_5GHZ],
+ __entry->mcast_rate[NL80211_BAND_6GHZ],
  __entry->mcast_rate[NL80211_BAND_60GHZ])
 );
 
-- 
1.9.1

[RFC V2 6/8] cfg80211: use same IR permissive rules for 6GHz band

[Arend van Spriel]

The function cfg80211_ir_permissive_chan() is applicable for
6GHz band as well so make sure it is handled.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/chan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 7dc1bbd..7c9d204 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -894,7 +894,8 @@ static bool cfg80211_ir_permissive_chan(struct wiphy *wiphy,
if (chan == other_chan)
return true;
 
-   if (chan->band != NL80211_BAND_5GHZ)
+   if (chan->band != NL80211_BAND_5GHZ &&
+   chan->band != NL80211_BAND_6GHZ)
continue;
 
r1 = cfg80211_get_unii(chan->center_freq);
-- 
1.9.1

[RFC V2 2/8] cfg80211: add 6GHz UNII band definitions

[Arend van Spriel]

For the new 6GHz there are new UNII band definitions as listed
in the FCC notice [1].

[1] https://docs.fcc.gov/public/attachments/FCC-18-147A1_Rcd.pdf

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/reg.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 4831ad74..646107a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3806,8 +3806,9 @@ void wiphy_regulatory_deregister(struct wiphy *wiphy)
 }
 
 /*
- * See http://www.fcc.gov/document/5-ghz-unlicensed-spectrum-unii, for
- * UNII band definitions
+ * See FCC notices for UNII band definitions
+ *  5GHz: https://www.fcc.gov/document/5-ghz-unlicensed-spectrum-unii
+ *  6GHz: 
https://www.fcc.gov/document/fcc-proposes-more-spectrum-unlicensed-use-0
  */
 int cfg80211_get_unii(int freq)
 {
@@ -3831,6 +3832,22 @@ int cfg80211_get_unii(int freq)
if (freq > 5725 && freq <= 5825)
return 4;
 
+   /* UNII-5 */
+   if (freq > 5925 && freq <= 6425)
+   return 5;
+
+   /* UNII-6 */
+   if (freq > 6425 && freq <= 6525)
+   return 6;
+
+   /* UNII-7 */
+   if (freq > 6525 && freq <= 6875)
+   return 7;
+
+   /* UNII-8 */
+   if (freq > 6875 && freq <= 7125)
+   return 8;
+
return -EINVAL;
 }
 
-- 
1.9.1

[RFC V2 4/8] cfg80211: extend ieee80211_operating_class_to_band() for 6GHz

[Arend van Spriel]

Add 6GHz operating class range as defined in 802.11ax D4.1 Annex E.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4e633d4..4462837 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1474,6 +1474,9 @@ bool ieee80211_operating_class_to_band(u8 operating_class,
case 128 ... 130:
*band = NL80211_BAND_5GHZ;
return true;
+   case 131 ... 135:
+   *band = NL80211_BAND_6GHZ;
+   return true;
case 81:
case 82:
case 83:
-- 
1.9.1

[RFC V2 8/8] cfg80211: apply same mandatory rate flags for 5GHz and 6GHz

[Arend van Spriel]

For the new 6GHz band the same rules apply for mandatory rates so
add it to set_mandatory_flags_band() function.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 4462837..f0558e7 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -156,6 +156,7 @@ static void set_mandatory_flags_band(struct 
ieee80211_supported_band *sband)
 
switch (sband->band) {
case NL80211_BAND_5GHZ:
+   case NL80211_BAND_6GHZ:
want = 3;
for (i = 0; i < sband->n_bitrates; i++) {
if (sband->bitrates[i].bitrate == 60 ||
-- 
1.9.1

[RFC V2 3/8] cfg80211: util: add 6GHz channel to freq conversion and vice versa

[Arend van Spriel]

Extend the functions ieee80211_channel_to_frequency() and
ieee80211_frequency_to_channel() to support 6GHz band according
specification in 802.11ax D4.1 27.3.22.2.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 1c39d6a..4e633d4 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -91,6 +91,11 @@ int ieee80211_channel_to_frequency(int chan, enum 
nl80211_band band)
else
return 5000 + chan * 5;
break;
+   case NL80211_BAND_6GHZ:
+   /* see 802.11ax D4.1 27.3.22.2 */
+   if (chan <= 253)
+   return 5940 + chan * 5;
+   break;
case NL80211_BAND_60GHZ:
if (chan < 7)
return 56160 + chan * 2160;
@@ -111,8 +116,11 @@ int ieee80211_frequency_to_channel(int freq)
return (freq - 2407) / 5;
else if (freq >= 4910 && freq <= 4980)
return (freq - 4000) / 5;
-   else if (freq <= 45000) /* DMG band lower limit */
+   else if (freq < 5940)
return (freq - 5000) / 5;
+   else if (freq <= 45000) /* DMG band lower limit */
+   /* see 802.11ax D4.1 27.3.22.2 */
+   return (freq - 5940) / 5;
else if (freq >= 58320 && freq <= 70200)
return (freq - 56160) / 2160;
else
-- 
1.9.1

[RFC V2 0/8] nl80211: add 6GHz band support

[Arend van Spriel]

This is more or less a resend. The difference with the previous RFC is
in the nl80211 API as the previous RFC was breaking ABI.

In 802.11ax D4.0 a new band has been proposed. This series contains
changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
was no overlap in channel number. However, this new band has channel
numbers with a range from 1 up to 253. The only place I could find an
issue with this is in cfg80211_wext_freq(). Not sure how to deal with
that so it is not part of this series.

The series applies to the master branch of the mac80211-next repository.

Arend van Spriel (8):
  nl80211: add 6GHz band definition to enum nl80211_band
  cfg80211: add 6GHz UNII band definitions
  cfg80211: util: add 6GHz channel to freq conversion and vice versa
  cfg80211: extend ieee80211_operating_class_to_band() for 6GHz
  cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS
entries
  cfg80211: use same IR permissive rules for 6GHz band
  cfg80211: ibss: use 11a mandatory rates for 6GHz band operation
  cfg80211: apply same mandatory rate flags for 5GHz and 6GHz

 include/uapi/linux/nl80211.h |  2 ++
 net/wireless/chan.c  |  3 ++-
 net/wireless/ibss.c  | 16 +++-
 net/wireless/nl80211.c   |  1 +
 net/wireless/reg.c   | 21 +++--
 net/wireless/trace.h |  3 ++-
 net/wireless/util.c  | 14 +-
 7 files changed, 50 insertions(+), 10 deletions(-)

-- 
1.9.1

Re: [RESEND] brcmfmac support for BCM4359 sdio on arm64 ??

[Arend Van Spriel]

Hi Christian,

Here it is. Hopefully unmangled this time.

Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c

index ec129864cc9c..7be8064c6dc7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -785,7 +785,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev 
*sdiodev)

  sdiodev->settings->bus.sdio.txglomsz);
nents += (nents >> 4) + 1;

-   WARN_ON(nents > sdiodev->max_segment_count);
+   WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, 
host_max_seg=%u, nents=%u\n",

+sdiodev->max_segment_count, host->max_segs, nents);

brcmf_dbg(TRACE, "nents=%d\n", nents);
err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);

Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner

[Arend Van Spriel]

On 6/22/2019 3:44 PM, Marcel Holtmann wrote:

Hi Arend,


If the wdev object has been created (via NEW_INTERFACE) with
SOCKET_OWNER attribute set, then limit certain commands only to the
process that created that wdev.

This can be used to make sure no other process on the system interferes
by sending unwanted scans, action frames or any other funny business.


The flag is a good addition opposed to having handlers deal with it. However, 
earlier motivation for SOCKET_OWNER use was about netlink multicast being 
unreliable, which I can agree to. However, avoiding

???  I can't agree to that as I have no idea what you're talking about :)  
Explain?  SOCKET_OWNER was introduced mainly to bring down links / scans / 
whatever in case the initiating process died.  As a side effect it also helped 
in the beginning when users ran iwd + wpa_s simultaneously (by accident) and 
all sorts of fun ensued.  We then re-used SOCKET_OWNER for running EAPoL over 
NL80211.  But 'multicast unreliability' was never an issue that I recall?


hmm. I tried searching in memory... of my email client but to no avail. I 
somehow recalled that netlink multicast was not guaranteed to be delivered/seen 
by all listeners.


"funny business" is a different thing. Our testing infrastructure is doing all 
kind of funny business. Guess we will need to refrain from

So you're going behind the managing daemon's back and messing with the kernel 
state...  I guess the question is why?  But really, if wpa_s wants to tolerate 
that, that is their problem :)  iwd doesn't want to, nor do we want to deal 
with the various race conditions and corner cases associated with that.  Life 
is hard as it is ;)


That's just it, right. This is what Marcel calls the real environment, but is 
it. The nl80211 is a kernel API and should that mean that there must be a 
managing daemon locking down APIs for other user-space tools to use. If I want 
a user-space app to show a radar screen with surrounding APs using scanning and 
FTM nl80211 commands it seems now it has to create a new interface and hope the 
resources are there for it to succeed. Where is my freedom in that? If I am 
using such an app don't you think I don't accept it could impact the managing 
daemon.


if you are operating on a shared radio resource you have to have some way of 
ensuring that nobody steals resources from you. Having an external application 
that will also use scanning and other off-channel operation will result in a 
bad experience. Especially if it involves scanning. Currently we still have 3 
or more parties triggering scanning on nl80211. Essentially they are now 
fighting for radio time. You have wpa_supplicant scanning, you have 
NetworkManager scanning and you have the UI scanning. Now adding just another 
application that just scans at its decided time location / direction finding is 
not helping the situation.


My app was just a hypothetical example. I understand your conundrum, but 
my point was that you can not know how a system is configured. Now for 
the SOCKET_OWNER I should say it does not provide you any guarantees. At 
best it improves your chances. With the nl80211 API being as it is, you 
can not rule out multiple application controlling the same device. The 
virtual interfaces can be guarded with SOCKET_OWNER, but in the end 
there is still one physical device and only if you are lucky you may 
come across a device with two physical radios, but most of them just 
have one. If you really want to be in control we should allow only one 
socket or at least only one "control" socket.



If our kernel cfg80211 / nl80211 would be smart enough to handle these 
concurrent tasks, I would have little objection to let all clients do whatever 
they want, but we don’t have that. I do not want an external application 
messing with my planned radio time. And frankly if I am in the middle of 
roaming, I don’t want to be delayed because some fancy radar looking UI decides 
to start a full spectrum scan or blocks us via an action frame that times out.


The have been some efforts to handle concurrent use. For scheduled scan 
concurrency was added and critical proto primitives allow to temporarily 
disable scans when user-space needs it, eg. for EAPOL or DHCP exchange.



With iwd we are moving towards the direction that we are utilizing the 
information from access points and surrounding networks to intelligently scan 
and reduce the time spent scanning to a minimum. For us that is the way to 
improve WiFi experience for Linux.

We have been through this with Bluetooth already years ago. You need a central 
daemon that watches out for your radio utilization. Doing anything behind the 
back of such a daemon is not going to work out long term. Same applies to 
2G/3G/LTE where even more tasks need to be managed. And even wpa_supplicant has 
an internal mutex to control radio time.


Right. Given how nl80211 works today the only real control of radio time 
would need to be done in k

Re: iwlwifi/brcmfmac public action frames crash (RESENDING)

[Arend Van Spriel]

On June 21, 2019 10:09:10 PM Denis Kenzior  wrote:


Ping, is anyone looking into these crashes?


Did not see this message before.



On 06/13/2019 11:45 AM, James Prestwood wrote:

Sorry if this comes in twice, I sent it ~12 hours ago but never saw it
hit the list, nor in the archives so I am resending it.


Hi,


[snip]






Here is the brcmfmac crash:


[19735.643941] BUG: unable to handle kernel NULL pointer dereference at

[19735.643965] PGD 8001874aa067 P4D 8001874aa067 PUD 2735fe067
PMD 0
[19735.643984] Oops:  [#1] SMP PTI
[19735.643993] CPU: 7 PID: 5051 Comm: iwd Tainted: GW
I   4.19.0-rc2-custom #27
[19735.644002] Hardware name: System manufacturer System Product
Name/SABERTOOTH X58, BIOS 140208/09/2012
[19735.644027] RIP: 0010:brcmf_p2p_send_action_frame+0x23a/0x850
[brcmfmac]


As the name suggest this was implemented for P2P support. Will look into this.

Regards,
Arend

Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner

[Arend Van Spriel]

On 6/21/2019 7:14 PM, Denis Kenzior wrote:

Hi Arend,

On 06/21/2019 03:09 AM, Arend Van Spriel wrote:

On 6/21/2019 12:07 AM, Denis Kenzior wrote:

If the wdev object has been created (via NEW_INTERFACE) with
SOCKET_OWNER attribute set, then limit certain commands only to the
process that created that wdev.

This can be used to make sure no other process on the system interferes
by sending unwanted scans, action frames or any other funny business.


The flag is a good addition opposed to having handlers deal with it. 
However, earlier motivation for SOCKET_OWNER use was about netlink 
multicast being unreliable, which I can agree to. However, avoiding 


???  I can't agree to that as I have no idea what you're talking about 
:)  Explain?  SOCKET_OWNER was introduced mainly to bring down links / 
scans / whatever in case the initiating process died.  As a side effect 
it also helped in the beginning when users ran iwd + wpa_s 
simultaneously (by accident) and all sorts of fun ensued.  We then 
re-used SOCKET_OWNER for running EAPoL over NL80211.  But 'multicast 
unreliability' was never an issue that I recall?


hmm. I tried searching in memory... of my email client but to no avail. 
I somehow recalled that netlink multicast was not guaranteed to be 
delivered/seen by all listeners.


"funny business" is a different thing. Our testing infrastructure is 
doing all kind of funny business. Guess we will need to refrain from 


So you're going behind the managing daemon's back and messing with the 
kernel state...  I guess the question is why?  But really, if wpa_s 
wants to tolerate that, that is their problem :)  iwd doesn't want to, 
nor do we want to deal with the various race conditions and corner cases 
associated with that.  Life is hard as it is ;)


That's just it, right. This is what Marcel calls the real environment, 
but is it. The nl80211 is a kernel API and should that mean that there 
must be a managing daemon locking down APIs for other user-space tools 
to use. If I want a user-space app to show a radar screen with 
surrounding APs using scanning and FTM nl80211 commands it seems now it 
has to create a new interface and hope the resources are there for it to 
succeed. Where is my freedom in that? If I am using such an app don't 
you think I don't accept it could impact the managing daemon.


using any user-space wireless tools that use the SOCKET_OWNER 
attribute, but how do we know? Somehow I suspect iwd is one to avoid 
;-) I have yet 


I guess you will be avoiding wpa_s since that one uses SOCKET_OWNER too ;)


Probably. One of my concerns was about NL80211_CMD_CONNECT event, but 
checking nl80211_send_connect_result() it seems to just send it to the 
mlme multicast group regardless SOCKET_OWNER use.


to give iwd a spin, but this SOCKET_OWNER strategy kept me from it. 
Maybe iwd could have a developer option which disables the use of the 
SOCKET_OWNER attribute.


Okay?  Not sure what you're trying to say here?  I'd interpret this as 
"You guys suck.  I'm taking my ball and going home?" but I hope this 
isn't what you're saying?


Not saying that. Just saying that the "real environment" is in the eye 
of the beholder and it would be nice if there was a way to opt out, but 
Marcel seems strongly opposed to it. So there seems no point in 
scratching that itch and come up with a patch.


Regards,
Arend

Re: [RFC 0/8] nl80211: add 6GHz band support

[Arend Van Spriel]

On 6/3/2019 12:39 PM, Arend Van Spriel wrote:

On 5/27/2019 10:46 PM, Arend Van Spriel wrote:

On 5/24/2019 8:38 PM, Arend Van Spriel wrote:
On May 24, 2019 1:56:43 PM Johannes Berg  
wrote:



Hi Arend,

On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote:

In 802.11ax D4.0 a new band has been proposed. This series contains
changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
was no overlap in channel number. However, this new band has channel
numbers with a range from 1 up to 253.


At the wireless workshop in Prague, we looked at this and sort of
decided that it'd be better to put all the 6 GHz channels into the 5 
GHz

"band" in nl80211, to avoid all the "5 || 6" since they're really the
same except for very specific places like scanning.


Would have liked to be there, but attending is no longer an option 
for me. We now have two autistic, non-verbal children and I am the 
primary caregiver for the oldest because my wife can't handle him. 
Guess I should have checked the workshop notes before working on this 
:-) Do you have URL?


Found the netdev wifi workshop page and looked over the slides 
quickly, but the notes page is pretty empty ;-)


Agree that most functional requirements for 6 GHz are same as 5 GHz. 
There are some 6 GHz specifics about beaconing as well.


This came up in discussion with my colleagues today and I would say 
from mac80211 perspective there is more to it than just scanning. In 
short the 6GHz band is for HE-only operation so for example only HE 
rates may be used. As the bitrates are in ieee80211_supported_band 
having a separate 6GHz band seems to have a (slight?) advantage.


Hi, Johannes

Any thoughts on this?


Hi Johannes,

It has been a while so maybe your thoughts are more concrete? ;-p

I really would like this to move forward as I also noticed hostapd 
changes being posted for 6GHz support yesterday.


Thanks,
Arend

Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner

[Arend Van Spriel]

On 6/21/2019 12:07 AM, Denis Kenzior wrote:

If the wdev object has been created (via NEW_INTERFACE) with
SOCKET_OWNER attribute set, then limit certain commands only to the
process that created that wdev.

This can be used to make sure no other process on the system interferes
by sending unwanted scans, action frames or any other funny business.


The flag is a good addition opposed to having handlers deal with it. 
However, earlier motivation for SOCKET_OWNER use was about netlink 
multicast being unreliable, which I can agree to. However, avoiding 
"funny business" is a different thing. Our testing infrastructure is 
doing all kind of funny business. Guess we will need to refrain from 
using any user-space wireless tools that use the SOCKET_OWNER attribute, 
but how do we know? Somehow I suspect iwd is one to avoid ;-) I have yet 
to give iwd a spin, but this SOCKET_OWNER strategy kept me from it. 
Maybe iwd could have a developer option which disables the use of the 
SOCKET_OWNER attribute.


Regards,
Arend


This patch introduces a new internal flag, and checks that flag in the
pre_doit hook.

Signed-off-by: Denis Kenzior 
---
  net/wireless/nl80211.c | 80 --
  1 file changed, 61 insertions(+), 19 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ff760ba83449..26bab9560c0f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13587,6 +13587,7 @@ static int nl80211_probe_mesh_link(struct sk_buff *skb, 
struct genl_info *info)
  #define NL80211_FLAG_NEED_WDEV_UP (NL80211_FLAG_NEED_WDEV |\
 NL80211_FLAG_CHECK_NETDEV_UP)
  #define NL80211_FLAG_CLEAR_SKB0x20
+#define NL80211_FLAG_OWNER_ONLY0x40
  
  static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,

struct genl_info *info)
@@ -13595,6 +13596,7 @@ static int nl80211_pre_doit(const struct genl_ops *ops, 
struct sk_buff *skb,
struct wireless_dev *wdev;
struct net_device *dev;
bool rtnl = ops->internal_flags & NL80211_FLAG_NEED_RTNL;
+   int ret;
  
  	if (rtnl)

rtnl_lock();
@@ -13602,10 +13604,10 @@ static int nl80211_pre_doit(const struct genl_ops 
*ops, struct sk_buff *skb,
if (ops->internal_flags & NL80211_FLAG_NEED_WIPHY) {
rdev = cfg80211_get_dev_from_info(genl_info_net(info), info);
if (IS_ERR(rdev)) {
-   if (rtnl)
-   rtnl_unlock();
-   return PTR_ERR(rdev);
+   ret = PTR_ERR(rdev);
+   goto done;
}
+
info->user_ptr[0] = rdev;
} else if (ops->internal_flags & NL80211_FLAG_NEED_NETDEV ||
   ops->internal_flags & NL80211_FLAG_NEED_WDEV) {
@@ -13614,32 +13616,33 @@ static int nl80211_pre_doit(const struct genl_ops 
*ops, struct sk_buff *skb,
wdev = __cfg80211_wdev_from_attrs(genl_info_net(info),
  info->attrs);
if (IS_ERR(wdev)) {
-   if (rtnl)
-   rtnl_unlock();
-   return PTR_ERR(wdev);
+   ret = PTR_ERR(wdev);
+   goto done;
}
  
  		dev = wdev->netdev;

rdev = wiphy_to_rdev(wdev->wiphy);
  
+		ret = -EINVAL;

if (ops->internal_flags & NL80211_FLAG_NEED_NETDEV) {
-   if (!dev) {
-   if (rtnl)
-   rtnl_unlock();
-   return -EINVAL;
-   }
+   if (!dev)
+   goto done;
  
  			info->user_ptr[1] = dev;

} else {
info->user_ptr[1] = wdev;
}
  
+		ret = -ENETDOWN;

if (ops->internal_flags & NL80211_FLAG_CHECK_NETDEV_UP &&
-   !wdev_running(wdev)) {
-   if (rtnl)
-   rtnl_unlock();
-   return -ENETDOWN;
-   }
+   !wdev_running(wdev))
+   goto done;
+
+   ret = -EPERM;
+   if (ops->internal_flags & NL80211_FLAG_OWNER_ONLY &&
+   wdev->owner_nlportid &&
+   wdev->owner_nlportid != info->snd_portid)
+   goto done;
  
  		if (dev)

dev_hold(dev);
@@ -13647,7 +13650,13 @@ static int nl80211_pre_doit(const struct genl_ops 
*ops, struct sk_buff *skb,
info->user_ptr[0] = rdev;
}
  
-	return 0;

+   ret = 0;
+
+done:
+   if (rtnl && !ret)
+   rtnl_unlock();
+
+   return ret;
  }
  
  static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Arend Van Spriel]

On 6/19/2019 7:26 AM, Marcel Holtmann wrote:

Hi Arend,


i was able to reproduce an (maybe older issue) with 4-way handshake
offloading for 802.1X in the brcmfmac driver. My setup consists of
Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
Raspberry Pi 3 A+ (Linux 4.19) on AP side.


Looks like Raspberry Pi isn't the only affected platform [3], [4].

[3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
[4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521


Stefan,

Could you please try the attached patch for your wpa_supplicant? We'll
upstream if it works for you.


I hope that someone is also providing a kernel patch to fix the issue. Hacking 
around a kernel issue in userspace is not enough. Fix the root cause in the 
kernel.

Marcel,
This is a kernel warning for invalid application PMK set actions, so the
fix is to only set PMK to wifi driver when 4-way is offloaded. I think
Arend added the WARN_ON() intentionally to catch application misuse of
PMK setting.
You may also remove the warnings with the attached patch, but let's see
what Arend says first.
Arend,
Any comment?


Hi Chi-Hsien, Marcel

 From the kernel side I do not see an issue. In order to use 802.1X offload the 
NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in NL80211_CMD_CONNECT. Otherwise, 
NL80211_CMD_SET_PMK is not accepted. The only improvement would be to document this more 
clearly in the "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.


so nl80211 is an API. And an application can use that API wrongly (be that 
intentionally or unintentionally), the kernel can not just go WARN_ON and print 
a backtrace. That is your bug. So please handle wrong user input properly.


Hi Marcel,

You are right. However, the kernel does also return an error if the 
WARN_ON is hit. We can improve by using the EXT_ACK functionality to 
provide more info than just -EINVAL, eg. "PMK not accepted; no 802.1X 
offload requested on connect".



Frankly, I don’t get why nl80211 itself is not validating the input and this is 
left to the driver. I think we need a nl80211 fuzzer that really exercises this 
API with random values and parameters to provide invalid input.


That would mean nl80211 should keep state info between commands. From 
what I remember that has been avoided from day one because of the 
experiences with that in the WEXT days. I welcome any testing be it 
fuzzer or something else.


Regards,
Arend

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Arend Van Spriel]

On 6/18/2019 7:03 PM, Stefan Wahren wrote:

Hi,

Am 18.06.19 um 10:27 schrieb Arend Van Spriel:

+ Jouni

On 6/18/2019 7:33 AM, Chi-Hsien Lin wrote:



On 06/17/2019 10:33, Marcel Holtmann wrote:

Hi Chi-hsien,


i was able to reproduce an (maybe older issue) with 4-way handshake
offloading for 802.1X in the brcmfmac driver. My setup consists of
Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA
side and a
Raspberry Pi 3 A+ (Linux 4.19) on AP side.


Looks like Raspberry Pi isn't the only affected platform [3], [4].

[3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
[4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521


Stefan,

Could you please try the attached patch for your wpa_supplicant? We'll
upstream if it works for you.

i've forward this patch to the Arch Linux board hoping someone else has
currently more time.


I hope that someone is also providing a kernel patch to fix the
issue. Hacking around a kernel issue in userspace is not enough. Fix
the root cause in the kernel.


Marcel,

This is a kernel warning for invalid application PMK set actions, so the
fix is to only set PMK to wifi driver when 4-way is offloaded. I think
Arend added the WARN_ON() intentionally to catch application misuse of

  > PMK setting.


You may also remove the warnings with the attached patch, but let's see
what Arend says first.

Instead of removing the WARN_ON i suggest to replace it with a more user
friendly dev_warn().



Arend,

Any comment?


Hi Chi-Hsien, Marcel

 From the kernel side I do not see an issue. In order to use 802.1X
offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in
NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted.
The only improvement would be to document this more clearly in the
"WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.


I missed to add my expectation as a user. At first i assume this new
behavior in wpa_supplicant 2.8 has been tested successful with at least
one Linux wifi driver. So i'm curious if all drivers behave that way?


As a matter of fact it has been tested with brcmfmac.


Another point is that in my wpa_supplicant.conf i never enforced 802.1X
offload and i assume this feature is optional. So can't we do some kind
of fallback in this case?


So when the driver indicates it supports the offload, wpa_supplicant opt 
in. There is no possibility for the user to opt out.


Regards,
Arend

Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk

[Arend Van Spriel]

+ Jouni

On 6/18/2019 7:33 AM, Chi-Hsien Lin wrote:



On 06/17/2019 10:33, Marcel Holtmann wrote:

Hi Chi-hsien,


i was able to reproduce an (maybe older issue) with 4-way handshake
offloading for 802.1X in the brcmfmac driver. My setup consists of
Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
Raspberry Pi 3 A+ (Linux 4.19) on AP side.


Looks like Raspberry Pi isn't the only affected platform [3], [4].

[3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
[4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521


Stefan,

Could you please try the attached patch for your wpa_supplicant? We'll
upstream if it works for you.


I hope that someone is also providing a kernel patch to fix the issue. Hacking 
around a kernel issue in userspace is not enough. Fix the root cause in the 
kernel.


Marcel,

This is a kernel warning for invalid application PMK set actions, so the
fix is to only set PMK to wifi driver when 4-way is offloaded. I think
Arend added the WARN_ON() intentionally to catch application misuse of

 > PMK setting.


You may also remove the warnings with the attached patch, but let's see
what Arend says first.


Arend,

Any comment?


Hi Chi-Hsien, Marcel

From the kernel side I do not see an issue. In order to use 802.1X 
offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in 
NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The 
only improvement would be to document this more clearly in the "WPA/WPA2 
EAPOL handshake offload" DOC section in nl80211.h.


As for the wpa_supplicant behavior it seemed a good idea to reuse the 
req_key_mgmt_offload parameter at the time, but it seems to bite each 
other. Maybe it is better to have a separate flag like 
'req_handshake_offload'. Jouni, any thoughts on this?


Regards,
Arend

Re: [RESEND] brcmfmac support for BCM4359 sdio on arm64 ??

[Arend Van Spriel]

On 6/8/2019 5:39 AM, Christian Hewitt wrote:

Hello Arend,

Last October Christoph Müllner reported BCM4359 SDIO issues here: 
https://www.spinics.net/lists/linux-wireless/msg178783.html but the 
investigation stalled after the needs/timescale of his project forced a change 
to a different (working) module.

BCM4359 is being used in an increasing number of Amlogic devices the Kodi 
focussed distro LibreELEC supports. I’m one of the maintainers for the distro 
and I’d like to assist/resume the investigation.

To recap: using changes from Wright Feng that can be found here 
https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0050-brcmfmac-Add-support-for-BCM4359-SDIO-chipset.patch
 result in the BCM4359 device being identified but firmware/nvram loading fails:

[8.557929] brcmfmac: F1 signature read @0x1800=0x17294359
[8.562087] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio 
for chip BCM4359/9
[8.775655] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[8.775667] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 
membytes at 0x0025f0c0
[8.775670] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file 
download failed


It seems to fail when reading back the nvram file to assure it was 
downloaded properly.



See: http://ix.io/1KfY for the full dmesg output on 5.1-rc1 kernel including a 
splat that may or may not be related/relevant. I am using firmware and nvram 
files from https://github.com/LibreELEC/brcmfmac_sdio-firmware which match 
files found in several other github and public repo locations. The 
firmware/nvram are reported working in Android.


The splat could be relevant. Maybe try the patch below to get actual 
values that are checked in the WARN_ON.



BCMDHD is also reported working with commits here: 
https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd
 but LibreELEC needs to support many different boards (with many different SDIO 
modules) from a single OS image, so BCMDHD is not the solution we need.

One additional patch I spotted mentioning BCM4359 (also from Wright Feng) was 
https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0073-non-upstream-reset-two-D11-cores-if-chip-has-two-D11.patch
 but it makes no difference (the dmesg log above is with this patch applied).

I don’t write code but am happy to build test kernels with suggested patches or 
explicit instructions. I’ve also CC’d LibreELEC colleague and linux-amlogic 
maintainer Neil Armstrong who can assist. NB: If direct access to hardware 
would help progress things I can easily organise remote access or get board 
samples shipped.

How can we resume the investigation?


Let's try one step at a time ;-)

Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/driver

index fc12598..e9b0986 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -772,7 +772,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev 
*sdiod

  sdiodev->settings->bus.sdio.txglomsz);
nents += (nents >> 4) + 1;

-   WARN_ON(nents > sdiodev->max_segment_count);
+   WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u, 
host_max_seg=

+sdiodev->max_segment_count, host->max_segs, nents);

brcmf_dbg(TRACE, "nents=%d\n", nents);
err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
q

Re: [PATCH V2] iw: print HE capabilities

[Arend Van Spriel]

On 6/7/2019 4:11 AM, Joe Perches wrote:

On Tue, 2019-05-28 at 08:58 +0200, John Crispin wrote:

Print the HE MAC/PHY capabilities and MCS/NSS sets.


trivia:


diff --git a/util.c b/util.c

[]

+void print_he_info(struct nlattr *nl_iftype)
+{
+   struct nlattr *tb[NL80211_BAND_IFTYPE_ATTR_MAX + 1];
+   struct nlattr *tb_flags[NL80211_IFTYPE_MAX + 1];
+   char *iftypes[NUM_NL80211_IFTYPES] = {
+   "Unspec", "Adhoc", "Station", "AP", "AP/VLAN", "WDS", "Monitor",
+   "Mesh", "P2P/Client", "P2P/Go", "P2P/Device", "OCB", "NAN",
+   };


Should probably be
const char * const iftypes[...]


We are doing this iftype string mapping in several places so a helper 
function may be warranted.


Gr. AvS

Re: [RFC 0/8] nl80211: add 6GHz band support

[Arend Van Spriel]

On 5/27/2019 10:46 PM, Arend Van Spriel wrote:

On 5/24/2019 8:38 PM, Arend Van Spriel wrote:
On May 24, 2019 1:56:43 PM Johannes Berg  
wrote:



Hi Arend,

On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote:

In 802.11ax D4.0 a new band has been proposed. This series contains
changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
was no overlap in channel number. However, this new band has channel
numbers with a range from 1 up to 253.


At the wireless workshop in Prague, we looked at this and sort of
decided that it'd be better to put all the 6 GHz channels into the 5 GHz
"band" in nl80211, to avoid all the "5 || 6" since they're really the
same except for very specific places like scanning.


Would have liked to be there, but attending is no longer an option for 
me. We now have two autistic, non-verbal children and I am the primary 
caregiver for the oldest because my wife can't handle him. Guess I 
should have checked the workshop notes before working on this :-) Do 
you have URL?


Found the netdev wifi workshop page and looked over the slides quickly, 
but the notes page is pretty empty ;-)


Agree that most functional requirements for 6 GHz are same as 5 GHz. 
There are some 6 GHz specifics about beaconing as well.


This came up in discussion with my colleagues today and I would say from 
mac80211 perspective there is more to it than just scanning. In short 
the 6GHz band is for HE-only operation so for example only HE rates may 
be used. As the bitrates are in ieee80211_supported_band having a 
separate 6GHz band seems to have a (slight?) advantage.


Hi, Johannes

Any thoughts on this?

Regards,
Arend

Re: [RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band

[Arend Van Spriel]

On May 30, 2019 7:43:27 PM Jeff Johnson  wrote:


On 2019-05-30 09:07, Arend Van Spriel wrote:

Sigh! Obviously that is a concern. Johannes already mentioned it.


Sorry, overlooked his comment on the [0/8] patch. I'll climb back under
my rock.


No need to do that. It is mainly me feeling stupid about making such a 
mistake that makes me sigh ;-)


Regards,
Arend

Re: [RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band

[Arend Van Spriel]

On May 30, 2019 4:53:13 PM Jeff Johnson  wrote:


On 2019-05-20 05:00, Arend van Spriel wrote:

[...snip...]
 enum nl80211_band {
NL80211_BAND_2GHZ,
NL80211_BAND_5GHZ,
+   NL80211_BAND_6GHZ,
NL80211_BAND_60GHZ,

NUM_NL80211_BANDS,


Is it not a concern that this changes the value of NL80211_BAND_60GHZ
and hence will break any ABI which expects the current value?


Sigh! Obviously that is a concern. Johannes already mentioned it.

Thanks,
Arend

Re: brcmfmac & DEL_INTERFACE

[Arend Van Spriel]

On 5/28/2019 8:16 PM, Denis Kenzior wrote:

Hi Arend,

We noticed that brcmfmac doesn't support .del_virtual_intf for 
non-p2p/ap interface types.  Any chance this can be added?


We currently remove all wifi interfaces and re-create the needed ones 
with SOCKET_OWNER set, and it would be nice if we didn't need to treat 
brcmfmac specially.


This came up recently. During probe the driver creates a network 
interface that we refer to as primary interface. We consider this 
non-virtual and ownership is with the driver. My guess is that this 
concept comes from the WEXT era, where we did not have the ieee80211 phy 
objects to interact with the driver from user-space. I suppose you don't 
mind the creation of this interface and just want to allow removing it, 
right?


Regards,
Arend

Re: [RFC 0/8] nl80211: add 6GHz band support

[Arend Van Spriel]

On 5/24/2019 8:38 PM, Arend Van Spriel wrote:

On May 24, 2019 1:56:43 PM Johannes Berg  wrote:


Hi Arend,

On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote:

In 802.11ax D4.0 a new band has been proposed. This series contains
changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
was no overlap in channel number. However, this new band has channel
numbers with a range from 1 up to 253.


At the wireless workshop in Prague, we looked at this and sort of
decided that it'd be better to put all the 6 GHz channels into the 5 GHz
"band" in nl80211, to avoid all the "5 || 6" since they're really the
same except for very specific places like scanning.


Would have liked to be there, but attending is no longer an option for 
me. We now have two autistic, non-verbal children and I am the primary 
caregiver for the oldest because my wife can't handle him. Guess I 
should have checked the workshop notes before working on this :-) Do you 
have URL?


Found the netdev wifi workshop page and looked over the slides quickly, 
but the notes page is pretty empty ;-)


Agree that most functional requirements for 6 GHz are same as 5 GHz. 
There are some 6 GHz specifics about beaconing as well.


This came up in discussion with my colleagues today and I would say from 
mac80211 perspective there is more to it than just scanning. In short 
the 6GHz band is for HE-only operation so for example only HE rates may 
be used. As the bitrates are in ieee80211_supported_band having a 
separate 6GHz band seems to have a (slight?) advantage.


Regards,
Arend

Re: [RFC 0/8] nl80211: add 6GHz band support

[Arend Van Spriel]

On May 24, 2019 1:56:43 PM Johannes Berg  wrote:


Hi Arend,

On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote:

In 802.11ax D4.0 a new band has been proposed. This series contains
changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
was no overlap in channel number. However, this new band has channel
numbers with a range from 1 up to 253.


At the wireless workshop in Prague, we looked at this and sort of
decided that it'd be better to put all the 6 GHz channels into the 5 GHz
"band" in nl80211, to avoid all the "5 || 6" since they're really the
same except for very specific places like scanning.


Would have liked to be there, but attending is no longer an option for me. 
We now have two autistic, non-verbal children and I am the primary 
caregiver for the oldest because my wife can't handle him. Guess I should 
have checked the workshop notes before working on this :-) Do you have URL?


Agree that most functional requirements for 6 GHz are same as 5 GHz. There 
are some 6 GHz specifics about beaconing as well.



The channel numbers problem came up, of course, but for nl80211 it's not
that relevant since we deal with frequencies only, and we thought inside
the kernel it'd be better to disambiguate them with operating classes,
where needed - only few places really deal with channel numbers to start
with.

Do you have any reason to think that it's better as a separate band enum


No specific reason. Just that the few cfg80211-based drivers tend to use 
channel number as hwvalue.



(which I notice you put before 60 GHz thus breaking the API/ABI :P)?


Right. Now I feel wet behind the ears :-p

I will go with 6G being additional 5G range and see how that works for us.

Gr. AvS

Re: [PATCH 1/7] brcm80211: switch common header files to using SPDX license identifier

[Arend Van Spriel]

On May 23, 2019 11:17:22 AM Kalle Valo  wrote:


Arend Van Spriel  writes:



Or do you want me to resend the whole series without patch 3?


If the series applies without patch 3 (and I assume it does) no need to
resend the whole series.


Thanks, Kalle

I assume the same.

Regards,
Arend

Re: [PATCH 1/7] brcm80211: switch common header files to using SPDX license identifier

[Arend Van Spriel]

On 5/20/2019 6:54 PM, Kalle Valo wrote:

Arend Van Spriel  writes:


On 5/16/2019 10:57 PM, Arend Van Spriel wrote:

On 5/16/2019 2:04 PM, Arend van Spriel wrote:

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.


Hi Kalle,

Given the feedback on checkpatch (or spdxcheck) failures let me
respin this series.


Actually let's *NOT* respin and leave this series as is and ignore the
warning for the header files as Thomas wrote in his response: " So we
can fixup the documentation and allow // style for headers as well.".


What about patch 3, should I drop that patch? Wasn't the conclusion that
you need separately change led.c?


Okay. Let's do that. Or do you want me to resend the whole series 
without patch 3?


Regards,
Arend

[RFC 2/8] cfg80211: add 6GHz UNII band definitions

[Arend van Spriel]

For the new 6GHz there are new UNII band definitions as listed
in the FCC notice [1].

[1] https://docs.fcc.gov/public/attachments/FCC-18-147A1_Rcd.pdf

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/reg.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 4831ad74..646107a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3806,8 +3806,9 @@ void wiphy_regulatory_deregister(struct wiphy *wiphy)
 }
 
 /*
- * See http://www.fcc.gov/document/5-ghz-unlicensed-spectrum-unii, for
- * UNII band definitions
+ * See FCC notices for UNII band definitions
+ *  5GHz: https://www.fcc.gov/document/5-ghz-unlicensed-spectrum-unii
+ *  6GHz: 
https://www.fcc.gov/document/fcc-proposes-more-spectrum-unlicensed-use-0
  */
 int cfg80211_get_unii(int freq)
 {
@@ -3831,6 +3832,22 @@ int cfg80211_get_unii(int freq)
if (freq > 5725 && freq <= 5825)
return 4;
 
+   /* UNII-5 */
+   if (freq > 5925 && freq <= 6425)
+   return 5;
+
+   /* UNII-6 */
+   if (freq > 6425 && freq <= 6525)
+   return 6;
+
+   /* UNII-7 */
+   if (freq > 6525 && freq <= 6875)
+   return 7;
+
+   /* UNII-8 */
+   if (freq > 6875 && freq <= 7125)
+   return 8;
+
return -EINVAL;
 }
 
-- 
1.9.1

[RFC 3/8] cfg80211: util: add 6GHz channel to freq conversion and vice versa

[Arend van Spriel]

Extend the functions ieee80211_channel_to_frequency() and
ieee80211_frequency_to_channel() to support 6GHz band according
specification in 802.11ax D4.1 27.3.22.2.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index cf63b63..081637e 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -91,6 +91,11 @@ int ieee80211_channel_to_frequency(int chan, enum 
nl80211_band band)
else
return 5000 + chan * 5;
break;
+   case NL80211_BAND_6GHZ:
+   /* see 802.11ax D4.1 27.3.22.2 */
+   if (chan <= 253)
+   return 5940 + chan * 5;
+   break;
case NL80211_BAND_60GHZ:
if (chan < 7)
return 56160 + chan * 2160;
@@ -111,8 +116,11 @@ int ieee80211_frequency_to_channel(int freq)
return (freq - 2407) / 5;
else if (freq >= 4910 && freq <= 4980)
return (freq - 4000) / 5;
-   else if (freq <= 45000) /* DMG band lower limit */
+   else if (freq < 5940)
return (freq - 5000) / 5;
+   else if (freq <= 45000) /* DMG band lower limit */
+   /* see 802.11ax D4.1 27.3.22.2 */
+   return (freq - 5940) / 5;
else if (freq >= 58320 && freq <= 70200)
return (freq - 56160) / 2160;
else
-- 
1.9.1

[RFC 4/8] cfg80211: extend ieee80211_operating_class_to_band() for 6GHz

[Arend van Spriel]

Add 6GHz operating class range as defined in 802.11ax D4.1 Annex E.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 081637e..03e7176 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1474,6 +1474,9 @@ bool ieee80211_operating_class_to_band(u8 operating_class,
case 128 ... 130:
*band = NL80211_BAND_5GHZ;
return true;
+   case 131 ... 135:
+   *band = NL80211_BAND_6GHZ;
+   return true;
case 81:
case 82:
case 83:
-- 
1.9.1

[RFC 5/8] cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS entries

[Arend van Spriel]

In nl80211.c there is a policy for all bands in NUM_NL80211_BANDS and
in trace.h there is a callback trace for multicast rates which is per
band in NUM_NL80211_BANDS. Both need to be extended for the new
NL80211_BAND_6GHZ.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/nl80211.c | 1 +
 net/wireless/trace.h   | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fffe4b3..c0224fc 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -627,6 +627,7 @@ static int validate_ie_attr(const struct nlattr *attr,
 nl80211_match_band_rssi_policy[NUM_NL80211_BANDS] = {
[NL80211_BAND_2GHZ] = { .type = NLA_S32 },
[NL80211_BAND_5GHZ] = { .type = NLA_S32 },
+   [NL80211_BAND_6GHZ] = { .type = NLA_S32 },
[NL80211_BAND_60GHZ] = { .type = NLA_S32 },
 };
 
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 2abfff9..a7f39a8 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2446,10 +2446,11 @@
   sizeof(int) * NUM_NL80211_BANDS);
),
TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", "
- "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 60GHz=0x%x]",
+ "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 6GHz=0x%x, 
60GHz=0x%x]",
  WIPHY_PR_ARG, NETDEV_PR_ARG,
  __entry->mcast_rate[NL80211_BAND_2GHZ],
  __entry->mcast_rate[NL80211_BAND_5GHZ],
+ __entry->mcast_rate[NL80211_BAND_6GHZ],
  __entry->mcast_rate[NL80211_BAND_60GHZ])
 );
 
-- 
1.9.1

[RFC 8/8] cfg80211: apply same mandatory rate flags for 5GHz and 6GHz

[Arend van Spriel]

For the new 6GHz band the same rules apply for mandatory rates so
add it to set_mandatory_flags_band() function.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 03e7176..fd90c86 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -156,6 +156,7 @@ static void set_mandatory_flags_band(struct 
ieee80211_supported_band *sband)
 
switch (sband->band) {
case NL80211_BAND_5GHZ:
+   case NL80211_BAND_6GHZ:
want = 3;
for (i = 0; i < sband->n_bitrates; i++) {
if (sband->bitrates[i].bitrate == 60 ||
-- 
1.9.1

[RFC 0/8] nl80211: add 6GHz band support

[Arend van Spriel]

In 802.11ax D4.0 a new band has been proposed. This series contains
changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
was no overlap in channel number. However, this new band has channel
numbers with a range from 1 up to 253. The only place I could find an
issue with this is in cfg80211_wext_freq(). Not sure how to deal with
that so it is not part of this series.

The series applies to the master branch of the mac80211-next repository.

Arend van Spriel (8):
  nl80211: add 6GHz band definition to enum nl80211_band
  cfg80211: add 6GHz UNII band definitions
  cfg80211: util: add 6GHz channel to freq conversion and vice versa
  cfg80211: extend ieee80211_operating_class_to_band() for 6GHz
  cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS
entries
  cfg80211: use same IR permissive rules for 6GHz band
  cfg80211: ibss: use 11a mandatory rates for 6GHz band operation
  cfg80211: apply same mandatory rate flags for 5GHz and 6GHz

 include/uapi/linux/nl80211.h |  2 ++
 net/wireless/chan.c  |  3 ++-
 net/wireless/ibss.c  | 16 +++-
 net/wireless/nl80211.c   |  1 +
 net/wireless/reg.c   | 21 +++--
 net/wireless/trace.h |  3 ++-
 net/wireless/util.c  | 14 +-
 7 files changed, 50 insertions(+), 10 deletions(-)

-- 
1.9.1

[RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band

[Arend van Spriel]

In the 802.11ax specification a new band is introduced, which
is also proposed by FCC for unlicensed use. This band is referred
to as 6GHz spanning frequency range from 5925 to 7125 MHz.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 include/uapi/linux/nl80211.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6f09d1500..5ea3c8c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4515,6 +4515,7 @@ enum nl80211_txrate_gi {
  * enum nl80211_band - Frequency band
  * @NL80211_BAND_2GHZ: 2.4 GHz ISM band
  * @NL80211_BAND_5GHZ: around 5 GHz band (4.9 - 5.7 GHz)
+ * @NL80211_BAND_6GHZ: around 6 GHz band (5.9 - 7.2 GHz)
  * @NL80211_BAND_60GHZ: around 60 GHz band (58.32 - 69.12 GHz)
  * @NUM_NL80211_BANDS: number of bands, avoid using this in userspace
  * since newer kernel versions may support more bands
@@ -4522,6 +4523,7 @@ enum nl80211_txrate_gi {
 enum nl80211_band {
NL80211_BAND_2GHZ,
NL80211_BAND_5GHZ,
+   NL80211_BAND_6GHZ,
NL80211_BAND_60GHZ,
 
NUM_NL80211_BANDS,
-- 
1.9.1

[RFC 6/8] cfg80211: use same IR permissive rules for 6GHz band

[Arend van Spriel]

The function cfg80211_ir_permissive_chan() is applicable for
6GHz band as well so make sure it is handled.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/chan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 7dc1bbd..7c9d204 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -894,7 +894,8 @@ static bool cfg80211_ir_permissive_chan(struct wiphy *wiphy,
if (chan == other_chan)
return true;
 
-   if (chan->band != NL80211_BAND_5GHZ)
+   if (chan->band != NL80211_BAND_5GHZ &&
+   chan->band != NL80211_BAND_6GHZ)
continue;
 
r1 = cfg80211_get_unii(chan->center_freq);
-- 
1.9.1

[RFC 7/8] cfg80211: ibss: use 11a mandatory rates for 6GHz band operation

[Arend van Spriel]

The default mandatory rates, ie. when not specified by user-space, is
determined by the band. Select 11a rateset for 6GHz band.

Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Leon Zegers 
Signed-off-by: Arend van Spriel 
---
 net/wireless/ibss.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index d1743e6..ae8fe66 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -104,13 +104,19 @@ int __cfg80211_join_ibss(struct 
cfg80211_registered_device *rdev,
* use the mandatory rate set for 11b or
* 11a for maximum compatibility.
*/
-   struct ieee80211_supported_band *sband =
-   rdev->wiphy.bands[params->chandef.chan->band];
+   struct ieee80211_supported_band *sband;
+   enum nl80211_band band;
+   u32 flag;
int j;
-   u32 flag = params->chandef.chan->band == NL80211_BAND_5GHZ ?
-   IEEE80211_RATE_MANDATORY_A :
-   IEEE80211_RATE_MANDATORY_B;
 
+   band = params->chandef.chan->band;
+   if (band == NL80211_BAND_5GHZ ||
+   band == NL80211_BAND_6GHZ)
+   flag = IEEE80211_RATE_MANDATORY_A;
+   else
+   flag = IEEE80211_RATE_MANDATORY_B;
+
+   sband = rdev->wiphy.bands[band];
for (j = 0; j < sband->n_bitrates; j++) {
if (sband->bitrates[j].flags & flag)
params->basic_rates |= BIT(j);
-- 
1.9.1

Re: [PATCH 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from sleep

[Arend Van Spriel]

On 5/18/2019 12:54 AM, Douglas Anderson wrote:

This series attempts to deal better with the expected transmission
errors that we get when waking up the SDIO-based WiFi on
rk3288-veyron-minnie, rk3288-veyron-speedy, and rk3288-veyron-mickey.

Some details about those errors can be found in
, but to summarize it here: if we try to
send the wakeup command to the WiFi card at the same time it has
decided to wake up itself then it will behave badly on the SDIO bus.
This can cause timeouts or CRC errors.

When I tested on 4.19 and 4.20 these CRC errors can be seen to cause
re-tuning.  Since I am currently developing on 4.19 this was the
original problem I attempted to solve.

On mainline it turns out that you don't see the retuning errors but
you see tons of spam about timeouts trying to wakeup from sleep.  I
tracked down the commit that was causing that and have partially
reverted it here.  I have no real knowledge about Broadcom WiFi, but
the commit that was causing problems sounds (from the descriptioin) to
be a hack commit penalizing all Broadcom WiFi users because of a bug
in a Cypress SD controller.  I will let others comment if this is
truly the case and, if so, what the right solution should be.


Let me give a bit of background. The brcmfmac driver implements its own 
runtime-pm like functionality, ie. if the driver is idle for some time 
it will put the device in a low-power state. When it does that it powers 
down several cores in the chip among which the SDIO core. However, the 
SDIO bus used be very bad at handling devices that do that so instead it 
has the Always-On-Station (AOS) block take over the SDIO core in 
handling the bus. Default is will send a R1 response, but only for CMD52 
(and CMD14 but no host is using that cruft). In noCmdDecode it does not 
respond and simply wakes up the SDIO core, which takes over again. 
Because it does not respond timeouts (-110) are kinda expected in this mode.


Regards,
Arend

Re: [PATCH 3/7] brcmsmac: switch source files to using SPDX license identifier

[Arend Van Spriel]

On 5/17/2019 8:07 PM, Rafał Miłecki wrote:

On Fri, 17 May 2019 at 01:25, Arend Van Spriel
 wrote:

On 5/16/2019 10:01 PM, Greg Kroah-Hartman wrote:

On Thu, May 16, 2019 at 09:45:19PM +0200, Arend Van Spriel wrote:

On 5/16/2019 7:31 PM, Greg Kroah-Hartman wrote:

On Thu, May 16, 2019 at 02:04:07PM +0200, Arend van Spriel wrote:

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.

Cc: Thomas Gleixner 
Cc: Greg Kroah-Hartman 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
Hi Thomas, Greg,

The file drivers/net/wireless/broadcom/brcm80211/brcmsmac/led.c
did not have license information nor copyright notice and as such
it got included in commit b24413180f56 ("License cleanup: add SPDX
GPL-2.0 license identifier to files with no license"). I added you
guys as I propose to align this source file with the rest of
the driver sources and change it to ISC license and add the missing
copyright notice while at it (not sure if that warrants a separate
patch).


A separate patch would be good, to make it explicit that you are
changing the license of the file.


Ok.


And ISC, ick, why...  :)


Because the license text in the other driver source files is a 1:1 match
with the ISC license.


Oh, I am not disagreeing with that, yes, that is obviously the license
of the files. Just complaining about that choice for Linux kernel code :)


I see.


Another option could be MIT license which is in the preferred folder.
Will have to consult our legal department about it though.


Hey, if your legal department is going to get asked this, why not just
switch it to GPLv2?  That would make everything much simpler.


Hah. Because I already know the answer to that. ;-)


It's not that obvious to me, sorry. Does your legal department require
something more permissive than GPLv2? Is that worth asking them about
dual-licensing? Something like
GPL-2.0 OR MIT
? That assures driver is compatible with Linux, no matter what's the
current lawyers interpretation of MIT vs. GPL 2.0. I believe Alan Cox
once told/suggested that dual-licensing is safer for legal reasons.


Thanks, Rafał

Indeed we want a more permissive license. I decided to stick with ISC 
for now. MIT is not off the table, but pending responses from copyright 
holders. If you or anyone else for that matter has additional and/or 
more accurate information about dual-licensing (and its legal safety) 
please let me know.


Regards,
Arend

Re: [PATCH 1/7] brcm80211: switch common header files to using SPDX license identifier

[Arend Van Spriel]

On 5/16/2019 10:57 PM, Arend Van Spriel wrote:

On 5/16/2019 2:04 PM, Arend van Spriel wrote:

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.


Hi Kalle,

Given the feedback on checkpatch (or spdxcheck) failures let me respin 
this series.


Actually let's *NOT* respin and leave this series as is and ignore the 
warning for the header files as Thomas wrote in his response: " So we 
can fixup the documentation and allow // style for headers as well.".


Regards,
Arend

Re: [PATCH 1/7] brcm80211: switch common header files to using SPDX license identifier

[Arend Van Spriel]

On 5/16/2019 2:04 PM, Arend van Spriel wrote:

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.


Hi Kalle,

Given the feedback on checkpatch (or spdxcheck) failures let me respin 
this series.


Gr. AvS

Re: [PATCH 3/7] brcmsmac: switch source files to using SPDX license identifier

[Arend Van Spriel]

On 5/16/2019 10:01 PM, Greg Kroah-Hartman wrote:

On Thu, May 16, 2019 at 09:45:19PM +0200, Arend Van Spriel wrote:

On 5/16/2019 7:31 PM, Greg Kroah-Hartman wrote:

On Thu, May 16, 2019 at 02:04:07PM +0200, Arend van Spriel wrote:

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.

Cc: Thomas Gleixner 
Cc: Greg Kroah-Hartman 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
Hi Thomas, Greg,

The file drivers/net/wireless/broadcom/brcm80211/brcmsmac/led.c
did not have license information nor copyright notice and as such
it got included in commit b24413180f56 ("License cleanup: add SPDX
GPL-2.0 license identifier to files with no license"). I added you
guys as I propose to align this source file with the rest of
the driver sources and change it to ISC license and add the missing
copyright notice while at it (not sure if that warrants a separate
patch).


A separate patch would be good, to make it explicit that you are
changing the license of the file.


Ok.


And ISC, ick, why...  :)


Because the license text in the other driver source files is a 1:1 match
with the ISC license.


Oh, I am not disagreeing with that, yes, that is obviously the license
of the files. Just complaining about that choice for Linux kernel code :)


I see.


Another option could be MIT license which is in the preferred folder.
Will have to consult our legal department about it though.


Hey, if your legal department is going to get asked this, why not just
switch it to GPLv2?  That would make everything much simpler.


Hah. Because I already know the answer to that. ;-)

Regards,
Arend

Re: SPDX identifier

[Arend Van Spriel]

On 5/16/2019 8:17 PM, Thomas Gleixner wrote:

Arend,

On Thu, 16 May 2019, Arend Van Spriel wrote:


Hi Kalle, Thomas,

I added SPDX tags in brcm80211 driver sources. Although it is a no-brainer I
decided to run checkpatch for the changes and quirky stuff started to happen.
For all files I added:

// SPDX-License-Identifier

but checkpatch started complaining I should use /* ... */ instead of //.

WARNING: Improper SPDX comment style for
'drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h', please use
'/*' instead
#29: FILE: drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h:1:
+// SPDX-License-Identifier: ISC

So I edited all patches and ran again. And again it started complaining.

WARNING: Improper SPDX comment style for
'drivers/net/wireless/broadcom/brcm80211/brcmsmac/aiutils.c', please use '//'
instead

So now I am in a bonkers state. It seems for header files we want /* */ and
for c files we want //. For real?


See Documentation. This is historical because the older binutils choked on
'//' comments. Not longer an issue as we moved to more modern binutils by
now. So we can fixup the documentation and allow // style for headers as well.


Right. I was pointed at the documentation already. I will ignore the 
warning for my series and stick with // style for both.


Thanks,
Arend

Re: [PATCH 3/7] brcmsmac: switch source files to using SPDX license identifier

[Arend Van Spriel]

On 5/16/2019 7:31 PM, Greg Kroah-Hartman wrote:

On Thu, May 16, 2019 at 02:04:07PM +0200, Arend van Spriel wrote:

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.

Cc: Thomas Gleixner 
Cc: Greg Kroah-Hartman 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
Hi Thomas, Greg,

The file drivers/net/wireless/broadcom/brcm80211/brcmsmac/led.c
did not have license information nor copyright notice and as such
it got included in commit b24413180f56 ("License cleanup: add SPDX
GPL-2.0 license identifier to files with no license"). I added you
guys as I propose to align this source file with the rest of
the driver sources and change it to ISC license and add the missing
copyright notice while at it (not sure if that warrants a separate
patch).


A separate patch would be good, to make it explicit that you are
changing the license of the file.


Ok.


And ISC, ick, why...  :)


Because the license text in the other driver source files is a 1:1 match 
with the ISC license. Another option could be MIT license which is in 
the preferred folder. Will have to consult our legal department about it 
though.


Thanks,
Arend

Re: SPDX identifier

[Arend Van Spriel]

On May 16, 2019 4:17:55 PM James Hughes  wrote:

On Thu, 16 May 2019 at 12:36, Arend Van Spriel
 wrote:


Hi Kalle, Thomas,

I added SPDX tags in brcm80211 driver sources. Although it is a
no-brainer I decided to run checkpatch for the changes and quirky stuff
started to happen. For all files I added:

// SPDX-License-Identifier

but checkpatch started complaining I should use /* ... */ instead of //.

WARNING: Improper SPDX comment style for
'drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h', please
use '/*' instead
#29: FILE: drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h:1:
+// SPDX-License-Identifier: ISC

So I edited all patches and ran again. And again it started complaining.

WARNING: Improper SPDX comment style for
'drivers/net/wireless/broadcom/brcm80211/brcmsmac/aiutils.c', please use
'//' instead

So now I am in a bonkers state. It seems for header files we want /* */
and for c files we want //. For real?


https://www.kernel.org/doc/html/v4.17/process/license-rules.html
explains why the comment style differs between .c and .h


Thanks, James

It explains why header files can not use //. Just wish the same comment 
style was chosen for the c files if only just to be consistent.


Regards,
Arend

[PATCH 1/7] brcm80211: switch common header files to using SPDX license identifier

[Arend van Spriel]

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h   | 13 +
 drivers/net/wireless/broadcom/brcm80211/include/brcmu_d11.h | 13 +
 .../net/wireless/broadcom/brcm80211/include/brcmu_utils.h   | 13 +
 .../net/wireless/broadcom/brcm80211/include/brcmu_wifi.h| 13 +
 .../net/wireless/broadcom/brcm80211/include/chipcommon.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/include/defs.h  | 13 +
 drivers/net/wireless/broadcom/brcm80211/include/soc.h   | 13 +
 7 files changed, 7 insertions(+), 84 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h 
b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 839980d..d1037b6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2010 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 #ifndef_BRCM_HW_IDS_H_
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_d11.h 
b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_d11.h
index 8b8b2ec..f634402 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_d11.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_d11.h
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2010 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 #ifndef_BRCMU_D11_H_
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_utils.h 
b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_utils.h
index 4196952..9465323 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_utils.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_utils.h
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2010 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 #ifndef_BRCMU_UTILS_H_
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h 
b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
index dddebaa..7b31c21 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_wifi.h
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2010 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that 

[PATCH 6/7] brcmfmac: use separate Kconfig file for brcmfmac

[Arend van Spriel]

The number of Kconfig items related to brcmfmac is considerable and
upcoming changes will add some more so it seems good idea to have
a separate Kconfig file for brcmfmac.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/Kconfig| 50 +-
 .../wireless/broadcom/brcm80211/brcmfmac/Kconfig   | 50 ++
 2 files changed, 51 insertions(+), 49 deletions(-)
 create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig

diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig 
b/drivers/net/wireless/broadcom/brcm80211/Kconfig
index 6acba67..580f666 100644
--- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
+++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
@@ -17,55 +17,7 @@ config BRCMSMAC
  be available if you select BCMA_DRIVER_GPIO. If you choose to build a
  module, the driver will be called brcmsmac.ko.
 
-config BRCMFMAC
-   tristate "Broadcom FullMAC WLAN driver"
-   depends on CFG80211
-   select BRCMUTIL
-   ---help---
- This module adds support for wireless adapters based on Broadcom
- FullMAC chipsets. It has to work with at least one of the bus
- interface support. If you choose to build a module, it'll be called
- brcmfmac.ko.
-
-config BRCMFMAC_PROTO_BCDC
-   bool
-
-config BRCMFMAC_PROTO_MSGBUF
-   bool
-
-config BRCMFMAC_SDIO
-   bool "SDIO bus interface support for FullMAC driver"
-   depends on (MMC = y || MMC = BRCMFMAC)
-   depends on BRCMFMAC
-   select BRCMFMAC_PROTO_BCDC
-   select FW_LOADER
-   default y
-   ---help---
- This option enables the SDIO bus interface support for Broadcom
- IEEE802.11n embedded FullMAC WLAN driver. Say Y if you want to
- use the driver for a SDIO wireless card.
-
-config BRCMFMAC_USB
-   bool "USB bus interface support for FullMAC driver"
-   depends on (USB = y || USB = BRCMFMAC)
-   depends on BRCMFMAC
-   select BRCMFMAC_PROTO_BCDC
-   select FW_LOADER
-   ---help---
- This option enables the USB bus interface support for Broadcom
- IEEE802.11n embedded FullMAC WLAN driver. Say Y if you want to
- use the driver for an USB wireless card.
-
-config BRCMFMAC_PCIE
-   bool "PCIE bus interface support for FullMAC driver"
-   depends on BRCMFMAC
-   depends on PCI
-   select BRCMFMAC_PROTO_MSGBUF
-   select FW_LOADER
-   ---help---
- This option enables the PCIE bus interface support for Broadcom
- IEEE802.11ac embedded FullMAC WLAN driver. Say Y if you want to
- use the driver for an PCIE wireless card.
+source "drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig"
 
 config BRCM_TRACING
bool "Broadcom device tracing"
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig
new file mode 100644
index 000..32794c1
--- /dev/null
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig
@@ -0,0 +1,50 @@
+config BRCMFMAC
+   tristate "Broadcom FullMAC WLAN driver"
+   depends on CFG80211
+   select BRCMUTIL
+   help
+ This module adds support for wireless adapters based on Broadcom
+ FullMAC chipsets. It has to work with at least one of the bus
+ interface support. If you choose to build a module, it'll be called
+ brcmfmac.ko.
+
+config BRCMFMAC_PROTO_BCDC
+   bool
+
+config BRCMFMAC_PROTO_MSGBUF
+   bool
+
+config BRCMFMAC_SDIO
+   bool "SDIO bus interface support for FullMAC driver"
+   depends on (MMC = y || MMC = BRCMFMAC)
+   depends on BRCMFMAC
+   select BRCMFMAC_PROTO_BCDC
+   select FW_LOADER
+   default y
+   help
+ This option enables the SDIO bus interface support for Broadcom
+ IEEE802.11n embedded FullMAC WLAN driver. Say Y if you want to
+ use the driver for a SDIO wireless card.
+
+config BRCMFMAC_USB
+   bool "USB bus interface support for FullMAC driver"
+   depends on (USB = y || USB = BRCMFMAC)
+   depends on BRCMFMAC
+   select BRCMFMAC_PROTO_BCDC
+   select FW_LOADER
+   help
+ This option enables the USB bus interface support for Broadcom
+ IEEE802.11n embedded FullMAC WLAN driver. Say Y if you want to
+ use the driver for an USB wireless card.
+
+config BRCMFMAC_PCIE
+   bool "PCIE bus interface support for FullMAC driver"
+   depends on BRCMFMAC
+   depends on PCI
+   select BRCMFMAC_PROTO_MSGBUF
+   select FW_LOADER
+   help
+ This option enables the PCIE bus interface support for Broadcom
+ IEEE802.11ac embedded FullMAC WLAN driver. Say Y if you want to
+ use the driver for an PCIE wireless card.
+
-- 
1.9.1

[PATCH 7/7] brcm80211: select WANT_DEV_COREDUMP conditionally for brcmfmac

[Arend van Spriel]

CONFIG_BRCMDBG selects WANT_DEV_COREDUMP but is only used by
brcmfmac so reflect that in the Kconfig.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig 
b/drivers/net/wireless/broadcom/brcm80211/Kconfig
index 580f666..21dc4ca 100644
--- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
+++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
@@ -33,6 +33,6 @@ config BRCM_TRACING
 config BRCMDBG
bool "Broadcom driver debug functions"
depends on BRCMSMAC || BRCMFMAC
-   select WANT_DEV_COREDUMP
+   select WANT_DEV_COREDUMP if BRCMFMAC
---help---
  Selecting this enables additional code for debug purposes.
-- 
1.9.1

[PATCH 0/7] brcm80211: SPDX tags and Kconfig cleanup

[Arend van Spriel]

This series consist of:
* adding SPDX identifiers.
* clean Kconfig files.

The patches apply to the master branch of the wireless-drivers-next
repository.

Arend van Spriel (7):
  brcm80211: switch common header files to using SPDX license identifier
  brcmutil: switch source files to using SPDX license identifier
  brcmsmac: switch source files to using SPDX license identifier
  brcmsmac: switch phy source files to using SPDX license identifier
  brcmfmac: switch source files to using SPDX license identifier
  brcmfmac: use separate Kconfig file for brcmfmac
  brcm80211: select WANT_DEV_COREDUMP conditionally for brcmfmac

 drivers/net/wireless/broadcom/brcm80211/Kconfig| 52 +-
 drivers/net/wireless/broadcom/brcm80211/Makefile   | 14 +-
 .../wireless/broadcom/brcm80211/brcmfmac/Kconfig   | 50 +
 .../wireless/broadcom/brcm80211/brcmfmac/Makefile  | 14 +-
 .../wireless/broadcom/brcm80211/brcmfmac/bcdc.c| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/bcdc.h| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/btcoex.c  | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/btcoex.h  | 13 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 13 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 13 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.h | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/chip.c| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/chip.h| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/common.h  | 16 ++-
 .../broadcom/brcm80211/brcmfmac/commonring.c   | 16 ++-
 .../broadcom/brcm80211/brcmfmac/commonring.h   | 16 ++-
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/core.h| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/debug.c   | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/debug.h   | 13 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/dmi.c | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/feature.h | 13 +-
 .../broadcom/brcm80211/brcmfmac/firmware.c | 13 +-
 .../broadcom/brcm80211/brcmfmac/firmware.h | 13 +-
 .../broadcom/brcm80211/brcmfmac/flowring.c | 16 ++-
 .../broadcom/brcm80211/brcmfmac/flowring.h | 16 ++-
 .../wireless/broadcom/brcm80211/brcmfmac/fweh.c| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fweh.h| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fwil.c| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fwil.h| 13 +-
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   | 13 +-
 .../broadcom/brcm80211/brcmfmac/fwsignal.c | 13 +-
 .../broadcom/brcm80211/brcmfmac/fwsignal.h | 14 +-
 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c  | 16 ++-
 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h  | 16 ++-
 .../net/wireless/broadcom/brcm80211/brcmfmac/of.c  | 13 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/of.h  | 13 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 13 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.h | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c| 16 ++-
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.h| 16 ++-
 .../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 13 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/pno.h | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/proto.c   | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/proto.h   | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.h| 13 +-
 .../broadcom/brcm80211/brcmfmac/tracepoint.c   | 13 +-
 .../broadcom/brcm80211/brcmfmac/tracepoint.h   | 13 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 13 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/usb.h | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/vendor.c  | 13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/vendor.h  | 13 +-
 .../wireless/broadcom/brcm80211/brcmsmac/Makefile  | 15 +--
 .../wireless/broadcom/brcm80211/brcmsmac/aiutils.c | 13 +-
 .../wireless/broadcom/brcm80211/brcmsmac/aiutils.h | 13 +-
 .../wireless/broadcom/brcm80211/brcmsmac/ampdu.c   | 13 +-
 .../wireless/broadcom/brcm80211/brcmsmac/ampdu.h   | 13 +-
 .../wireless/broadcom/brcm80211/brcmsmac/antsel.c  | 13 +-
 .../wireless/broadcom/brcm80211/brcmsmac/antsel.h  | 13 +-
 .../brcm80211/brcmsmac/brcms_trace_brcmsmac.h  | 13 +-
 .../brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h  | 13 +-
 .../brcm80211/brcmsmac/brcms_trace_brcmsmac_tx.h   | 13 +-
 .../brcm80211/brcmsmac/brcms_trace_events.c| 13 +-
 .../brcm80211/brcmsmac

[PATCH 5/7] brcmfmac: switch source files to using SPDX license identifier

[Arend van Spriel]

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/Makefile | 14 ++
 .../net/wireless/broadcom/brcm80211/brcmfmac/Makefile| 14 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.h  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c| 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/btcoex.c| 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/btcoex.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h   | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/common.c| 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/common.h| 16 +++-
 .../wireless/broadcom/brcm80211/brcmfmac/commonring.c| 16 +++-
 .../wireless/broadcom/brcm80211/brcmfmac/commonring.h| 16 +++-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c   | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/feature.c   | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/feature.h   | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.h  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/flowring.c  | 16 +++-
 .../net/wireless/broadcom/brcm80211/brcmfmac/flowring.h  | 16 +++-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h  | 13 +
 .../wireless/broadcom/brcm80211/brcmfmac/fwil_types.h| 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h  | 14 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c| 16 +++-
 .../net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h| 16 +++-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.h   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c  | 16 +++-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.h  | 16 +++-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.h   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.c | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/proto.h | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h  | 13 +
 .../wireless/broadcom/brcm80211/brcmfmac/tracepoint.c| 13 +
 .../wireless/broadcom/brcm80211/brcmfmac/tracepoint.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h   | 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/vendor.c| 13 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/vendor.h| 13 +
 54 files changed, 74 insertions(+), 658 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/Makefile 
b/drivers/net/wireless/broadcom/brcm80211/Makefile
index b987920..88115d0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/Makefile
+++ b/drivers/net/wireless/broadcom/brcm80211/Makefile
@@ -1,19 +1,9 @@
+# SPDX-License-Identifier: ISC
 #
-# Makefile fragment for Broadcom 802.11n Networking Device Driver
+# Makefile fragment for Broadcom 802.11 Networking Device Driver
 #
 # Copyright (c) 2010 Broadcom Corporation

[PATCH 2/7] brcmutil: switch source files to using SPDX license identifier

[Arend van Spriel]

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c  | 13 +
 3 files changed, 3 insertions(+), 36 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile 
b/drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile
index bb02c62..7a82d61 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile
@@ -1,20 +1,9 @@
+# SPDX-License-Identifier: ISC
 #
 # Makefile fragment for Broadcom 802.11n Networking Device Driver Utilities
 #
 # Copyright (c) 2011 Broadcom Corporation
 #
-# Permission to use, copy, modify, and/or distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
-# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
-# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
-# SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
-# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
-# OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
-# CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
 ccflags-y := -I $(srctree)/$(src)/../include
 
 obj-$(CONFIG_BRCMUTIL) += brcmutil.o
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
index 8ac3482..1e2b1e4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2013 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 /*channel spec common functions*/
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c
index 0543607..4c84c300 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2010 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
1.9.1

[PATCH 3/7] brcmsmac: switch source files to using SPDX license identifier

[Arend van Spriel]

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.

Cc: Thomas Gleixner 
Cc: Greg Kroah-Hartman 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
Hi Thomas, Greg,

The file drivers/net/wireless/broadcom/brcm80211/brcmsmac/led.c
did not have license information nor copyright notice and as such
it got included in commit b24413180f56 ("License cleanup: add SPDX
GPL-2.0 license identifier to files with no license"). I added you
guys as I propose to align this source file with the rest of
the driver sources and change it to ISC license and add the missing
copyright notice while at it (not sure if that warrants a separate
patch).

Regards,
Arend
---
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 15 ++-
 .../net/wireless/broadcom/brcm80211/brcmsmac/aiutils.c| 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/aiutils.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/ampdu.c  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/ampdu.h  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/antsel.c | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/antsel.h | 13 +
 .../broadcom/brcm80211/brcmsmac/brcms_trace_brcmsmac.h| 13 +
 .../brcm80211/brcmsmac/brcms_trace_brcmsmac_msg.h | 13 +
 .../broadcom/brcm80211/brcmsmac/brcms_trace_brcmsmac_tx.h | 13 +
 .../broadcom/brcm80211/brcmsmac/brcms_trace_events.c  | 13 +
 .../broadcom/brcm80211/brcmsmac/brcms_trace_events.h  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/channel.c| 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/channel.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/debug.c  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/debug.h  | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/led.c|  5 -
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/led.h| 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c| 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/mac80211_if.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.h   | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c   | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.h   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/pmu.c| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/pmu.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/pub.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/rate.c   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/rate.h   | 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/scb.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.h| 13 +
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/types.h  | 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/ucode_loader.c   | 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/ucode_loader.h   | 13 +
 36 files changed, 40 insertions(+), 422 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile
index 482d773..a55d02c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile
@@ -1,20 +1,9 @@
+# SPDX-License-Identifier: ISC
 #
-# Makefile fragment for Broadcom 802.11n Networking Device Driver
+# Makefile fragment for Broadcom 802.11 Networking Device Driver
 #
 # Copyright (c) 2010 Broadcom Corporation
 #
-# Permission to use, copy, modify, and/or distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
-# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
-# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
-# SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
-# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
-# OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
-# CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
 ccflags-y := \
-I $(srctree)/$(src) \
   

[PATCH 4/7] brcmsmac: switch phy source files to using SPDX license identifier

[Arend van Spriel]

With ISC license text in place under the LICENSES folder switch
to using the SPDX license identifier to refer to the ISC license.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_hal.h  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.h  | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c| 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c| 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.h| 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/phy/phy_radio.h| 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phyreg_n.h | 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c   | 13 +
 .../wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.h   | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 13 +
 .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_n.h | 13 +
 14 files changed, 14 insertions(+), 168 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
index 35e3b10..2441714 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2010 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 #include 
 #include 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_hal.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_hal.h
index 4d3734f..2e6a3d4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_hal.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_hal.h
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2010 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 /*
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h
index e9e8337..8668fa5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_int.h
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: ISC
 /*
  * Copyright (c) 2010 Broadcom Corporation
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
- * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 #ifndef _BRCM_PHY_INT_H_
dif

SPDX identifier

[Arend Van Spriel]

Hi Kalle, Thomas,

I added SPDX tags in brcm80211 driver sources. Although it is a 
no-brainer I decided to run checkpatch for the changes and quirky stuff 
started to happen. For all files I added:


// SPDX-License-Identifier

but checkpatch started complaining I should use /* ... */ instead of //.

WARNING: Improper SPDX comment style for 
'drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h', please 
use '/*' instead

#29: FILE: drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h:1:
+// SPDX-License-Identifier: ISC

So I edited all patches and ran again. And again it started complaining.

WARNING: Improper SPDX comment style for 
'drivers/net/wireless/broadcom/brcm80211/brcmsmac/aiutils.c', please use 
'//' instead


So now I am in a bonkers state. It seems for header files we want /* */ 
and for c files we want //. For real?


This is on wireless-drivers-next so maybe it is already fixed, but I 
think this should be fixed.


Regards,
Arend

Re: [PATCH 2/6] brcmfmac: send port authorized event for 802.1X 4-way handshake offload

[Arend Van Spriel]

+ Jouni

On 5/9/2019 10:58 AM, Stanley Hsu wrote:

On Mon, Jan 07, 2019 at 10:44:01AM +0100, Arend Van Spriel wrote:

On 1/4/2019 7:11 AM, Chi-Hsien Lin wrote:

From: Chung-Hsien Hsu 

With 4-way handshake offload for 802.1X authentication, a port
authorized event should be sent to user space after the completion of
4-way handshake. It is used to indicate that a connection is authorized
and 802.1X authentication is no longer required.


It had been a while since I had looked at our offload code
(basically since the initial implementation for the nl80211 work) so
I was unsure why this would be needed.

So initially we added a PORT_AUTHORIZED *attribute* in the nl80211
api and later on the PORT_AUTHORIZED *event* was introduced and
4-way hs offload support in wpa_supplicant is ignoring the
*attribute* and only handling the *event*. I think this information
is important enough to add to this commit message with a reference
to commit 503c1fb98ba3 ("cfg80211/nl80211: add a port authorized
event") which "broke" the functionality in brcmfmac.


Thanks a lot for the feedback.
After looking further, it is observed that the connection state will be
set to WPA_COMPLETED in wpa_supplicant after it sets PMK to the driver.
So no need to have this change. Let's drop it form the series.


In my opinion wpa_supplicant does set WPA_COMPLETED too early. If we 
were to use eapol-over-nl80211 and set the netdev carrier when the 
connection is authorized it would be kinda ok and we would not need the 
event. Added Jouni to chime in on this.


Regards,
Arend