Re: [PATCH] staging: wilc1000: check for kmalloc allocation failures

[Joe Perches]

On Wed, 2018-03-21 at 19:19 +, Colin King wrote:
> From: Colin Ian King 
> 
> There are three kmalloc allocations that are not null checked which
> potentially could lead to null pointer dereference issues. Fix this
> by adding null pointer return checks.

looks like all of these should be kmemdup or kstrdup

> Detected by CoverityScan, CID#1466025-27 ("Dereference null return")
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/wilc1000/host_interface.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c 
> b/drivers/staging/wilc1000/host_interface.c
> index 5082ede720f0..9b9b86654958 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -944,6 +944,10 @@ static s32 handle_connect(struct wilc_vif *vif,
>  
>   if (conn_attr->bssid) {
>   hif_drv->usr_conn_req.bssid = kmalloc(6, GFP_KERNEL);
> + if (!hif_drv->usr_conn_req.bssid) {
> + result = -ENOMEM;
> + goto error;
> + }
>   memcpy(hif_drv->usr_conn_req.bssid, conn_attr->bssid, 6);
>   }
>  
> @@ -951,6 +955,10 @@ static s32 handle_connect(struct wilc_vif *vif,
>   if (conn_attr->ssid) {
>   hif_drv->usr_conn_req.ssid = kmalloc(conn_attr->ssid_len + 1,
>GFP_KERNEL);
> + if (!hif_drv->usr_conn_req.ssid) {
> + result = -ENOMEM;
> + goto error;
> + }
>   memcpy(hif_drv->usr_conn_req.ssid,
>  conn_attr->ssid,
>  conn_attr->ssid_len);
> @@ -961,6 +969,10 @@ static s32 handle_connect(struct wilc_vif *vif,
>   if (conn_attr->ies) {
>   hif_drv->usr_conn_req.ies = kmalloc(conn_attr->ies_len,
>   GFP_KERNEL);
> + if (!hif_drv->usr_conn_req.ies) {
> + result = -ENOMEM;
> + goto error;
> + }
>   memcpy(hif_drv->usr_conn_req.ies,
>  conn_attr->ies,
>  conn_attr->ies_len);

[PATCH] staging: wilc1000: check for kmalloc allocation failures

[Colin King]

From: Colin Ian King 

There are three kmalloc allocations that are not null checked which
potentially could lead to null pointer dereference issues. Fix this
by adding null pointer return checks.

Detected by CoverityScan, CID#1466025-27 ("Dereference null return")

Signed-off-by: Colin Ian King 
---
 drivers/staging/wilc1000/host_interface.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 5082ede720f0..9b9b86654958 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -944,6 +944,10 @@ static s32 handle_connect(struct wilc_vif *vif,
 
if (conn_attr->bssid) {
hif_drv->usr_conn_req.bssid = kmalloc(6, GFP_KERNEL);
+   if (!hif_drv->usr_conn_req.bssid) {
+   result = -ENOMEM;
+   goto error;
+   }
memcpy(hif_drv->usr_conn_req.bssid, conn_attr->bssid, 6);
}
 
@@ -951,6 +955,10 @@ static s32 handle_connect(struct wilc_vif *vif,
if (conn_attr->ssid) {
hif_drv->usr_conn_req.ssid = kmalloc(conn_attr->ssid_len + 1,
 GFP_KERNEL);
+   if (!hif_drv->usr_conn_req.ssid) {
+   result = -ENOMEM;
+   goto error;
+   }
memcpy(hif_drv->usr_conn_req.ssid,
   conn_attr->ssid,
   conn_attr->ssid_len);
@@ -961,6 +969,10 @@ static s32 handle_connect(struct wilc_vif *vif,
if (conn_attr->ies) {
hif_drv->usr_conn_req.ies = kmalloc(conn_attr->ies_len,
GFP_KERNEL);
+   if (!hif_drv->usr_conn_req.ies) {
+   result = -ENOMEM;
+   goto error;
+   }
memcpy(hif_drv->usr_conn_req.ies,
   conn_attr->ies,
   conn_attr->ies_len);
-- 
2.15.1

Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

[Greg KH]

On Wed, Mar 21, 2018 at 04:28:46PM +, Nipun Gupta wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Wednesday, March 21, 2018 15:05
> > To: Nipun Gupta 
> > Cc: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk;
> > m.szyprow...@samsung.com; bhelg...@google.com; zaj...@gmail.com;
> > andy.gr...@linaro.org; david.br...@linaro.org; dan.j.willi...@intel.com;
> > vinod.k...@intel.com; thierry.red...@gmail.com; robh...@kernel.org;
> > frowand.l...@gmail.com; jarkko.sakki...@linux.intel.com;
> > rafael.j.wyso...@intel.com; dmitry.torok...@gmail.com; jo...@kernel.org;
> > msucha...@suse.de; linux-ker...@vger.kernel.org; iommu@lists.linux-
> > foundation.org; linux-wireless@vger.kernel.org; linux-arm-
> > m...@vger.kernel.org; linux-...@vger.kernel.org; dmaeng...@vger.kernel.org;
> > dri-de...@lists.freedesktop.org; linux-te...@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Bhushan
> > ; Leo Li 
> > Subject: Re: [PATCH v2 2/2] drivers: remove force dma flag from buses
> > 
> > On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote:
> > > With each bus implementing its own DMA configuration callback,
> > > there is no need for bus to explicitly have force_dma in its
> > > global structure. This patch modifies of_dma_configure API to
> > > accept an input parameter which specifies if implicit DMA
> > > configuration is required even when it is not described by the
> > > firmware.
> > 
> > Having to "remember" what that bool variable means on the end of the
> > function call is a royal pain over time, right?
> > 
> > Why not just create a new function:
> > dma_common_configure_force(dma)
> > that always does this?  Leave "dma_common_configure()" alone, and then
> > wrap the old code with these two helper functions that call the 'core'
> > code with the bool set properly?
> > 
> > That way you do not have to "know" what that parameter is, the function
> > name just documents it automatically, so when you see it in the
> > bus-specific code, no need to go and have to hunt for anything.  And if
> > you are reading the dma core code, it's obvious what is happening as the
> > functions are all right there.
> 
> How about we do not pass any flag in 'dma_common_configure()', and inside this
> API we pass "true" to 'of_dma_configure()'? I am saying this because currently
> both the busses (platform and AMBA) which uses 'dma_common_configure()' passes
> "true" value. If we create additional 'dma_common_configure_force()', then
> 'dma_common_configure()' will not be used anytime and will become redundant.
> 
> If someday new busses come and they needs to use similar functionality which
> 'dma_common_configure()' provides, but with passing "false" to 
> 'of_dma_configure()',
> then what you suggests of having two separate such API's will be more 
> reasonable
> and can be implemented?

If that makes things "simple", yes, sounds good.

greg k-h

Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

[Greg KH]

On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if implicit DMA
> configuration is required even when it is not described by the
> firmware.

Having to "remember" what that bool variable means on the end of the
function call is a royal pain over time, right?

Why not just create a new function:
dma_common_configure_force(dma)
that always does this?  Leave "dma_common_configure()" alone, and then
wrap the old code with these two helper functions that call the 'core'
code with the bool set properly?

That way you do not have to "know" what that parameter is, the function
name just documents it automatically, so when you see it in the
bus-specific code, no need to go and have to hunt for anything.  And if
you are reading the dma core code, it's obvious what is happening as the
functions are all right there.

thanks,

greg k-h

Re: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Greg KH]

On Wed, Mar 21, 2018 at 12:25:22PM +0530, Nipun Gupta wrote:
> It's bus specific aspect to map a given device on the bus and
> relevant firmware description of its DMA configuration.
> So, this change introduces '/dma_configure/' as bus callback
> giving flexibility to busses for implementing its own dma
> configuration function.
> 
> The change eases the addition of new busses w.r.t. adding the dma
> configuration functionality.
> 
> This patch also updates the PCI, Platform, ACPI and host1x bus to
> use new introduced callbacks.
> 
> Suggested-by: Christoph Hellwig 
> Signed-off-by: Nipun Gupta 
> ---
>  - The patches are based on the comments on:
>https://patchwork.kernel.org/patch/10259087/
> 
> Changes in v2:
>   - Do not have dma_deconfigure callback
>   - Have '/dma_common_configure/' API to provide a common DMA
> configuration which can be used by busses if it suits them.
>   - Platform and ACPI bus to use '/dma_common_configure/' in
> '/dma_configure/' callback.
>   - Updated commit message
>   - Updated pci_dma_configure API with changes suggested by Robin
> 
>  drivers/amba/bus.c  |  7 +++
>  drivers/base/dma-mapping.c  | 35 +++
>  drivers/base/platform.c |  6 ++
>  drivers/gpu/host1x/bus.c|  9 +
>  drivers/pci/pci-driver.c| 32 
>  include/linux/device.h  |  4 
>  include/linux/dma-mapping.h |  1 +
>  7 files changed, 74 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 594c228..2fa1e8b 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -171,6 +172,11 @@ static int amba_pm_runtime_resume(struct device *dev)
>  }
>  #endif /* CONFIG_PM */
>  
> +static int amba_dma_configure(struct device *dev)
> +{
> + return dma_common_configure(dev);
> +}
> +
>  static const struct dev_pm_ops amba_pm = {
>   .suspend= pm_generic_suspend,
>   .resume = pm_generic_resume,
> @@ -194,6 +200,7 @@ struct bus_type amba_bustype = {
>   .dev_groups = amba_dev_groups,
>   .match  = amba_match,
>   .uevent = amba_uevent,
> + .dma_configure  = amba_dma_configure,
>   .pm = _pm,
>   .force_dma  = true,
>  };
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index 3b11835..48f9af0 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -331,38 +331,33 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
> unsigned long vm_flags)
>  #endif
>  
>  /*
> - * Common configuration to enable DMA API use for a device
> + * Common configuration to enable DMA API use for a device.
> + * A bus can use this function in its 'dma_configure' callback, if
> + * suitable for the bus.
>   */
> -#include 
> -
> -int dma_configure(struct device *dev)
> +int dma_common_configure(struct device *dev)
>  {
> - struct device *bridge = NULL, *dma_dev = dev;
>   enum dev_dma_attr attr;
>   int ret = 0;
>  
> - if (dev_is_pci(dev)) {
> - bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> - dma_dev = bridge;
> - if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
> - dma_dev->parent->of_node)
> - dma_dev = dma_dev->parent;
> - }
> -
> - if (dma_dev->of_node) {
> - ret = of_dma_configure(dev, dma_dev->of_node);
> - } else if (has_acpi_companion(dma_dev)) {
> - attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
> + if (dev->of_node) {
> + ret = of_dma_configure(dev, dev->of_node);
> + } else if (has_acpi_companion(dev)) {
> + attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
>   if (attr != DEV_DMA_NOT_SUPPORTED)
>   ret = acpi_dma_configure(dev, attr);
>   }
>  
> - if (bridge)
> - pci_put_host_bridge_device(bridge);
> -
>   return ret;
>  }
>  
> +int dma_configure(struct device *dev)
> +{
> + if (dev->bus->dma_configure)
> + return dev->bus->dma_configure(dev);
> +
> + return 0;
> +}
>  void dma_deconfigure(struct device *dev)

Empty line after this new function?  Sorry, couldn't help it :)

>  {
>   of_dma_deconfigure(dev);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index f1bf7b3..d2d5891 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1130,6 +1130,11 @@ int platform_pm_restore(struct device *dev)
>  
>  #endif /* CONFIG_HIBERNATE_CALLBACKS */
>  
> +static int platform_dma_configure(struct device *dev)
> +{
> + return dma_common_configure(dev);
> +}
> +
>  static const struct dev_pm_ops platform_dev_pm_ops = {
>   .runtime_suspend = pm_generic_runtime_suspend,
>   .runtime_resume = 

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

[Greg KH]

On Tue, Mar 20, 2018 at 06:24:09PM +, Luis R. Rodriguez wrote:
> On Tue, Mar 20, 2018 at 06:38:01PM +0100, Greg KH wrote:
> > On Tue, Mar 20, 2018 at 05:34:09PM +, Luis R. Rodriguez wrote:
> > > On Tue, Mar 20, 2018 at 09:30:55AM +0100, Greg KH wrote:
> > > > On Sat, Mar 10, 2018 at 06:15:00AM -0800, Luis R. Rodriguez wrote:
> > > > > +EXPORT_SYMBOL_GPL(request_firmware_cache);
> > > > 
> > > > I know you are just following the existing naming scheme, but please
> > > > let's not continue the problem here.  Can you prefix all of the firmware
> > > > exported symbols with "firmware_", and then the verb.  So this would be
> > > > "firmware_request_cache",
> > > 
> > > Sure.
> > > 
> > > >  and the older function would be
> > > > "firmware_request_direct".
> > > 
> > > Sure, so you want to also rename the old exported symbols, and add a macro
> > > or static inline to enable use of the older names?
> > 
> > Renaming is best, let's not keep them around for no good reason :)
> 
> Sure thing, I'll rename the old firmware calls.

Ah, in looking at this closer, that might take a bit of time, as there
are a _lot_ of callers of request_firmware().  So maybe a macro/wrapper
is good for that one so we can propagate the changes through the
different subsystems and do this over a few kernel releases.

But for anything new, let's get it right the first time :)

thanks,

greg k-h

Re: [PATCH v3] iw: avgerage ack rssi changes for data frames

[Johannes Berg]

On Thu, 2018-03-08 at 12:49 +0530, Balaji Pothunoori wrote:
> This patch is to display the average ack rssi for data
> frames. "avg ack signal" field diplay limited by host based on
> firmware capablities.

I no longer have a corresponding kernel patch pending, so this is
useless?

johannes

Re: [PATCH] mac80211: add ieee80211_hw flag for QoS NDP support

[Johannes Berg]

On Mon, 2018-03-19 at 12:57 +1300, Ben Caradoc-Davies wrote:
> Commit 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing") adds an
> argument qos_ok to ieee80211_nullfunc_get to support QoS NDP. Despite
> the claim in the commit log "Change all the drivers to *not* allow
> QoS NDP for now, even though it looks like most of them should be OK
> with that", this commit enables QoS NDP in response to beacons (see
> change to mlme.c:ieee80211_send_nullfunc), causing ath9k_htc to lose
> IP connectivity. See:
> https://patchwork.kernel.org/patch/10241109/
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060
> 
> This patch replaces the argument qos_ok of ieee80211_nullfunc_get
> with an ieee80211_hw flag that drivers can use to declare support for
> QoS NDP, allowing consistent behaviour between mlme.c and drivers.

A version identifier (as in "[PATCH v3]" in the subject) would help :-)

I've applied a modified version of this patch - it will also require
setting the new "broken" flag in the driver.

johannes

[PATCH v4] mac80211: add ieee80211_hw flag for QoS NDP support

[Johannes Berg]

From: Ben Caradoc-Davies 

Commit 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing") added an
argument qos_ok to ieee80211_nullfunc_get to support QoS NDP. Despite
the claim in the commit log "Change all the drivers to *not* allow
QoS NDP for now, even though it looks like most of them should be OK
with that", this commit enables QoS NDP in response to beacons (see
change to mlme.c:ieee80211_send_nullfunc), causing ath9k_htc to lose
IP connectivity. See:
https://patchwork.kernel.org/patch/10241109/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060

Introduce a hardware flag to allow such buggy drivers to override the
correct default behaviour of mac80211 of sending QoS NDP packets.

Signed-off-by: Ben Caradoc-Davies 
Signed-off-by: Johannes Berg 
---
 include/net/mac80211.h | 4 
 net/mac80211/debugfs.c | 1 +
 net/mac80211/mlme.c| 3 ++-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index c96511fa9198..2b581bd93812 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2063,6 +2063,9 @@ struct ieee80211_txq {
  * @IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA: Hardware supports buffer STA on
  * TDLS links.
  *
+ * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
+ * support QoS NDP for AP probing - that's most likely a driver bug.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2106,6 +2109,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_REPORTS_LOW_ACK,
IEEE80211_HW_SUPPORTS_TX_FRAG,
IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA,
+   IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 1f466d12a6bc..94c7ee9df33b 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -212,6 +212,7 @@ static const char *hw_flag_names[] = {
FLAG(REPORTS_LOW_ACK),
FLAG(SUPPORTS_TX_FRAG),
FLAG(SUPPORTS_TDLS_BUFFER_STA),
+   FLAG(DOESNT_SUPPORT_QOS_NDP),
 #undef FLAG
 };
 
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 39b660b9a908..5f303abac5ad 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -896,7 +896,8 @@ void ieee80211_send_nullfunc(struct ieee80211_local *local,
struct ieee80211_hdr_3addr *nullfunc;
struct ieee80211_if_managed *ifmgd = >u.mgd;
 
-   skb = ieee80211_nullfunc_get(>hw, >vif, true);
+   skb = ieee80211_nullfunc_get(>hw, >vif,
+   !ieee80211_hw_check(>hw, DOESNT_SUPPORT_QOS_NDP));
if (!skb)
return;
 
-- 
2.15.1

[PATCH] ath9k_htc: use non-QoS NDP for AP probing

[Johannes Berg]

From: Johannes Berg 

When switching mac80211 to use QoS NDP, it turned out that
ath9k_htc is somehow broken by this, e.g. see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060.

Fix this by using the new mac80211 flag to go back to the
old, incorrect, behaviour for this driver.

Fixes: 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing")
Reported-by: Ben Caradoc-Davies 
Signed-off-by: Johannes Berg 
---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index e89e5ef2c2a4..f246e9ed4a81 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -729,6 +729,7 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
ieee80211_hw_set(hw, SPECTRUM_MGMT);
ieee80211_hw_set(hw, SIGNAL_DBM);
ieee80211_hw_set(hw, AMPDU_AGGREGATION);
+   ieee80211_hw_set(hw, DOESNT_SUPPORT_QOS_NDP);
 
if (ath9k_ps_enable)
ieee80211_hw_set(hw, SUPPORTS_PS);
-- 
2.15.1

[PATCH] ath: Remove unnecessary ath_bcast_mac and use eth_broadcast_addr

[Joe Perches]

Remove the static array and use the generic routine to set the
Ethernet broadcast address.

Signed-off-by: Joe Perches 
---
 drivers/net/wireless/ath/ath.h| 2 --
 drivers/net/wireless/ath/ath5k/attach.c   | 2 +-
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +-
 drivers/net/wireless/ath/ath9k/init.c | 2 +-
 4 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index f3f2784f6ebd..7a364eca46d6 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -33,8 +33,6 @@
  */
 #defineATH_KEYMAX  128 /* max key cache size we handle 
*/
 
-static const u8 ath_bcast_mac[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-
 struct ath_ani {
bool caldone;
unsigned int longcal_timer;
diff --git a/drivers/net/wireless/ath/ath5k/attach.c 
b/drivers/net/wireless/ath/ath5k/attach.c
index 233054bd6b52..12d3a6c92ba4 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -327,7 +327,7 @@ int ath5k_hw_init(struct ath5k_hw *ah)
ath5k_hw_set_lladdr(ah, zero_mac);
 
/* Set BSSID to bcast address: ff:ff:ff:ff:ff:ff for now */
-   memcpy(common->curbssid, ath_bcast_mac, ETH_ALEN);
+   eth_broadcast_addr(common->curbssid);
ath5k_hw_set_bssid(ah);
ath5k_hw_set_opmode(ah, ah->opmode);
 
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index e89e5ef2c2a4..bf36bb2821b4 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -591,7 +591,7 @@ static void ath9k_init_misc(struct ath9k_htc_priv *priv)
 {
struct ath_common *common = ath9k_hw_common(priv->ah);
 
-   memcpy(common->bssidmask, ath_bcast_mac, ETH_ALEN);
+   eth_broadcast_addr(common->bssidmask);
 
common->last_rssi = ATH_RSSI_DUMMY_MARKER;
priv->ah->opmode = NL80211_IFTYPE_STATION;
diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index e479fae5aab9..748becee3ecf 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -427,7 +427,7 @@ static void ath9k_init_misc(struct ath_softc *sc)
timer_setup(>ani.timer, ath_ani_calibrate, 0);
 
common->last_rssi = ATH_RSSI_DUMMY_MARKER;
-   memcpy(common->bssidmask, ath_bcast_mac, ETH_ALEN);
+   eth_broadcast_addr(common->bssidmask);
sc->beacon.slottime = 9;
 
for (i = 0; i < ARRAY_SIZE(sc->beacon.bslot); i++)
-- 
2.15.0

Re: [PATCH 00/11] staging: wilc1000: fix for checkpatch and handled malloc memory properly

[Ajay Singh]

Hi Dan,

On Wed, 21 Mar 2018 10:51:16 +0300
Dan Carpenter  wrote:

> These look good.  I've reviewed them all.
> 
> Reviewed-by: Dan Carpenter 

Thanks for reviewing all the patches.

> 
> I had some small process complaints but it doesn't make life easier for
> me if you resend them and I have to review everything twice :P
> 

In future patches, I will take care as per your suggestions. Instead of
resubmitting this patch series, I will include the additional changes
required for [PATCH 01/11] in separate patch series.


Regards,
Ajay

Re: [PATCH 2/2] cfg80211: Modify wiphy registration semantics for self managed hints

[Johannes Berg]

So I really think this should just be one patch - it's not about
"registration semantics" but about which types of requests get passed
to reg_notifier(), and if you do it in one place you'd better also do
it in the other.

Secondly, this changes behaviour - not only for ath which presumably is
what you want, but also for
 * brcmfmac
 * brcmsmac
 * libertas
 * mwifiex
 * mt76
 * qtnfmac
 * rtlwifi (& its staging cousin)
 * rsi
 * wlcore
 * rtl8723bs (staging)

So I'm not really convinced we should do this unconditionally.

johannes

Re: [RFC v5 3/9] nl80211: Add CONTROL_PORT_OVER_NL80211 attribute

[Johannes Berg]

On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:
> 
> + if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]) {
> + if (!info->attrs[NL80211_ATTR_SOCKET_OWNER])
> + return -EINVAL;
> 
There might be value in adding GENL_SET_ERR_MSG() calls to new
instances of -EINVAL, but if you don't want to do that now I won't
insist (and perhaps add some when I apply the patches).

johannes

[PATCH] mac80211_hwsim: fix secondary MAC address assignment

[Johannes Berg]

From: Johannes Berg 

OR'ing in 0x40 before a memcpy() to overwrite the value doesn't
do much good - flip the order of operations are reported and
tested by Jouni.

Fixes: cb1a5bae5684 ("mac80211_hwsim: add permanent mac address option for new 
radios")
Reported-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
---
 drivers/net/wireless/mac80211_hwsim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 7b6c3640a94f..930ddef91093 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2584,8 +2584,8 @@ static int mac80211_hwsim_new_radio(struct genl_info 
*info,
addr[4] = idx;
memcpy(data->addresses[0].addr, addr, ETH_ALEN);
/* Why need here second address ? */
-   data->addresses[1].addr[0] |= 0x40;
memcpy(data->addresses[1].addr, addr, ETH_ALEN);
+   data->addresses[1].addr[0] |= 0x40;
hw->wiphy->n_addresses = 2;
hw->wiphy->addresses = data->addresses;
/* possible address clash is checked at hash table insertion */
-- 
2.15.1

[PATCH] ath10k: build ce layer in ath10k core module

[Govind Singh]

CE layer is shared between pci and snoc target and results
in duplicate object inclusion if both modules are compiled
together statically and undefined KBUILD_MODNAME if
compiled as module.

Fix this by building ce layer in ath10k core module by
adding ce object inclusion with ATH10K_CE boolean CONFIG.

Signed-off-by: Govind Singh 
---
 drivers/net/wireless/ath/ath10k/Kconfig  |  4 
 drivers/net/wireless/ath/ath10k/Makefile |  4 ++--
 drivers/net/wireless/ath/ath10k/ce.c | 22 ++
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index deb5ae2..d266f27 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -4,12 +4,16 @@ config ATH10K
select ATH_COMMON
select CRC32
select WANT_DEV_COREDUMP
+   select ATH10K_CE
 ---help---
   This module adds support for wireless adapters based on
   Atheros IEEE 802.11ac family of chipsets.
 
   If you choose to build a module, it'll be called ath10k.
 
+config ATH10K_CE
+   bool
+
 config ATH10K_PCI
tristate "Atheros ath10k PCI support"
depends on ATH10K && PCI
diff --git a/drivers/net/wireless/ath/ath10k/Makefile 
b/drivers/net/wireless/ath/ath10k/Makefile
index 6739ac2..536f3df 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -22,10 +22,10 @@ ath10k_core-$(CONFIG_THERMAL) += thermal.o
 ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
 ath10k_core-$(CONFIG_PM) += wow.o
 ath10k_core-$(CONFIG_DEV_COREDUMP) += coredump.o
+ath10k_core-$(CONFIG_ATH10K_CE) += ce.o
 
 obj-$(CONFIG_ATH10K_PCI) += ath10k_pci.o
-ath10k_pci-y += pci.o \
-   ce.o
+ath10k_pci-y += pci.o
 
 ath10k_pci-$(CONFIG_ATH10K_AHB) += ahb.o
 
diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index b9def7b..e7e7b34 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -464,6 +464,7 @@ int ath10k_ce_send_nolock(struct ath10k_ce_pipe *ce_state,
return ce_state->ops->ce_send_nolock(ce_state, per_transfer_context,
buffer, nbytes, transfer_id, flags);
 }
+EXPORT_SYMBOL(ath10k_ce_send_nolock);
 
 void __ath10k_ce_send_revert(struct ath10k_ce_pipe *pipe)
 {
@@ -491,6 +492,7 @@ void __ath10k_ce_send_revert(struct ath10k_ce_pipe *pipe)
 
src_ring->per_transfer_context[src_ring->write_index] = NULL;
 }
+EXPORT_SYMBOL(__ath10k_ce_send_revert);
 
 int ath10k_ce_send(struct ath10k_ce_pipe *ce_state,
   void *per_transfer_context,
@@ -510,6 +512,7 @@ int ath10k_ce_send(struct ath10k_ce_pipe *ce_state,
 
return ret;
 }
+EXPORT_SYMBOL(ath10k_ce_send);
 
 int ath10k_ce_num_free_src_entries(struct ath10k_ce_pipe *pipe)
 {
@@ -525,6 +528,7 @@ int ath10k_ce_num_free_src_entries(struct ath10k_ce_pipe 
*pipe)
 
return delta;
 }
+EXPORT_SYMBOL(ath10k_ce_num_free_src_entries);
 
 int __ath10k_ce_rx_num_free_bufs(struct ath10k_ce_pipe *pipe)
 {
@@ -539,6 +543,7 @@ int __ath10k_ce_rx_num_free_bufs(struct ath10k_ce_pipe 
*pipe)
 
return CE_RING_DELTA(nentries_mask, write_index, sw_index - 1);
 }
+EXPORT_SYMBOL(__ath10k_ce_rx_num_free_bufs);
 
 static int __ath10k_ce_rx_post_buf(struct ath10k_ce_pipe *pipe, void *ctx,
   dma_addr_t paddr)
@@ -622,6 +627,7 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe 
*pipe, u32 nentries)
ath10k_ce_dest_ring_write_index_set(ar, ctrl_addr, write_index);
dest_ring->write_index = write_index;
 }
+EXPORT_SYMBOL(ath10k_ce_rx_update_write_idx);
 
 int ath10k_ce_rx_post_buf(struct ath10k_ce_pipe *pipe, void *ctx,
  dma_addr_t paddr)
@@ -636,6 +642,7 @@ int ath10k_ce_rx_post_buf(struct ath10k_ce_pipe *pipe, void 
*ctx,
 
return ret;
 }
+EXPORT_SYMBOL(ath10k_ce_rx_post_buf);
 
 /*
  * Guts of ath10k_ce_completed_recv_next.
@@ -748,6 +755,7 @@ int ath10k_ce_completed_recv_next_nolock(struct 
ath10k_ce_pipe *ce_state,
per_transfer_ctx,
nbytesp);
 }
+EXPORT_SYMBOL(ath10k_ce_completed_recv_next_nolock);
 
 int ath10k_ce_completed_recv_next(struct ath10k_ce_pipe *ce_state,
  void **per_transfer_contextp,
@@ -766,6 +774,7 @@ int ath10k_ce_completed_recv_next(struct ath10k_ce_pipe 
*ce_state,
 
return ret;
 }
+EXPORT_SYMBOL(ath10k_ce_completed_recv_next);
 
 static int _ath10k_ce_revoke_recv_next(struct ath10k_ce_pipe *ce_state,
   void **per_transfer_contextp,
@@ -882,6 +891,7 @@ int ath10k_ce_revoke_recv_next(struct ath10k_ce_pipe 
*ce_state,
  per_transfer_contextp,

[PATCH] mac80211_hwsim: Set wmediumd for new radios

[Andrew Zaborowski]

Set the wmediumd to the net's wmediumd when the radio gets created.
Radios created after HWSIM_CMD_REGISTER don't currently get their
data->wmediumd set and the userspace would need to reconnect to
netlink to be able to call HWSIM_CMD_REGISTER again.

Alternatively I think data->netgroup and data->wmedium could be
replaced with a pointer to hwsim_net.

Signed-off-by: Andrew Zaborowski 
---
 drivers/net/wireless/mac80211_hwsim.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index 7b6c3640a9..100cf42db6 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2742,6 +2742,7 @@ static int mac80211_hwsim_new_radio(struct genl_info 
*info,
mutex_init(>mutex);
 
data->netgroup = hwsim_net_get_netgroup(net);
+   data->wmediumd = hwsim_net_get_wmediumd(net);
 
/* Enable frame retransmissions for lossy channels */
hw->max_rates = 4;
-- 
2.14.1

Re: [PATCH 04/11] staging: wilc1000: refactor WILC_WFI_p2p_rx() to avoid line over 80 char

[Dan Carpenter]

This one would have been easier for me to review if it were broken up
slightly differently.  I have a script to review when people split
functions up, but there were a bunch of other stuff so my script gets
confused.

Anyway, looks good.

regards,
dan carpenter

Re: [RFC v5 4/9] cfg80211: Support all iftypes in autodisconnect_wk

[Johannes Berg]

On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:
> Currently autodisconnect_wk assumes that only interface types of
> P2P_CLIENT and STATION use conn_owner_nlportid.  Change this so all
> interface types are supported.

Hmm. This sort of duplicates cfg80211_leave() for the most part, apart
from the special case with cfg80211_mlme_deauth(). I wonder why we need
that, and if we could use cfg80211_leave()?

johannes

Re: [RFC] mac80211: advertise supported interface types for sw encryption

[Johannes Berg]

On Fri, 2018-03-09 at 11:57 +0530, mpubb...@codeaurora.org wrote:
> From: Manikanta Pubbisetty 
> 
> Extending SW_CRYPTO_CONTROL interface so that drivers can advertise
> the interface types on which they can support software encryption.
> Driver's job is not done by advertising the supported vif types alone,
> they should also return -EOPNOTSUPP from set_key.
> 
> Mac80211 will make the fallback decision to sw ecryption based
> on the return type of set_key callback and the driver's support for
> software encryption.
> 
> This change is done with the sole reason of adding the support of
> VLANs for drivers which enable SW_CRYPTO_CONTROL(ex:ath10k).
> 
> With the current logic, configuring GTKs for specific VLAN groups will
> always fail with the drivers enabling SW_CRYPTO_CONTROL. I understand
> that the driver can return 1 from set_key to enable software encryption
> in mac80211, but GTKs for VLANs are never passed down to the driver.
> Since the return value is initialized to -EOPNOTSUPP, with this approach,
> we get away with the failure.

Is there much value in having this control to start with, rather than
saying it's *always* allowed for AP_VLAN interfaces?

I mean - if the driver wants to support (encryption on) AP_VLAN
interfaces with SW_CRYPTO_CONTROL it basically has to set this to allow
it, which is kinda pointless - it's hard to imagine a driver that wants
to support AP_VLAN only for unencrypted, so if it doesn't support this
it might as well just disable AP_VLAN support entirely.

So IMHO - just get rid of the bitmap and hard-code AP_VLAN.

johannes

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Bharat Bhushan
> Sent: Wednesday, March 21, 2018 12:49

> >
> > +int dma_configure(struct device *dev)
> > +{
> > +   if (dev->bus->dma_configure)
> > +   return dev->bus->dma_configure(dev);
> 
> What if dma_common_configure() is called in case "bus->dma_configure" is
> not defined?
> 
> Thanks
> -Bharat

I think it is cleaner for bus to call '/dma_common_configure/' rather
than this been called implicitly, but Robin/Christoph can comment
better on this.

Thanks,
Nipun

Re: [PATCH] mt76: enable MAC80211_LEDS by default

[Arnd Bergmann]

On Wed, Mar 21, 2018 at 6:45 AM, Johannes Berg
 wrote:
> On Fri, 2018-03-16 at 15:45 +0100, Lorenzo Bianconi wrote:
>> --- a/drivers/net/wireless/mediatek/mt76/Kconfig
>> +++ b/drivers/net/wireless/mediatek/mt76/Kconfig
>> @@ -1,5 +1,8 @@
>>  config MT76_CORE
>>   tristate
>> + select MAC80211_LEDS
>
> Should drivers really mess with mac80211's configuration that way? I
> believe this is a user-visible config, no?

We have a couple of drivers using 'select LEDS_CLASS' and others
doing 'depends on LEDS_CLASS'. I think the latter is what we should
have here for all those drivers.

MAC80211_LEDS looks like it's designed to be optional, so nothing
should select or depend on that.

  Arnd

Re: [PATCH 06/11] staging: wilc1000: refactor mgmt_tx to fix line over 80 chars

[Dan Carpenter]

This would have been easier for me if it were split up slightly
different again.

This patch is fine.  I have a couple comments for future patches which
you are free to ignore if you want because it's mostly just my personal
taste.

On Tue, Mar 20, 2018 at 10:25:39PM +0530, Ajay Singh wrote:
> + if (subtype != P2P_INV_REQ && subtype != P2P_INV_RSP) {
> + int vendor_spec_len = sizeof(p2p_vendor_spec);

I'm not a huge fan of making shorter names for sizeof()s just to get
around the 80 character rule.  The 80 character rule is ultimately
supposed to make the code more readable, and this is making less
readable so it's maybe better to just ignore the rule.

> +
> + memcpy(_tx->buff[len], p2p_vendor_spec,
> +vendor_spec_len);
> + mgmt_tx->buff[len + vendor_spec_len] = p2p_local_random;
> + mgmt_tx->size = buf_len;
> + }
> + }
> +}
> +
>  static int mgmt_tx(struct wiphy *wiphy,
>  struct wireless_dev *wdev,
>  struct cfg80211_mgmt_tx_params *params,
> @@ -1568,9 +1620,9 @@ static int mgmt_tx(struct wiphy *wiphy,
>   struct p2p_mgmt_data *mgmt_tx;
>   struct wilc_priv *priv;
>   struct host_if_drv *wfi_drv;
> - u32 i;
>   struct wilc_vif *vif;
>   u32 buf_len = len + sizeof(p2p_vendor_spec) + sizeof(p2p_local_random);
> + int ret = 0;
>  
>   vif = netdev_priv(wdev->netdev);
>   priv = wiphy_priv(wiphy);
> @@ -1580,92 +1632,75 @@ static int mgmt_tx(struct wiphy *wiphy,
>   priv->tx_cookie = *cookie;
>   mgmt = (const struct ieee80211_mgmt *)buf;
>  
> - if (ieee80211_is_mgmt(mgmt->frame_control)) {
> - mgmt_tx = kmalloc(sizeof(struct p2p_mgmt_data), GFP_KERNEL);
> - if (!mgmt_tx)
> - return -EFAULT;
> + if (!ieee80211_is_mgmt(mgmt->frame_control))
> + goto out;


I hate this "goto out;".  My first question when I see it is "what does
goto out; do?"  It's a kind of vague label name.  So I have to scroll
down to the bottom of the function.  And then I'm like "Oh, it doesn't
do anything.  Well that was a waste of time."  And then it occurs to me,
"Huh, what is 'ret' set to?" So now I have to scroll all the way to the
very start of the function...  All this scrolling could be avoided if we
just did a direct "return 0;"

regards,
dan carpenter

Re: [PATCH 09/11] staging: wilc1000: remove line over 80 char in cfg_connect_result()

[Dan Carpenter]

On Tue, Mar 20, 2018 at 10:25:42PM +0530, Ajay Singh wrote:
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index 1b6fe64..af1b8aa 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -460,6 +460,17 @@ static void cfg_scan_result(enum scan_event scan_event,
>   }
>  }
>  
> +static inline bool wilc_wfi_cfg_scan_time_expired(int i)

"i" is the wrong parameter to pass.  The name is not useful.  Probably
the right parameter is either _scanned_shadow[i] or
last_scanned_shadow[i].time_scan_cached.

> +{
> + unsigned long now = jiffies;
> +
> + if (time_after(now, last_scanned_shadow[i].time_scan_cached +
> +(unsigned long)(nl80211_SCAN_RESULT_EXPIRE - (1 * HZ
> + return true;
> + else
> + return false;

Also I think it you apply this patch and then run checkpatch.pl --strict
against the file it will complain that it should be:

if (time_after(now, last_scanned_shadow[i].time_scan_cached +
   (unsigned long)(nl80211_SCAN_RESULT_EXPIRE - (1 * HZ
return true;
return false;

> +}
> +
>  int wilc_connecting;
>  
>  static void cfg_connect_result(enum conn_event conn_disconn_evt,
> @@ -505,17 +516,14 @@ static void cfg_connect_result(enum conn_event 
> conn_disconn_evt,
>   bool scan_refresh = false;
>   u32 i;
>  
> - memcpy(priv->associated_bss, conn_info->bssid, 
> ETH_ALEN);
> + memcpy(priv->associated_bss, conn_info->bssid,
> +ETH_ALEN);
>  

It basically always helps me if the "new function" changes are in a
patch by themselves.  These lines are a pure white space changes and I
have a script that reviews those for me instantly, but when it's mixed
with this patch I have to do it by hand.

regards,
dan carpenter

[PATCH v2 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.

Signed-off-by: Nipun Gupta 
---

Changes in v2:
  - This is a new change suggested by Robin and Christoph
and is added to the series.

 drivers/amba/bus.c| 3 +--
 drivers/base/dma-mapping.c| 4 ++--
 drivers/base/platform.c   | 3 +--
 drivers/bcma/main.c   | 2 +-
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 drivers/gpu/host1x/bus.c  | 5 ++---
 drivers/of/device.c   | 6 --
 drivers/of/of_reserved_mem.c  | 2 +-
 drivers/pci/pci-driver.c  | 3 +--
 include/linux/device.h| 4 
 include/linux/dma-mapping.h   | 2 +-
 include/linux/of_device.h | 4 +++-
 12 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 2fa1e8b..1d58348 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -174,7 +174,7 @@ static int amba_pm_runtime_resume(struct device *dev)
 
 static int amba_dma_configure(struct device *dev)
 {
-   return dma_common_configure(dev);
+   return dma_common_configure(dev, true);
 }
 
 static const struct dev_pm_ops amba_pm = {
@@ -202,7 +202,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure  = amba_dma_configure,
.pm = _pm,
-   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 48f9af0..03f8584 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -335,13 +335,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
  * A bus can use this function in its 'dma_configure' callback, if
  * suitable for the bus.
  */
-int dma_common_configure(struct device *dev)
+int dma_common_configure(struct device *dev, bool force_dma)
 {
enum dev_dma_attr attr;
int ret = 0;
 
if (dev->of_node) {
-   ret = of_dma_configure(dev, dev->of_node);
+   ret = of_dma_configure(dev, dev->of_node, force_dma);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d2d5891..154707c 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1132,7 +1132,7 @@ int platform_pm_restore(struct device *dev)
 
 static int platform_dma_configure(struct device *dev)
 {
-   return dma_common_configure(dev);
+   return dma_common_configure(dev, true);
 }
 
 static const struct dev_pm_ops platform_dev_pm_ops = {
@@ -1148,7 +1148,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
-   .force_dma  = true,
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
 
core->irq = bcma_of_get_irq(parent, core, 0);
 
-   of_dma_configure(>dev, node);
+   of_dma_configure(>dev, node, false);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
-   of_dma_configure(_pdev->dev, child);
+   of_dma_configure(_pdev->dev, child, true);
/*
 * It is assumed that calling of_msi_configure is safe on
 * platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index fa9896d..211eb6b 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
 static int host1x_dma_configure(struct device *dev)
 {
if (dev->of_node)
-   return of_dma_configure(dev, dev->of_node);
+   return of_dma_configure(dev, dev->of_node, true);
 
return 0;
 }
@@ -336,7 +336,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure  = host1x_dma_configure,
.pm = _device_pm_ops,
-   .force_dma = true,
 };
 
 static void 

[PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

It's bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces '/dma_configure/' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.

The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.

This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.

Suggested-by: Christoph Hellwig 
Signed-off-by: Nipun Gupta 
---
 - The patches are based on the comments on:
   https://patchwork.kernel.org/patch/10259087/

Changes in v2:
  - Do not have dma_deconfigure callback
  - Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
  - Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
  - Updated commit message
  - Updated pci_dma_configure API with changes suggested by Robin

 drivers/amba/bus.c  |  7 +++
 drivers/base/dma-mapping.c  | 35 +++
 drivers/base/platform.c |  6 ++
 drivers/gpu/host1x/bus.c|  9 +
 drivers/pci/pci-driver.c| 32 
 include/linux/device.h  |  4 
 include/linux/dma-mapping.h |  1 +
 7 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..2fa1e8b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -171,6 +172,11 @@ static int amba_pm_runtime_resume(struct device *dev)
 }
 #endif /* CONFIG_PM */
 
+static int amba_dma_configure(struct device *dev)
+{
+   return dma_common_configure(dev);
+}
+
 static const struct dev_pm_ops amba_pm = {
.suspend= pm_generic_suspend,
.resume = pm_generic_resume,
@@ -194,6 +200,7 @@ struct bus_type amba_bustype = {
.dev_groups = amba_dev_groups,
.match  = amba_match,
.uevent = amba_uevent,
+   .dma_configure  = amba_dma_configure,
.pm = _pm,
.force_dma  = true,
 };
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..48f9af0 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -331,38 +331,33 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
 #endif
 
 /*
- * Common configuration to enable DMA API use for a device
+ * Common configuration to enable DMA API use for a device.
+ * A bus can use this function in its 'dma_configure' callback, if
+ * suitable for the bus.
  */
-#include 
-
-int dma_configure(struct device *dev)
+int dma_common_configure(struct device *dev)
 {
-   struct device *bridge = NULL, *dma_dev = dev;
enum dev_dma_attr attr;
int ret = 0;
 
-   if (dev_is_pci(dev)) {
-   bridge = pci_get_host_bridge_device(to_pci_dev(dev));
-   dma_dev = bridge;
-   if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
-   dma_dev->parent->of_node)
-   dma_dev = dma_dev->parent;
-   }
-
-   if (dma_dev->of_node) {
-   ret = of_dma_configure(dev, dma_dev->of_node);
-   } else if (has_acpi_companion(dma_dev)) {
-   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
ret = acpi_dma_configure(dev, attr);
}
 
-   if (bridge)
-   pci_put_host_bridge_device(bridge);
-
return ret;
 }
 
+int dma_configure(struct device *dev)
+{
+   if (dev->bus->dma_configure)
+   return dev->bus->dma_configure(dev);
+
+   return 0;
+}
 void dma_deconfigure(struct device *dev)
 {
of_dma_deconfigure(dev);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index f1bf7b3..d2d5891 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,11 @@ int platform_pm_restore(struct device *dev)
 
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
+static int platform_dma_configure(struct device *dev)
+{
+   return dma_common_configure(dev);
+}
+
 static const struct dev_pm_ops platform_dev_pm_ops = {
.runtime_suspend = pm_generic_runtime_suspend,
.runtime_resume = pm_generic_runtime_resume,
@@ -1141,6 +1146,7 @@ struct bus_type platform_bus_type = {
.dev_groups = platform_dev_groups,
.match  = platform_match,
.uevent = platform_uevent,
+   .dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
.force_dma  = 

Re: [PATCH 00/11] staging: wilc1000: fix for checkpatch and handled malloc memory properly

[Dan Carpenter]

These look good.  I've reviewed them all.

Reviewed-by: Dan Carpenter 

I had some small process complaints but it doesn't make life easier for
me if you resend them and I have to review everything twice :P

regards,
dan carpenter

Re: [PATCH] mac80211: notify driver for change in multicast rates

[Johannes Berg]

On Tue, 2018-03-20 at 16:52 -0700, Pradeep Kumar Chitrapu wrote:
> It is required to pass the rate information to driver/firmware
> when rate control is offloaded to firmware. This helps in changing
> multicast traffic rates thereby improving the network performance.

Looks like there are two more places where you should set the new flag?

johannes

Re: [PATCH] ath9k_htc: use non-QoS NDP for AP probing

[Kalle Valo]

Johannes Berg  writes:

> From: Johannes Berg 
>
> When switching mac80211 to use QoS NDP, it turned out that
> ath9k_htc is somehow broken by this, e.g. see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060.
>
> Fix this by using the new mac80211 flag to go back to the
> old, incorrect, behaviour for this driver.
>
> Fixes: 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing")
> Reported-by: Ben Caradoc-Davies 
> Signed-off-by: Johannes Berg 

Acked-by: Kalle Valo 

-- 
Kalle Valo

pull-request: mac80211 2018-03-21

[Johannes Berg]

Hi Dave,

Another few fixes - one for hwsim, so not really all that interesting,
and two patches to work around an ath9k_htc problem.

Note that I pulled your net tree today, so you may need to be careful
to not fast-forward if you don't merge anything else before this.

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit 5f2fb802eee1df0810b47ea251942fe3fd36589a:

  ipv6: old_dport should be a __be16 in __ip6_datagram_connect() (2018-03-20 
12:43:43 -0400)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2018-03-21

for you to fetch changes up to 60b01bcce97191f473fa869df2713143936d6ef4:

  ath9k_htc: use non-QoS NDP for AP probing (2018-03-21 13:01:55 +0100)


Two more fixes (in three patches):
 * ath9k_htc doesn't like QoS NDP frames, use regular ones
 * hwsim: set up wmediumd for radios created later


Andrew Zaborowski (1):
  mac80211_hwsim: Set wmediumd for new radios

Ben Caradoc-Davies (1):
  mac80211: add ieee80211_hw flag for QoS NDP support

Johannes Berg (1):
  ath9k_htc: use non-QoS NDP for AP probing

 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
 drivers/net/wireless/mac80211_hwsim.c | 1 +
 include/net/mac80211.h| 4 
 net/mac80211/debugfs.c| 1 +
 net/mac80211/mlme.c   | 3 ++-
 5 files changed, 9 insertions(+), 1 deletion(-)

[PATCH] brcmfmac: Add timestamp to scan results report

[dimitrysh]

From 01da9ee11ce6e0973972b2ffd37eef660714f71a Mon Sep 17 00:00:00 2001
From: Dmitry Shmidt 
Date: Wed, 21 Mar 2018 15:35:45 -0700
Subject: [PATCH] brcmfmac: Add timestamp to scan results report

Monotonic time from boot is good timestamp indicator
and it can be used by kernel and userspace.

Change-Id: I122374fa79c6dbd7967b2c30553cb04dee032ebc
Signed-off-by: Dmitry Shmidt 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c  
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c

index 4157c90ad973..76d6ed553b7c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2845,6 +2845,8 @@ static s32 brcmf_inform_single_bss(struct  
brcmf_cfg80211_info *cfg,

struct cfg80211_bss *bss;
struct ieee80211_supported_band *band;
struct brcmu_chan ch;
+   struct timespec ts;
+   u64 timestamp;
u16 channel;
u32 freq;
u16 notify_capability;
@@ -2885,10 +2887,12 @@ static s32 brcmf_inform_single_bss(struct  
brcmf_cfg80211_info *cfg,

brcmf_dbg(CONN, "Beacon interval: %d\n", notify_interval);
brcmf_dbg(CONN, "Signal: %d\n", notify_signal);

+   get_monotonic_boottime();
+   timestamp = (u64)ts.tv_sec * 100 + ts.tv_nsec / 1000;
bss = cfg80211_inform_bss(wiphy, notify_channel,
  CFG80211_BSS_FTYPE_UNKNOWN,
  (const u8 *)bi->BSSID,
- 0, notify_capability,
+ timestamp, notify_capability,
  notify_interval, notify_ie,
  notify_ielen, notify_signal,
  GFP_KERNEL);
--
2.17.0.rc0.231.g781580f067-goog

[trivial PATCH V2] treewide: Align function definition open/close braces

[Joe Perches]

Some functions definitions have either the initial open brace and/or
the closing brace outside of column 1.

Move those braces to column 1.

This allows various function analyzers like gnu complexity to work
properly for these modified functions.

Signed-off-by: Joe Perches 
Acked-by: Andy Shevchenko 
Acked-by: Paul Moore 
Acked-by: Alex Deucher 
Acked-by: Dave Chinner 
Reviewed-by: Darrick J. Wong 
Acked-by: Alexandre Belloni 
Acked-by: Martin K. Petersen 
Acked-by: Takashi Iwai 
Acked-by: Mauro Carvalho Chehab 
---

git diff -w still shows no difference.

This patch was sent but December and not applied.

As the trivial maintainer seems not active, it'd be nice if
Andrew Morton picks this up.

V2: Remove fs/xfs/libxfs/xfs_alloc.c as it's updated and remerge the rest

 arch/x86/include/asm/atomic64_32.h   |  2 +-
 drivers/acpi/custom_method.c |  2 +-
 drivers/acpi/fan.c   |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c |  2 +-
 drivers/media/i2c/msp3400-kthreads.c |  2 +-
 drivers/message/fusion/mptsas.c  |  2 +-
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c |  2 +-
 drivers/net/wireless/ath/ath9k/xmit.c|  2 +-
 drivers/platform/x86/eeepc-laptop.c  |  2 +-
 drivers/rtc/rtc-ab-b5ze-s3.c |  2 +-
 drivers/scsi/dpt_i2o.c   |  2 +-
 drivers/scsi/sym53c8xx_2/sym_glue.c  |  2 +-
 fs/locks.c   |  2 +-
 fs/ocfs2/stack_user.c|  2 +-
 fs/xfs/xfs_export.c  |  2 +-
 kernel/audit.c   |  6 +++---
 kernel/trace/trace_printk.c  |  4 ++--
 lib/raid6/sse2.c | 14 +++---
 sound/soc/fsl/fsl_dma.c  |  2 +-
 19 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/arch/x86/include/asm/atomic64_32.h 
b/arch/x86/include/asm/atomic64_32.h
index 46e1ef17d92d..92212bf0484f 100644
--- a/arch/x86/include/asm/atomic64_32.h
+++ b/arch/x86/include/asm/atomic64_32.h
@@ -123,7 +123,7 @@ static inline long long arch_atomic64_read(const atomic64_t 
*v)
long long r;
alternative_atomic64(read, "=" (r), "c" (v) : "memory");
return r;
- }
+}
 
 /**
  * arch_atomic64_add_return - add and return
diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index b33fba70ec51..a07fbe999eb6 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -97,7 +97,7 @@ static void __exit acpi_custom_method_exit(void)
 {
if (cm_dentry)
debugfs_remove(cm_dentry);
- }
+}
 
 module_init(acpi_custom_method_init);
 module_exit(acpi_custom_method_exit);
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index 6cf4988206f2..3563103590c6 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev, 
unsigned long state)
return fan_set_state_acpi4(device, state);
else
return fan_set_state(device, state);
- }
+}
 
 static const struct thermal_cooling_device_ops fan_cooling_ops = {
.get_max_state = fan_get_max_state,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 8394d69b963f..e934326a95d3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -588,7 +588,7 @@ static void disable_dangling_plane(struct dc *dc, struct 
dc_state *context)
  
**/
 
 struct dc *dc_create(const struct dc_init_data *init_params)
- {
+{
struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
unsigned int full_pipe_count;
 
diff --git a/drivers/media/i2c/msp3400-kthreads.c 
b/drivers/media/i2c/msp3400-kthreads.c
index 4dd01e9f553b..dc6cb8d475b3 100644
--- a/drivers/media/i2c/msp3400-kthreads.c
+++ b/drivers/media/i2c/msp3400-kthreads.c
@@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
 }
 
 static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
- {
+{
struct msp_state *state = to_state(i2c_get_clientdata(client));
int source, matrix;
 
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 439ee9c5f535..231f3a1e27bf 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -2967,7 +2967,7 @@ mptsas_exp_repmanufacture_info(MPT_ADAPTER *ioc,
mutex_unlock(>sas_mgmt.mutex);
 out:
  

[PATCH v4 2/3] firmware: add firmware_request_cache() to help with cache on reboot

[Luis R. Rodriguez]

Some devices have an optimization in place to enable the firmware to
be retaineed during a system reboot, so after reboot the device can skip
requesting and loading the firmware. This can save up to 1s in load
time. The mt7601u 802.11 device happens to be such a device.

When these devices retain the firmware on a reboot and then suspend
they can miss looking for the firmware on resume. To help with this we
need a way to cache the firmware when such an optimization has taken
place.

Signed-off-by: Luis R. Rodriguez 
---
 .../driver-api/firmware/request_firmware.rst   | 14 +
 drivers/base/firmware_loader/main.c| 24 ++
 include/linux/firmware.h   |  3 +++
 3 files changed, 41 insertions(+)

diff --git a/Documentation/driver-api/firmware/request_firmware.rst 
b/Documentation/driver-api/firmware/request_firmware.rst
index cc0aea880824..cf4516dfbf96 100644
--- a/Documentation/driver-api/firmware/request_firmware.rst
+++ b/Documentation/driver-api/firmware/request_firmware.rst
@@ -44,6 +44,20 @@ request_firmware_nowait
 .. kernel-doc:: drivers/base/firmware_class.c
:functions: request_firmware_nowait
 
+Special optimizations on reboot
+===
+
+Some devices have an optimization in place to enable the firmware to be
+retained during system reboot. When such optimizations are used the driver
+author must ensure the firmware is still available on resume from suspend,
+this can be done with firmware_request_cache() insted of requesting for the
+firmare to be loaded.
+
+firmware_request_cache()
+---
+.. kernel-doc:: drivers/base/firmware_class.c
+   :functions: firmware_request_cache
+
 request firmware API expected driver use
 
 
diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index 2913bb0e5e7b..eb34089e4299 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -656,6 +656,30 @@ 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
+ * @name: name of firmware file
+ * @device: device for which firmware should be cached for
+ *
+ * There are some devices with an optimization that enables the device to not
+ * require loading firmware on system reboot. This optimization may still
+ * require the firmware present on resume from suspend. This routine can be
+ * used to ensure the firmware is present on resume from suspend in these
+ * situations. This helper is not compatible with drivers which use
+ * request_firmware_into_buf() or request_firmware_nowait() with no uevent set.
+ **/
+int firmware_request_cache(struct device *device, const char *name)
+{
+   int ret;
+
+   mutex_lock(_lock);
+   ret = fw_add_devm_name(device, name);
+   mutex_unlock(_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(firmware_request_cache);
+
 /**
  * request_firmware_into_buf - load firmware into a previously allocated buffer
  * @firmware_p: pointer to firmware image
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index d4508080348d..41050417cafb 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -85,4 +85,7 @@ static inline int request_firmware_into_buf(const struct 
firmware **firmware_p,
 }
 
 #endif
+
+int firmware_request_cache(struct device *device, const char *name);
+
 #endif
-- 
2.16.2

[PATCH v4 1/3] firmware: fix typo on pr_info_once() when ignore_sysfs_fallback is used

[Luis R. Rodriguez]

When the sysctl knob is used ignore the fallback mechanism we pr_info_once()
to ensure its noted the knob was used. The print incorrectly states its a
debugfs knob, its a sysctl knob, so correct this typo.

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

diff --git a/drivers/base/firmware_loader/fallback.c 
b/drivers/base/firmware_loader/fallback.c
index d231bbcb95d7..31b5015b59fe 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -652,7 +652,7 @@ static bool fw_force_sysfs_fallback(unsigned int opt_flags)
 static bool fw_run_sysfs_fallback(unsigned int opt_flags)
 {
if (fw_fallback_config.ignore_sysfs_fallback) {
-   pr_info_once("Ignoring firmware sysfs fallback due to debugfs 
knob\n");
+   pr_info_once("Ignoring firmware sysfs fallback due to sysctl 
knob\n");
return false;
}
 
-- 
2.16.2

[PATCH v4 3/3] mt7601u: use firmware_request_cache() to address cache on reboot

[Luis R. Rodriguez]

request_firmware_cache() will ensure the firmware is available on resume
from suspend if on reboot the device retains the firmware.

This optimization is in place given otherwise on reboot we have to
reload the firmware, the opmization saves us about max 1s, minimum 10ms.

Cantabile has reported back this fixes his woes with both suspend and
hibernation.

Reported-by: Cantabile 
Tested-by: Cantabile 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/wireless/mediatek/mt7601u/mcu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c 
b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index d9d6fd7eff5e..61705f679856 100644
--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -420,7 +420,7 @@ static int mt7601u_load_firmware(struct mt7601u_dev *dev)
 MT_USB_DMA_CFG_TX_BULK_EN));
 
if (firmware_running(dev))
-   return 0;
+   return firmware_request_cache(dev->dev, MT7601U_FIRMWARE);
 
ret = request_firmware(, MT7601U_FIRMWARE, dev->dev);
if (ret)
-- 
2.16.2

[PATCH v4 0/3] firmware: add firmware_request_cache()

[Luis R. Rodriguez]

Greg,

Here are the last straggler patches to clean up what was left which you
requested and to add the new firmware_request_cache() call to fix a
corner case suspend issue.

The extra space character you found in earlier patches no longer needs
to be fixed as that assignement was replaced with a new line in later
patches which does not have the extra space in the assignment. The only
other straggler fix needed which you had pointed out was the debugfs typo.

The new API call was renamed as suggested to firmware_request_cache(),
with the API name first. I'll use a separate series to start addressing
the firmware API rename for the rest of the callers. That will take some
time as I'm running quite a bit of tests on those changes and I am going
to wait for 0-day to give me its blesssings.

Question, feedback, and specially rants are greatly appreciated.

  Luis

Luis R. Rodriguez (3):
  firmware: fix typo on pr_info_once() when ignore_sysfs_fallback is
used
  firmware: add firmware_request_cache() to help with cache on reboot
  mt7601u: use firmware_request_cache() to address cache on reboot

 .../driver-api/firmware/request_firmware.rst   | 14 +
 drivers/base/firmware_loader/fallback.c|  2 +-
 drivers/base/firmware_loader/main.c| 24 ++
 drivers/net/wireless/mediatek/mt7601u/mcu.c|  2 +-
 include/linux/firmware.h   |  3 +++
 5 files changed, 43 insertions(+), 2 deletions(-)

-- 
2.16.2

[PATCH v2] mac80211: notify driver for change in multicast rates

[Pradeep Kumar Chitrapu]

It is required to pass the rate information to driver/firmware
when rate control is offloaded to firmware. This helps in changing
multicast traffic rates thereby improving the network performance.

Signed-off-by: Pradeep Kumar Chitrapu 
---
V2:
  - Set the flag in missing places

 include/net/mac80211.h | 1 +
 net/mac80211/cfg.c | 2 ++
 net/mac80211/ibss.c| 2 +-
 net/mac80211/mesh.c| 3 ++-
 net/mac80211/util.c| 3 ++-
 5 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 4c99c13..4360765 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -336,6 +336,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_OCB = 1<<22,
BSS_CHANGED_MU_GROUPS   = 1<<23,
BSS_CHANGED_KEEP_ALIVE  = 1<<24,
+   BSS_CHANGED_MCAST_RATE  = 1<<25,
 
/* when adding here, make sure to change ieee80211_reconfig */
 };
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 0763792..22bb82e 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2313,6 +2313,8 @@ static int ieee80211_set_mcast_rate(struct wiphy *wiphy, 
struct net_device *dev,
memcpy(sdata->vif.bss_conf.mcast_rate, rate,
   sizeof(int) * NUM_NL80211_BANDS);
 
+   ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_MCAST_RATE);
+
return 0;
 }
 
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index e9c6aa3..f4b0634 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1840,7 +1840,7 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data 
*sdata,
  IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED
| IEEE80211_HT_PARAM_RIFS_MODE;
 
-   changed |= BSS_CHANGED_HT;
+   changed |= BSS_CHANGED_HT | BSS_CHANGED_MCAST_RATE;
ieee80211_bss_info_change_notify(sdata, changed);
 
sdata->smps_mode = IEEE80211_SMPS_OFF;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 277398d..55c04e1 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -884,7 +884,8 @@ int ieee80211_start_mesh(struct ieee80211_sub_if_data 
*sdata)
  BSS_CHANGED_BEACON_ENABLED |
  BSS_CHANGED_HT |
  BSS_CHANGED_BASIC_RATES |
- BSS_CHANGED_BEACON_INT;
+ BSS_CHANGED_BEACON_INT |
+ BSS_CHANGED_MCAST_RATE;
 
local->fif_other_bss++;
/* mesh ifaces must set allmulti to forward mcast traffic */
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 6aef679..6594df0 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1971,7 +1971,8 @@ int ieee80211_reconfig(struct ieee80211_local *local)
  BSS_CHANGED_CQM |
  BSS_CHANGED_QOS |
  BSS_CHANGED_IDLE |
- BSS_CHANGED_TXPOWER;
+ BSS_CHANGED_TXPOWER |
+ BSS_CHANGED_MCAST_RATE;
 
if (sdata->vif.mu_mimo_owner)
changed |= BSS_CHANGED_MU_GROUPS;
-- 
1.9.1

Re: [PATCH] mac80211: aes-cmac: remove VLA usage

[Johannes Berg]

On Wed, 2018-03-21 at 08:42 -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLAs and replace them
> with dynamic memory allocation instead.
> 
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in general, as code evolves it is easy to
> lose track of how big a VLA can get. Thus, we can end up having runtime
> failures that are hard to debug.
> 
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  net/mac80211/aes_cmac.c | 36 
>  1 file changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
> index 2fb6558..c9444bf 100644
> --- a/net/mac80211/aes_cmac.c
> +++ b/net/mac80211/aes_cmac.c
> @@ -27,30 +27,42 @@ static const u8 zero[CMAC_TLEN_256];
>  void ieee80211_aes_cmac(struct crypto_shash *tfm, const u8 *aad,
>   const u8 *data, size_t data_len, u8 *mic)
>  {
> - SHASH_DESC_ON_STACK(desc, tfm);
> + struct shash_desc *shash;
>   u8 out[AES_BLOCK_SIZE];
>  
> - desc->tfm = tfm;
> + shash = kmalloc(sizeof(*shash) + crypto_shash_descsize(tfm),
> + GFP_KERNEL);
> + if (!shash)
> + return;

Honestly, this seems like a really bad idea - you're now hitting
kmalloc for every TX/RX frame here.

SHA_DESC_ON_STACK() should just be fixed to not need a VLA, but take
some sort of maximum, I guess?

johannes

Re: [PATCH] mac80211: aes-cmac: remove VLA usage

[Gustavo A. R. Silva]

On 03/21/2018 08:48 AM, Johannes Berg wrote:

On Wed, 2018-03-21 at 08:42 -0500, Gustavo A. R. Silva wrote:

In preparation to enabling -Wvla, remove VLAs and replace them
with dynamic memory allocation instead.

The use of stack Variable Length Arrays needs to be avoided, as they
can be a vector for stack exhaustion, which can be both a runtime bug
or a security flaw. Also, in general, as code evolves it is easy to
lose track of how big a VLA can get. Thus, we can end up having runtime
failures that are hard to debug.

Also, fixed as part of the directive to remove all VLAs from
the kernel: https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Gustavo A. R. Silva 
---
  net/mac80211/aes_cmac.c | 36 
  1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
index 2fb6558..c9444bf 100644
--- a/net/mac80211/aes_cmac.c
+++ b/net/mac80211/aes_cmac.c
@@ -27,30 +27,42 @@ static const u8 zero[CMAC_TLEN_256];
  void ieee80211_aes_cmac(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
  {
-   SHASH_DESC_ON_STACK(desc, tfm);
+   struct shash_desc *shash;
u8 out[AES_BLOCK_SIZE];
  
-	desc->tfm = tfm;

+   shash = kmalloc(sizeof(*shash) + crypto_shash_descsize(tfm),
+   GFP_KERNEL);
+   if (!shash)
+   return;


Honestly, this seems like a really bad idea - you're now hitting
kmalloc for every TX/RX frame here.

SHA_DESC_ON_STACK() should just be fixed to not need a VLA, but take
some sort of maximum, I guess?



SHA_DESC_ON_STACK is currently being used in multiple places. But, yeah, 
I think we can define multiple macros of the same kind and adjust to the 
characteristics of each the component.


How big do you think tfm can get?

Thanks
--
Gustavo

Re: [PATCH] mac80211: aes-cmac: remove VLA usage

[Gustavo A. R. Silva]

On 03/21/2018 08:58 AM, Johannes Berg wrote:

On Wed, 2018-03-21 at 08:57 -0500, Gustavo A. R. Silva wrote:


SHA_DESC_ON_STACK is currently being used in multiple places. But, yeah,
I think we can define multiple macros of the same kind and adjust to the
characteristics of each the component.

How big do you think tfm can get?


I have no idea, I guess you'll have to take that with Herbert.

johannes



I see. I'll contact him then.

Thanks for the feedback.
--
Gustavo

Re: [RFC v5 0/9] EAPoL over NL80211

[Johannes Berg]

> TODO:

That was well-hidden :)

> - It is unclear to me how AP_VLAN and AP interfaces should synchronize on
> conn_owner_nlportid.  This is required for tx_control_port to work.

I'm not really sure what you mean? Technically I guess an AP_VLAN could
have a different owner from an AP, but if the AP goes down all the
AP_VLANs go down with it already anyway.

> - JOIN_IBSS & JOIN_MESH don't seem to support control_port_ethertype or
> control_port_no_encrypt.  Should struct cfg80211_crypto_settings parsed inside
> nl80211_crypto_settings be added to ibss_params or mesh_config/mesh_setup?

I don't think it matters - they just don't support this now and don't
really need to.

johannes

Re: [PATCH 04/11] staging: wilc1000: refactor WILC_WFI_p2p_rx() to avoid line over 80 char

[Claudiu Beznea]

Also good for me, only one minor thing mentioned below.

On 20.03.2018 18:55, Ajay Singh wrote:
> + if (subtype == GO_NEG_REQ || subtype == GO_NEG_RSP ||
> + subtype == P2P_INV_REQ || subtype == P2P_INV_RSP) {
> + for (i = P2P_PUB_ACTION_SUBTYPE + 2; i < size; i++) {
> + if (buff[i] == P2PELEM_ATTR_ID &&
> + !(memcmp(p2p_oui, [i + 2], 4))) {
You can remove  "(" ")" around memcmp. Your choice.

> + wilc_wfi_cfg_parse_rx_action([i + 6],
> +  size - (i + 6));
> + break;
> + }
> + }
> + }

Re: [PATCH 00/11] staging: wilc1000: fix for checkpatch and handled malloc memory properly

[Claudiu Beznea]

Patch 6 may be reworked a bit. Other than this:

Reviewed-by: Claudiu Beznea 

On 21.03.2018 11:20, Ajay Singh wrote:
> Hi Dan,
> 
> On Wed, 21 Mar 2018 10:51:16 +0300
> Dan Carpenter  wrote:
> 
>> These look good.  I've reviewed them all.
>>
>> Reviewed-by: Dan Carpenter 
> 
> Thanks for reviewing all the patches.
> 
>>
>> I had some small process complaints but it doesn't make life easier for
>> me if you resend them and I have to review everything twice :P
>>
> 
> In future patches, I will take care as per your suggestions. Instead of
> resubmitting this patch series, I will include the additional changes
> required for [PATCH 01/11] in separate patch series.
> 
> 
> Regards,
> Ajay
> 

Re: [PATCH] mac80211: aes-cmac: remove VLA usage

[Johannes Berg]

On Wed, 2018-03-21 at 08:57 -0500, Gustavo A. R. Silva wrote:
> 
> SHA_DESC_ON_STACK is currently being used in multiple places. But, yeah, 
> I think we can define multiple macros of the same kind and adjust to the 
> characteristics of each the component.
> 
> How big do you think tfm can get?

I have no idea, I guess you'll have to take that with Herbert.

johannes

Re: [PATCH 06/11] staging: wilc1000: refactor mgmt_tx to fix line over 80 chars

[Claudiu Beznea]

On 20.03.2018 18:55, Ajay Singh wrote:
> Refactor mgmt_tx() to fix line over 80 characters issue. Split the
> function to avoid the checkpatch.pl warning. Returning the same error
> code in case of memory allocation failure.
> 
> Signed-off-by: Ajay Singh 
> ---
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 187 
> +-
>  1 file changed, 111 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index d7ff0a9..9950ca5 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -1555,6 +1555,58 @@ static int cancel_remain_on_channel(struct wiphy 
> *wiphy,
>   priv->remain_on_ch_params.listen_session_id);
>  }
>  
> +static void wilc_wfi_cfg_tx_vendor_spec(struct p2p_mgmt_data *mgmt_tx,
> + struct cfg80211_mgmt_tx_params *params,
> + u8 iftype, u32 buf_len)
> +{
> + const u8 *buf = params->buf;
> + size_t len = params->len;
> + u32 i;
> + u8 subtype = buf[P2P_PUB_ACTION_SUBTYPE];
> +
> + if (subtype == GO_NEG_REQ || subtype == GO_NEG_RSP) {
> + if (p2p_local_random == 1 &&
> + p2p_recv_random < p2p_local_random) {
I think you can inner this if in the above one. Your choice.

> + get_random_bytes(_local_random, 1);
> + p2p_local_random++;
> + }
> + }
> +
> + if (p2p_local_random > p2p_recv_random && (subtype == GO_NEG_REQ ||
> +subtype == GO_NEG_RSP ||
> +subtype == P2P_INV_REQ ||
> +subtype == P2P_INV_RSP)) {
> + bool found = false;
> + bool oper_ch = false;
> +
> + for (i = P2P_PUB_ACTION_SUBTYPE + 2; i < len; i++) {
> + if (buf[i] == P2PELEM_ATTR_ID &&
> + !(memcmp(p2p_oui, [i + 2], 4))) {
You can remove "(" ")" around memcmp. Again, your choice.

> + if (subtype == P2P_INV_REQ ||
> + subtype == P2P_INV_RSP)
> + oper_ch = true;
> +
> + found = true;
> + break;
> + }
> + }
> +
> + if (found)
> + wilc_wfi_cfg_parse_tx_action(_tx->buff[i + 6],
> +  len - (i + 6), oper_ch,
> +  iftype);
> +
> + if (subtype != P2P_INV_REQ && subtype != P2P_INV_RSP) {
> + int vendor_spec_len = sizeof(p2p_vendor_spec);
> +
> + memcpy(_tx->buff[len], p2p_vendor_spec,
> +vendor_spec_len);
> + mgmt_tx->buff[len + vendor_spec_len] = p2p_local_random;
> + mgmt_tx->size = buf_len;
> + }
> + }
> +}
Looking at wilc_wfi_cfg_tx_vendor_spec() and
wilc_wfi_cfg_parse_rx_vendor_spec() from patch 4 from this series I can see
that conditions in these two are mostly the same but you refactor them
differently. I think the approach in wilc_wfi_cfg_parse_rx_vendor_spec()
from patch 4 is better and can help you avoid usage of bool variables like
found and oper_ch.

For instance, you can have:

static void wilc_wfi_cfg_tx_vendor_spec(struct p2p_mgmt_data *mgmt_tx,
struct cfg80211_mgmt_tx_params *params,
u8 iftype, u32 buf_len)
{
const u8 *buf = params->buf;
size_t len = params->len;
u32 i;
u8 subtype = buf[P2P_PUB_ACTION_SUBTYPE];

if ((subtype == GO_NEG_REQ || subtype == GO_NEG_RSP) &&
p2p_local_random == 1 && p2p_recv_random < p2p_local_random) {
get_random_bytes(_local_random, 1);
p2p_local_random++;
}

if (p2p_local_random <= p2p_recv_random)
return;

if (subtype == GO_NEG_REQ || subtype == GO_NEG_RSP ||
subtype == P2P_INV_REQ || subtype == P2P_INV_RSP) {
for (i = P2P_PUB_ACTION_SUBTYPE + 2; i < len; i++) {
if (buf[i] != P2PELEM_ATTR_ID ||
memcmp(p2p_oui, [i + 2], 4))
continue;

wilc_wfi_cfg_parse_tx_action(_tx->buff[i + 6],
 len - (i + 6),
 (subtype == P2P_INV_REQ ||
  subtype == P2P_INV_RSP),
  iftype);

Re: [RFC v5 3/9] nl80211: Add CONTROL_PORT_OVER_NL80211 attribute

[Denis Kenzior]

Hi Johannes,

On 03/21/2018 02:47 AM, Johannes Berg wrote:

On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:


+   if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]) {
+   if (!info->attrs[NL80211_ATTR_SOCKET_OWNER])
+   return -EINVAL;


There might be value in adding GENL_SET_ERR_MSG() calls to new
instances of -EINVAL, but if you don't want to do that now I won't
insist (and perhaps add some when I apply the patches).



Sure, that sounds easy enough.  Did you see the TODO comments I added in 
RFC v5 0/9 message?  I need your help figuring out how you want to 
handle those.  Those are pretty esoteric though and would require more 
surgery.


Any chance that we can merge the non-controversial bits of this RFC so 
that we can get some wider testing and start encouraging non-mac80211 
based drivers to support these mechanisms?


Regards,
-Denis

Re: [RFC v5 3/9] nl80211: Add CONTROL_PORT_OVER_NL80211 attribute

[Johannes Berg]

On Wed, 2018-03-21 at 10:01 -0500, Denis Kenzior wrote:
> Hi Johannes,
> 
> On 03/21/2018 02:47 AM, Johannes Berg wrote:
> > On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:
> > > 
> > > + if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]) {
> > > + if (!info->attrs[NL80211_ATTR_SOCKET_OWNER])
> > > + return -EINVAL;
> > > 
> > 
> > There might be value in adding GENL_SET_ERR_MSG() calls to new
> > instances of -EINVAL, but if you don't want to do that now I won't
> > insist (and perhaps add some when I apply the patches).
> > 
> 
> Sure, that sounds easy enough.  Did you see the TODO comments I added in 
> RFC v5 0/9 message?  I need your help figuring out how you want to 
> handle those.  Those are pretty esoteric though and would require more 
> surgery.

Sorry, I hadn't. I'll take a look now.

> Any chance that we can merge the non-controversial bits of this RFC so 
> that we can get some wider testing and start encouraging non-mac80211 
> based drivers to support these mechanisms?

Yeah, sure, we can do that.

johannes

Intel Corporation Wireless 8260 [8086:24f3] (rev 3a) - Hardware error in PCI passthrough

[Mohamed Khalfella]

Hi,

I am working in pci passthrough for qemu under SmartOS. My test
machine is Intel NUC Kit NUC6i3SYH BOXNUC6I3SYH which comes with Intel
Wireless 8260 [8086:24f3]. So far the guest OS recognize the PCI
device and the driver, iwlwifi reports an error when it tries to
initialize the device.

Here is what I see in linux guest console https://pastebin.com/cCzEUgGz.
lspci from the guest OS https://pastebin.com/pPS7c1HT
lspci from the host OS, running the same iso image
https://pastebin.com/xLTpw9fz. Host OS regencies the device perfectly.

I did mmio tracing and here are the results
https://docs.google.com/spreadsheets/d/1GFW1JTA9Q5OVh4CQMYYHSQ378j45nP078juewogBIp0/edit?usp=sharing.
For some reason, which I don't know, the guest gets different result
when it reads register 3C. I don't know why does that happen.

My implementation doesn't present PCI extended capabilities, I am not
sure if this is stopping the device to work or not.

Unfortunately, I don't have the device specification to dig deeper
into the issue. The code I am working on is accessible in upci branch
in

upci driver https://github.com/khalfella/illumos-gate
qemu https://github.com/khalfella/illumos-kvm-cmd

Appreciate any hints or ideas.


Thanks,
Mohamed A. Khalfella

Re: [PATCH] mt76: enable MAC80211_LEDS by default

[Arnd Bergmann]

On Wed, Mar 21, 2018, 23:27 Lorenzo Bianconi
 wrote:
>
> On Mar 21, Arnd Bergmann wrote:
> > On Wed, Mar 21, 2018 at 6:45 AM, Johannes Berg
> >  wrote:
> > > On Fri, 2018-03-16 at 15:45 +0100, Lorenzo Bianconi wrote:
> > >> --- a/drivers/net/wireless/mediatek/mt76/Kconfig
> > >> +++ b/drivers/net/wireless/mediatek/mt76/Kconfig
> > >> @@ -1,5 +1,8 @@
> > >>  config MT76_CORE
> > >>   tristate
> > >> + select MAC80211_LEDS
> > >
> > > Should drivers really mess with mac80211's configuration that way? I
> > > believe this is a user-visible config, no?
> >
> > We have a couple of drivers using 'select LEDS_CLASS' and others
> > doing 'depends on LEDS_CLASS'. I think the latter is what we should
> > have here for all those drivers.
> >
> > MAC80211_LEDS looks like it's designed to be optional, so nothing
> > should select or depend on that.
> >
> >   Arnd
>
> Reviewing the current code we do not actually need MAC80211_LEDS, so I agree
> to remove it from Kconfig and let userspace selects the option. I would use
> select for LEDS_CLASS. If you agree I can send a v2 otherwise I fine to apply
> Arnd's patch.
> Felix what do you think?

Looking at mt76 again, my impression is that the core driver should not have
an dependency on LEDS at all, the dependency should instead be restricted
to the CONFIG_MT76_LEDS symbol as my patch from January did (with the
change to 'default y').

  Arnd

Re: [PATCH] mac80211: add ieee80211_hw flag for QoS NDP support

[Ben Caradoc-Davies]

On 21/03/18 22:53, Johannes Berg wrote:

I've applied a modified version of this patch - it will also require
setting the new "broken" flag in the driver.


Thanks very much, Johannes. I have tested your modified patch 
 together with the patch 
 that enables the new 
"broken" flag and they seem to fix the problem (when backported to 
Debian 4.15.11-1).


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

RE: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, March 21, 2018 15:00



> > +int dma_configure(struct device *dev)
> > +{
> > +   if (dev->bus->dma_configure)
> > +   return dev->bus->dma_configure(dev);
> > +
> > +   return 0;
> > +}
> >  void dma_deconfigure(struct device *dev)
> 
> Empty line after this new function?  Sorry, couldn't help it :)
> 
> >  {
> > of_dma_deconfigure(dev);
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index f1bf7b3..d2d5891 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -1130,6 +1130,11 @@ int platform_pm_restore(struct device *dev)
> >
> >  #endif /* CONFIG_HIBERNATE_CALLBACKS */
> >



> > +
> > const struct dev_pm_ops *pm;
> >
> > const struct iommu_ops *iommu_ops;
> > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > index eb9eab4..c15986b 100644
> > --- a/include/linux/dma-mapping.h
> > +++ b/include/linux/dma-mapping.h
> > @@ -761,6 +761,7 @@ void *dma_mark_declared_memory_occupied(struct
> device *dev,
> >  }
> >  #endif /* CONFIG_HAVE_GENERIC_DMA_COHERENT */
> >
> > +int dma_common_configure(struct device *dev);
> >  #ifdef CONFIG_HAS_DMA
> 
> Blank line after the new function declaration?
> 
> Other than those very minor things, nice job, this looks good:
> 
> Reviewed-by: Greg Kroah-Hartman 

Thank you for the review :). I will fix your comments in next version.

Regards,
Nipun

RE: [PATCH v2 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, March 21, 2018 15:05
> To: Nipun Gupta 
> Cc: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk;
> m.szyprow...@samsung.com; bhelg...@google.com; zaj...@gmail.com;
> andy.gr...@linaro.org; david.br...@linaro.org; dan.j.willi...@intel.com;
> vinod.k...@intel.com; thierry.red...@gmail.com; robh...@kernel.org;
> frowand.l...@gmail.com; jarkko.sakki...@linux.intel.com;
> rafael.j.wyso...@intel.com; dmitry.torok...@gmail.com; jo...@kernel.org;
> msucha...@suse.de; linux-ker...@vger.kernel.org; iommu@lists.linux-
> foundation.org; linux-wireless@vger.kernel.org; linux-arm-
> m...@vger.kernel.org; linux-...@vger.kernel.org; dmaeng...@vger.kernel.org;
> dri-de...@lists.freedesktop.org; linux-te...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Bhushan
> ; Leo Li 
> Subject: Re: [PATCH v2 2/2] drivers: remove force dma flag from buses
> 
> On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote:
> > With each bus implementing its own DMA configuration callback,
> > there is no need for bus to explicitly have force_dma in its
> > global structure. This patch modifies of_dma_configure API to
> > accept an input parameter which specifies if implicit DMA
> > configuration is required even when it is not described by the
> > firmware.
> 
> Having to "remember" what that bool variable means on the end of the
> function call is a royal pain over time, right?
> 
> Why not just create a new function:
>   dma_common_configure_force(dma)
> that always does this?  Leave "dma_common_configure()" alone, and then
> wrap the old code with these two helper functions that call the 'core'
> code with the bool set properly?
> 
> That way you do not have to "know" what that parameter is, the function
> name just documents it automatically, so when you see it in the
> bus-specific code, no need to go and have to hunt for anything.  And if
> you are reading the dma core code, it's obvious what is happening as the
> functions are all right there.

How about we do not pass any flag in 'dma_common_configure()', and inside this
API we pass "true" to 'of_dma_configure()'? I am saying this because currently
both the busses (platform and AMBA) which uses 'dma_common_configure()' passes
"true" value. If we create additional 'dma_common_configure_force()', then
'dma_common_configure()' will not be used anytime and will become redundant.

If someday new busses come and they needs to use similar functionality which
'dma_common_configure()' provides, but with passing "false" to 
'of_dma_configure()',
then what you suggests of having two separate such API's will be more reasonable
and can be implemented?

Thanks,
Nipun

> 
> thanks,
> 
> greg k-h

Re: [ath10k throughput] low throughput in multi-user mode

[Ben Greear]

On 03/20/2018 06:44 PM, gary wrote:


Hi all,
I have run the throughput test on veriwave.(from Ethernet to wireless)
My AP suports 4*4, 11ac, mu-mimo.,wireless chip is QCA9984.
At first, the throughput is about 80Mbps only with 16 users, so I force to
return true in function ath10k_mac_tx_can_push().
As a result, when the user number is 1~16, the udp throughput is about
1.2Gbps ~1.4Gbps.
But when the user number is 32, the udp throughput is only 520Mbps.

So I try to substitute ath10k-firmware.
With firmware 10.4-3.4-0082 and above, the throughput is around 520Mbps.
But with firmware 10.4-3.4-0072, the throughput gets 1.1Gbps.

Do I miss something in configuration?
Any comment is appreciated.


What kernel version (or backports, if you are using that?) are you using?

And, I'd be curious how the latest ath10k-CT (beta) firmware compares
if you have time to try that:

http://www.candelatech.com/ath10k-10.4.php

At least in upload testing, we get better throughput with lots of
virtual stations if we tune the number of tx descriptors to be larger
as that will generate larger AMPDUs on air.

You might also check your rate-ctrl logic to make sure all of your
stations are using higher MCS rates.

Thanks,
Ben

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

[PATCH] mac80211: aes-cmac: remove VLA usage

[Gustavo A. R. Silva]

In preparation to enabling -Wvla, remove VLAs and replace them
with dynamic memory allocation instead.

The use of stack Variable Length Arrays needs to be avoided, as they
can be a vector for stack exhaustion, which can be both a runtime bug
or a security flaw. Also, in general, as code evolves it is easy to
lose track of how big a VLA can get. Thus, we can end up having runtime
failures that are hard to debug.

Also, fixed as part of the directive to remove all VLAs from
the kernel: https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Gustavo A. R. Silva 
---
 net/mac80211/aes_cmac.c | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
index 2fb6558..c9444bf 100644
--- a/net/mac80211/aes_cmac.c
+++ b/net/mac80211/aes_cmac.c
@@ -27,30 +27,42 @@ static const u8 zero[CMAC_TLEN_256];
 void ieee80211_aes_cmac(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
 {
-   SHASH_DESC_ON_STACK(desc, tfm);
+   struct shash_desc *shash;
u8 out[AES_BLOCK_SIZE];
 
-   desc->tfm = tfm;
+   shash = kmalloc(sizeof(*shash) + crypto_shash_descsize(tfm),
+   GFP_KERNEL);
+   if (!shash)
+   return;
 
-   crypto_shash_init(desc);
-   crypto_shash_update(desc, aad, AAD_LEN);
-   crypto_shash_update(desc, data, data_len - CMAC_TLEN);
-   crypto_shash_finup(desc, zero, CMAC_TLEN, out);
+   shash->tfm = tfm;
+
+   crypto_shash_init(shash);
+   crypto_shash_update(shash, aad, AAD_LEN);
+   crypto_shash_update(shash, data, data_len - CMAC_TLEN);
+   crypto_shash_finup(shash, zero, CMAC_TLEN, out);
 
memcpy(mic, out, CMAC_TLEN);
+   kfree(shash);
 }
 
 void ieee80211_aes_cmac_256(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
 {
-   SHASH_DESC_ON_STACK(desc, tfm);
+   struct shash_desc *shash;
+
+   shash = kmalloc(sizeof(*shash) + crypto_shash_descsize(tfm),
+   GFP_KERNEL);
+   if (!shash)
+   return;
 
-   desc->tfm = tfm;
+   shash->tfm = tfm;
 
-   crypto_shash_init(desc);
-   crypto_shash_update(desc, aad, AAD_LEN);
-   crypto_shash_update(desc, data, data_len - CMAC_TLEN_256);
-   crypto_shash_finup(desc, zero, CMAC_TLEN_256, mic);
+   crypto_shash_init(shash);
+   crypto_shash_update(shash, aad, AAD_LEN);
+   crypto_shash_update(shash, data, data_len - CMAC_TLEN_256);
+   crypto_shash_finup(shash, zero, CMAC_TLEN_256, mic);
+   kfree(shash);
 }
 
 struct crypto_shash *ieee80211_aes_cmac_key_setup(const u8 key[],
-- 
2.7.4

Re: [RFC v5 4/9] cfg80211: Support all iftypes in autodisconnect_wk

[Denis Kenzior]

Hi Johannes,

On 03/21/2018 02:46 AM, Johannes Berg wrote:

On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:

Currently autodisconnect_wk assumes that only interface types of
P2P_CLIENT and STATION use conn_owner_nlportid.  Change this so all
interface types are supported.


Hmm. This sort of duplicates cfg80211_leave() for the most part, apart
from the special case with cfg80211_mlme_deauth(). I wonder why we need
that, and if we could use cfg80211_leave()?


cfg80211_leave also messes with scans and autodisconnect_wk didn't.  So 
I played it safe as I didn't want to introduce any silent semantic changes.


Also, cfg80211_leave uses stop_ap/leave_ibss with notify argument being 
true, while I thought it made more sense to use false (as there's 
arguably nobody left to pay attention to it) and to be consistent with 
nl80211_stop_ap and nl80211_leave_ibss which also use false.


I don't see an issue with using cfg80211_leave though.  Just tell me 
which way you prefer.


Regards,
-Denis

Re: [RFC v5 0/9] EAPoL over NL80211

[Denis Kenzior]

Hi Johannes,

On 03/21/2018 10:13 AM, Johannes Berg wrote:



TODO:


That was well-hidden :)


Sorry.  I assumed people read the change log :)




- It is unclear to me how AP_VLAN and AP interfaces should synchronize on
conn_owner_nlportid.  This is required for tx_control_port to work.


I'm not really sure what you mean? Technically I guess an AP_VLAN could
have a different owner from an AP, but if the AP goes down all the
AP_VLANs go down with it already anyway.


So the issue is that when mac80211 calls cfg80211_rx_control_port and 
subsequently __nl80211_rx_control_port, we grab the nlportid from the 
wdev.  So if that isn't synchronized, then AP_VLAN devices won't be 
sending the EAPoL frames to the right place.





- JOIN_IBSS & JOIN_MESH don't seem to support control_port_ethertype or
control_port_no_encrypt.  Should struct cfg80211_crypto_settings parsed inside
nl80211_crypto_settings be added to ibss_params or mesh_config/mesh_setup?


I don't think it matters - they just don't support this now and don't
really need to.



Except that the eapol over nl80211 flag is being sent in security 
settings.  This covers STA/AP/P2P_GO/P2P_CLIENT.  We need some way of 
passing this information for mesh & ibss.


Regards,
-Denis

Re: [PATCH] mt76: enable MAC80211_LEDS by default

[Lorenzo Bianconi]

On Mar 21, Arnd Bergmann wrote:
> On Wed, Mar 21, 2018 at 6:45 AM, Johannes Berg
>  wrote:
> > On Fri, 2018-03-16 at 15:45 +0100, Lorenzo Bianconi wrote:
> >> --- a/drivers/net/wireless/mediatek/mt76/Kconfig
> >> +++ b/drivers/net/wireless/mediatek/mt76/Kconfig
> >> @@ -1,5 +1,8 @@
> >>  config MT76_CORE
> >>   tristate
> >> + select MAC80211_LEDS
> >
> > Should drivers really mess with mac80211's configuration that way? I
> > believe this is a user-visible config, no?
> 
> We have a couple of drivers using 'select LEDS_CLASS' and others
> doing 'depends on LEDS_CLASS'. I think the latter is what we should
> have here for all those drivers.
> 
> MAC80211_LEDS looks like it's designed to be optional, so nothing
> should select or depend on that.
> 
>   Arnd

Reviewing the current code we do not actually need MAC80211_LEDS, so I agree
to remove it from Kconfig and let userspace selects the option. I would use
select for LEDS_CLASS. If you agree I can send a v2 otherwise I fine to apply
Arnd's patch.
Felix what do you think?

Regards,
Lorenzo

Re: AP6335 with mainline kernel

[Vanessa Maegima]

Hi Arend,

On Sex, 2018-01-19 at 10:02 +0100, Arend van Spriel wrote:
> On 1/18/2018 12:47 PM, Vanessa Maegima wrote:
> > 
> > Hi Arend,
> > 
> > On Ter, 2018-01-16 at 21:21 +0100, Arend van Spriel wrote:
> > > 
> > > On 1/15/2018 9:08 PM, Fabio Estevam wrote:
> > > > 
> > > > 
> > > > Hi Arend,
> > > > 
> > > > On Tue, Dec 5, 2017 at 12:58 PM, Vanessa Maegima
> > > >  wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > Hi Arend,
> > > > > 
> > > > > Sorry for this!
> > > > > 
> > > > > I updated the folder on https://emea01.safelinks.protection.o
> > > > > utlook.com/?url=https%3A%2F%2Femea01.safelinks.protection.out
> > > > > lo=02%7C01%7Cvanessa.maegima%40nxp.com%7C39040229475441d
> > > > > 7b5aa08d55f1b6cd3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%
> > > > > 7C636519493755298348=Zws4AElm4La96Q4pjK152nH2lP6v4mPJJN
> > > > > xSGz7TLBA%3D=0
> > > > > ok.com/?url=https%3A%2F%2Fdrive.google.com%2Fdrive%2Ffolders%
> > > > > 2F1f
> > > > > osahjL=02%7C01%7Cvanessa.maegima%40nxp.com%7Cf07cd1a6ffb
> > > > > 34c0
> > > > > 961f608d55d1eb901%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> > > > > 7C63
> > > > > 6517308901643244=6JAqSN%2BVPJ%2FCF7cbnBjm8geMKWydWkG9Jc
> > > > > UhGB
> > > > > Pj644%3D=0
> > > > > N1KI5NKS59_aPZdHLpENPFHtK
> > > > > 
> > > > > Thanks!
> > > > Any ideas, please?
> > > Well, the dumps confirm a crash early in the firmware boot.
> > > However,
> > > I
> > > could not obtain more information from it. To capture the failure
> > > I
> > > need
> > > to rework some firmware functionality which is not trivial and I
> > > can
> > > not
> > > claim time for it right now.
> > > 
> > > Regards,
> > > Arend
> > > 
> > Thanks for all your investigation here!
> > 
> > I just want to report one more thing that I noticed from my tests.
> > 
> > I have tried to use an html file that I downloaded using wget as
> > the
> > nvram file (https://emea01.safelinks.protection.outlook.com/?url=ht
> > tps%3A%2F%2Fgithub.com%2FOpenELEC%2Fwlan-
> > firmware%2Fblob%2Fmaster%2Ffirmw=02%7C01%7Cvanessa.maegima%40n
> > xp.com%7C39040229475441d7b5aa08d55f1b6cd3%7C686ea1d3bc2b4c6fa92cd99
> > c5c301635%7C0%7C1%7C636519493755298348=EZFVV3qbStjH9Eqe6uVVXJ
> > f7LmQlMLIURXHaQIMIpms%3D=0
> > are/brcm/nvram_ap6335.txt) and the wifi seems to work. I have not
> > noticed the wrong format file until testing it.
> Interesting. In brcmfmac the file is parsed before sending it to the 
> firmware so I am wondering what is effectively send to the device.
> 
> Can you dump the nvram that is sent to the device. Just add hexdump
> call 
> of nvram in brcmf_fw_request_nvram_done() in firmware.c just before 
> fwctx->done() is called.
> 
> Regards,
> Arend

Sorry for my delayed response, but I could not get the hexdump from the
nvram. I have tried several hexdump functions I found on kernel and on
the brcmfmac driver but none of them printed any output.

Is there any CONFIG I need to enable to get those working?

Thanks!

Best,
Vanessa

Re: [RFC v5 4/9] cfg80211: Support all iftypes in autodisconnect_wk

[Johannes Berg]

On Wed, 2018-03-21 at 10:27 -0500, Denis Kenzior wrote:
> 
> cfg80211_leave also messes with scans and autodisconnect_wk didn't.  So 
> I played it safe as I didn't want to introduce any silent semantic changes.

Makes sense, but we could pass an argument and avoid duplicating the
code?

> Also, cfg80211_leave uses stop_ap/leave_ibss with notify argument being 
> true, while I thought it made more sense to use false (as there's 
> arguably nobody left to pay attention to it) and to be consistent with 
> nl80211_stop_ap and nl80211_leave_ibss which also use false.

Fair enough.

> I don't see an issue with using cfg80211_leave though.  Just tell me 
> which way you prefer.

It just seemed duplicated, ultimately I don't think I care all that
much.

johannes