[PATCH] ath10k: Replace bit shifts with the BIT() macro for rx desc bits

[Govind Singh]

Use the BIT() macro from 'linux/bitops.h' to define the rx desc
bit flags to have consistency with new definitions.

Signed-off-by: Govind Singh 
---
 drivers/net/wireless/ath/ath10k/rx_desc.h | 134 +++---
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h 
b/drivers/net/wireless/ath/ath10k/rx_desc.h
index 545deb6d7af1..b3d7c6e7ac90 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -19,38 +19,38 @@
 #define _RX_DESC_H_
 
 enum rx_attention_flags {
-   RX_ATTENTION_FLAGS_FIRST_MPDU  = 1 << 0,
-   RX_ATTENTION_FLAGS_LAST_MPDU   = 1 << 1,
-   RX_ATTENTION_FLAGS_MCAST_BCAST = 1 << 2,
-   RX_ATTENTION_FLAGS_PEER_IDX_INVALID= 1 << 3,
-   RX_ATTENTION_FLAGS_PEER_IDX_TIMEOUT= 1 << 4,
-   RX_ATTENTION_FLAGS_POWER_MGMT  = 1 << 5,
-   RX_ATTENTION_FLAGS_NON_QOS = 1 << 6,
-   RX_ATTENTION_FLAGS_NULL_DATA   = 1 << 7,
-   RX_ATTENTION_FLAGS_MGMT_TYPE   = 1 << 8,
-   RX_ATTENTION_FLAGS_CTRL_TYPE   = 1 << 9,
-   RX_ATTENTION_FLAGS_MORE_DATA   = 1 << 10,
-   RX_ATTENTION_FLAGS_EOSP= 1 << 11,
-   RX_ATTENTION_FLAGS_U_APSD_TRIGGER  = 1 << 12,
-   RX_ATTENTION_FLAGS_FRAGMENT= 1 << 13,
-   RX_ATTENTION_FLAGS_ORDER   = 1 << 14,
-   RX_ATTENTION_FLAGS_CLASSIFICATION  = 1 << 15,
-   RX_ATTENTION_FLAGS_OVERFLOW_ERR= 1 << 16,
-   RX_ATTENTION_FLAGS_MSDU_LENGTH_ERR = 1 << 17,
-   RX_ATTENTION_FLAGS_TCP_UDP_CHKSUM_FAIL = 1 << 18,
-   RX_ATTENTION_FLAGS_IP_CHKSUM_FAIL  = 1 << 19,
-   RX_ATTENTION_FLAGS_SA_IDX_INVALID  = 1 << 20,
-   RX_ATTENTION_FLAGS_DA_IDX_INVALID  = 1 << 21,
-   RX_ATTENTION_FLAGS_SA_IDX_TIMEOUT  = 1 << 22,
-   RX_ATTENTION_FLAGS_DA_IDX_TIMEOUT  = 1 << 23,
-   RX_ATTENTION_FLAGS_ENCRYPT_REQUIRED= 1 << 24,
-   RX_ATTENTION_FLAGS_DIRECTED= 1 << 25,
-   RX_ATTENTION_FLAGS_BUFFER_FRAGMENT = 1 << 26,
-   RX_ATTENTION_FLAGS_MPDU_LENGTH_ERR = 1 << 27,
-   RX_ATTENTION_FLAGS_TKIP_MIC_ERR= 1 << 28,
-   RX_ATTENTION_FLAGS_DECRYPT_ERR = 1 << 29,
-   RX_ATTENTION_FLAGS_FCS_ERR = 1 << 30,
-   RX_ATTENTION_FLAGS_MSDU_DONE   = 1 << 31,
+   RX_ATTENTION_FLAGS_FIRST_MPDU  = BIT(0),
+   RX_ATTENTION_FLAGS_LAST_MPDU   = BIT(1),
+   RX_ATTENTION_FLAGS_MCAST_BCAST = BIT(2),
+   RX_ATTENTION_FLAGS_PEER_IDX_INVALID= BIT(3),
+   RX_ATTENTION_FLAGS_PEER_IDX_TIMEOUT= BIT(4),
+   RX_ATTENTION_FLAGS_POWER_MGMT  = BIT(5),
+   RX_ATTENTION_FLAGS_NON_QOS = BIT(6),
+   RX_ATTENTION_FLAGS_NULL_DATA   = BIT(7),
+   RX_ATTENTION_FLAGS_MGMT_TYPE   = BIT(8),
+   RX_ATTENTION_FLAGS_CTRL_TYPE   = BIT(9),
+   RX_ATTENTION_FLAGS_MORE_DATA   = BIT(10),
+   RX_ATTENTION_FLAGS_EOSP= BIT(11),
+   RX_ATTENTION_FLAGS_U_APSD_TRIGGER  = BIT(12),
+   RX_ATTENTION_FLAGS_FRAGMENT= BIT(13),
+   RX_ATTENTION_FLAGS_ORDER   = BIT(14),
+   RX_ATTENTION_FLAGS_CLASSIFICATION  = BIT(15),
+   RX_ATTENTION_FLAGS_OVERFLOW_ERR= BIT(16),
+   RX_ATTENTION_FLAGS_MSDU_LENGTH_ERR = BIT(17),
+   RX_ATTENTION_FLAGS_TCP_UDP_CHKSUM_FAIL = BIT(18),
+   RX_ATTENTION_FLAGS_IP_CHKSUM_FAIL  = BIT(19),
+   RX_ATTENTION_FLAGS_SA_IDX_INVALID  = BIT(20),
+   RX_ATTENTION_FLAGS_DA_IDX_INVALID  = BIT(21),
+   RX_ATTENTION_FLAGS_SA_IDX_TIMEOUT  = BIT(22),
+   RX_ATTENTION_FLAGS_DA_IDX_TIMEOUT  = BIT(23),
+   RX_ATTENTION_FLAGS_ENCRYPT_REQUIRED= BIT(24),
+   RX_ATTENTION_FLAGS_DIRECTED= BIT(25),
+   RX_ATTENTION_FLAGS_BUFFER_FRAGMENT = BIT(26),
+   RX_ATTENTION_FLAGS_MPDU_LENGTH_ERR = BIT(27),
+   RX_ATTENTION_FLAGS_TKIP_MIC_ERR= BIT(28),
+   RX_ATTENTION_FLAGS_DECRYPT_ERR = BIT(29),
+   RX_ATTENTION_FLAGS_FCS_ERR = BIT(30),
+   RX_ATTENTION_FLAGS_MSDU_DONE   = BIT(31),
 };
 
 struct rx_attention {
@@ -254,15 +254,15 @@ enum htt_rx_mpdu_encrypt_type {
 #define RX_MPDU_START_INFO0_SEQ_NUM_LSB   16
 #define RX_MPDU_START_INFO0_ENCRYPT_TYPE_MASK 0xf000
 #define RX_MPDU_START_INFO0_ENCRYPT_TYPE_LSB  28
-#define RX_MPDU_START_INFO0_FROM_DS   (1 << 11)
-#define RX_MPDU_START_INFO0_TO_DS (1 << 12)
-#define RX_MPDU_START_INFO0_ENCRYPTED (1 << 13)
-#define RX_MPDU_START_INFO0_RETRY (1 << 14)
-#define RX_MPDU_START_INFO0_TXBF_H_INFO   (1 << 15)
+#define RX_MPDU_START_INFO0_FROM_DS   BIT(11)
+#define RX_MPDU_START_INFO0_TO_DS BIT(12)
+#define RX_MPDU_START_INFO0_ENCRYPTED BIT(13)
+#define 

Re: [PATCH v3 00/12] *** Add support for wifi QMI client driver ***

[Govind Singh]

On 2018-05-08 23:07, Bjorn Andersson wrote:

On Sun 25 Mar 22:37 PDT 2018, Govind Singh wrote:


Add QMI client driver for Q6 integrated WLAN connectivity subsystem.
This module is responsible for communicating WLAN control messages to 
FW

over QMI interface.

“QUALCOMM Messaging Interface”(QMI) provides the control interface 
between
components running b/w remote processors with underlying transport 
layer
based on integrated chipset(shared memory) or discrete 
chipset(PCI/USB/SDIO/UART).


QMI client driver implementation is based on qmi frmework 
https://lwn.net/Articles/729924/.


Below is the sequence of qmi handshake.

   QMI CLIENT(APPS) QMI 
SERVER(FW in Q6)


 <--wlan service discoverd

   -connect to wlam qmi service->

   wlan info request->

   

 

 



 

  < QMI FW ready indication---


Does the responsibility of the driver ends here? I mean is this a 
driver

for setting up the firmware and then there's something else doing the
actual wifi operation, or does it simply hand over execution to the
common ath10k logic at this point?



From wlan qmi client point of view once wlan qmi service is discovered, 
it connects to the service and
does the above handshakes and later it handover the execution to common 
ath10k logic.

These handshakes will be done as part of pd restart as well.



Govind Singh (12):
  ath10k: Add qmi service for wlan qmi client
  dt: bindings: add bindings for ath10k qmi client
  ath10k: Add WCN3990 QMI client driver
  ath10k: add support to start and stop qmi service
  ath10k: Add support of QMI indication message
  firmware: qcom: scm: Add WLAN VMID for Qualcomm SCM interface
  ath10k: Add MSA handshake QMI mgs support
  ath10k: Add QMI CAP request support
  ath10k: Add QMI HOST CAP request support
  ath10k: add bdf/cal indication support
  ath10k: Add wlan mode on/off qmi message
  ath10k: Add qmi wlan enable/disable support for WCN3990


I'm missing this last patch in my mailbox, and it would be nice if all
the patches where in-reply-to the cover letter, to make them easier to
find.

Regards,
Bjorn


Sure, I will take care this while submitting next version of this patch 
series.


BR,
Govind

Re: [PATCH 06/12] firmware: qcom: scm: Add WLAN VMID for Qualcomm SCM interface

[Govind Singh]

On 2018-05-08 02:12, Bjorn Andersson wrote:

On Sun 25 Mar 22:40 PDT 2018, Govind Singh wrote:


Add WLAN related VMID's to support wlan driver to set up
the remote's permissions call via TrustZone.

Signed-off-by: Govind Singh 


Please use ./scripts/get_maintainer.pl for each patch to get a hint
about whom to send your patches to.

While I think it's okay that Kalle picks it through his tree Andy 
should

give his ack first.


Acked-by: Bjorn Andersson 

Regards,
Bjorn



Thanks Bjorn for the review.
I will take care this point while sending the next version of the qmi 
patch set.



---
 include/linux/qcom_scm.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index b401b96..da63d84 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -1,4 +1,4 @@
-/* Copyright (c) 2010-2015, The Linux Foundation. All rights 
reserved.
+/* Copyright (c) 2010-2015, 2018, The Linux Foundation. All rights 
reserved.

  * Copyright (C) 2015 Linaro Ltd.
  *
  * This program is free software; you can redistribute it and/or 
modify

@@ -33,6 +33,8 @@ struct qcom_scm_vmperm {

 #define QCOM_SCM_VMID_HLOS   0x3
 #define QCOM_SCM_VMID_MSS_MSA0xF
+#define QCOM_SCM_VMID_WLAN   0x18
+#define QCOM_SCM_VMID_WLAN_CE0x19
 #define QCOM_SCM_PERM_READ   0x4
 #define QCOM_SCM_PERM_WRITE  0x2
 #define QCOM_SCM_PERM_EXEC   0x1
--
1.9.1

Re: [PATCH v6 00/13] firmware_loader changes for v4.18

[Kees Cook]

On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote:
> Greg,
>
> Here is what I have queued up for the firmware_loader for v4.18. It
> includes a slew of cleanup work, and the new firmware_request_nowarn()
> which is quiet but enables the sysfs fallback mechanism. I've gone ahead
> and also queued up a few minor fixes for the firmware loader documentation
> which have come up recently. These changes are available on my git tree
> both based on linux-next [0] and Linus' latest tree [1]. Folks working
> on new developments for the firmware loader can use my linux-next
> branch 20180508-firmware_loader_for-v4.18-try2 for now.
>
> 0-day sends its blessings.
>
> The patches from Mimi's series still require a bit more discussion and
> review. The discussion over the EFI firmware fallback mechanism is still
> ongoing.
>
> As for the rename that you wanted, perhaps we can do this late in the
> merge window considering we're at rc4 now. I can prep something up for
> that later.
>
> Question, and specially rants are warmly welcomed.

I sent some typo catches, but with those fixed, please consider the
whole series:

Reviewed-by: Kees Cook <keesc...@chromium.org>

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v6 05/13] firmware_loader: enhance Kconfig documentation over FW_LOADER

[Kees Cook]

On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez  wrote:
> If you try to read FW_LOADER today it speaks of old riddles and
> unless you have been following development closely you will loose

Typo: lose

> track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD
> is a bit fuzzy and how it fits into this big picture.
>
> Give the FW_LOADER kconfig documentation some love with more up to
> date developments and recommendations. While at it, wrap the FW_LOADER
> code into its own menu to compartamentalize and make it clearer which

Typo: compartmentalize

> components really are part of the FW_LOADER. This should also make
> it easier to later move these kconfig entries into the firmware_loader/
> directory later.
>
> This also now recommends using firmwared [0] for folks left needing a uevent
> handler in userspace for the sysfs firmware fallback mechanis given udev's
> uevent firmware mechanism was ripped out a while ago.
>
> [0] https://github.com/teg/firmwared
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  drivers/base/Kconfig | 165 ++-
>  1 file changed, 131 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 29b0eb452b3a..a4fe86caecca 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -70,39 +70,64 @@ config STANDALONE
>   If unsure, say Y.
>
>  config PREVENT_FIRMWARE_BUILD
> -   bool "Prevent firmware from being built"
> +   bool "Disable drivers features which enable custom firmware building"
> default y
> help
> - Say yes to avoid building firmware. Firmware is usually shipped
> - with the driver and only when updating the firmware should a
> - rebuild be made.
> - If unsure, say Y here.
> + Say yes to disable driver features which enable building a custom
> + driver firmwar at kernel build time. These drivers do not use the

Typo: firmware

> + kernel firmware API to load firmware (CONFIG_FW_LOADER), instead 
> they
> + use their own custom loading mechanism. The required firmware is
> + usually shipped with the driver, building the driver firmware
> + should only be needed if you have an updated firmware source.
> +
> + Firmware should not be being built as part of kernel, these days
> + you should always prevent this and say Y here. There are only two
> + old drivers which enable building of its firmware at kernel build
> + time:
> +
> +   o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE
> +   o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE
> +
> +menu "Firmware loader"
>
>  config FW_LOADER
> -   tristate "Userspace firmware loading support" if EXPERT
> +   tristate "Firmware loading facility" if EXPERT
> default y
> ---help---
> - This option is provided for the case where none of the in-tree 
> modules
> - require userspace firmware loading support, but a module built
> - out-of-tree does.
> + This enables the firmware loading facility in the kernel. The kernel
> + will first look for built-in firmware, if it has any. Next, it will
> + look for the requested firmware in a series of filesystem paths:
> +
> +   o firmware_class path module parameter or kernel boot param
> +   o /lib/firmware/updates/UTS_RELEASE
> +   o /lib/firmware/updates
> +   o /lib/firmware/UTS_RELEASE
> +   o /lib/firmware
> +
> + Enabling this feature only increases your kernel image by about
> + 828 bytes, enable this option unless you are certain you don't
> + need firmware.
> +
> + You typically want this built-in (=y) but you can also enable this
> + as a module, in which case the firmware_class module will be built.
> + You also want to be sure to enable this built-in if you are going to
> + enable built-in firmware (CONFIG_EXTRA_FIRMWARE).
> +
> +if FW_LOADER
>
>  config EXTRA_FIRMWARE
> -   string "External firmware blobs to build into the kernel binary"
> -   depends on FW_LOADER
> +   string "Build these firmware blobs into the kernel binary"

Maybe "Build named firmware blobs ..." "these" took me a while to figure out.

> help
> - Various drivers in the kernel source tree may require firmware,
> - which is generally available in your distribution's linux-firmware
> - package.
> + Device drivers which require firmware can typically deal with
> + having the kernel load firmware from the various supported
> + /lib/firmware/ paths. This option enables you to build into the
> + kernel firmware files. Built-in firmware searches are preceeded

Typo: preceded

> + over firmware lookups using your filesystem over the 

Re: [PATCH] nl80211: Reject disconnect commands except from conn_owner

[Andrew Zaborowski]

Hi,

On 8 May 2018 at 14:19, Johannes Berg  wrote:
> On Tue, 2018-05-08 at 14:18 +0200, Arend van Spriel wrote:
>> On 5/7/2018 9:19 PM, Johannes Berg wrote:
>> > On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:
>> > > On 28 April 2018 at 15:07, Kalle Valo  wrote:
>> > > > Andrew Zaborowski  writes:
>> > > > > Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE,
>> > > > > NL80211_CMD_DEAUTHENTICATE and NL80211_CMD_ASSOCIATE commands
>> > > > > from clients other than the connection owner set in the connect,
>> > > > > authenticate or associate commands, if it was set.
>> > > > >
>> > > > > The main point of this check is to prevent chaos when two processes
>> > > > > try to use nl80211 at the same time, it's not a security measure.
>> > > > > The same thing should possibly be done for JOIN_IBSS/LEAVE_IBSS and
>> > > > > START_AP/STOP_AP.
>> > > >
>> > > > s-o-b missing.
>> > >
>> > > True, thanks.  Also I was going to send this as an RFC.
>> > >
>> >
>> > Looks fine to me, please resend if you want it in :)
>>
>> Do we really want this? Is the referred chaos hypothetical or an actual
>> issue. Nothing stops me from doing an 'ifconfig down' so why should 'iw
>> disconnect' be any different. As far I can tell it does not affect my
>> testing environment, but particularly in such use-cases I can expect
>> issues adopting this change, which is also hypothetical of course ;-)
>
> Yeah, it's a good question. But it might help with inadvertent issues,
> like starting wpa_s which immediately disconnects if it finds something
> connected. If that fails, perhaps you have a better chance of noticing
> the error?

This patch was only motivated by a case of running both iwd and
wpa_supplicant simultaneously by mistake.  They can both handle things
like 'ifconfig down', but when one daemon tries to connect the other
immediately commands a disconnect (makes sense) and it made us think
whether it was more correct if that disconnect command failed.  I'm
not really sure what's right here so I wanted to float this idea.

Best regards

Re: [PATCH v2 1/2] wireless-regdb: Add wmm rule for EEA and EFTA countries

[Seth Forshee]

On Thu, May 03, 2018 at 06:58:22PM +0300, Haim Dreyfuss wrote:
> The ETSI EN 301 893 v211 (2017-05) standard defines a new channel
> access mechanism that all devices (WLAN and LAA) need to comply with.
> In previous versions the device was allowed by ETSI to implement
> 802.11 channel access mechanism based on a set of priority classes
> which are taken from 802.11.
> According to the new standard there might be some exception
> which require the EEA and the EFTA countries, which adhere
> ETSI rules, to follow more restrictive rules.
> In order to comply with the new standard introduced by ETSI, add
> wmmrule global item with the new ETSI channel mechanism rules.
> Also add wmmrule flag to EEA and EFTA countries.
> 
> Signed-off-by: Haim Dreyfuss 

That's looking better. I did some light testing and nothing blew up with
4.15 or 4.17.

Applied both patches, thanks!

Re: [PATCH v6 13/13] Documentation: clarify firmware_class provenance and why we can't rename the module

[Andres Rodriguez]

On 2018-05-08 02:12 PM, Luis R. Rodriguez wrote:

Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.

Signed-off-by: Luis R. Rodriguez 
---
  .../driver-api/firmware/fallback-mechanisms.rst  | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index a39323ef7d29..a8047be4a96e 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device 
hierarchy by
  associating the device used to make the request as the device's parent.
  The sysfs directory's file attributes are defined and controlled through
  the new device's class (firmware_class) and group (fw_dev_attr_groups).
-This is actually where the original firmware_class.c file name comes from,
-as originally the only firmware loading mechanism available was the
-mechanism we now use as a fallback mechanism.
+This is actually where the original firmware_class module name came from,
+given that originally the only firmware loading mechanism available was the
+mechanism we now use as a fallback mechanism, which which registers a


Just a tiny repeated word here, "which which".

-Andres



+struct class firmware_class. Because the attributes exposed are part of the
+module name, the module name firmware_class cannot be renamed in the future, to
+ensure backward compatibilty with old userspace.
  
  To load firmware using the sysfs interface we expose a loading indicator,

  and a file upload firmware into:

[PATCH v6 01/13] firmware: wrap FW_OPT_* into an enum

[Luis R. Rodriguez]

From: Andres Rodriguez 

This should let us associate enum kdoc to these values.
While at it, kdocify the fw_opt.

Signed-off-by: Andres Rodriguez 
Acked-by: Luis R. Rodriguez 
[mcgrof: coding style fixes, merge kdoc with enum move]
Signed-off-by: Luis R. Rodriguez 
---
 drivers/base/firmware_loader/fallback.c | 12 
 drivers/base/firmware_loader/fallback.h |  6 ++--
 drivers/base/firmware_loader/firmware.h | 37 +++--
 drivers/base/firmware_loader/main.c |  6 ++--
 4 files changed, 42 insertions(+), 19 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index 358354148dec..b57a7b3b4122 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -512,7 +512,7 @@ static const struct attribute_group *fw_dev_attr_groups[] = 
{
 
 static struct fw_sysfs *
 fw_create_instance(struct firmware *firmware, const char *fw_name,
-  struct device *device, unsigned int opt_flags)
+  struct device *device, enum fw_opt opt_flags)
 {
struct fw_sysfs *fw_sysfs;
struct device *f_dev;
@@ -545,7 +545,7 @@ fw_create_instance(struct firmware *firmware, const char 
*fw_name,
  * In charge of constructing a sysfs fallback interface for firmware loading.
  **/
 static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
- unsigned int opt_flags, long timeout)
+ enum fw_opt opt_flags, long timeout)
 {
int retval = 0;
struct device *f_dev = _sysfs->dev;
@@ -599,7 +599,7 @@ static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
 
 static int fw_load_from_user_helper(struct firmware *firmware,
const char *name, struct device *device,
-   unsigned int opt_flags)
+   enum fw_opt opt_flags)
 {
struct fw_sysfs *fw_sysfs;
long timeout;
@@ -640,7 +640,7 @@ static int fw_load_from_user_helper(struct firmware 
*firmware,
return ret;
 }
 
-static bool fw_force_sysfs_fallback(unsigned int opt_flags)
+static bool fw_force_sysfs_fallback(enum fw_opt opt_flags)
 {
if (fw_fallback_config.force_sysfs_fallback)
return true;
@@ -649,7 +649,7 @@ static bool fw_force_sysfs_fallback(unsigned int opt_flags)
return true;
 }
 
-static bool fw_run_sysfs_fallback(unsigned int opt_flags)
+static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
 {
if (fw_fallback_config.ignore_sysfs_fallback) {
pr_info_once("Ignoring firmware sysfs fallback due to sysctl 
knob\n");
@@ -664,7 +664,7 @@ static bool fw_run_sysfs_fallback(unsigned int opt_flags)
 
 int fw_sysfs_fallback(struct firmware *fw, const char *name,
  struct device *device,
- unsigned int opt_flags,
+ enum fw_opt opt_flags,
  int ret)
 {
if (!fw_run_sysfs_fallback(opt_flags))
diff --git a/drivers/base/firmware_loader/fallback.h 
b/drivers/base/firmware_loader/fallback.h
index f8255670a663..a3b73a09db6c 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -5,6 +5,8 @@
 #include 
 #include 
 
+#include "firmware.h"
+
 /**
  * struct firmware_fallback_config - firmware fallback configuration settings
  *
@@ -31,7 +33,7 @@ struct firmware_fallback_config {
 #ifdef CONFIG_FW_LOADER_USER_HELPER
 int fw_sysfs_fallback(struct firmware *fw, const char *name,
  struct device *device,
- unsigned int opt_flags,
+ enum fw_opt opt_flags,
  int ret);
 void kill_pending_fw_fallback_reqs(bool only_kill_custom);
 
@@ -43,7 +45,7 @@ void unregister_sysfs_loader(void);
 #else /* CONFIG_FW_LOADER_USER_HELPER */
 static inline int fw_sysfs_fallback(struct firmware *fw, const char *name,
struct device *device,
-   unsigned int opt_flags,
+   enum fw_opt opt_flags,
int ret)
 {
/* Keep carrying over the same error */
diff --git a/drivers/base/firmware_loader/firmware.h 
b/drivers/base/firmware_loader/firmware.h
index 64acbb1a392c..4f433b447367 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -2,6 +2,7 @@
 #ifndef __FIRMWARE_LOADER_H
 #define __FIRMWARE_LOADER_H
 
+#include 
 #include 
 #include 
 #include 
@@ -10,13 +11,33 @@
 
 #include 
 
-/* firmware behavior options */
-#define FW_OPT_UEVENT  (1U << 0)
-#define FW_OPT_NOWAIT  (1U << 1)
-#define FW_OPT_USERHELPER  (1U << 2)
-#define FW_OPT_NO_WARN (1U << 3)
-#define FW_OPT_NOCACHE 

[PATCH v6 04/13] firmware_loader: document firmware_sysfs_fallback()

[Luis R. Rodriguez]

This also sets the expecations for future fallback interfaces, even
if they are not exported.

Signed-off-by: Luis R. Rodriguez 
---
 drivers/base/firmware_loader/fallback.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index 3db9e0f225ac..9169e7b9800c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -662,6 +662,26 @@ static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
return fw_force_sysfs_fallback(opt_flags);
 }
 
+/**
+ * firmware_fallback_sysfs() - use the fallback mechanism to find firmware
+ * @fw: pointer to firmware image
+ * @name: name of firmware file to look for
+ * @device: device for which firmware is being loaded
+ * @opt_flags: options to control firmware loading behaviour
+ * @ret: return value from direct lookup which triggered the fallback mechanism
+ *
+ * This function is called if direct lookup for the firmware failed, it enables
+ * a fallback mechanism through userspace by exposing a sysfs loading
+ * interface. Userspace is in charge of loading the firmware through the syfs
+ * loading interface. This syfs fallback mechanism may be disabled completely
+ * on a system by setting the proc sysctl value ignore_sysfs_fallback to true.
+ * If this false we check if the internal API caller set the @FW_OPT_NOFALLBACK
+ * flag, if so it would also disable the fallback mechanism. A system may want
+ * to enfoce the sysfs fallback mechanism at all times, it can do this by
+ * setting ignore_sysfs_fallback to false and force_sysfs_fallback to true.
+ * Enabling force_sysfs_fallback is functionally equivalent to build a kernel
+ * with CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
+ **/
 int firmware_fallback_sysfs(struct firmware *fw, const char *name,
struct device *device,
enum fw_opt opt_flags,
-- 
2.17.0

[PATCH v6 02/13] firmware: use () to terminate kernel-doc function names

[Luis R. Rodriguez]

From: Andres Rodriguez 

The kernel-doc spec dictates a function name ends in ().

Signed-off-by: Andres Rodriguez 
Acked-by: Randy Dunlap 
Acked-by: Luis R. Rodriguez 
[mcgrof: adjust since the wide API rename is not yet merged]
Signed-off-by: Luis R. Rodriguez 
---
 drivers/base/firmware_loader/fallback.c |  8 
 drivers/base/firmware_loader/main.c | 22 +++---
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index b57a7b3b4122..529f7013616f 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -125,7 +125,7 @@ static ssize_t timeout_show(struct class *class, struct 
class_attribute *attr,
 }
 
 /**
- * firmware_timeout_store - set number of seconds to wait for firmware
+ * firmware_timeout_store() - set number of seconds to wait for firmware
  * @class: device class pointer
  * @attr: device attribute pointer
  * @buf: buffer to scan for timeout value
@@ -239,7 +239,7 @@ static int map_fw_priv_pages(struct fw_priv *fw_priv)
 }
 
 /**
- * firmware_loading_store - set value in the 'loading' control file
+ * firmware_loading_store() - set value in the 'loading' control file
  * @dev: device pointer
  * @attr: device attribute pointer
  * @buf: buffer to scan for loading control value
@@ -431,7 +431,7 @@ static int fw_realloc_pages(struct fw_sysfs *fw_sysfs, int 
min_size)
 }
 
 /**
- * firmware_data_write - write method for firmware
+ * firmware_data_write() - write method for firmware
  * @filp: open sysfs file
  * @kobj: kobject for the device
  * @bin_attr: bin_attr structure
@@ -537,7 +537,7 @@ fw_create_instance(struct firmware *firmware, const char 
*fw_name,
 }
 
 /**
- * fw_load_sysfs_fallback - load a firmware via the sysfs fallback mechanism
+ * fw_load_sysfs_fallback() - load a firmware via the sysfs fallback mechanism
  * @fw_sysfs: firmware sysfs information for the firmware to load
  * @opt_flags: flags of options, FW_OPT_*
  * @timeout: timeout to wait for the load
diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 9919f0e6a7cc..4d11efadb3a4 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -597,7 +597,7 @@ _request_firmware(const struct firmware **firmware_p, const 
char *name,
 }
 
 /**
- * request_firmware: - send firmware request and wait for it
+ * request_firmware() - send firmware request and wait for it
  * @firmware_p: pointer to firmware image
  * @name: name of firmware file
  * @device: device for which firmware is being loaded
@@ -632,7 +632,7 @@ request_firmware(const struct firmware **firmware_p, const 
char *name,
 EXPORT_SYMBOL(request_firmware);
 
 /**
- * request_firmware_direct: - load firmware directly without usermode helper
+ * request_firmware_direct() - load firmware directly without usermode helper
  * @firmware_p: pointer to firmware image
  * @name: name of firmware file
  * @device: device for which firmware is being loaded
@@ -657,7 +657,7 @@ int request_firmware_direct(const struct firmware 
**firmware_p,
 EXPORT_SYMBOL_GPL(request_firmware_direct);
 
 /**
- * firmware_request_cache: - cache firmware for suspend so resume can use it
+ * firmware_request_cache() - cache firmware for suspend so resume can use it
  * @name: name of firmware file
  * @device: device for which firmware should be cached for
  *
@@ -681,7 +681,7 @@ int firmware_request_cache(struct device *device, const 
char *name)
 EXPORT_SYMBOL_GPL(firmware_request_cache);
 
 /**
- * request_firmware_into_buf - load firmware into a previously allocated buffer
+ * request_firmware_into_buf() - load firmware into a previously allocated 
buffer
  * @firmware_p: pointer to firmware image
  * @name: name of firmware file
  * @device: device for which firmware is being loaded and DMA region allocated
@@ -713,7 +713,7 @@ request_firmware_into_buf(const struct firmware 
**firmware_p, const char *name,
 EXPORT_SYMBOL(request_firmware_into_buf);
 
 /**
- * release_firmware: - release the resource associated with a firmware image
+ * release_firmware() - release the resource associated with a firmware image
  * @fw: firmware resource to release
  **/
 void release_firmware(const struct firmware *fw)
@@ -755,7 +755,7 @@ static void request_firmware_work_func(struct work_struct 
*work)
 }
 
 /**
- * request_firmware_nowait - asynchronous version of request_firmware
+ * request_firmware_nowait() - asynchronous version of request_firmware
  * @module: module requesting the firmware
  * @uevent: sends uevent to copy the firmware image if this flag
  * is non-zero else the firmware copy must be done manually.
@@ -824,7 +824,7 @@ EXPORT_SYMBOL(request_firmware_nowait);
 static ASYNC_DOMAIN_EXCLUSIVE(fw_cache_domain);
 
 /**
- * cache_firmware - cache one 

[PATCH v6 05/13] firmware_loader: enhance Kconfig documentation over FW_LOADER

[Luis R. Rodriguez]

If you try to read FW_LOADER today it speaks of old riddles and
unless you have been following development closely you will loose
track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD
is a bit fuzzy and how it fits into this big picture.

Give the FW_LOADER kconfig documentation some love with more up to
date developments and recommendations. While at it, wrap the FW_LOADER
code into its own menu to compartamentalize and make it clearer which
components really are part of the FW_LOADER. This should also make
it easier to later move these kconfig entries into the firmware_loader/
directory later.

This also now recommends using firmwared [0] for folks left needing a uevent
handler in userspace for the sysfs firmware fallback mechanis given udev's
uevent firmware mechanism was ripped out a while ago.

[0] https://github.com/teg/firmwared

Signed-off-by: Luis R. Rodriguez 
---
 drivers/base/Kconfig | 165 ++-
 1 file changed, 131 insertions(+), 34 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 29b0eb452b3a..a4fe86caecca 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -70,39 +70,64 @@ config STANDALONE
  If unsure, say Y.
 
 config PREVENT_FIRMWARE_BUILD
-   bool "Prevent firmware from being built"
+   bool "Disable drivers features which enable custom firmware building"
default y
help
- Say yes to avoid building firmware. Firmware is usually shipped
- with the driver and only when updating the firmware should a
- rebuild be made.
- If unsure, say Y here.
+ Say yes to disable driver features which enable building a custom
+ driver firmwar at kernel build time. These drivers do not use the
+ kernel firmware API to load firmware (CONFIG_FW_LOADER), instead they
+ use their own custom loading mechanism. The required firmware is
+ usually shipped with the driver, building the driver firmware
+ should only be needed if you have an updated firmware source.
+
+ Firmware should not be being built as part of kernel, these days
+ you should always prevent this and say Y here. There are only two
+ old drivers which enable building of its firmware at kernel build
+ time:
+
+   o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE
+   o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE
+
+menu "Firmware loader"
 
 config FW_LOADER
-   tristate "Userspace firmware loading support" if EXPERT
+   tristate "Firmware loading facility" if EXPERT
default y
---help---
- This option is provided for the case where none of the in-tree modules
- require userspace firmware loading support, but a module built
- out-of-tree does.
+ This enables the firmware loading facility in the kernel. The kernel
+ will first look for built-in firmware, if it has any. Next, it will
+ look for the requested firmware in a series of filesystem paths:
+
+   o firmware_class path module parameter or kernel boot param
+   o /lib/firmware/updates/UTS_RELEASE
+   o /lib/firmware/updates
+   o /lib/firmware/UTS_RELEASE
+   o /lib/firmware
+
+ Enabling this feature only increases your kernel image by about
+ 828 bytes, enable this option unless you are certain you don't
+ need firmware.
+
+ You typically want this built-in (=y) but you can also enable this
+ as a module, in which case the firmware_class module will be built.
+ You also want to be sure to enable this built-in if you are going to
+ enable built-in firmware (CONFIG_EXTRA_FIRMWARE).
+
+if FW_LOADER
 
 config EXTRA_FIRMWARE
-   string "External firmware blobs to build into the kernel binary"
-   depends on FW_LOADER
+   string "Build these firmware blobs into the kernel binary"
help
- Various drivers in the kernel source tree may require firmware,
- which is generally available in your distribution's linux-firmware
- package.
+ Device drivers which require firmware can typically deal with
+ having the kernel load firmware from the various supported
+ /lib/firmware/ paths. This option enables you to build into the
+ kernel firmware files. Built-in firmware searches are preceeded
+ over firmware lookups using your filesystem over the supported
+ /lib/firmware paths documented on CONFIG_FW_LOADER.
 
- The linux-firmware package should install firmware into
- /lib/firmware/ on your system, so they can be loaded by userspace
- helpers on request.
-
- This option allows firmware to be built into the kernel for the case
- where the user either cannot or doesn't want to provide it from
- userspace at 

[PATCH v6 03/13] firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()

[Luis R. Rodriguez]

From: Andres Rodriguez 

This is done since this call is now exposed through kernel-doc,
and since this also paves the way for different future types of
fallback mechanims.

Signed-off-by: Andres Rodriguez 
Acked-by: Luis R. Rodriguez 
[mcgrof: small coding style changes]
Signed-off-by: Luis R. Rodriguez 
---
 drivers/base/firmware_loader/fallback.c |  8 
 drivers/base/firmware_loader/fallback.h | 16 
 drivers/base/firmware_loader/firmware.h |  2 +-
 drivers/base/firmware_loader/main.c |  2 +-
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index 529f7013616f..3db9e0f225ac 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -662,10 +662,10 @@ static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
return fw_force_sysfs_fallback(opt_flags);
 }
 
-int fw_sysfs_fallback(struct firmware *fw, const char *name,
- struct device *device,
- enum fw_opt opt_flags,
- int ret)
+int firmware_fallback_sysfs(struct firmware *fw, const char *name,
+   struct device *device,
+   enum fw_opt opt_flags,
+   int ret)
 {
if (!fw_run_sysfs_fallback(opt_flags))
return ret;
diff --git a/drivers/base/firmware_loader/fallback.h 
b/drivers/base/firmware_loader/fallback.h
index a3b73a09db6c..21063503e4ea 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -31,10 +31,10 @@ struct firmware_fallback_config {
 };
 
 #ifdef CONFIG_FW_LOADER_USER_HELPER
-int fw_sysfs_fallback(struct firmware *fw, const char *name,
- struct device *device,
- enum fw_opt opt_flags,
- int ret);
+int firmware_fallback_sysfs(struct firmware *fw, const char *name,
+   struct device *device,
+   enum fw_opt opt_flags,
+   int ret);
 void kill_pending_fw_fallback_reqs(bool only_kill_custom);
 
 void fw_fallback_set_cache_timeout(void);
@@ -43,10 +43,10 @@ void fw_fallback_set_default_timeout(void);
 int register_sysfs_loader(void);
 void unregister_sysfs_loader(void);
 #else /* CONFIG_FW_LOADER_USER_HELPER */
-static inline int fw_sysfs_fallback(struct firmware *fw, const char *name,
-   struct device *device,
-   enum fw_opt opt_flags,
-   int ret)
+static inline int firmware_fallback_sysfs(struct firmware *fw, const char 
*name,
+ struct device *device,
+ enum fw_opt opt_flags,
+ int ret)
 {
/* Keep carrying over the same error */
return ret;
diff --git a/drivers/base/firmware_loader/firmware.h 
b/drivers/base/firmware_loader/firmware.h
index 4f433b447367..4c1395f8e7ed 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -20,7 +20,7 @@
  * @FW_OPT_NOWAIT: Used to describe the firmware request is asynchronous.
  * @FW_OPT_USERHELPER: Enable the fallback mechanism, in case the direct
  * filesystem lookup fails at finding the firmware.  For details refer to
- * fw_sysfs_fallback().
+ * firmware_fallback_sysfs().
  * @FW_OPT_NO_WARN: Quiet, avoid printing warning messages.
  * @FW_OPT_NOCACHE: Disables firmware caching. Firmware caching is used to
  * cache the firmware upon suspend, so that upon resume races against the
diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 4d11efadb3a4..abdc4e4d55f1 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -581,7 +581,7 @@ _request_firmware(const struct firmware **firmware_p, const 
char *name,
dev_warn(device,
 "Direct firmware load for %s failed with error 
%d\n",
 name, ret);
-   ret = fw_sysfs_fallback(fw, name, device, opt_flags, ret);
+   ret = firmware_fallback_sysfs(fw, name, device, opt_flags, ret);
} else
ret = assign_fw(fw, device, opt_flags);
 
-- 
2.17.0

[PATCH v6 06/13] firmware_loader: move kconfig FW_LOADER entries to its own file

[Luis R. Rodriguez]

This will make it easier to track and easier to understand
what components and features are part of the FW_LOADER. There
are some components related to firmware which have *nothing* to
do with the FW_LOADER, souch as PREVENT_FIRMWARE_BUILD.

Signed-off-by: Luis R. Rodriguez 
---
 drivers/base/Kconfig | 155 +--
 drivers/base/firmware_loader/Kconfig | 154 ++
 2 files changed, 155 insertions(+), 154 deletions(-)
 create mode 100644 drivers/base/firmware_loader/Kconfig

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index a4fe86caecca..06d6e27784fa 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -88,160 +88,7 @@ config PREVENT_FIRMWARE_BUILD
o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE
o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE
 
-menu "Firmware loader"
-
-config FW_LOADER
-   tristate "Firmware loading facility" if EXPERT
-   default y
-   ---help---
- This enables the firmware loading facility in the kernel. The kernel
- will first look for built-in firmware, if it has any. Next, it will
- look for the requested firmware in a series of filesystem paths:
-
-   o firmware_class path module parameter or kernel boot param
-   o /lib/firmware/updates/UTS_RELEASE
-   o /lib/firmware/updates
-   o /lib/firmware/UTS_RELEASE
-   o /lib/firmware
-
- Enabling this feature only increases your kernel image by about
- 828 bytes, enable this option unless you are certain you don't
- need firmware.
-
- You typically want this built-in (=y) but you can also enable this
- as a module, in which case the firmware_class module will be built.
- You also want to be sure to enable this built-in if you are going to
- enable built-in firmware (CONFIG_EXTRA_FIRMWARE).
-
-if FW_LOADER
-
-config EXTRA_FIRMWARE
-   string "Build these firmware blobs into the kernel binary"
-   help
- Device drivers which require firmware can typically deal with
- having the kernel load firmware from the various supported
- /lib/firmware/ paths. This option enables you to build into the
- kernel firmware files. Built-in firmware searches are preceeded
- over firmware lookups using your filesystem over the supported
- /lib/firmware paths documented on CONFIG_FW_LOADER.
-
- This may be useful for testing or if the firmware is required early on
- in boot and cannot rely on the firmware being placed in an initrd or
- initramfs.
-
- This option is a string and takes the (space-separated) names of the
- firmware files -- the same names that appear in MODULE_FIRMWARE()
- and request_firmware() in the source. These files should exist under
- the directory specified by the EXTRA_FIRMWARE_DIR option, which is
- /lib/firmware by default.
-
- For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy
- the usb8388.bin file into /lib/firmware, and build the kernel. Then
- any request_firmware("usb8388.bin") will be satisfied internally
- inside the kernel without ever looking at your filesystem at runtime.
-
- WARNING: If you include additional firmware files into your binary
- kernel image that are not available under the terms of the GPL,
- then it may be a violation of the GPL to distribute the resulting
- image since it combines both GPL and non-GPL work. You should
- consult a lawyer of your own before distributing such an image.
-
-config EXTRA_FIRMWARE_DIR
-   string "Firmware blobs root directory"
-   depends on EXTRA_FIRMWARE != ""
-   default "/lib/firmware"
-   help
- This option controls the directory in which the kernel build system
- looks for the firmware files listed in the EXTRA_FIRMWARE option.
-
-config FW_LOADER_USER_HELPER
-   bool "Enable the firmware sysfs fallback mechanism"
-   help
- This option enables a sysfs loading facility to enable firmware
- loading to the kernel through userspace as a fallback mechanism
- if and only if the kernel's direct filesystem lookup for the
- firmware failed using the different /lib/firmware/ paths, or the
- path specified in the firmware_class path module parameter, or the
- firmware_class path kernel boot parameter if the firmware_class is
- built-in. For details on how to work with the sysfs fallback mechanism
- refer to Documentation/driver-api/firmware/fallback-mechanisms.rst.
-
- The direct filesystem lookup for firwmare is always used first now.
-
- If the kernel's direct filesystem lookup for firware fails to find
- the requested firmware a sysfs fallback loading facility is 

[PATCH v6 09/13] ath10k: use firmware_request_nowarn() to load firmware

[Luis R. Rodriguez]

From: Andres Rodriguez 

This reduces the unnecessary spew when trying to load optional firmware:
"Direct firmware load for ... failed with error -2"

Signed-off-by: Andres Rodriguez 
Acked-by: Kalle Valo 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 4cf54a7ef09a..ad4f6e3c0737 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -694,7 +694,7 @@ static const struct firmware *ath10k_fetch_fw_file(struct 
ath10k *ar,
dir = ".";
 
snprintf(filename, sizeof(filename), "%s/%s", dir, file);
-   ret = request_firmware(, filename, ar->dev);
+   ret = firmware_request_nowarn(, filename, ar->dev);
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot fw request '%s': %d\n",
   filename, ret);
 
-- 
2.17.0

[PATCH v6 07/13] firmware_loader: make firmware_fallback_sysfs() print more useful

[Luis R. Rodriguez]

If we resort to using the sysfs fallback mechanism we don't print
the filename. This can be deceiving given we could have a series of
callers intertwined and it'd be unclear exactly for what firmware
this was meant for.

Additionally, although we don't currently use FW_OPT_NO_WARN when
dealing with the fallback mechanism, we will soon, so just respect
its use consistently.

And even if you *don't* want to print always on failure, you may
want to print when debugging so enable dynamic debug print when
FW_OPT_NO_WARN is used.

Signed-off-by: Luis R. Rodriguez 
---
 drivers/base/firmware_loader/fallback.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index 9169e7b9800c..b676a99c469c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -690,6 +690,11 @@ int firmware_fallback_sysfs(struct firmware *fw, const 
char *name,
if (!fw_run_sysfs_fallback(opt_flags))
return ret;
 
-   dev_warn(device, "Falling back to user helper\n");
+   if (!(opt_flags & FW_OPT_NO_WARN))
+   dev_warn(device, "Falling back to syfs fallback for: %s\n",
+name);
+   else
+   dev_dbg(device, "Falling back to sysfs fallback for: %s\n",
+   name);
return fw_load_from_user_helper(fw, name, device, opt_flags);
 }
-- 
2.17.0

[PATCH v6 10/13] ath10k: re-enable the firmware fallback mechanism for testmode

[Luis R. Rodriguez]

From: Andres Rodriguez 

The ath10k testmode uses request_firmware_direct() in order to avoid
producing firmware load warnings. Disabling the fallback mechanism was a
side effect of disabling warnings.

We now have a new API that allows us to avoid warnings while keeping the
fallback mechanism enabled. So use that instead.

Signed-off-by: Andres Rodriguez 
Acked-by: Kalle Valo 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/wireless/ath/ath10k/testmode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/testmode.c 
b/drivers/net/wireless/ath/ath10k/testmode.c
index 568810b41657..c24ee616833c 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -157,7 +157,7 @@ static int ath10k_tm_fetch_utf_firmware_api_1(struct ath10k 
*ar,
 ar->hw_params.fw.dir, ATH10K_FW_UTF_FILE);
 
/* load utf firmware image */
-   ret = request_firmware_direct(_file->firmware, filename, ar->dev);
+   ret = firmware_request_nowarn(_file->firmware, filename, ar->dev);
ath10k_dbg(ar, ATH10K_DBG_TESTMODE, "testmode fw request '%s': %d\n",
   filename, ret);
 
-- 
2.17.0

[PATCH v6 08/13] firmware: add firmware_request_nowarn() - load firmware without warnings

[Luis R. Rodriguez]

From: Andres Rodriguez 

Currently the firmware loader only exposes one silent path for querying
optional firmware, and that is firmware_request_direct(). This function
also disables the sysfs fallback mechanism, which might not always be the
desired behaviour [0].

This patch introduces a variations of request_firmware() that enable the
caller to disable the undesired warning messages but enables the sysfs
fallback mechanism. This is equivalent to adding FW_OPT_NO_WARN to the
old behaviour.

[0]: https://git.kernel.org/linus/c0cc00f250e1

Signed-off-by: Andres Rodriguez 
Acked-by: Luis R. Rodriguez 
[mcgrof: used the old API calls as the full rename is not done yet, and
 add the caller for when FW_LOADER is disabled, enhance documentation ]
Signed-off-by: Luis R. Rodriguez 
---
 .../driver-api/firmware/request_firmware.rst  |  5 
 drivers/base/firmware_loader/main.c   | 27 +++
 include/linux/firmware.h  | 10 +++
 3 files changed, 42 insertions(+)

diff --git a/Documentation/driver-api/firmware/request_firmware.rst 
b/Documentation/driver-api/firmware/request_firmware.rst
index d5ec95a7195b..f62bdcbfed5b 100644
--- a/Documentation/driver-api/firmware/request_firmware.rst
+++ b/Documentation/driver-api/firmware/request_firmware.rst
@@ -20,6 +20,11 @@ request_firmware
 .. kernel-doc:: drivers/base/firmware_loader/main.c
:functions: request_firmware
 
+firmware_request_nowarn
+---
+.. kernel-doc:: drivers/base/firmware_loader/main.c
+   :functions: firmware_request_nowarn
+
 request_firmware_direct
 ---
 .. kernel-doc:: drivers/base/firmware_loader/main.c
diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index abdc4e4d55f1..2be79ee773c0 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -631,6 +631,33 @@ request_firmware(const struct firmware **firmware_p, const 
char *name,
 }
 EXPORT_SYMBOL(request_firmware);
 
+/**
+ * firmware_request_nowarn() - request for an optional fw module
+ * @firmware: pointer to firmware image
+ * @name: name of firmware file
+ * @device: device for which firmware is being loaded
+ *
+ * This function is similar in behaviour to request_firmware(), except
+ * it doesn't produce warning messages when the file is not found.
+ * The sysfs fallback mechanism is enabled if direct filesystem lookup fails,
+ * however, however failures to find the firmware file with it are still
+ * supressed. It is therefore up to the driver to check for the return value
+ * of this call and to decide when to inform the users of errors.
+ **/
+int firmware_request_nowarn(const struct firmware **firmware, const char *name,
+   struct device *device)
+{
+   int ret;
+
+   /* Need to pin this module until return */
+   __module_get(THIS_MODULE);
+   ret = _request_firmware(firmware, name, device, NULL, 0,
+   FW_OPT_UEVENT | FW_OPT_NO_WARN);
+   module_put(THIS_MODULE);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(firmware_request_nowarn);
+
 /**
  * request_firmware_direct() - load firmware directly without usermode helper
  * @firmware_p: pointer to firmware image
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index 41050417cafb..2dd566c91d44 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -42,6 +42,8 @@ struct builtin_fw {
 #if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE) && 
defined(MODULE))
 int request_firmware(const struct firmware **fw, const char *name,
 struct device *device);
+int firmware_request_nowarn(const struct firmware **fw, const char *name,
+   struct device *device);
 int request_firmware_nowait(
struct module *module, bool uevent,
const char *name, struct device *device, gfp_t gfp, void *context,
@@ -59,6 +61,14 @@ static inline int request_firmware(const struct firmware 
**fw,
 {
return -EINVAL;
 }
+
+static inline int firmware_request_nowarn(const struct firmware **fw,
+ const char *name,
+ struct device *device)
+{
+   return -EINVAL;
+}
+
 static inline int request_firmware_nowait(
struct module *module, bool uevent,
const char *name, struct device *device, gfp_t gfp, void *context,
-- 
2.17.0

[PATCH v6 11/13] Documentation: fix few typos and clarifications for the firmware loader

[Luis R. Rodriguez]

Fix a few typos, and clarify a few sentences.

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/driver-api/firmware/fallback-mechanisms.rst | 5 +++--
 Documentation/driver-api/firmware/firmware_cache.rst  | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index f353783ae0be..a39323ef7d29 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -83,7 +83,7 @@ and a file upload firmware into:
   * /sys/$DEVPATH/data
 
 To upload firmware you will echo 1 onto the loading file to indicate
-you are loading firmware. You then cat the firmware into the data file,
+you are loading firmware. You then write the firmware into the data file,
 and you notify the kernel the firmware is ready by echo'ing 0 onto
 the loading file.
 
@@ -136,7 +136,8 @@ by kobject uevents. This is specially exacerbated due to 
the fact that most
 distributions today disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
 
 Refer to do_firmware_uevent() for details of the kobject event variables
-setup. Variables passwdd with a kobject add event:
+setup. The variables currently passed to userspace with a "kobject add"
+event are:
 
 * FIRMWARE=firmware name
 * TIMEOUT=timeout value
diff --git a/Documentation/driver-api/firmware/firmware_cache.rst 
b/Documentation/driver-api/firmware/firmware_cache.rst
index 2210e5bfb332..c2e69d9c6bf1 100644
--- a/Documentation/driver-api/firmware/firmware_cache.rst
+++ b/Documentation/driver-api/firmware/firmware_cache.rst
@@ -29,8 +29,8 @@ Some implementation details about the firmware cache setup:
 * If an asynchronous call is used the firmware cache is only set up for a
   device if if the second argument (uevent) to request_firmware_nowait() is
   true. When uevent is true it requests that a kobject uevent be sent to
-  userspace for the firmware request. For details refer to the Fackback
-  mechanism documented below.
+  userspace for the firmware request through the sysfs fallback mechanism
+  if the firmware file is not found.
 
 * If the firmware cache is determined to be needed as per the above two
   criteria the firmware cache is setup by adding a devres entry for the
-- 
2.17.0

[PATCH v6 12/13] Documentation: remove stale firmware API reference

[Luis R. Rodriguez]

It refers to a pending patch, but this was merged eons ago.

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/dell_rbu.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
index 0fdb6aa2704c..077fdc29a0d0 100644
--- a/Documentation/dell_rbu.txt
+++ b/Documentation/dell_rbu.txt
@@ -121,9 +121,6 @@ read back the image downloaded.
 
 .. note::
 
-   This driver requires a patch for firmware_class.c which has the modified
-   request_firmware_nowait function.
-
Also after updating the BIOS image a user mode application needs to execute
code which sends the BIOS update request to the BIOS. So on the next reboot
the BIOS knows about the new image downloaded and it updates itself.
-- 
2.17.0

[PATCH v6 13/13] Documentation: clarify firmware_class provenance and why we can't rename the module

[Luis R. Rodriguez]

Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.

Signed-off-by: Luis R. Rodriguez 
---
 .../driver-api/firmware/fallback-mechanisms.rst  | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index a39323ef7d29..a8047be4a96e 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device 
hierarchy by
 associating the device used to make the request as the device's parent.
 The sysfs directory's file attributes are defined and controlled through
 the new device's class (firmware_class) and group (fw_dev_attr_groups).
-This is actually where the original firmware_class.c file name comes from,
-as originally the only firmware loading mechanism available was the
-mechanism we now use as a fallback mechanism.
+This is actually where the original firmware_class module name came from,
+given that originally the only firmware loading mechanism available was the
+mechanism we now use as a fallback mechanism, which which registers a
+struct class firmware_class. Because the attributes exposed are part of the
+module name, the module name firmware_class cannot be renamed in the future, to
+ensure backward compatibilty with old userspace.
 
 To load firmware using the sysfs interface we expose a loading indicator,
 and a file upload firmware into:
-- 
2.17.0

[PATCH v6 00/13] firmware_loader changes for v4.18

[Luis R. Rodriguez]

Greg,

Here is what I have queued up for the firmware_loader for v4.18. It
includes a slew of cleanup work, and the new firmware_request_nowarn()
which is quiet but enables the sysfs fallback mechanism. I've gone ahead
and also queued up a few minor fixes for the firmware loader documentation
which have come up recently. These changes are available on my git tree
both based on linux-next [0] and Linus' latest tree [1]. Folks working
on new developments for the firmware loader can use my linux-next
branch 20180508-firmware_loader_for-v4.18-try2 for now.

0-day sends its blessings.

The patches from Mimi's series still require a bit more discussion and
review. The discussion over the EFI firmware fallback mechanism is still
ongoing.

As for the rename that you wanted, perhaps we can do this late in the
merge window considering we're at rc4 now. I can prep something up for
that later.

Question, and specially rants are warmly welcomed.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20180508-firmware_loader_for-v4.18-try2
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20180508-firmware_loader_for-v4.18-try2

Andres Rodriguez (6):
  firmware: wrap FW_OPT_* into an enum
  firmware: use () to terminate kernel-doc function names
  firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()
  firmware: add firmware_request_nowarn() - load firmware without
warnings
  ath10k: use firmware_request_nowarn() to load firmware
  ath10k: re-enable the firmware fallback mechanism for testmode

Luis R. Rodriguez (7):
  firmware_loader: document firmware_sysfs_fallback()
  firmware_loader: enhance Kconfig documentation over FW_LOADER
  firmware_loader: move kconfig FW_LOADER entries to its own file
  firmware_loader: make firmware_fallback_sysfs() print more useful
  Documentation: fix few typos and clarifications for the firmware
loader
  Documentation: remove stale firmware API reference
  Documentation: clarify firmware_class provenance and why we can't
rename the module

 Documentation/dell_rbu.txt|   3 -
 .../firmware/fallback-mechanisms.rst  |  14 +-
 .../driver-api/firmware/firmware_cache.rst|   4 +-
 .../driver-api/firmware/request_firmware.rst  |   5 +
 drivers/base/Kconfig  |  90 ++
 drivers/base/firmware_loader/Kconfig  | 154 ++
 drivers/base/firmware_loader/fallback.c   |  53 --
 drivers/base/firmware_loader/fallback.h   |  18 +-
 drivers/base/firmware_loader/firmware.h   |  37 -
 drivers/base/firmware_loader/main.c   |  57 +--
 drivers/net/wireless/ath/ath10k/core.c|   2 +-
 drivers/net/wireless/ath/ath10k/testmode.c|   2 +-
 include/linux/firmware.h  |  10 ++
 13 files changed, 319 insertions(+), 130 deletions(-)
 create mode 100644 drivers/base/firmware_loader/Kconfig

-- 
2.17.0

[mac80211-next:master 12/14] drivers/net//wireless/ath/wil6210/debugfs.c:1245:1: warning: the frame size of 1600 bytes is larger than 1024 bytes

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
master
head:   57c6cb81717f957fb741f2e4c79bd0e2f4f55910
commit: 52539ca89f365d3db530535fbffa88a3cca4d2ec [12/14] cfg80211: Expose TXQ 
stats and parameters to userspace
config: i386-randconfig-i1-201818 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 52539ca89f365d3db530535fbffa88a3cca4d2ec
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/net//wireless/ath/wil6210/debugfs.c: In function 
'wil_link_debugfs_show':
>> drivers/net//wireless/ath/wil6210/debugfs.c:1245:1: warning: the frame size 
>> of 1600 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^
--
   drivers/net//wireless/ath/wil6210/wmi.c: In function 'wmi_evt_connect':
>> drivers/net//wireless/ath/wil6210/wmi.c:979:1: warning: the frame size of 
>> 1684 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^
--
   drivers/net//wireless/quantenna/qtnfmac/event.c: In function 
'qtnf_event_handle_sta_assoc':
>> drivers/net//wireless/quantenna/qtnfmac/event.c:107:1: warning: the frame 
>> size of 1616 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^

vim +1245 drivers/net//wireless/ath/wil6210/debugfs.c

9eb82d43 Vladimir Kondratiev 2014-06-16  1198  
9eb82d43 Vladimir Kondratiev 2014-06-16  1199  /*-link*/
9eb82d43 Vladimir Kondratiev 2014-06-16  1200  static int 
wil_link_debugfs_show(struct seq_file *s, void *data)
9eb82d43 Vladimir Kondratiev 2014-06-16  1201  {
9eb82d43 Vladimir Kondratiev 2014-06-16  1202   struct wil6210_priv *wil = 
s->private;
9eb82d43 Vladimir Kondratiev 2014-06-16  1203   struct station_info sinfo;
9eb82d43 Vladimir Kondratiev 2014-06-16  1204   int i, rc;
9eb82d43 Vladimir Kondratiev 2014-06-16  1205  
9eb82d43 Vladimir Kondratiev 2014-06-16  1206   for (i = 0; i < 
ARRAY_SIZE(wil->sta); i++) {
9eb82d43 Vladimir Kondratiev 2014-06-16  1207   struct wil_sta_info *p 
= >sta[i];
9eb82d43 Vladimir Kondratiev 2014-06-16  1208   char *status = 
"unknown";
5bd60982 Lior David  2018-02-26  1209   struct wil6210_vif *vif;
5bd60982 Lior David  2018-02-26  1210   u8 mid;
8fe59627 Vladimir Kondratiev 2014-09-10  1211  
9eb82d43 Vladimir Kondratiev 2014-06-16  1212   switch (p->status) {
9eb82d43 Vladimir Kondratiev 2014-06-16  1213   case wil_sta_unused:
9eb82d43 Vladimir Kondratiev 2014-06-16  1214   status = 
"unused   ";
9eb82d43 Vladimir Kondratiev 2014-06-16  1215   break;
9eb82d43 Vladimir Kondratiev 2014-06-16  1216   case 
wil_sta_conn_pending:
9eb82d43 Vladimir Kondratiev 2014-06-16  1217   status = 
"pending  ";
9eb82d43 Vladimir Kondratiev 2014-06-16  1218   break;
9eb82d43 Vladimir Kondratiev 2014-06-16  1219   case wil_sta_connected:
9eb82d43 Vladimir Kondratiev 2014-06-16  1220   status = 
"connected";
9eb82d43 Vladimir Kondratiev 2014-06-16  1221   break;
9eb82d43 Vladimir Kondratiev 2014-06-16  1222   }
5bd60982 Lior David  2018-02-26  1223   mid = (p->status != 
wil_sta_unused) ? p->mid : U8_MAX;
5bd60982 Lior David  2018-02-26  1224   seq_printf(s, "[%d][MID 
%d] %pM %s\n",
5bd60982 Lior David  2018-02-26  1225  i, mid, 
p->addr, status);
9eb82d43 Vladimir Kondratiev 2014-06-16  1226  
5bd60982 Lior David  2018-02-26  1227   if (p->status != 
wil_sta_connected)
5bd60982 Lior David  2018-02-26  1228   continue;
5bd60982 Lior David  2018-02-26  1229  
5bd60982 Lior David  2018-02-26  1230   vif = (mid < 
wil->max_vifs) ? wil->vifs[mid] : NULL;
5bd60982 Lior David  2018-02-26  1231   if (vif) {
e00243fa Lior David  2018-02-26  1232   rc = 
wil_cid_fill_sinfo(vif, i, );
9eb82d43 Vladimir Kondratiev 2014-06-16  1233   if (rc)
9eb82d43 Vladimir Kondratiev 2014-06-16  1234   return 
rc;
9eb82d43 Vladimir Kondratiev 2014-06-16  1235  
9eb82d43 Vladimir Kondratiev 2014-06-16  1236   seq_printf(s, " 
 Tx_mcs = %d\n", sinfo.txrate.mcs);
9eb82d43 Vladimir Kondratiev 2014-06-16  1237   seq_printf(s, " 
 Rx_mcs = %d\n", sinfo.rxrate.mcs);
9eb82d43 Vladimir Kondratiev 2014-06-16  1238   seq_printf(s, " 
 SQ = %d\n", sinfo.signal);
5bd60982 Lior David  2018-02-26  1239   } else {
5bd60982 Lior David  2018-02-26  1240   seq_puts(s, "  
INVALID MID\n");
9eb82d43 Vladimir Kondratiev 2014-06-16  1241   }
9eb82d43 Vladimir Kondratiev 2014-06-16  1242   }
9eb82d43 Vladimir Kondratiev 2014-06-16  1243  
9eb82d43 Vladimir Kondratiev 2014-06-16  1244   return 0;
9eb82d43 Vladimir Kondratiev 

Re: [PATCH 00/18] Fix some build warnings/errors with Sphinx

[Luis R. Rodriguez]

On Tue, May 08, 2018 at 10:13:42AM -0600, Jonathan Corbet wrote:
> On Mon,  7 May 2018 06:35:36 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > I decided to give a try with Sphinx last stable version
> > (1.17.4), and noticed several issues. The worse one was
> > with the networking book: a non-standard footnote there
> > with [*] instead of a number causes it to break PDF building.
> > 
> > So, I took some spare time to address some warnings all over
> > the tree, and moved a few text documents to a book. 
> 
> OK, I've applied the ones that seem to make sense for me to take now.
> There's comments on the firmware one, 

I'll fold in the fixes for the firmware API which do apply to my queue.

  Luis

Re: [PATCH v3 00/12] *** Add support for wifi QMI client driver ***

[Bjorn Andersson]

On Sun 25 Mar 22:37 PDT 2018, Govind Singh wrote:

> Add QMI client driver for Q6 integrated WLAN connectivity subsystem.
> This module is responsible for communicating WLAN control messages to FW
> over QMI interface.
> 
> “QUALCOMM Messaging Interface”(QMI) provides the control interface between
> components running b/w remote processors with underlying transport layer
> based on integrated chipset(shared memory) or discrete 
> chipset(PCI/USB/SDIO/UART).
> 
> QMI client driver implementation is based on qmi frmework 
> https://lwn.net/Articles/729924/.
> 
> Below is the sequence of qmi handshake.
> 
>QMI CLIENT(APPS) QMI SERVER(FW 
> in Q6)
> 
>  <--wlan service discoverd
> 
>-connect to wlam qmi service->
> 
>wlan info request->
> 
> 
>msa info req>
> 
>   
>  msa ready req>
> 
>   
>   
>  capability req--->
> 
>  
> qmi bdf req->
> 
>   
>   qmi cal trigger--->
> 
>   < QMI FW ready indication---

Does the responsibility of the driver ends here? I mean is this a driver
for setting up the firmware and then there's something else doing the
actual wifi operation, or does it simply hand over execution to the
common ath10k logic at this point?

> 
> Govind Singh (12):
>   ath10k: Add qmi service for wlan qmi client
>   dt: bindings: add bindings for ath10k qmi client
>   ath10k: Add WCN3990 QMI client driver
>   ath10k: add support to start and stop qmi service
>   ath10k: Add support of QMI indication message
>   firmware: qcom: scm: Add WLAN VMID for Qualcomm SCM interface
>   ath10k: Add MSA handshake QMI mgs support
>   ath10k: Add QMI CAP request support
>   ath10k: Add QMI HOST CAP request support
>   ath10k: add bdf/cal indication support
>   ath10k: Add wlan mode on/off qmi message
>   ath10k: Add qmi wlan enable/disable support for WCN3990

I'm missing this last patch in my mailbox, and it would be nice if all
the patches where in-reply-to the cover letter, to make them easier to
find.

Regards,
Bjorn

Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

[Luis R. Rodriguez]

On Thu, May 03, 2018 at 08:24:26PM -0400, Mimi Zohar wrote:
> On Fri, 2018-05-04 at 00:07 +, Luis R. Rodriguez wrote:
> > On Tue, May 01, 2018 at 09:48:20AM -0400, Mimi Zohar wrote:
> > > Allow LSMs and IMA to differentiate between signed regulatory.db and
> > > other firmware.
> > > 
> > > Signed-off-by: Mimi Zohar 
> > > Cc: Luis R. Rodriguez 
> > > Cc: David Howells 
> > > Cc: Kees Cook 
> > > Cc: Seth Forshee 
> > > Cc: Johannes Berg 
> > > ---
> > >  drivers/base/firmware_loader/main.c | 5 +
> > >  include/linux/fs.h  | 1 +
> > >  2 files changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/base/firmware_loader/main.c 
> > > b/drivers/base/firmware_loader/main.c
> > > index eb34089e4299..d7cdf04a8681 100644
> > > --- a/drivers/base/firmware_loader/main.c
> > > +++ b/drivers/base/firmware_loader/main.c
> > > @@ -318,6 +318,11 @@ fw_get_filesystem_firmware(struct device *device, 
> > > struct fw_priv *fw_priv)
> > >   break;
> > >   }
> > >  
> > > +#ifdef CONFIG_CFG80211_REQUIRE_SIGNED_REGDB
> > > + if ((strcmp(fw_priv->fw_name, "regulatory.db") == 0) ||
> > > + (strcmp(fw_priv->fw_name, "regulatory.db.p7s") == 0))
> > > + id = READING_FIRMWARE_REGULATORY_DB;
> > > +#endif
> > 
> > Whoa, no way.
> 
> There are two methods for the kernel to verify firmware signatures.

Yes, but although CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is its own kernel
mechanism to verify firmware it uses the request_firmware*() API for
regulatory.db and regulatory.db.p7s, and IMA already can appraise these two
files since the firmware API is used.

As such I see no reason to add a new ID for them at all.

Its not providing an *alternative*, its providing an *extra* kernel measure.
If anything CONFIG_CFG80211_REQUIRE_SIGNED_REGDB perhaps should be its own
stacked LSM. I'd be open to see patches which set that out. May be a
cleaner interface.

> If both are enabled, do we require both signatures or is one enough.

Good question. Considering it as a stacked LSM (although not implemented
as one), I'd say its up to who enabled the Kconfig entries. If IMA and
CONFIG_CFG80211_REQUIRE_SIGNED_REGDB are enabled then both. If someone enabled
IMA though, then surely I agree that enabling
CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is stupid and redundant, but its up to the
system integrator to decide.

If we however want to make it clear that such things as
CONFIG_CFG80211_REQUIRE_SIGNED_REGDB are not required when IMA is enabled we
could just make the kconfig depend on !IMA or something? Or perhaps a new
kconfig for IMA which if selected it means that drivers can opt to open code
*further* kernel signature verification, even though IMA already is sufficient.
Perhaps CONFIG_ENABLE_IMA_OVERLAPPING, and the driver depends on it?

> Assigning a different id for regdb signed firmware allows LSMs and IMA
> to handle regdb files differently.

That's not the main concern here, its the precedent we are setting here for
any new kernel interface which open codes firmware signing on its own. What
you are doing means other kernel users who open codes their own firmware
signing may need to add yet-another reading ID. That doesn't either look
well on code, and seems kind of silly from a coding perspective given
the above, in which I clarify IMA still is doing its own appraisal on it.

> > >   fw_priv->size = 0;
> > >   rc = kernel_read_file_from_path(path, _priv->data, ,
> > >   msize, id);
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > index dc16a73c3d38..d1153c2884b9 100644
> > > --- a/include/linux/fs.h
> > > +++ b/include/linux/fs.h
> > > @@ -2811,6 +2811,7 @@ extern int do_pipe_flags(int *, int);
> > >   id(FIRMWARE, firmware)  \
> > >   id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
> > >   id(FIRMWARE_FALLBACK, firmware) \
> > > + id(FIRMWARE_REGULATORY_DB, firmware)\
> > 
> > Why could IMA not appriase these files? They are part of the standard path.
> 
> The subsequent patch attempts to verify the IMA-appraisal signature, but on
> failure it falls back to allowing regdb signatures. 
> For systems that only want to load firmware based on IMA-appraisal, then
>regdb wouldn't be enabled.

I think we can codify this a bit better, without a new ID.

  Luis

[PATCH] iw: Add duration parameter to scan command

[Pradeep Kumar Chitrapu]

This patch lets user to specify duration(TUs) and set duration-mandatory
flag in scan command.

Signed-off-by: Pradeep Kumar Chitrapu 
---

 scan.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/scan.c b/scan.c
index 74ccc06..3e9daef 100644
--- a/scan.c
+++ b/scan.c
@@ -411,10 +411,13 @@ static int handle_scan(struct nl80211_state *state,
IES,
SSID,
MESHID,
+   DURATION,
DONE,
} parse = NONE;
int freq;
+   unsigned int duration = 0;
bool passive = false, have_ssids = false, have_freqs = false;
+   bool duration_mandatory = false;
size_t ies_len = 0, meshid_len = 0;
unsigned char *ies = NULL, *meshid = NULL, *tmpies;
unsigned int flags = 0;
@@ -448,6 +451,9 @@ static int handle_scan(struct nl80211_state *state,
} else if (strcmp(argv[i], "ap-force") == 0) {
flags |= NL80211_SCAN_FLAG_AP;
break;
+   } else if (strcmp(argv[i], "duration-mandatory") == 0) {
+   duration_mandatory = true;
+   break;
} else if (strncmp(argv[i], "randomise", 9) == 0 ||
   strncmp(argv[i], "randomize", 9) == 0) {
flags |= NL80211_SCAN_FLAG_RANDOM_ADDR;
@@ -466,6 +472,9 @@ static int handle_scan(struct nl80211_state *state,
} else if (strcmp(argv[i], "meshid") == 0) {
parse = MESHID;
break;
+   } else if (strcmp(argv[i], "duration") == 0) {
+   parse = DURATION;
+   break;
}
case DONE:
nlmsg_free(ssids);
@@ -501,6 +510,10 @@ static int handle_scan(struct nl80211_state *state,
meshid_len += 2;
parse = NONE;
break;
+   case DURATION:
+   duration = strtoul(argv[i], , 10);
+   parse = NONE;
+   break;
}
}
 
@@ -535,6 +548,17 @@ static int handle_scan(struct nl80211_state *state,
nla_put_nested(msg, NL80211_ATTR_SCAN_FREQUENCIES, freqs);
if (flags)
NLA_PUT_U32(msg, NL80211_ATTR_SCAN_FLAGS, flags);
+   if (duration)
+   NLA_PUT_U16(msg, NL80211_ATTR_MEASUREMENT_DURATION, duration);
+   if (duration_mandatory) {
+   if (duration) {
+   NLA_PUT_FLAG(msg,
+
NL80211_ATTR_MEASUREMENT_DURATION_MANDATORY);
+   } else {
+   err = -EINVAL;
+   goto nla_put_failure;
+   }
+   }
 
err = 0;
  nla_put_failure:
@@ -2275,7 +2299,7 @@ static int handle_scan_combined(struct nl80211_state 
*state,
dump_argv[0] = argv[0];
return handle_cmd(state, id, dump_argc, dump_argv);
 }
-TOPLEVEL(scan, "[-u] [freq *] [ies ] [meshid ] 
[lowpri,flush,ap-force] [randomise[=/]] [ssid *|passive]", 0, 
0,
+TOPLEVEL(scan, "[-u] [freq *] [duration ] [ies ] 
[meshid ] [lowpri,flush,ap-force,duration-mandatory] 
[randomise[=/]] [ssid *|passive]", 0, 0,
 CIB_NETDEV, handle_scan_combined,
 "Scan on the given frequencies and probe for the given SSIDs\n"
 "(or wildcard if not given) unless passive scanning is requested.\n"
@@ -2285,10 +2309,11 @@ COMMAND(scan, dump, "[-u]",
NL80211_CMD_GET_SCAN, NLM_F_DUMP, CIB_NETDEV, handle_scan_dump,
"Dump the current scan results. If -u is specified, print unknown\n"
"data in scan results.");
-COMMAND(scan, trigger, "[freq *] [ies ] [meshid 
] [lowpri,flush,ap-force] [randomise[=/]] [ssid 
*|passive]",
+COMMAND(scan, trigger, "[freq *] [duration ] [ies ] [meshid ] [lowpri,flush,ap-force,duration-mandatory] 
[randomise[=/]] [ssid *|passive]",
NL80211_CMD_TRIGGER_SCAN, 0, CIB_NETDEV, handle_scan,
 "Trigger a scan on the given frequencies with probing for the given\n"
-"SSIDs (or wildcard if not given) unless passive scanning is 
requested.");
+"SSIDs (or wildcard if not given) unless passive scanning is 
requested.\n"
+"Duration(in TUs), if specified, will be used to set dwell times.\n");
 
 
 static int handle_scan_abort(struct nl80211_state *state,
-- 
1.9.1

[mac80211-next:master 12/14] htmldocs: include/net/cfg80211.h:3997: warning: Function parameter or member 'txq_limit' not described in 'wiphy'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
master
head:   57c6cb81717f957fb741f2e4c79bd0e2f4f55910
commit: 52539ca89f365d3db530535fbffa88a3cca4d2ec [12/14] cfg80211: Expose TXQ 
stats and parameters to userspace
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
>> include/net/cfg80211.h:3997: warning: Function parameter or member 
>> 'txq_limit' not described in 'wiphy'
>> include/net/cfg80211.h:3997: warning: Function parameter or member 
>> 'txq_memory_limit' not described in 'wiphy'
>> include/net/cfg80211.h:3997: warning: Function parameter or member 
>> 'txq_quantum' not described in 'wiphy'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.ibss' not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.connect' not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.keys' not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 'wext.ie' 
not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.ie_len' not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.bssid' not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.ssid' not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.default_key' not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.default_mgmt_key' not described in 'wireless_dev'
   include/net/cfg80211.h:4269: warning: Function parameter or member 
'wext.prev_bssid_valid' not described in 'wireless_dev'
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2282: warning: Function parameter or member 
'radiotap_timestamp.units_pos' not described in 'ieee80211_hw'
   include/net/mac80211.h:2282: warning: Function parameter or member 
'radiotap_timestamp.accuracy' not described in 'ieee80211_hw'
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:2083: warning: bad line: >
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.rates' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.use_rts' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.use_cts_prot' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.short_preamble' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.skip_table' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.jiffies' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.vif' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.hw_key' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.flags' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'control.enqueue_time' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 'ack' not 
described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'ack.cookie' not described in 'ieee80211_tx_info'
   include/net/mac80211.h:955: warning: Function parameter or member 
'status.rates' not 

Re: [PATCH 4.17] bcma: fix buffer size caused crash in bcma_core_mips_print_irq()

[Joe Perches]

On Tue, 2018-05-08 at 11:31 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Used buffer wasn't big enough to hold whole strings. Example output of
> this function is:
> [0.180892] bcma: bus0: core 0x0800, irq: 2(S)* 3  4  5  6  D  I
> [0.180948] bcma: bus0: core 0x0812, irq: 2(S)  3* 4  5  6  D  I
> [0.180998] bcma: bus0: core 0x082d, irq: 2(S)  3  4* 5  6  D  I
> [0.181046] bcma: bus0: core 0x082c, irq: 2(S)  3  4  5  6  D  I*
> which means we need to store up to 24 chars.
> 
> Fixes: 758f7e06063a8 ("bcma: Use bcma_debug and not pr_cont in MIPS driver")
> Signed-off-by: Rafał Miłecki 
> Cc: sta...@vger.kernel.org # v4.15+

Oops.  Apologies for not counting properly.

> ---
>  drivers/bcma/driver_mips.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
> index f040aba48d50..27e9686b6d3a 100644
> --- a/drivers/bcma/driver_mips.c
> +++ b/drivers/bcma/driver_mips.c
> @@ -184,7 +184,7 @@ static void bcma_core_mips_print_irq(struct bcma_device 
> *dev, unsigned int irq)
>  {
>   int i;
>   static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
> - char interrupts[20];
> + char interrupts[25];
>   char *ints = interrupts;
>  
>   for (i = 0; i < ARRAY_SIZE(irq_name); i++)

Re: [PATCH 00/18] Fix some build warnings/errors with Sphinx

[Jonathan Corbet]

On Mon,  7 May 2018 06:35:36 -0300
Mauro Carvalho Chehab  wrote:

> I decided to give a try with Sphinx last stable version
> (1.17.4), and noticed several issues. The worse one was
> with the networking book: a non-standard footnote there
> with [*] instead of a number causes it to break PDF building.
> 
> So, I took some spare time to address some warnings all over
> the tree, and moved a few text documents to a book. 

OK, I've applied the ones that seem to make sense for me to take now.
There's comments on the firmware one, and I'd rather have Tejun's OK for
the cgroup one.  The code-comment changes should probably go via the
usual maintainers.

> I with
> I had more time to move the other ones and to solve other
> warnings.

You and me both - but each step helps!

Thanks,

jon

Re: [v2, 06/10] wil6210: use country specific board file upon reg domain change

[Kalle Valo]

Maya Erez  wrote:

> From: Dedy Lansky 
> 
> wil6210 device needs to use country specific board file while in China
> regulatory domain.
> Register cfg80211 reg_notifier and switch board file if needed
> according to new regulatory domain.
> This feature is disabled by default and can be enabled with a new
> country_specific_board_file module parameter.
> 
> Signed-off-by: Dedy Lansky 
> Signed-off-by: Maya Erez 

This looks fishy, especially the addition of a new module parameter.
I'll drop this as I don't have time to investigate in detail.

Patch set to Changes Requested.

-- 
https://patchwork.kernel.org/patch/10356435/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18

[Luis R. Rodriguez]

On Fri, May 04, 2018 at 10:43:49AM -0700, Luis R. Rodriguez wrote:
> Greg,
> 
> I've reviewed the pending patches for the firmware_laoder and as for
> v4.18, the following 3 patches from Andres have been iterated enough
> that they're ready after I made some final minor changes, mostly just
> style fixes and re-arrangements in terms of order. The new API he was
> suggesting to add requires just a bit more review.

We're done with review of the new API for the sync no warn call,
so I'll just re-issue another patch series with those patches
in a new series.

Coming right up.

  Luis

Re: [02/10] wil6210: set/get EDMG channel through debugfs

[Kalle Valo]

me...@codeaurora.org writes:

> On 2018-04-24 12:47, Kalle Valo wrote:
>> me...@codeaurora.org writes:
>>
>>> On 2018-04-19 19:15, Kalle Valo wrote:
 Maya Erez  wrote:

> Setting EDMG channel through debugfs for connect and PCP start
> commands.
 Why? And what is an EDMG channel?
 https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_log_does_not_answer_why
 I get bad vibes that this debugfs file is just a workaround for not
 adding this to nl80211, a proper commit log would not give me such
 vibes in the first place :)
>>>
>>> EDMG (Enhanced Directional Multi-Gigabit) is a new feature, part of
>>> 11ad/11ay specification. In a nutshell it allows channel bonding of
>>> 60Ghz channels.
>>>
>>> The debugfs is used for debug-only to allow forcing a channel, not
>>> intended to replace NL API, which we are working to upstream such.
>>
>> But why cannot you do debugging via nl80211 as well?
>
> Debugging via nl80211 is possible, but there are benefits in using the
> debugfs interface:
> - Debugfs allows forcing a specific channel, which is not always an
> option with NL API
> - Debug via nl80211 is less straight forward and requires development
> of user-space application
> and upgrade of the kernel version on the debug setups
>
> If you believe that the duplication is not justified please drop this
> patch.

Yeah, I think it's better to drop this. Let's revisit after we have the
corresonding nl80211 command in place.

-- 
Kalle Valo

Re: [PATCHv2,3/3] ath10k: average ack rssi support for data frames

[Kalle Valo]

Balaji Pothunoori  wrote:

> Average ack rssi value is weighted average of ack rssi for
> no of msdu's has been sent.
> This feature is enabled by the host driver if firmware is capable.
> After receiving event from host, firmware allocates the necessary
> memory to store the ack_rssi for data packets during the init time.
> 
> After each successful transmission, If tx completion status is OK
> and 24th bit is set in HTT message header then host will fetch the
> ack_rssi else host can ignore the ack_rssi field.
> 
> Signed-off-by: Balaji Pothunoori 

A note to myself that this depends on:

cc60dbbfed8f mac80211: average ack rssi support for data frames

Currently in mac80211-next.

-- 
https://patchwork.kernel.org/patch/10343153/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] net: wireless: ath: ath9k: Fix a possible data race in ath_chanctx_set_next

[Toke Høiland-Jørgensen]

Kalle Valo  writes:

> Jia-Ju Bai  writes:
>
>> The write operation to "sc->next_chan" is protected by
>> the lock on line 1287, but the read operation to
>> this data on line 1262 is not protected by the lock.
>> Thus, there may exist a data race for "sc->next_chan".
>>
>> To fix this data race, the read operation to "sc->next_chan" 
>> should be also protected by the lock.
>>
>> Signed-off-by: Jia-Ju Bai 
>
> I need this reviewed by someone else before I'm willing to take it.

Only possible issue I can see is that it puts a call to
getrawmonotonic() under the spinlock. Not sure if that has any bad
implications...

-Toke

Re: [PATCH v2] ath10k: remove variables which set but not used

[Jeff Johnson]

On 2018-05-07 02:39, Kenneth Lu wrote:

Variable buf_len and num_vdev_stats are bging assigned but never read.


typo: bging => being

Re: [PATCH] net: wireless: ath: ath9k: Fix a possible data race in ath_chanctx_set_next

[Kalle Valo]

Jia-Ju Bai  writes:

> The write operation to "sc->next_chan" is protected by
> the lock on line 1287, but the read operation to
> this data on line 1262 is not protected by the lock.
> Thus, there may exist a data race for "sc->next_chan".
>
> To fix this data race, the read operation to "sc->next_chan" 
> should be also protected by the lock.
>
> Signed-off-by: Jia-Ju Bai 

I need this reviewed by someone else before I'm willing to take it.

-- 
Kalle Valo

Re: [PATCH] mac80211: ethtool: avoid 32 bit multiplication overflow

[Johannes Berg]

On Tue, 2018-05-08 at 13:57 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The multiplication of 10 * cfg80211_calculate_bitrate() is a 32 bit
> operation and can overflow if cfg80211_calculate_bitrate is greater
> than 42949. Although I don't believe this is occurring at present, it
> would be safer to avoid the potential overflow by making the constant
> 10 an ULL to ensure a 64 multiplication occurs.

Yeah it can't happen since mac80211 doesn't support 60 GHz devices, and
all others are limited to less than than.

Still, applied.

johannes

[PATCH] mac80211: ethtool: avoid 32 bit multiplication overflow

[Colin King]

From: Colin Ian King 

The multiplication of 10 * cfg80211_calculate_bitrate() is a 32 bit
operation and can overflow if cfg80211_calculate_bitrate is greater
than 42949. Although I don't believe this is occurring at present, it
would be safer to avoid the potential overflow by making the constant
10 an ULL to ensure a 64 multiplication occurs.

Detected by CoverityScan, CID#1468643 ("Unintentional integer overflow")

Signed-off-by: Colin Ian King 
---
 net/mac80211/ethtool.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/ethtool.c b/net/mac80211/ethtool.c
index 08408520c3f8..2ba5686cbcab 100644
--- a/net/mac80211/ethtool.c
+++ b/net/mac80211/ethtool.c
@@ -117,11 +117,11 @@ static void ieee80211_get_stats(struct net_device *dev,
 
 
if (sinfo.filled & BIT(NL80211_STA_INFO_TX_BITRATE))
-   data[i] = 10 *
+   data[i] = 10ULL *
cfg80211_calculate_bitrate();
i++;
if (sinfo.filled & BIT(NL80211_STA_INFO_RX_BITRATE))
-   data[i] = 10 *
+   data[i] = 10ULL *
cfg80211_calculate_bitrate();
i++;
 
-- 
2.17.0

Re: [PATCH] brcmfmac: Add support for bcm43364 wireless chipset

[Kalle Valo]

Arend van Spriel  writes:

> + Kalle (explicitly)
>
> On 5/8/2018 9:58 AM, Ulf Hansson wrote:
>> On 4 May 2018 at 08:48, Sean Lanigan  wrote:
>>> Add support for the BCM43364 chipset via an SDIO interface, as used in
>>> e.g. the Murata 1FX module.
>>>
>>> The BCM43364 uses the same firmware as the BCM43430 (which is already
>>> included), the only difference is the omission of Bluetooth.
>>>
>>> However, the SDIO_ID for the BCM43364 is 02D0:A9A4, giving it a MODALIAS
>>> of sdio:c00v02D0dA9A4, which doesn't get recognised and hence doesn't
>>> load the brcmfmac module. Adding the 'A9A4' ID in the appropriate place
>>> triggers the brcmfmac driver to load, and then correctly use the
>>> firmware file 'brcmfmac43430-sdio.bin'.
>>>
>>>
>>> Signed-off-by: Sean Lanigan 
>>
>> Acked-by: Ulf Hansson 
>>
>> Arend, I assume you want to pick this up? If not, just tell and I can do it.
>
> Not necessarily. I let Kalle do the leg work ;-) Given the change I do
> not expect any conflict so we can go either way with a slight
> preference for wl-drivers-next. Kalle?

Yeah, I would like to take this to wireless-drivers-next. Less conflicts
that way.

-- 
Kalle Valo

Re: [PATCH] nl80211: Reject disconnect commands except from conn_owner

[Arend van Spriel]

On 5/8/2018 2:19 PM, Johannes Berg wrote:

On Tue, 2018-05-08 at 14:18 +0200, Arend van Spriel wrote:

On 5/7/2018 9:19 PM, Johannes Berg wrote:

On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:

On 28 April 2018 at 15:07, Kalle Valo  wrote:

Andrew Zaborowski  writes:

Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE,
NL80211_CMD_DEAUTHENTICATE and NL80211_CMD_ASSOCIATE commands
from clients other than the connection owner set in the connect,
authenticate or associate commands, if it was set.

The main point of this check is to prevent chaos when two processes
try to use nl80211 at the same time, it's not a security measure.
The same thing should possibly be done for JOIN_IBSS/LEAVE_IBSS and
START_AP/STOP_AP.


s-o-b missing.


True, thanks.  Also I was going to send this as an RFC.



Looks fine to me, please resend if you want it in :)


Do we really want this? Is the referred chaos hypothetical or an actual
issue. Nothing stops me from doing an 'ifconfig down' so why should 'iw
disconnect' be any different. As far I can tell it does not affect my
testing environment, but particularly in such use-cases I can expect
issues adopting this change, which is also hypothetical of course ;-)


Yeah, it's a good question. But it might help with inadvertent issues,
like starting wpa_s which immediately disconnects if it finds something
connected. If that fails, perhaps you have a better chance of noticing
the error?


Sure. I guess we all have been there kicking of wpa_s and discovering 
there is already one running in the background. I am just a bit 
squeamish to change the behavior like this. H. Is wpa_s already 
using SOCKET_OWNER. If so, I might create a patch to opt-out for that so 
people can knowingly choose chaos ;-)


Regards,
Arend

Re: [PATCH] nl80211: Reject disconnect commands except from conn_owner

[Johannes Berg]

On Tue, 2018-05-08 at 14:18 +0200, Arend van Spriel wrote:
> On 5/7/2018 9:19 PM, Johannes Berg wrote:
> > On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:
> > > On 28 April 2018 at 15:07, Kalle Valo  wrote:
> > > > Andrew Zaborowski  writes:
> > > > > Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE,
> > > > > NL80211_CMD_DEAUTHENTICATE and NL80211_CMD_ASSOCIATE commands
> > > > > from clients other than the connection owner set in the connect,
> > > > > authenticate or associate commands, if it was set.
> > > > > 
> > > > > The main point of this check is to prevent chaos when two processes
> > > > > try to use nl80211 at the same time, it's not a security measure.
> > > > > The same thing should possibly be done for JOIN_IBSS/LEAVE_IBSS and
> > > > > START_AP/STOP_AP.
> > > > 
> > > > s-o-b missing.
> > > 
> > > True, thanks.  Also I was going to send this as an RFC.
> > > 
> > 
> > Looks fine to me, please resend if you want it in :)
> 
> Do we really want this? Is the referred chaos hypothetical or an actual 
> issue. Nothing stops me from doing an 'ifconfig down' so why should 'iw 
> disconnect' be any different. As far I can tell it does not affect my 
> testing environment, but particularly in such use-cases I can expect 
> issues adopting this change, which is also hypothetical of course ;-)

Yeah, it's a good question. But it might help with inadvertent issues,
like starting wpa_s which immediately disconnects if it finds something
connected. If that fails, perhaps you have a better chance of noticing
the error?

johannes

Re: [PATCH] nl80211: Reject disconnect commands except from conn_owner

[Arend van Spriel]

On 5/7/2018 9:19 PM, Johannes Berg wrote:

On Sun, 2018-04-29 at 20:30 +0200, Andrew Zaborowski wrote:

On 28 April 2018 at 15:07, Kalle Valo  wrote:

Andrew Zaborowski  writes:

Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE,
NL80211_CMD_DEAUTHENTICATE and NL80211_CMD_ASSOCIATE commands
from clients other than the connection owner set in the connect,
authenticate or associate commands, if it was set.

The main point of this check is to prevent chaos when two processes
try to use nl80211 at the same time, it's not a security measure.
The same thing should possibly be done for JOIN_IBSS/LEAVE_IBSS and
START_AP/STOP_AP.


s-o-b missing.


True, thanks.  Also I was going to send this as an RFC.


Looks fine to me, please resend if you want it in :)


Do we really want this? Is the referred chaos hypothetical or an actual 
issue. Nothing stops me from doing an 'ifconfig down' so why should 'iw 
disconnect' be any different. As far I can tell it does not affect my 
testing environment, but particularly in such use-cases I can expect 
issues adopting this change, which is also hypothetical of course ;-)


Regards,
Arend

Re: [PATCH] brcmfmac: Add support for bcm43364 wireless chipset

[Arend van Spriel]

+ Kalle (explicitly)

On 5/8/2018 9:58 AM, Ulf Hansson wrote:

On 4 May 2018 at 08:48, Sean Lanigan  wrote:

Add support for the BCM43364 chipset via an SDIO interface, as used in
e.g. the Murata 1FX module.

The BCM43364 uses the same firmware as the BCM43430 (which is already
included), the only difference is the omission of Bluetooth.

However, the SDIO_ID for the BCM43364 is 02D0:A9A4, giving it a MODALIAS
of sdio:c00v02D0dA9A4, which doesn't get recognised and hence doesn't
load the brcmfmac module. Adding the 'A9A4' ID in the appropriate place
triggers the brcmfmac driver to load, and then correctly use the
firmware file 'brcmfmac43430-sdio.bin'.


Signed-off-by: Sean Lanigan 


Acked-by: Ulf Hansson 

Arend, I assume you want to pick this up? If not, just tell and I can do it.


Not necessarily. I let Kalle do the leg work ;-) Given the change I do 
not expect any conflict so we can go either way with a slight preference 
for wl-drivers-next. Kalle?


Regards,
Arend

[PATCH] ath10k: add fw crash dump support for QCA9888 and QCA99X0

[Anilkumar Kolli]

This patch adds crash dump support for QCA9888 and QCA99X0

Tested On: QCA9888, Firmware Version: 10.4-3.5.3-00053
Tested on QCA99X0, Firmware Version: 10.4.1.00030-1

Signed-off-by: Anilkumar Kolli 
---
 drivers/net/wireless/ath/ath10k/coredump.c |   98 
 1 file changed, 98 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/coredump.c 
b/drivers/net/wireless/ath/ath10k/coredump.c
index f90cec0ebb1c..e0eb2eb1a66d 100644
--- a/drivers/net/wireless/ath/ath10k/coredump.c
+++ b/drivers/net/wireless/ath/ath10k/coredump.c
@@ -701,6 +701,89 @@
},
 };
 
+static const struct ath10k_mem_region qca99X0_hw20_mem_regions[] = {
+   {
+   .type = ATH10K_MEM_REGION_TYPE_DRAM,
+   .start = 0x40,
+   .len = 0x6,
+   .name = "DRAM",
+   .section_table = {
+   .sections = NULL,
+   .size = 0,
+   },
+   },
+   {
+   .type = ATH10K_MEM_REGION_TYPE_REG,
+   .start = 0x98000,
+   .len = 0x5,
+   .name = "IRAM",
+   .section_table = {
+   .sections = NULL,
+   .size = 0,
+   },
+   },
+   {
+   .type = ATH10K_MEM_REGION_TYPE_IOSRAM,
+   .start = 0xC,
+   .len = 0x4,
+   .name = "SRAM",
+   .section_table = {
+   .sections = NULL,
+   .size = 0,
+   },
+   },
+   {
+   .type = ATH10K_MEM_REGION_TYPE_IOREG,
+   .start = 0x3,
+   .len = 0x7000,
+   .name = "APB REG 1",
+   .section_table = {
+   .sections = NULL,
+   .size = 0,
+   },
+   },
+   {
+   .type = ATH10K_MEM_REGION_TYPE_IOREG,
+   .start = 0x3f000,
+   .len = 0x3000,
+   .name = "APB REG 2",
+   .section_table = {
+   .sections = NULL,
+   .size = 0,
+   },
+   },
+   {
+   .type = ATH10K_MEM_REGION_TYPE_IOREG,
+   .start = 0x43000,
+   .len = 0x3000,
+   .name = "WIFI REG",
+   .section_table = {
+   .sections = NULL,
+   .size = 0,
+   },
+   },
+   {
+   .type = ATH10K_MEM_REGION_TYPE_IOREG,
+   .start = 0x4A000,
+   .len = 0x5000,
+   .name = "CE REG",
+   .section_table = {
+   .sections = NULL,
+   .size = 0,
+   },
+   },
+   {
+   .type = ATH10K_MEM_REGION_TYPE_IOREG,
+   .start = 0x8,
+   .len = 0x6000,
+   .name = "SOC REG",
+   .section_table = {
+   .sections = NULL,
+   .size = 0,
+   },
+   },
+};
+
 static const struct ath10k_mem_region qca9984_hw10_mem_regions[] = {
{
.type = ATH10K_MEM_REGION_TYPE_DRAM,
@@ -848,6 +931,21 @@
.size = ARRAY_SIZE(qca9984_hw10_mem_regions),
},
},
+   {
+   .hw_id = QCA9888_HW_2_0_DEV_VERSION,
+   .region_table = {
+   .regions = qca9984_hw10_mem_regions,
+   .size = ARRAY_SIZE(qca9984_hw10_mem_regions),
+   },
+   },
+   {
+   .hw_id = QCA99X0_HW_2_0_DEV_VERSION,
+   .region_table = {
+   .regions = qca99X0_hw20_mem_regions,
+   .size = ARRAY_SIZE(qca99X0_hw20_mem_regions),
+   },
+   },
+
 };
 
 static u32 ath10k_coredump_get_ramdump_size(struct ath10k *ar)
-- 
1.7.9.5

[PATCH v2 2/2] iw: Add getting and setting of TXQ params for phy

[Toke Høiland-Jørgensen]

This adds commands to get and set the per-phy TXQ parameters for drivers
that use the intermediate TXQs. These are the settings and statistics that
are also available through /sys/kernel/debug/ieee80211/phyX/aqm.

Sample output:

$ iw phy phy0 get txq
Packet limit:   8192 pkts
Memory limit:   4194304 bytes
Quantum:300 bytes
Number of queues:   4096
Backlog:12 pkts
Memory usage:   52224 bytes
Packet limit overflows: 0
Memory limit overflows: 0
Hash collisions:1

Signed-off-by: Toke Høiland-Jørgensen 
---
 info.c |2 +
 phy.c  |  116 
 2 files changed, 118 insertions(+)

diff --git a/info.c b/info.c
index be68571..fbf3ee0 100644
--- a/info.c
+++ b/info.c
@@ -686,6 +686,8 @@ broken_combination:
ext_feat_print(tb, 
NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211,
   "CONTROL_PORT_OVER_NL80211",
   "control port over nl80211");
+   ext_feat_print(tb, NL80211_EXT_FEATURE_TXQS,
+  "TXQS", "FQ-CoDel-enabled intermediate TXQs");
}
 
if (tb_msg[NL80211_ATTR_COALESCE_RULE]) {
diff --git a/phy.c b/phy.c
index be31820..77df7a7 100644
--- a/phy.c
+++ b/phy.c
@@ -727,3 +727,119 @@ COMMAND(set, antenna, " | all |  ",
NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_antenna,
"Set a bitmap of allowed antennas to use for TX and RX.\n"
"The driver may reject antenna configurations it cannot support.");
+
+static int handle_set_txq(struct nl80211_state *state,
+ struct nl_msg *msg,
+ int argc, char **argv,
+ enum id_input id)
+{
+   unsigned int argval;
+   char *end;
+
+   if (argc != 2)
+   return 1;
+
+   if (!*argv[0] || !*argv[1])
+   return 1;
+
+   argval = strtoul(argv[1], , 10);
+
+   if (*end)
+   return 1;
+
+   if (!argval)
+   return 1;
+
+   if (strcmp("limit", argv[0]) == 0)
+   NLA_PUT_U32(msg, NL80211_ATTR_TXQ_LIMIT, argval);
+   else if (strcmp("memory_limit", argv[0]) == 0)
+   NLA_PUT_U32(msg, NL80211_ATTR_TXQ_MEMORY_LIMIT, argval);
+   else if (strcmp("quantum", argv[0]) == 0)
+   NLA_PUT_U32(msg, NL80211_ATTR_TXQ_QUANTUM, argval);
+   else
+   return -1;
+
+   return 0;
+ nla_put_failure:
+   return -ENOBUFS;
+}
+COMMAND(set, txq, "limit  | memory_limit  | quantum ",
+   NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_set_txq,
+   "Set TXQ parameters. The limit and memory_limit are global queue 
limits\n"
+   "for the whole phy. The quantum is the DRR scheduler quantum setting.\n"
+   "Valid values: 1 - 2**32");
+
+static int print_txq_handler(struct nl_msg *msg, void *arg)
+{
+   struct nlattr *attrs[NL80211_ATTR_MAX + 1];
+   struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+   struct nlattr *txqstats_info[NL80211_TXQ_STATS_MAX + 1], *txqinfo;
+   static struct nla_policy txqstats_policy[NL80211_TXQ_STATS_MAX + 1] = {
+   [NL80211_TXQ_STATS_BACKLOG_PACKETS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_BACKLOG_BYTES] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_OVERLIMIT] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_OVERMEMORY] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_COLLISIONS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_MAX_FLOWS] = { .type = NLA_U32 },
+   };
+
+   nla_parse(attrs, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+ genlmsg_attrlen(gnlh, 0), NULL);
+
+
+   if (attrs[NL80211_ATTR_TXQ_LIMIT])
+   printf("Packet limit:\t\t%u pkts\n",
+   nla_get_u32(attrs[NL80211_ATTR_TXQ_LIMIT]));
+   if (attrs[NL80211_ATTR_TXQ_MEMORY_LIMIT])
+   printf("Memory limit:\t\t%u bytes\n",
+   nla_get_u32(attrs[NL80211_ATTR_TXQ_MEMORY_LIMIT]));
+   if (attrs[NL80211_ATTR_TXQ_QUANTUM])
+   printf("Quantum:\t\t%u bytes\n",
+   nla_get_u32(attrs[NL80211_ATTR_TXQ_QUANTUM]));
+
+   if (attrs[NL80211_ATTR_TXQ_STATS]) {
+   if (nla_parse_nested(txqstats_info, NL80211_TXQ_STATS_MAX,
+attrs[NL80211_ATTR_TXQ_STATS],
+txqstats_policy)) {
+   printf("failed to parse nested TXQ stats attributes!");
+   return 0;
+   }
+   txqinfo = txqstats_info[NL80211_TXQ_STATS_MAX_FLOWS];
+   if (txqinfo)
+   printf("Number of queues:\t%u\n", nla_get_u32(txqinfo));
+
+   txqinfo = txqstats_info[NL80211_TXQ_STATS_BACKLOG_PACKETS];
+   if (txqinfo)
+   printf("Backlog:\t\t%u 

[PATCH v2 1/2] iw: Print TXQ statistics for stations and interfaces

[Toke Høiland-Jørgensen]

This adds printing of TXQ statistics for stations and interfaces when
supplied by the kernel. For stations, another section is added when verbose
mode is enabled; for interfaces, the multicast queue information is always
printed when available.

This is the information also available through debugfs in
/sys/kernel/debug/ieee80211/phyX/netdev:Y/aqm and
/sys/kernel/debug/ieee80211/phyX/netdev:Y/stations/*/aqm.

Sample output:

$ iw dev wlp2s0 station dump -v
Station xx:xx:xx:xx:xx:xx (on wlp2s0)
[...]
TXQs:
TID qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol 
tx-bytestx-packets
0   0   0   0   0   0   0   0   
0   0
1   0   0   0   0   0   0   0   
0   0
2   0   0   0   0   0   0   0   
0   0
3   0   0   0   0   0   0   0   
0   0
4   0   0   0   0   0   0   0   
0   0
5   0   0   0   0   0   0   0   
0   0
6   0   0   0   0   0   0   0   
0   0
7   0   0   0   0   0   0   0   
0   0
8   0   0   0   0   0   0   0   
0   0
9   0   0   0   0   0   0   0   
0   0
10  0   0   0   0   0   0   0   
0   0
11  0   0   0   0   0   0   0   
0   0
12  0   0   0   0   0   0   0   
0   0
13  0   0   0   0   0   0   0   
0   0
14  0   0   0   0   0   0   0   
0   0
15  0   0   0   0   0   0   0   
0   0
[...]

$ iw dev wlp2s0 info
Interface wlp2s0
ifindex 9
wdev 0x1
addr xx:xx:xx:xx:xx:xx
type AP
wiphy 0
channel 165 (5825 MHz), width: 20 MHz, center1: 5825 MHz
txpower 24.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol 
tx-bytestx-packets
0   0   72  0   0   0   0   7380
72

Signed-off-by: Toke Høiland-Jørgensen 
---
 interface.c |6 +
 iw.h|2 ++
 station.c   |   71 ++-
 3 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/interface.c b/interface.c
index a19c83f..712bbdc 100644
--- a/interface.c
+++ b/interface.c
@@ -441,6 +441,12 @@ static int print_iface_handler(struct nl_msg *msg, void 
*arg)
   indent, txp / 100, txp % 100);
}
 
+   if (tb_msg[NL80211_ATTR_TXQ_STATS]) {
+   char buf[150];
+   parse_txq_stats(buf, sizeof(buf), 
tb_msg[NL80211_ATTR_TXQ_STATS], 1, -1, indent);
+   printf("%s\tmulticast TXQ:%s\n", indent, buf);
+   }
+
return NL_SKIP;
 }
 
diff --git a/iw.h b/iw.h
index ee7ca20..47aa27d 100644
--- a/iw.h
+++ b/iw.h
@@ -183,6 +183,8 @@ unsigned char *parse_hex(char *hex, size_t *outlen);
 int parse_keys(struct nl_msg *msg, char **argv, int argc);
 int parse_freqchan(struct chandef *chandef, bool chan, int argc, char **argv, 
int *parsed);
 enum nl80211_chan_width str_to_bw(const char *str);
+int parse_txq_stats(char *buf, int buflen, struct nlattr *tid_stats_attr, int 
header,
+   int tid, const char *indent);
 int put_chandef(struct nl_msg *msg, struct chandef *chandef);
 
 void print_ht_mcs(const __u8 *mcs);
diff --git a/station.c b/station.c
index 4885dc0..38c5f91 100644
--- a/station.c
+++ b/station.c
@@ -43,6 +43,62 @@ static void print_power_mode(struct nlattr *a)
}
 }
 
+int parse_txq_stats(char *buf, int buflen, struct nlattr *tid_stats_attr, int 
header,
+   int tid, const char *indent)
+{
+   struct nlattr *txqstats_info[NL80211_TXQ_STATS_MAX + 1], *txqinfo;
+   static struct nla_policy txqstats_policy[NL80211_TXQ_STATS_MAX + 1] = {
+   [NL80211_TXQ_STATS_BACKLOG_BYTES] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_BACKLOG_PACKETS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_FLOWS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_DROPS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_ECN_MARKS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_OVERLIMIT] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_COLLISIONS] = { .type = NLA_U32 },
+ 

[PATCH v2 2/2] mac80211: Support the new cfg80211 TXQ stats API

[Toke Høiland-Jørgensen]

This adds support to mac80211 to export TXQ stats via the newly added
cfg80211 API.

Signed-off-by: Toke Høiland-Jørgensen 
---
 net/mac80211/cfg.c |   99 
 net/mac80211/ieee80211_i.h |3 +
 net/mac80211/main.c|3 +
 net/mac80211/sta_info.c|   12 +
 net/mac80211/tx.c  |   20 +
 5 files changed, 137 insertions(+)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 85dbaa891059..670ad48cf555 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2376,6 +2376,11 @@ static int ieee80211_set_wiphy_params(struct wiphy 
*wiphy, u32 changed)
(WIPHY_PARAM_RETRY_SHORT | WIPHY_PARAM_RETRY_LONG))
ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_RETRY_LIMITS);
 
+   if (changed & (WIPHY_PARAM_TXQ_LIMIT |
+  WIPHY_PARAM_TXQ_MEMORY_LIMIT |
+  WIPHY_PARAM_TXQ_QUANTUM))
+   ieee80211_txq_set_params(local);
+
return 0;
 }
 
@@ -3705,6 +3710,99 @@ static int ieee80211_set_multicast_to_unicast(struct 
wiphy *wiphy,
return 0;
 }
 
+void ieee80211_fill_txq_stats(struct cfg80211_txq_stats *txqstats,
+ struct txq_info *txqi)
+{
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_BACKLOG_BYTES))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_BACKLOG_BYTES);
+   txqstats->backlog_bytes = txqi->tin.backlog_bytes;
+   }
+
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_BACKLOG_PACKETS))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_BACKLOG_PACKETS);
+   txqstats->backlog_packets = txqi->tin.backlog_packets;
+   }
+
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_FLOWS))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_FLOWS);
+   txqstats->flows = txqi->tin.flows;
+   }
+
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_DROPS))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_DROPS);
+   txqstats->drops = txqi->cstats.drop_count;
+   }
+
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_ECN_MARKS))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_ECN_MARKS);
+   txqstats->ecn_marks = txqi->cstats.ecn_mark;
+   }
+
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_OVERLIMIT))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_OVERLIMIT);
+   txqstats->overlimit = txqi->tin.overlimit;
+   }
+
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_COLLISIONS))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_COLLISIONS);
+   txqstats->collisions = txqi->tin.collisions;
+   }
+
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_TX_BYTES))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_TX_BYTES);
+   txqstats->tx_bytes = txqi->tin.tx_bytes;
+   }
+
+   if (!(txqstats->filled & BIT(NL80211_TXQ_STATS_TX_PACKETS))) {
+   txqstats->filled |= BIT(NL80211_TXQ_STATS_TX_PACKETS);
+   txqstats->tx_packets = txqi->tin.tx_packets;
+   }
+}
+
+static int ieee80211_get_txq_stats(struct wiphy *wiphy,
+  struct wireless_dev *wdev,
+  struct cfg80211_txq_stats *txqstats)
+{
+   struct ieee80211_local *local = wiphy_priv(wiphy);
+   struct ieee80211_sub_if_data *sdata;
+   int ret = 0;
+
+   if (!local->ops->wake_tx_queue)
+   return 1;
+
+   spin_lock_bh(>fq.lock);
+   rcu_read_lock();
+
+   if (wdev) {
+   sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
+   if (!sdata->vif.txq) {
+   ret = 1;
+   goto out;
+   }
+   ieee80211_fill_txq_stats(txqstats, to_txq_info(sdata->vif.txq));
+   } else {
+   /* phy stats */
+   txqstats->filled |= (BIT(NL80211_TXQ_STATS_BACKLOG_PACKETS) |
+BIT(NL80211_TXQ_STATS_BACKLOG_BYTES) |
+BIT(NL80211_TXQ_STATS_OVERLIMIT) |
+BIT(NL80211_TXQ_STATS_OVERMEMORY) |
+BIT(NL80211_TXQ_STATS_COLLISIONS) |
+BIT(NL80211_TXQ_STATS_MAX_FLOWS));
+   txqstats->backlog_packets = local->fq.backlog;
+   txqstats->backlog_bytes = local->fq.memory_usage;
+   txqstats->overlimit = local->fq.overlimit;
+   txqstats->overmemory = local->fq.overmemory;
+   txqstats->collisions = local->fq.collisions;
+   txqstats->max_flows = local->fq.flows_cnt;
+   }
+
+out:
+   rcu_read_unlock();
+   spin_unlock_bh(>fq.lock);
+
+   return ret;
+}
+
 const struct cfg80211_ops mac80211_config_ops = {
.add_virtual_intf = ieee80211_add_iface,

[PATCH v2 1/2] cfg80211: Expose TXQ stats and parameters to userspace

[Toke Høiland-Jørgensen]

This adds support for exporting the mac80211 TXQ stats via nl80211 by
way of a nested TXQ stats attribute, as well as for configuring the
quantum and limits that were previously only changeable through debugfs.

This commit adds just the nl80211 API, a subsequent commit adds support to
mac80211 itself.

Signed-off-by: Toke Høiland-Jørgensen 
---
 include/net/cfg80211.h   |   50 ++
 include/uapi/linux/nl80211.h |   58 
 net/mac80211/ethtool.c   |   32 ---
 net/wireless/nl80211.c   |  202 --
 net/wireless/rdev-ops.h  |   12 ++
 net/wireless/trace.h |   14 +++
 net/wireless/wext-compat.c   |   23 +++--
 7 files changed, 343 insertions(+), 48 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5e888ec62811..8db6071b6063 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1079,6 +1079,37 @@ struct sta_bss_parameters {
u16 beacon_interval;
 };
 
+/**
+ * struct cfg80211_txq_stats - TXQ statistics for this TID
+ * @filled: bitmap of flags using the bits of  nl80211_txq_stats to
+ * indicate the relevant values in this struct are filled
+ * @backlog_bytes: total number of bytes currently backlogged
+ * @backlog_packets: total number of packets currently backlogged
+ * @flows: number of new flows seen
+ * @drops: total number of packets dropped
+ * @ecn_marks: total number of packets marked with ECN CE
+ * @overlimit: number of drops due to queue space overflow
+ * @overmemory: number of drops due to memory limit overflow
+ * @collisions: number of hash collisions
+ * @tx_bytes: total number of bytes dequeued
+ * @tx_packets: total number of packets dequeued
+ * @max_flows: maximum number of flows supported
+ */
+struct cfg80211_txq_stats {
+   u32 filled;
+   u32 backlog_bytes;
+   u32 backlog_packets;
+   u32 flows;
+   u32 drops;
+   u32 ecn_marks;
+   u32 overlimit;
+   u32 overmemory;
+   u32 collisions;
+   u32 tx_bytes;
+   u32 tx_packets;
+   u32 max_flows;
+};
+
 /**
  * struct cfg80211_tid_stats - per-TID statistics
  * @filled: bitmap of flags using the bits of  nl80211_tid_stats to
@@ -1088,6 +1119,7 @@ struct sta_bss_parameters {
  * @tx_msdu_retries: number of retries (not counting the first) for
  * transmitted MSDUs
  * @tx_msdu_failed: number of failed transmitted MSDUs
+ * @txq_stats: TXQ statistics
  */
 struct cfg80211_tid_stats {
u32 filled;
@@ -1095,6 +1127,7 @@ struct cfg80211_tid_stats {
u64 tx_msdu;
u64 tx_msdu_retries;
u64 tx_msdu_failed;
+   struct cfg80211_txq_stats txq_stats;
 };
 
 #define IEEE80211_MAX_CHAINS   4
@@ -2204,6 +2237,9 @@ enum cfg80211_connect_params_changed {
  * @WIPHY_PARAM_RTS_THRESHOLD: wiphy->rts_threshold has changed
  * @WIPHY_PARAM_COVERAGE_CLASS: coverage class changed
  * @WIPHY_PARAM_DYN_ACK: dynack has been enabled
+ * @WIPHY_PARAM_TXQ_LIMIT: TXQ packet limit has been changed
+ * @WIPHY_PARAM_TXQ_MEMORY_LIMIT: TXQ memory limit has been changed
+ * @WIPHY_PARAM_TXQ_QUANTUM: TXQ scheduler quantum
  */
 enum wiphy_params_flags {
WIPHY_PARAM_RETRY_SHORT = 1 << 0,
@@ -2212,6 +2248,9 @@ enum wiphy_params_flags {
WIPHY_PARAM_RTS_THRESHOLD   = 1 << 3,
WIPHY_PARAM_COVERAGE_CLASS  = 1 << 4,
WIPHY_PARAM_DYN_ACK = 1 << 5,
+   WIPHY_PARAM_TXQ_LIMIT   = 1 << 6,
+   WIPHY_PARAM_TXQ_MEMORY_LIMIT= 1 << 7,
+   WIPHY_PARAM_TXQ_QUANTUM = 1 << 8,
 };
 
 /**
@@ -2964,6 +3003,9 @@ struct cfg80211_external_auth_params {
  *
  * @set_multicast_to_unicast: configure multicast to unicast conversion for BSS
  *
+ * @get_txq_stats: Get TXQ stats for interface or phy. If wdev is %NULL, this
+ *  function should return phy stats, and interface stats otherwise.
+ *
  * @set_pmk: configure the PMK to be used for offloaded 802.1X 4-Way handshake.
  * If not deleted through @del_pmk the PMK remains valid until disconnect
  * upon which the driver should clear it.
@@ -3265,6 +3307,10 @@ struct cfg80211_ops {
struct net_device *dev,
const bool enabled);
 
+   int (*get_txq_stats)(struct wiphy *wiphy,
+struct wireless_dev *wdev,
+struct cfg80211_txq_stats *txqstats);
+
int (*set_pmk)(struct wiphy *wiphy, struct net_device *dev,
   const struct cfg80211_pmk_conf *conf);
int (*del_pmk)(struct wiphy *wiphy, struct net_device *dev,
@@ -3943,6 +3989,10 @@ struct wiphy {
 
u8 nan_supported_bands;
 
+   u32 txq_limit;
+   u32 txq_memory_limit;
+   u32 txq_quantum;
+
char priv[0] __aligned(NETDEV_ALIGN);
 };
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 8e55b63ed3ff..6bfb39db828e 100644
--- 

Re: [PATCH 1/3] cfg80211: Expose TXQ stats and parameters to userspace

[Toke Høiland-Jørgensen]

Johannes Berg  writes:

> On Tue, 2018-05-08 at 12:18 +0200, Toke Høiland-Jørgensen wrote:
>> Johannes Berg  writes:
>> 
>> > net/mac80211/cfg.c:3762:12: warning: context imbalance in
>> > 'ieee80211_get_txq_stats' - different lock contexts for basic block
>> 
>> Found and fixed all the other warnings, but I'm not seeing this one. And
>> I don't really see what is wrong with the locking in that function? What
>> am I missing?
>
> Oh and what's wrong is that you "return 1" from the function with a lock
> held in one place, IIRC.

Ohhh, right... I already fixed that in my local branch, which is why I
can't find it I guess :D

-Toke

Re: [PATCH 1/3] cfg80211: Expose TXQ stats and parameters to userspace

[Johannes Berg]

On Mon, 2018-02-19 at 18:02 +0100, Toke Høiland-Jørgensen wrote:
> +static int ieee80211_get_txq_stats(struct wiphy *wiphy,
> +  struct wireless_dev *wdev,
> +  struct cfg80211_txq_stats *txqstats)
> +{
> +   struct ieee80211_local *local = wiphy_priv(wiphy);
> +   struct ieee80211_sub_if_data *sdata;
> +
> +   if (!local->ops->wake_tx_queue)
> +   return 1;
> +
> +   spin_lock_bh(>fq.lock);
> +   rcu_read_lock();
> +
> +   if (wdev) {
> +   sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
> +   if (!sdata->vif.txq)
> +   return 1;

here.

btw, it'd be nice to split it into cfg80211 and mac80211 separate
patches.

johannes

Re: [PATCH 1/3] cfg80211: Expose TXQ stats and parameters to userspace

[Johannes Berg]

On Tue, 2018-05-08 at 12:18 +0200, Toke Høiland-Jørgensen wrote:
> Johannes Berg  writes:
> 
> > net/mac80211/cfg.c:3762:12: warning: context imbalance in
> > 'ieee80211_get_txq_stats' - different lock contexts for basic block
> 
> Found and fixed all the other warnings, but I'm not seeing this one. And
> I don't really see what is wrong with the locking in that function? What
> am I missing?

Oh and what's wrong is that you "return 1" from the function with a lock
held in one place, IIRC.

johannes

Re: [PATCH 1/3] cfg80211: Expose TXQ stats and parameters to userspace

[Johannes Berg]

On Tue, 2018-05-08 at 12:18 +0200, Toke Høiland-Jørgensen wrote:
> Johannes Berg  writes:
> 
> > net/mac80211/cfg.c:3762:12: warning: context imbalance in
> > 'ieee80211_get_txq_stats' - different lock contexts for basic block
> 
> Found and fixed all the other warnings, but I'm not seeing this one. And
> I don't really see what is wrong with the locking in that function? What
> am I missing?

This probably came up with sparse/smatch only, I run both sparse and
smatch from "make C=1"

johannes

Re: [PATCH 1/3] cfg80211: Expose TXQ stats and parameters to userspace

[Toke Høiland-Jørgensen]

Johannes Berg  writes:

> net/mac80211/cfg.c:3762:12: warning: context imbalance in
> 'ieee80211_get_txq_stats' - different lock contexts for basic block

Found and fixed all the other warnings, but I'm not seeing this one. And
I don't really see what is wrong with the locking in that function? What
am I missing?

-Toke

Re: [PATCH 4.17] bcma: fix buffer size caused crash in bcma_core_mips_print_irq()

[Kalle Valo]

Rafał Miłecki  writes:

> From: Rafał Miłecki 
>
> Used buffer wasn't big enough to hold whole strings. Example output of
> this function is:
> [0.180892] bcma: bus0: core 0x0800, irq: 2(S)* 3  4  5  6  D  I
> [0.180948] bcma: bus0: core 0x0812, irq: 2(S)  3* 4  5  6  D  I
> [0.180998] bcma: bus0: core 0x082d, irq: 2(S)  3  4* 5  6  D  I
> [0.181046] bcma: bus0: core 0x082c, irq: 2(S)  3  4  5  6  D  I*
> which means we need to store up to 24 chars.
>
> Fixes: 758f7e06063a8 ("bcma: Use bcma_debug and not pr_cont in MIPS driver")
> Signed-off-by: Rafał Miłecki 
> Cc: sta...@vger.kernel.org # v4.15+

I'll queue this for 4.17.

-- 
Kalle Valo

[PATCH 4.17] bcma: fix buffer size caused crash in bcma_core_mips_print_irq()

[Rafał Miłecki]

From: Rafał Miłecki 

Used buffer wasn't big enough to hold whole strings. Example output of
this function is:
[0.180892] bcma: bus0: core 0x0800, irq: 2(S)* 3  4  5  6  D  I
[0.180948] bcma: bus0: core 0x0812, irq: 2(S)  3* 4  5  6  D  I
[0.180998] bcma: bus0: core 0x082d, irq: 2(S)  3  4* 5  6  D  I
[0.181046] bcma: bus0: core 0x082c, irq: 2(S)  3  4  5  6  D  I*
which means we need to store up to 24 chars.

Fixes: 758f7e06063a8 ("bcma: Use bcma_debug and not pr_cont in MIPS driver")
Signed-off-by: Rafał Miłecki 
Cc: sta...@vger.kernel.org # v4.15+
---
 drivers/bcma/driver_mips.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index f040aba48d50..27e9686b6d3a 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -184,7 +184,7 @@ static void bcma_core_mips_print_irq(struct bcma_device 
*dev, unsigned int irq)
 {
int i;
static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
-   char interrupts[20];
+   char interrupts[25];
char *ints = interrupts;
 
for (i = 0; i < ARRAY_SIZE(irq_name); i++)
-- 
2.13.6

Re: RTL8723BE performance regression

[Pkshih]

On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 1, 2018 at 10:58 PM, Pkshih  wrote:
> > On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> >>
> >> > -Original Message-
> >> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> > To: Larry Finger
> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> >> > Chaoming_Li; Kalle Valo;
> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo 
> >> > Rechi Vita; linux@endless
> m.c
> >> om
> >> > Subject: Re: RTL8723BE performance regression
> >> >
> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger  
> >> > wrote:
> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> > >>
> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> >> > >> 
> >> > >> wrote:
> >> > >>
> >> > >> (...)
> >> > >>
> >> > >>> As the antenna selection code changes affected your first bisection, 
> >> > >>> do
> >> > >>> you
> >> > >>> have one of those HP laptops with only one antenna and the incorrect
> >> > >>> coding
> >> > >>> in the FUSE?
> >> > >>
> >> > >>
> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> > >> was needed to achieve a good performance in the past, before this
> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> > >> card.
> >> > >>
> >> > >>> If so, please make sure that you still have the same signal
> >> > >>> strength for good and bad cases. I have tried to keep the driver and 
> >> > >>> the
> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> > >>>
> >> > >>
> >> > >> What is the recommended way to monitor the signal strength?
> >> > >
> >> > >
> >> > > The btcoex code is developed for multiple platforms by a different 
> >> > > group
> >> > > than the Linux driver. I think they made a change that caused ant_sel 
> >> > > to
> >> > > switch from 1 to 2. At least numerous comments at
> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that 
> >> > > change.
> >> > >
> >> > > Mhy recommended method is to verify the wifi device name with "iw 
> >> > > dev". Then
> >> > > using that device
> >> > >
> >> > > sudo iw dev  scan | egrep "SSID|signal"
> >> > >
> >> >
> >> > I have confirmed that the performance regression is indeed tied to
> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> > also switched to testing bandwidth in controlled LAN environment using
> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> > iperf3 server connected via ethernet.
> >> >
> >>
> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: 
> >> cleanup
> >> 8723be ant_sel definition"). You can use the above commit and do the same
> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your 
> >> results.
> >> Since performance is tied to signal strength, you can only share signal 
> >> strength.
> >>
> >
> > Please pay attention to cold reboot once ant_sel is changed.
> >
> 
> I've tested the commit mentioned above and it fixes the problem on top
> of v4.16 (in addition to the latest wireless-drivers-next also been
> fixed as it already contains such commit). On v4.15, we also need the
> following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
> definition" to have a good performance again:
> 
>   874e837d67d0 rtlwifi: fill FW version and subversion
>   a44709bba70f rtlwifi: btcoex: Add power_on_setting routine
>   40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex

v4.15 isn't longterm version and had been EOL.

> 
> Surprisingly, it seems forcing ant_sel=1 is not needed anymore on
> these machines, as the shown by the numbers bellow (ant_sel=0 means
> that actually no parameter was passed to the module). I have powered
> off the machine and done a cold boot for every test. It seems
> something have changed in the antenna auto-selection code since v4.11,
> the latest point where I could confirm we definitely need to force
> ant_sel=1. I've been trying to understand what causes this difference,
> but haven't made progress on that so far, so any suggestions are
> appreciated (we are trying to decide if we can confidently drop the
> downstream DMI quirks for these specific machines).
> 
I think your rtl8723be module programed correct efuse content, so it
works properly with ant_sel=0, and quirk isn't required for your
machine.

>   w-d-n ant_sel=0: -14.00 dBm,  69.5 Mbps -> good
>   w-d-n ant_sel=1: -10.00 dBm,  41.1 Mbps -> good
>   w-d-n ant_sel=2: -44.00 

[PATCH] net: wireless: ath: ath9k: Fix a possible data race in ath_chanctx_set_next

[Jia-Ju Bai]

The write operation to "sc->next_chan" is protected by
the lock on line 1287, but the read operation to
this data on line 1262 is not protected by the lock.
Thus, there may exist a data race for "sc->next_chan".

To fix this data race, the read operation to "sc->next_chan" 
should be also protected by the lock.

Signed-off-by: Jia-Ju Bai 
---
 drivers/net/wireless/ath/ath9k/channel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/channel.c 
b/drivers/net/wireless/ath/ath9k/channel.c
index 1b05b5d7a038..ed3cd5523481 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1257,12 +1257,12 @@ void ath_chanctx_set_next(struct ath_softc *sc, bool 
force)
"Stopping current chanctx: %d\n",
sc->cur_chan->chandef.center_freq1);
sc->cur_chan->stopped = true;
-   spin_unlock_bh(>chan_lock);
 
if (sc->next_chan == >offchannel.chan) {
getrawmonotonic();
measure_time = true;
}
+   spin_unlock_bh(>chan_lock);
 
ath9k_chanctx_stop_queues(sc, sc->cur_chan);
queues_stopped = true;
-- 
2.17.0

Re: [PATCH] brcmfmac: Add support for bcm43364 wireless chipset

[Ulf Hansson]

On 4 May 2018 at 08:48, Sean Lanigan  wrote:
> Add support for the BCM43364 chipset via an SDIO interface, as used in
> e.g. the Murata 1FX module.
>
> The BCM43364 uses the same firmware as the BCM43430 (which is already
> included), the only difference is the omission of Bluetooth.
>
> However, the SDIO_ID for the BCM43364 is 02D0:A9A4, giving it a MODALIAS
> of sdio:c00v02D0dA9A4, which doesn't get recognised and hence doesn't
> load the brcmfmac module. Adding the 'A9A4' ID in the appropriate place
> triggers the brcmfmac driver to load, and then correctly use the
> firmware file 'brcmfmac43430-sdio.bin'.
>
>
> Signed-off-by: Sean Lanigan 

Acked-by: Ulf Hansson 

Arend, I assume you want to pick this up? If not, just tell and I can do it.

Kind regards
Uffe

> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
>  include/linux/mmc/sdio_ids.h  | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index 0b68240..4648a3d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -963,6 +963,7 @@ static const struct sdio_device_id brcmf_sdmmc_ids[] = {
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43340),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43341),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43362),
> +   BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43364),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4335_4339),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4339),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43430),
> diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
> index cdd66a5..0a7abe8 100644
> --- a/include/linux/mmc/sdio_ids.h
> +++ b/include/linux/mmc/sdio_ids.h
> @@ -35,6 +35,7 @@
>  #define SDIO_DEVICE_ID_BROADCOM_4335_4339  0x4335
>  #define SDIO_DEVICE_ID_BROADCOM_4339   0x4339
>  #define SDIO_DEVICE_ID_BROADCOM_43362  0xa962
> +#define SDIO_DEVICE_ID_BROADCOM_43364  0xa9a4
>  #define SDIO_DEVICE_ID_BROADCOM_43430  0xa9a6
>  #define SDIO_DEVICE_ID_BROADCOM_4345   0x4345
>  #define SDIO_DEVICE_ID_BROADCOM_43455  0xa9bf
> --
> 2.7.4
>