[PATCH] staging: rtl8723au: use proper typecast in assignment

[Anatoly Stepanov]

This resolves the following Sparse warning:
"incorrect type in assignment (different base types)"

Signed-off-by: Anatoly Stepanov 
---
 drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c 
b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
index 1662c03c..fdd9cf1 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
@@ -115,7 +115,7 @@ exit:
 
 int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param)
 {
-   *((u32 *)param) = cpu_to_le32(*((u32 *)param));
+   *((__le32 *)param) = cpu_to_le32(*((u32 *)param));
 
FillH2CCmd(padapter, RSSI_SETTING_EID, 3, param);
 
-- 
1.9.1

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

Re: [PATCH v2] wcn36xx: handle rx skb allocation failure to avoid system crash

[fengwei.yin]

On 2015/12/15 6:47, Julian Calaby wrote:

Hi Fengwei,

On Mon, Dec 14, 2015 at 9:06 PM, Fengwei Yin  wrote:

Lawrence reported that git clone could make system crash on a
Qualcomm ARM soc based device (DragonBoard, 1G memory without
swap) running 64bit Debian.

It's turned out the crash is related with rx skb allocation
failure. git could consume more than 600MB anonymous memory.
And system is in extremely memory shortage case.

But driver didn't handle the rx allocation failure case. This patch
doesn't submit skb to upper layer if rx skb allocation fails.
Instead, it reuse the old skb for rx DMA again. It's more like
drop the packets if system is in memory shortage case.

With this change, git clone is OOMed instead of system crash.

Reported-by: King, Lawrence 
Signed-off-by: Fengwei Yin 
---
Changes from v1:
  * Move switch block out of while loop.
  * Remove the warning of unknown channel because we didn't deal with it.

  drivers/net/wireless/ath/wcn36xx/dxe.c | 50 --
  1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
b/drivers/net/wireless/ath/wcn36xx/dxe.c
index f8dfa05..6b61874 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -467,6 +467,18 @@ out_err:

  }

+#defineGET_CH_CTRL_VALUE(x)\
+   ({ u32 __v = WCN36XX_DXE_CTRL_RX_H; \
+  if ((x) == WCN36XX_DXE_CH_RX_L)  \
+   __v = WCN36XX_DXE_CTRL_RX_L;\
+  __v; })
+
+#defineGET_CH_INT_MASK(x)  \
+   ({ u32 __v = WCN36XX_DXE_INT_CH3_MASK;  \
+  if ((x) == WCN36XX_DXE_CH_RX_L)  \
+   __v = WCN36XX_DXE_INT_CH1_MASK; \
+  __v; })
+


Why add these ugly macros if you're only calling them once?


  static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
  struct wcn36xx_dxe_ch *ch)
  {
@@ -474,36 +486,34 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
 struct wcn36xx_dxe_desc *dxe = ctl->desc;
 dma_addr_t  dma_addr;
 struct sk_buff *skb;
+   int ret = 0, int_mask;
+   u32 value;
+


Surely something like:

if (ch->ch_type == WCN36XX_DXE_CH_RX_L) {
 value = WCN36XX_DXE_CTRL_RX_L;
 int_mask = WCN36XX_DXE_INT_CH1_MASK;
} else {
 value = WCN36XX_DXE_CTRL_RX_H;
 int_mask = WCN36XX_DXE_INT_CH3_MASK;
}

would be much cleaner.

OK. I will remove the ugly macros. Thanks a lot for reviewing it.

Regards
Yin, Fengwei



Thanks,


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

Re: [PATCH v2] wcn36xx: handle rx skb allocation failure to avoid system crash

[Bjorn Andersson]

On Mon 14 Dec 02:06 PST 2015, Fengwei Yin wrote:

> Lawrence reported that git clone could make system crash on a
> Qualcomm ARM soc based device (DragonBoard, 1G memory without
> swap) running 64bit Debian.
> 
> It's turned out the crash is related with rx skb allocation
> failure. git could consume more than 600MB anonymous memory.
> And system is in extremely memory shortage case.
> 
> But driver didn't handle the rx allocation failure case. This patch
> doesn't submit skb to upper layer if rx skb allocation fails.
> Instead, it reuse the old skb for rx DMA again. It's more like
> drop the packets if system is in memory shortage case.
> 
> With this change, git clone is OOMed instead of system crash.
> 
> Reported-by: King, Lawrence 
> Signed-off-by: Fengwei Yin 
> ---
> Changes from v1:
>  * Move switch block out of while loop.
>  * Remove the warning of unknown channel because we didn't deal with it.
> 
>  drivers/net/wireless/ath/wcn36xx/dxe.c | 50 
> --
>  1 file changed, 30 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
> b/drivers/net/wireless/ath/wcn36xx/dxe.c
> index f8dfa05..6b61874 100644
> --- a/drivers/net/wireless/ath/wcn36xx/dxe.c
> +++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
> @@ -467,6 +467,18 @@ out_err:
>  
>  }
>  
> +#define  GET_CH_CTRL_VALUE(x)\
> + ({ u32 __v = WCN36XX_DXE_CTRL_RX_H; \
> +if ((x) == WCN36XX_DXE_CH_RX_L)  \
> + __v = WCN36XX_DXE_CTRL_RX_L;\
> +__v; })
> +
> +#define  GET_CH_INT_MASK(x)  \
> + ({ u32 __v = WCN36XX_DXE_INT_CH3_MASK;  \
> +if ((x) == WCN36XX_DXE_CH_RX_L)  \
> + __v = WCN36XX_DXE_INT_CH1_MASK; \
> +__v; })
> +
>  static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
>struct wcn36xx_dxe_ch *ch)
>  {
> @@ -474,36 +486,34 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx 
> *wcn,
>   struct wcn36xx_dxe_desc *dxe = ctl->desc;
>   dma_addr_t  dma_addr;
>   struct sk_buff *skb;
> + int ret = 0, int_mask;
> + u32 value;
> +
> + value = GET_CH_CTRL_VALUE(ch->ch_type);
> + int_mask = GET_CH_INT_MASK(ch->ch_type);
>  
>   while (!(dxe->ctrl & WCN36XX_DXE_CTRL_VALID_MASK)) {
>   skb = ctl->skb;
>   dma_addr = dxe->dst_addr_l;
> - wcn36xx_dxe_fill_skb(wcn->dev, ctl);

I believe a better way to implement this is to check the return value
here and simply break the loop upon error.

> -
> - switch (ch->ch_type) {
> - case WCN36XX_DXE_CH_RX_L:
> - dxe->ctrl = WCN36XX_DXE_CTRL_RX_L;
> - wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
> -WCN36XX_DXE_INT_CH1_MASK);
> - break;
> - case WCN36XX_DXE_CH_RX_H:
> - dxe->ctrl = WCN36XX_DXE_CTRL_RX_H;
> - wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
> -WCN36XX_DXE_INT_CH3_MASK);
> - break;
> - default:
> - wcn36xx_warn("Unknown channel\n");
> - }
> -
> - dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
> -  DMA_FROM_DEVICE);
> - wcn36xx_rx_skb(wcn, skb);
> + ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);
> + if (0 == ret) {

With this you say that if allocation of a new skb fails we just mark the
old one as free again and move the list forward. Not unlikely this will
run through all packets in the list and give them back to the hardware.

Most likely both cases will just result in us dropping a series of
packets, but I believe we should leave the buffers occupied rather then
running this loop cycling buffers back to the hardware.

> + /* new skb allocation ok. Use the new one and queue
> +  * the old one to network system.
> +  */
> + dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
> + DMA_FROM_DEVICE);
> + wcn36xx_rx_skb(wcn, skb);
> + } /* else keep rx skb not submitted and use for rx DMA again */
> +
> + dxe->ctrl = value;
>   ctl = ctl->next;
>   dxe = ctl->desc;
>   }
>  
>   ch->head_blk_ctl = ctl;
>  
> + wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR, int_mask);
> +

I suspect this part kicks the hardware, to start filling new dxes after
updating our list. So it does make sense to only do that once, after
looping through all the descriptors. But please do so in a separate
patch, so we can bisect it if it turns out to cause issues.

>   return 0;
>  }

Regards,
Bjorn
--

Re: [PATCH v2] wcn36xx: handle rx skb allocation failure to avoid system crash

[fengwei.yin]

Hi Bjorn,

On 2015/12/15 8:20, Bjorn Andersson wrote:

On Mon 14 Dec 02:06 PST 2015, Fengwei Yin wrote:


Lawrence reported that git clone could make system crash on a
Qualcomm ARM soc based device (DragonBoard, 1G memory without
swap) running 64bit Debian.

It's turned out the crash is related with rx skb allocation
failure. git could consume more than 600MB anonymous memory.
And system is in extremely memory shortage case.

But driver didn't handle the rx allocation failure case. This patch
doesn't submit skb to upper layer if rx skb allocation fails.
Instead, it reuse the old skb for rx DMA again. It's more like
drop the packets if system is in memory shortage case.

With this change, git clone is OOMed instead of system crash.

Reported-by: King, Lawrence 
Signed-off-by: Fengwei Yin 
---
Changes from v1:
  * Move switch block out of while loop.
  * Remove the warning of unknown channel because we didn't deal with it.

  drivers/net/wireless/ath/wcn36xx/dxe.c | 50 --
  1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
b/drivers/net/wireless/ath/wcn36xx/dxe.c
index f8dfa05..6b61874 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -467,6 +467,18 @@ out_err:

  }

+#defineGET_CH_CTRL_VALUE(x)\
+   ({ u32 __v = WCN36XX_DXE_CTRL_RX_H; \
+  if ((x) == WCN36XX_DXE_CH_RX_L)  \
+   __v = WCN36XX_DXE_CTRL_RX_L;\
+  __v; })
+
+#defineGET_CH_INT_MASK(x)  \
+   ({ u32 __v = WCN36XX_DXE_INT_CH3_MASK;  \
+  if ((x) == WCN36XX_DXE_CH_RX_L)  \
+   __v = WCN36XX_DXE_INT_CH1_MASK; \
+  __v; })
+
  static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
 struct wcn36xx_dxe_ch *ch)
  {
@@ -474,36 +486,34 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
struct wcn36xx_dxe_desc *dxe = ctl->desc;
dma_addr_t  dma_addr;
struct sk_buff *skb;
+   int ret = 0, int_mask;
+   u32 value;
+
+   value = GET_CH_CTRL_VALUE(ch->ch_type);
+   int_mask = GET_CH_INT_MASK(ch->ch_type);

while (!(dxe->ctrl & WCN36XX_DXE_CTRL_VALID_MASK)) {
skb = ctl->skb;
dma_addr = dxe->dst_addr_l;
-   wcn36xx_dxe_fill_skb(wcn->dev, ctl);


I believe a better way to implement this is to check the return value
here and simply break the loop upon error.

No. We can't break the loop because:
1. The following items in the list could have DMA done and we have to deal
   with them (At least initialize their dxe->ctrl again).

2. It's possible system page reclaim get free pages and coming skb allocation
   could success.




-
-   switch (ch->ch_type) {
-   case WCN36XX_DXE_CH_RX_L:
-   dxe->ctrl = WCN36XX_DXE_CTRL_RX_L;
-   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
-  WCN36XX_DXE_INT_CH1_MASK);
-   break;
-   case WCN36XX_DXE_CH_RX_H:
-   dxe->ctrl = WCN36XX_DXE_CTRL_RX_H;
-   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
-  WCN36XX_DXE_INT_CH3_MASK);
-   break;
-   default:
-   wcn36xx_warn("Unknown channel\n");
-   }
-
-   dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
-DMA_FROM_DEVICE);
-   wcn36xx_rx_skb(wcn, skb);
+   ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);
+   if (0 == ret) {


With this you say that if allocation of a new skb fails we just mark the
old one as free again and move the list forward. Not unlikely this will
run through all packets in the list and give them back to the hardware.

Not whole list. The loop just deal with the packets have DMA done. I don't
think it will cross the whole list.



Most likely both cases will just result in us dropping a series of
packets, but I believe we should leave the buffers occupied rather then
running this loop cycling buffers back to the hardware.


My understanding is that the DMA never stop. WCN36XX_DXE_CH_NEXT_DESC_ADDR_RX_L
is only initialized once. And then just update the each description's dest
address.

If DMA is not stopped, we always need DMA buffer ready. So we can't submit
the rx skb if the new rx skb allocation fails.

But if we could stop DMA and restart the whole cycle again, we can submit
the rx skb to upper layer and restart the whole cycle once new rx skb is
available.


+   /* new skb allocation ok. Use the new one and queue
+* the old one to network system.
+*/
+

Re: [PATCH] ath10k: allow Mesh Point to install peer security key

[Kalle Valo]

Peter Oh  writes:

> Mesh Point requires peer security key install when running
> in secured mode since it's a type of peer links, otherwise peer
> link will be removed due to key install failure.
>
> MFP feature set is required to run Mesh in secured mode and
> QCA988X firmware, 10.2.4.70.14-2 and above, is the only one
> supporting secured Mesh at this moment.
>
> Signed-off-by: Peter Oh 

Applied, thanks.

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

Re: [PATCH 000/182] Rid struct gpio_chip from container_of() usage

[Johan Hovold]

On Wed, Dec 09, 2015 at 03:46:00PM +0100, Linus Walleij wrote:
> On Wed, Dec 9, 2015 at 2:44 PM, Russell King - ARM Linux
>  wrote:

> > On Wed, Dec 09, 2015 at 02:08:35PM +0100, Linus Walleij wrote:
> >> Because we want to have a proper userspace ABI for GPIO chips,
> >> which involves using a character device that the user opens
> >> and closes. While the character device is open, the underlying
> >> kernel objects must not go away.
> >
> > Okay, so you stop the gpio_chip struct from going away.
> 
> Actually I was going to create a new struct gpio_device, but yes.
> 
> > What
> > about the code which is called via gpio_chip - say, if userspace
> > keeps the chardev open, and someone rmmod's the driver providing
> > the GPIO driver.
> 
> The idea was that when what is today gpiochip_remove() is called by the
> gpiochip driver, the static data pointer to the vtable with all
> callbacks is set to NULL (in some safe way), and the code avoids
> calling these, so the device goes numb.
> 
> I think you give me the right solution to this "safe way" below,
> thanks!
> 
> > I'm not sure that splitting up objects in this way really solves
> > anything at all.  Yes, it divorses the driver's private data from
> > the subsystem data, but is that really an advantage?
> 
> I like the design pattern you describe below, and
> I have no strong opinion on it. If there is a precedent in the kernel
> to do it with a separate alloc_foo() function I can do that.
> 
> (Would like Greg's and/or Johan's opinion on this though.)

I'd prefer separating allocation and registration rather than using a
setup callback.

> > Things get a little more complex with gpio, because there's the
> > issue that some methods are spinlocked while others can take
> > semaphores, but it should be possible to come up with a solution
> > to that - maybe an atomic_t which is incremented whenever we're
> > in some operation provided it's >= 0 (otherwise it fails), and
> > decremented when the operation completes.  We can then control
> > in the unregistration path further GPIO accesses, and also
> > prevent new accesses occuring by setting the atomic_t to -1.
> > This shouldn't require any additional locking in any path.  It
> > does mean that the unregistration path needs careful thought to
> > ensure that when we set it to -1, we wait for it to be dropped
> > by the appropriate amount.
> 
> Yeah we will both in spinlocks/hotpath and
> semaphores/mutexes/slowpath in these ops for sure :/
> 
> The atomic hack should work: I understand that you mean
> we read it and set it to -1 and if it was 2 wait for it to
> become -3, then conclude unregistration with callbacks
> numbed.

Ok, but let's take a step back. So you have all this in place and a
consumer calls gpiod_get_value() that returns an errno because the device
is gone. Note that this wasn't even possible before e20538b82f1f ("gpio:
Propagate errors from chip->get()") that went into *v4.3*, and I assume
most drivers would need to be updated to even handle that that gpio
call, and all future calls, are now suddenly failing.

So this ties into the generic problem of inter-device dependencies. Does
it even make sense to keep the consumer around, now that its gpio
resources have gone away?  

If your current concern is a new gpio chardev interface, perhaps solving
only that use case in the way that Dimitry suggested elsewhere in this
thread is what you should be doing.

> Then there is a particular case that occurs with USB or similar
> pluggable buses, where there is a glitch or powercycle on the
> bus, and the same device goes away and comes back in
> a few milliseconds, and that means it should reattach to the
> character device that is already open.

No, that does not follow. A USB device being disconnected and
reconnected is considered to be a new device. All state is gone, and the
dangling character device will be unusable.

> Making that work is however non-trivial :(

Fortunately, you don't need to worry about that.

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

[PATCH 01/14] mwifiex: change ap and station interface limits

[Amitkumar Karwar]

From: Shengzhen Li 

ap/station interface limit has been changed to allow
creating maximum 3 interfaces.

Signed-off-by: Shengzhen Li 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 65dd85d..47d8afd 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -26,12 +26,10 @@ module_param(reg_alpha2, charp, 0);
 
 static const struct ieee80211_iface_limit mwifiex_ap_sta_limits[] = {
{
-   .max = 2, .types = BIT(NL80211_IFTYPE_STATION) |
+   .max = 3, .types = BIT(NL80211_IFTYPE_STATION) |
   BIT(NL80211_IFTYPE_P2P_GO) |
-  BIT(NL80211_IFTYPE_P2P_CLIENT),
-   },
-   {
-   .max = 1, .types = BIT(NL80211_IFTYPE_AP),
+  BIT(NL80211_IFTYPE_P2P_CLIENT) |
+  BIT(NL80211_IFTYPE_AP),
},
 };
 
-- 
1.8.1.4

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

[PATCH 13/14] mwifiex: use world for unidentified region code

[Amitkumar Karwar]

It's better to use world if region code from EEPROM is
unidentied instead of forcing it to FCC

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 45ae38e..cb25aa7 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -1637,9 +1637,9 @@ int mwifiex_ret_get_hw_spec(struct mwifiex_private *priv,
if (adapter->region_code == region_code_index[i])
break;
 
-   /* If it's unidentified region code, use the default (USA) */
+   /* If it's unidentified region code, use the default (world) */
if (i >= MWIFIEX_MAX_REGION_CODE) {
-   adapter->region_code = 0x10;
+   adapter->region_code = 0x00;
mwifiex_dbg(adapter, WARN,
"cmd: unknown region code, use default (USA)\n");
}
-- 
1.8.1.4

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

[PATCH 11/14] mwifiex: fix wake on disconnect feature

[Amitkumar Karwar]

From: chunfan chen 

Default gpio and gap is downloaded to firmware while
configuring host sleep for wake on disconnect. We may
have gpio and gap modified by user.

This patch fixes the problem.

Signed-off-by: chunfan chen 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index f7c26d6..e7adef7 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3159,8 +3159,8 @@ static int mwifiex_cfg80211_suspend(struct wiphy *wiphy,
memset(_cfg, 0, sizeof(hs_cfg));
hs_cfg.is_invoke_hostcmd = false;
hs_cfg.conditions = HS_CFG_COND_MAC_EVENT;
-   hs_cfg.gpio = HS_CFG_GPIO_DEF;
-   hs_cfg.gap = HS_CFG_GAP_DEF;
+   hs_cfg.gpio = adapter->hs_cfg.gpio;
+   hs_cfg.gap = adapter->hs_cfg.gap;
ret = mwifiex_set_hs_params(priv, HostCmd_ACT_GEN_SET,
MWIFIEX_SYNC_CMD, _cfg);
if (ret) {
-- 
1.8.1.4

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

Re: [PATCH 00/14] mwifiex fixes

[Johannes Berg]

On Mon, 2015-12-14 at 04:15 -0800, Amitkumar Karwar wrote:
> These patches include few fixes for mwifiex and add a
> debugfs file for chip reset.
> 

A lot of these "fixes" look like new firmware features to me (e.g.
interface limits, sms4 cipher, pattern length).

First of all - is that really appropriate as "fixes", what tree are you
targeting?

And secondly, how are you making sure the user won't have an older
firmware version where this will presumably cause crashes?

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

Re: iwlwifi A-MSDU tx

[Emmanuel Grumbach]

On Sat, Dec 12, 2015 at 10:54 PM, Emmanuel Grumbach  wrote:
> On Fri, Dec 11, 2015 at 10:02 PM, Stefan Sperling  wrote:
>> Hi Emmanuel,
>>
>> Thanks a bunch, this worked out quite well for me.
>> I got what I was aiming for out of this already but I still have some
>> additional questions if you don't mind.
>
> Happy to hear that.
>
>>
>> Do you know of a good way to generate A-MSDUs?
>> One way I found is to run:
>>   top -d .01
>> on the AP and watching this top over SSH from my associated OpenBSD client.
>
> iperf? :)
>
> You can also load iwlwifi with 11n_disable=2. This will prevent A-MPDU
> if you don't want to have A-MSDU in A-MPDU at that stage.
>
>>
>> It seems only locally generated packets will trigger A-MSDUs.
>> I suppose forwarded frames always fit the interface MTU and don't
>> trigger A-MSDUs. Is there a way to test this with forwarded traffic?
>
> Hmm. Good question. A-MSDUs are created each time we get a large send
> from the network stack. I think that this relies on the socket
> occupancy which means that you are right. I don't think we can test
> this with forwarded traffic for now.
>
>>
>> One issue I discovered is that OpenBSD (with my partly uncommitted 11n
>> patch set) cannot decrypt encrypted A-MSDUs sent by iwlwifi.
>> Frames carrying normal MSDUs have a CCMP header and are decrypted correctly.
>> But frames carrying A-MSDUs have a wep/tkip header (wireshark shows
>> "WEP parameters" instead of CCMP parameters") and decryption fails on
>> OpenBSD in ieee80211_ccmp_decrypt() because the ExtIV bit is not set.
>> It doesn't look like the source of this problem is at OpenBSD's end since
>> CCMP is required for HT. So in case the firmware doesn't produce CCMP for
>> A-MSDUs, this would be a problem in the firmware. Can you confirm this?
>> I also tried running iwlwifi in software crypto mode but the AP would
>> not send A-MSDUs at all in that case.
>
> SW crypto won't work for A-MSDU since it'll refuse LSO which in turn
> disables A-MSDU.
> I don't really touch the wifi header, I just duplicate it if needed,
> so I don't see off the top of my head where the problem could be.
> Thanks for reporting it.
>

I found the problem. Patch attached.

>>
>> On the receiving OpenBSD side I'm currently limited to 4k A-MSDU and it
>> turns out the AP won't send more than 2 subframes per A-MSDU in this case.
>
> with default MTU, you won't get more than that.
>
>> To test with more than 2 subframes I applied the following crude patch which
>> makes the AP send more subframes but crashes the firmware after the frame
>> is sent. The driver recovers fine and traffic keeps flowing but that's
>> not pretty. Do you have a better idea? If not, no problem. I mainly did
>> this to confirm that OpenBSD won't crash handling A-MSDU with more than
>> 2 subframes, which it won't.
>
> ouch. No :)  What you should really do is to reduce the MTU to 500 bytes.
> iperf -M will do.
>
>>
>> Thanks again,
>> Stefan
>>
>> diff --git a/drivers/net/wireless/iwlwifi/mvm/tx.c 
>> b/drivers/net/wireless/iwlwifi/mvm/tx.c
>> index 7ece5c1..b3d562d 100644
>> --- a/drivers/net/wireless/iwlwifi/mvm/tx.c
>> +++ b/drivers/net/wireless/iwlwifi/mvm/tx.c
>> @@ -448,7 +448,7 @@ static int iwl_mvm_tx_tso(struct iwl_mvm *mvm, struct 
>> sk_buff *skb,
>> struct iwl_mvm_sta *mvmsta = iwl_mvm_sta_from_mac80211(sta);
>> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
>> struct ieee80211_hdr *hdr = (void *)skb->data;
>> -   unsigned int mss = skb_shinfo(skb)->gso_size;
>> +   unsigned int mss = skb_shinfo(skb)->gso_size / 2;
>> struct sk_buff *tmp, *next;
>> char cb[sizeof(skb->cb)];
>> unsigned int num_subframes, tcp_payload_len, subf_len, max_amsdu_len;
>>
>> On Fri, Dec 04, 2015 at 12:30:52PM +0200, Emmanuel Grumbach wrote:
>>> Adding the right mailing list this time.
>>>
>>> On Fri, Dec 4, 2015 at 10:18 AM, Emmanuel Grumbach  
>>> wrote:
>>> > On Fri, Dec 4, 2015 at 9:35 AM, Emmanuel Grumbach  
>>> > wrote:
>>> >> Hi,
>>> >>
>>> >> On Fri, Dec 4, 2015 at 12:05 AM, Stefan Sperling  
>>> >> wrote:
>>> >>> Hi Emmanuel,
>>> >>>
>>> >>> As part of implementing 802.11n support in OpenBSD I'm looking for
>>> >>> an AP which sends A-MSDUs. Preferrably under software control rather
>>> >>> than firmware.
>>> >>>
>>> >>> I found your iwlwifi A-MSDU patches at
>>> >>> http://marc.info/?l=linux-wireless=144553311122495=2
>>> >>> and http://marc.info/?l=linux-wireless=144553311822496=2
>>> >>>
>>> >>> Would these patches make it possible to run an AP with an 5300 or 7260
>>> >>> card and send A-MSDUs? That would be great as I have the necessary 
>>> >>> hardware.
>>> >>
>>> >> 7260 will go. Not 5300.
>>> >> Note that this code simulates Tx TCP Csum offload. I did that to write
>>> >> the code while we still don't have the hardware that has this
>>> >> capability. But for testing purposes, 

[PATCH 14/14] mwifiex: fix WPA connection problem

[Amitkumar Karwar]

From: chunfan chen 

Device fails to connect to some AP's configured in WPA
security mode. Currently IE buffer parsing logic in driver
expects WPA IE to be present at the beginning of IE buffer.
Otherwise connection is failed with 'incompatible network
setting' error.

This patch fixes the problem by improving IE buffer parsing
logic.

Signed-off-by: chunfan chen 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 75 +---
 1 file changed, 53 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c 
b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index 62b35a3..439e73f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -1293,6 +1293,8 @@ mwifiex_set_gen_ie_helper(struct mwifiex_private *priv, 
u8 *ie_data_ptr,
struct ieee_types_vendor_header *pvendor_ie;
const u8 wpa_oui[] = { 0x00, 0x50, 0xf2, 0x01 };
const u8 wps_oui[] = { 0x00, 0x50, 0xf2, 0x04 };
+   u16 unparsed_len = ie_len;
+   int find_wpa_ie = 0;
 
/* If the passed length is zero, reset the buffer */
if (!ie_len) {
@@ -1304,40 +1306,69 @@ mwifiex_set_gen_ie_helper(struct mwifiex_private *priv, 
u8 *ie_data_ptr,
return -1;
}
pvendor_ie = (struct ieee_types_vendor_header *) ie_data_ptr;
-   /* Test to see if it is a WPA IE, if not, then it is a gen IE */
-   if (((pvendor_ie->element_id == WLAN_EID_VENDOR_SPECIFIC) &&
-(!memcmp(pvendor_ie->oui, wpa_oui, sizeof(wpa_oui ||
-   (pvendor_ie->element_id == WLAN_EID_RSN)) {
 
-   /* IE is a WPA/WPA2 IE so call set_wpa function */
-   ret = mwifiex_set_wpa_ie_helper(priv, ie_data_ptr, ie_len);
-   priv->wps.session_enable = false;
+   while (pvendor_ie) {
+   if (pvendor_ie->element_id == WLAN_EID_VENDOR_SPECIFIC) {
+   /* Test to see if it is a WPA IE, if not, then it is a
+* gen IE
+*/
+   if (!memcmp(pvendor_ie->oui, wpa_oui,
+   sizeof(wpa_oui))) {
+   find_wpa_ie = 1;
+   break;
+   }
 
-   return ret;
-   } else if (pvendor_ie->element_id == WLAN_EID_BSS_AC_ACCESS_DELAY) {
+   /* Test to see if it is a WPS IE, if so, enable
+* wps session flag
+*/
+   if (!memcmp(pvendor_ie->oui, wps_oui,
+   sizeof(wps_oui))) {
+   priv->wps.session_enable = true;
+   mwifiex_dbg(priv->adapter, MSG,
+   "info: WPS Session Enabled.\n");
+   ret = mwifiex_set_wps_ie(priv,
+(u8 *)pvendor_ie,
+unparsed_len);
+   }
+   }
+
+   if (pvendor_ie->element_id == WLAN_EID_RSN) {
+   find_wpa_ie = 1;
+   break;
+   }
+
+   if (pvendor_ie->element_id == WLAN_EID_BSS_AC_ACCESS_DELAY) {
/* IE is a WAPI IE so call set_wapi function */
-   ret = mwifiex_set_wapi_ie(priv, ie_data_ptr, ie_len);
+   ret = mwifiex_set_wapi_ie(priv, (u8 *)pvendor_ie,
+ unparsed_len);
+   return ret;
+   }
+
+   unparsed_len -= (pvendor_ie->len +
+sizeof(struct ieee_types_header));
+
+   if (unparsed_len <= sizeof(struct ieee_types_header))
+   pvendor_ie = NULL;
+   else
+   pvendor_ie = (struct ieee_types_vendor_header *)
+   (((u8 *)pvendor_ie) + pvendor_ie->len +
+sizeof(struct ieee_types_header));
+   }
 
+   if (find_wpa_ie) {
+   /* IE is a WPA/WPA2 IE so call set_wpa function */
+   ret = mwifiex_set_wpa_ie_helper(priv, (u8 *)pvendor_ie,
+   unparsed_len);
+   priv->wps.session_enable = false;
return ret;
}
+
/*
 * Verify that the passed length is not larger than the
 * available space remaining in the buffer
 */
if (ie_len < (sizeof(priv->gen_ie_buf) - priv->gen_ie_buf_len)) {
 
-   /* Test to see if it is a WPS IE, if so, enable
-* wps session flag
-*/
-   pvendor_ie = (struct ieee_types_vendor_header *) 

[PATCH 10/14] mwifiex: fix AMPDU not setup on TDLS link problem

[Amitkumar Karwar]

Sometimes AP sends TDLS setup response as AMSDU packet.
As driver doesn't parse it and update peer station's 11n
capability in this case, AMPDU doesn't get setup.

This patch calls mwifiex_process_tdls_action_frame() in
AMSDU Rx path to fix the problem.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Cathy Luo 
---
 drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c 
b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index b3970a8..09578c6 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -48,7 +48,17 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct 
mwifiex_private *priv,
 priv->wdev.iftype, 0, false);
 
while (!skb_queue_empty()) {
+   struct rx_packet_hdr *rx_hdr;
+
rx_skb = __skb_dequeue();
+   rx_hdr = (struct rx_packet_hdr *)rx_skb->data;
+   if (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) &&
+   ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) {
+   mwifiex_process_tdls_action_frame(priv,
+ (u8 *)rx_hdr,
+ skb->len);
+   }
+
ret = mwifiex_recv_packet(priv, rx_skb);
if (ret == -1)
mwifiex_dbg(priv->adapter, ERROR,
-- 
1.8.1.4

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

[PATCH 12/14] mwifiex: update region_code_index array

[Amitkumar Karwar]

This array contains list of supported region codes.
It is changed to make it aligned with region code
to country mapping table in driver.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfp.c  | 2 +-
 drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index beb564f..09fae27 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -67,7 +67,7 @@ static u8 supported_rates_bg[BG_SUPPORTED_RATES] = { 0x02, 
0x04, 0x0b, 0x0c,
0x60, 0x6c, 0 };
 
 u16 region_code_index[MWIFIEX_MAX_REGION_CODE] = { 0x00, 0x10, 0x20, 0x30,
-   0x32, 0x40, 0x41, 0xff };
+   0x31, 0x32, 0x40, 0x41, 0x50 };
 
 static u8 supported_rates_n[N_SUPPORTED_RATES] = { 0x02, 0x04, 0 };
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 10e614e..0fa1d8e 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -84,7 +84,7 @@ enum {
 
 #define MWIFIEX_KEY_BUFFER_SIZE16
 #define MWIFIEX_DEFAULT_LISTEN_INTERVAL 10
-#define MWIFIEX_MAX_REGION_CODE 8
+#define MWIFIEX_MAX_REGION_CODE 9
 
 #define DEFAULT_BCN_AVG_FACTOR  8
 #define DEFAULT_DATA_AVG_FACTOR 8
-- 
1.8.1.4

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

[PATCH 02/14] mwifiex: multiple bss support

[Amitkumar Karwar]

From: Shengzhen Li 

This patch fixes issues observed while starting 3 different
bss simultaneously, eg, 2 AP + 1 STA or 3 AP

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 20 
 drivers/net/wireless/marvell/mwifiex/decl.h |  6 ++--
 drivers/net/wireless/marvell/mwifiex/main.h | 42 -
 3 files changed, 51 insertions(+), 17 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 47d8afd..ab0ba6a 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -825,18 +825,26 @@ mwifiex_init_new_priv_params(struct mwifiex_private *priv,
switch (type) {
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_ADHOC:
+   priv->bss_num = mwifiex_get_unused_bss_num(adapter,
+MWIFIEX_BSS_TYPE_STA);
priv->bss_role =  MWIFIEX_BSS_ROLE_STA;
priv->bss_type = MWIFIEX_BSS_TYPE_STA;
break;
case NL80211_IFTYPE_P2P_CLIENT:
+   priv->bss_num = mwifiex_get_unused_bss_num(adapter,
+MWIFIEX_BSS_TYPE_P2P);
priv->bss_role =  MWIFIEX_BSS_ROLE_STA;
priv->bss_type = MWIFIEX_BSS_TYPE_P2P;
break;
case NL80211_IFTYPE_P2P_GO:
+   priv->bss_num = mwifiex_get_unused_bss_num(adapter,
+MWIFIEX_BSS_TYPE_P2P);
priv->bss_role =  MWIFIEX_BSS_ROLE_UAP;
priv->bss_type = MWIFIEX_BSS_TYPE_P2P;
break;
case NL80211_IFTYPE_AP:
+   priv->bss_num = mwifiex_get_unused_bss_num(adapter,
+MWIFIEX_BSS_TYPE_UAP);
priv->bss_type = MWIFIEX_BSS_TYPE_UAP;
priv->bss_role = MWIFIEX_BSS_ROLE_UAP;
break;
@@ -2606,7 +2614,8 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct 
wiphy *wiphy,
return ERR_PTR(-EINVAL);
}
 
-   priv = mwifiex_get_unused_priv(adapter);
+   priv = mwifiex_get_unused_priv_by_bss_type(
+   adapter, MWIFIEX_BSS_TYPE_STA);
if (!priv) {
mwifiex_dbg(adapter, ERROR,
"could not get free private struct\n");
@@ -2625,7 +2634,6 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct 
wiphy *wiphy,
priv->frame_type = MWIFIEX_DATA_FRAME_TYPE_ETH_II;
priv->bss_priority = 0;
priv->bss_role = MWIFIEX_BSS_ROLE_STA;
-   priv->bss_num = adapter->curr_iface_comb.sta_intf;
 
break;
case NL80211_IFTYPE_AP:
@@ -2636,7 +2644,8 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct 
wiphy *wiphy,
return ERR_PTR(-EINVAL);
}
 
-   priv = mwifiex_get_unused_priv(adapter);
+   priv = mwifiex_get_unused_priv_by_bss_type(
+   adapter, MWIFIEX_BSS_TYPE_UAP);
if (!priv) {
mwifiex_dbg(adapter, ERROR,
"could not get free private struct\n");
@@ -2651,7 +2660,6 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct 
wiphy *wiphy,
priv->bss_priority = 0;
priv->bss_role = MWIFIEX_BSS_ROLE_UAP;
priv->bss_started = 0;
-   priv->bss_num = adapter->curr_iface_comb.uap_intf;
priv->bss_mode = type;
 
break;
@@ -2663,7 +2671,8 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct 
wiphy *wiphy,
return ERR_PTR(-EINVAL);
}
 
-   priv = mwifiex_get_unused_priv(adapter);
+   priv = mwifiex_get_unused_priv_by_bss_type(
+   adapter, MWIFIEX_BSS_TYPE_P2P);
if (!priv) {
mwifiex_dbg(adapter, ERROR,
"could not get free private struct\n");
@@ -2687,7 +2696,6 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct 
wiphy *wiphy,
priv->bss_priority = MWIFIEX_BSS_ROLE_STA;
priv->bss_role = MWIFIEX_BSS_ROLE_STA;
priv->bss_started = 0;
-   priv->bss_num = adapter->curr_iface_comb.p2p_intf;
 
if (mwifiex_cfg80211_init_p2p_client(priv)) {
memset(>wdev, 0, sizeof(priv->wdev));
diff --git a/drivers/net/wireless/marvell/mwifiex/decl.h 
b/drivers/net/wireless/marvell/mwifiex/decl.h
index 098e1f1..d9c15cd 100644
--- a/drivers/net/wireless/marvell/mwifiex/decl.h
+++ b/drivers/net/wireless/marvell/mwifiex/decl.h
@@ -111,9 +111,9 @@
 /* Rate index for OFDM 0 */
 #define 

[PATCH 04/14] mwifiex: fix bug for wildcard-prefix wowlan pattern

[Amitkumar Karwar]

From: Xinming Hu 

Wildcard prefix bytes are ignored while downloading packet
pattern to firmware. As packet offset is not adjusted
accordingly firmware end up matching the pattern at wrong
offset. The packet offset is corrected in this patch.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 3349c2a..0aab935 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2921,6 +2921,12 @@ mwifiex_is_pattern_supported(struct cfg80211_pkt_pattern 
*pat, s8 *byte_seq,
dont_care_byte = true;
}
 
+   /* wildcard bytes record as the offset
+* before the valid byte
+*/
+   if (!valid_byte_cnt && !dont_care_byte)
+   pat->pkt_offset++;
+
if (valid_byte_cnt > max_byte_seq)
return false;
}
-- 
1.8.1.4

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

[PATCH 09/14] mwifiex: add debugfs file for testing reset of card

[Amitkumar Karwar]

This provides an option for user to power cycle the card.
It will be used to change the firmware without actually
rebooting the system.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/debugfs.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/debugfs.c 
b/drivers/net/wireless/marvell/mwifiex/debugfs.c
index 9824d8d..5e55629 100644
--- a/drivers/net/wireless/marvell/mwifiex/debugfs.c
+++ b/drivers/net/wireless/marvell/mwifiex/debugfs.c
@@ -906,6 +906,34 @@ mwifiex_timeshare_coex_write(struct file *file, const char 
__user *ubuf,
return count;
 }
 
+static ssize_t
+mwifiex_reset_write(struct file *file,
+   const char __user *ubuf, size_t count, loff_t *ppos)
+{
+   struct mwifiex_private *priv = file->private_data;
+   struct mwifiex_adapter *adapter = priv->adapter;
+   char cmd;
+   bool result;
+
+   if (copy_from_user(, ubuf, sizeof(cmd)))
+   return -EFAULT;
+
+   if (strtobool(, ))
+   return -EINVAL;
+
+   if (!result)
+   return -EINVAL;
+
+   if (adapter->if_ops.card_reset) {
+   dev_info(adapter->dev, "Resetting per request\n");
+   adapter->hw_status = MWIFIEX_HW_STATUS_RESET;
+   mwifiex_cancel_all_pending_cmd(adapter);
+   adapter->if_ops.card_reset(adapter);
+   }
+
+   return count;
+}
+
 #define MWIFIEX_DFS_ADD_FILE(name) do { \
if (!debugfs_create_file(#name, 0644, priv->dfs_dev_dir,\
priv, _dfs_##name##_fops))  \
@@ -943,6 +971,7 @@ MWIFIEX_DFS_FILE_OPS(hscfg);
 MWIFIEX_DFS_FILE_OPS(histogram);
 MWIFIEX_DFS_FILE_OPS(debug_mask);
 MWIFIEX_DFS_FILE_OPS(timeshare_coex);
+MWIFIEX_DFS_FILE_WRITE_OPS(reset);
 
 /*
  * This function creates the debug FS directory structure and the files.
@@ -970,6 +999,7 @@ mwifiex_dev_debugfs_init(struct mwifiex_private *priv)
MWIFIEX_DFS_ADD_FILE(histogram);
MWIFIEX_DFS_ADD_FILE(debug_mask);
MWIFIEX_DFS_ADD_FILE(timeshare_coex);
+   MWIFIEX_DFS_ADD_FILE(reset);
 }
 
 /*
-- 
1.8.1.4

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

[PATCH 07/14] mwifiex: suppress "Rx of mgmt packet failed" message

[Amitkumar Karwar]

Block ACK action frames are dropped in driver. This error
is expected in this case. Let's lower the priority of this
message.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/sta_rx.c   | 2 +-
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_rx.c 
b/drivers/net/wireless/marvell/mwifiex/sta_rx.c
index d4d4cb1..00fcbda 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_rx.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_rx.c
@@ -215,7 +215,7 @@ int mwifiex_process_sta_rx_packet(struct mwifiex_private 
*priv,
if (rx_pkt_type == PKT_TYPE_MGMT) {
ret = mwifiex_process_mgmt_packet(priv, skb);
if (ret)
-   mwifiex_dbg(adapter, ERROR, "Rx of mgmt packet failed");
+   mwifiex_dbg(adapter, DATA, "Rx of mgmt packet failed");
dev_kfree_skb_any(skb);
return ret;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c 
b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
index 74d5d72..52f7981 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
@@ -310,8 +310,7 @@ int mwifiex_process_uap_rx_packet(struct mwifiex_private 
*priv,
if (rx_pkt_type == PKT_TYPE_MGMT) {
ret = mwifiex_process_mgmt_packet(priv, skb);
if (ret)
-   mwifiex_dbg(adapter, ERROR,
-   "Rx of mgmt packet failed");
+   mwifiex_dbg(adapter, DATA, "Rx of mgmt packet failed");
dev_kfree_skb_any(skb);
return ret;
}
-- 
1.8.1.4

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

[PATCH 05/14] mwifiex: increase supported wowlan pattern length

[Amitkumar Karwar]

From: Xinming Hu 

Maximum supported wowlan pattern length has been increased
from 20 to 40.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/fw.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h 
b/drivers/net/wireless/marvell/mwifiex/fw.h
index 89938f6..ced7af2 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -537,7 +537,7 @@ enum P2P_MODES {
 #define EVENT_GET_BSS_TYPE(event_cause) \
(((event_cause) >> 24) & 0x00ff)
 
-#define MWIFIEX_MAX_PATTERN_LEN20
+#define MWIFIEX_MAX_PATTERN_LEN40
 #define MWIFIEX_MAX_OFFSET_LEN 100
 #define STACK_NBYTES   100
 #define TYPE_DNUM  1
-- 
1.8.1.4

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

[PATCH 00/14] mwifiex fixes

[Amitkumar Karwar]

These patches include few fixes for mwifiex and add a
debugfs file for chip reset.

Amitkumar Karwar (6):
  mwifiex: suppress "Rx of mgmt packet failed" message
  mwifiex: remove redundant timestamp assignment
  mwifiex: add debugfs file for testing reset of card
  mwifiex: fix AMPDU not setup on TDLS link problem
  mwifiex: update region_code_index array
  mwifiex: use world for unidentified region code

Shengzhen Li (2):
  mwifiex: change ap and station interface limits
  mwifiex: multiple bss support

Xinming Hu (3):
  mwifiex: fix bug for wildcard-prefix wowlan pattern
  mwifiex: increase supported wowlan pattern length
  mwifiex: abort cac in del_station() handler

Zhaoyang Liu (1):
  mwifiex: advertise SMS4 cipher suite

chunfan chen (2):
  mwifiex: fix wake on disconnect feature
  mwifiex: fix WPA connection problem

 drivers/net/wireless/marvell/mwifiex/11n_aggr.c|  2 -
 .../net/wireless/marvell/mwifiex/11n_rxreorder.c   | 10 +++
 drivers/net/wireless/marvell/mwifiex/cfg80211.c| 44 +
 drivers/net/wireless/marvell/mwifiex/cfp.c |  2 +-
 drivers/net/wireless/marvell/mwifiex/cmdevt.c  |  4 +-
 drivers/net/wireless/marvell/mwifiex/debugfs.c | 30 +
 drivers/net/wireless/marvell/mwifiex/decl.h|  6 +-
 drivers/net/wireless/marvell/mwifiex/fw.h  |  2 +-
 drivers/net/wireless/marvell/mwifiex/main.h| 44 ++---
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 75 +++---
 drivers/net/wireless/marvell/mwifiex/sta_rx.c  |  2 +-
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c|  3 +-
 12 files changed, 168 insertions(+), 56 deletions(-)

-- 
1.8.1.4

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

[PATCH 06/14] mwifiex: abort cac in del_station() handler

[Amitkumar Karwar]

From: Xinming Hu 

When hostapd is killed with Ctrl+C before cac get completed,
stop_ap handler will not be called, thus priv->wdev.cac_started
flag remains set.
Hostapd restart attempt will be failed in this case with device
busy error. This patch aborts cac in del_station handler to
handle this corner case.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 0aab935..f7c26d6 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -1708,6 +1708,11 @@ mwifiex_cfg80211_del_station(struct wiphy *wiphy, struct 
net_device *dev,
u8 deauth_mac[ETH_ALEN];
unsigned long flags;
 
+   if (!priv->bss_started && priv->wdev.cac_started) {
+   mwifiex_dbg(priv->adapter, INFO, "%s: abort CAC!\n", __func__);
+   mwifiex_abort_cac(priv);
+   }
+
if (list_empty(>sta_list) || !priv->bss_started)
return 0;
 
-- 
1.8.1.4

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

[PATCH 08/14] mwifiex: remove redundant timestamp assignment

[Amitkumar Karwar]

During AMSDU aggregation, we are already using timestamp
value of a first packet being aggregated. This patch removes
redundant ktime_get_real() call.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/11n_aggr.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/11n_aggr.c 
b/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
index aa498e0..1efef3b 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_aggr.c
@@ -203,8 +203,6 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
skb_aggr->priority = skb_src->priority;
skb_aggr->tstamp = skb_src->tstamp;
 
-   skb_aggr->tstamp = ktime_get_real();
-
do {
/* Check if AMSDU can accommodate this MSDU */
if (skb_tailroom(skb_aggr) < (skb_src->len + LLC_SNAP_LEN))
-- 
1.8.1.4

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

Re: [PATCH v7] Add new mac80211 driver mwlwifi.

[Emmanuel Grumbach]

Hi,

I was interested in the checking the A-MSDU implementation only, so I
reviewed only that.

I am not sure I really followed your implementation though.
In iwlwifi I chose the LSO mechanism to implement A-MSDU. I understand that for
an AP it makes less sense since you don't really have locally generated traffic
and LSO won't work well with packets forwarded by the IP layer.
So you seem to have added a timeout mechanism inside the driver that accumulates
the packet for a certain period of time and send them all when the max number of
packets has been reached?
But I didn't see any timer there, so that if you start an A-MSDU and
then suddenly
stop receiving packets for transmission, the packet already in the
buffer will stay
stale?

A few more comments below.

On Thu, Nov 12, 2015 at 5:51 AM, David Lin  wrote:
> This patch provides the mwlwifi driver for Marvell 8863, 8864 and 8897
> chipsets.
> This driver was developed as part of the openwrt.org project to support
> Linksys WRT1900AC and is maintained on https://github.com/kaloz/mwlwifi.
>
> The mwlwifi driver differs from existing mwifiex driver:
> o mwlwifi is a "softmac driver" using the kernel? mac802.11 subsystem
> to provide full AP/Wireless Bridge functionality (routers).
> o mwifiex is a "fullmac driver" which provides a comprehensive set of
> client functions (laptops/embedded devices)
> o only mwlwifi supports Marvell AP chip 886X series
>

[snip]

> +
> +static int mwl_mac80211_ampdu_action(struct ieee80211_hw *hw,
> +struct ieee80211_vif *vif,
> +enum ieee80211_ampdu_mlme_action action,
> +struct ieee80211_sta *sta,
> +u16 tid, u16 *ssn, u8 buf_size, bool 
> amsdu)
> +{
> +   int rc = 0;
> +   struct mwl_priv *priv = hw->priv;
> +   struct mwl_ampdu_stream *stream;
> +   u8 *addr = sta->addr, idx;
> +   struct mwl_sta *sta_info;
> +
> +   sta_info = mwl_dev_get_sta(sta);
> +
> +   spin_lock_bh(>stream_lock);
> +
> +   stream = mwl_fwcmd_lookup_stream(hw, addr, tid);
> +
> +   switch (action) {
> +   case IEEE80211_AMPDU_RX_START:
> +   case IEEE80211_AMPDU_RX_STOP:
> +   break;
> +   case IEEE80211_AMPDU_TX_START:
> +   if (!sta_info->is_ampdu_allowed) {
> +   wiphy_warn(hw->wiphy, "ampdu not allowed\n");
> +   rc = -EPERM;
> +   break;
> +   }
> +
> +   if (!stream) {
> +   stream = mwl_fwcmd_add_stream(hw, sta, tid);
> +   if (!stream) {
> +   wiphy_warn(hw->wiphy, "no stream found\n");
> +   rc = -EPERM;
> +   break;
> +   }
> +   }
> +
> +   spin_unlock_bh(>stream_lock);
> +   rc = mwl_fwcmd_check_ba(hw, stream, vif);
> +   spin_lock_bh(>stream_lock);
> +   if (rc) {
> +   mwl_fwcmd_remove_stream(hw, stream);
> +   wiphy_err(hw->wiphy,
> + "ampdu start error code: %d\n", rc);
> +   rc = -EPERM;
> +   break;
> +   }
> +   stream->state = AMPDU_STREAM_IN_PROGRESS;
> +   *ssn = 0;
> +   ieee80211_start_tx_ba_cb_irqsafe(vif, addr, tid);

This is why you have the race you mention below. What you should really
be doing is to wait until the all the packets for that RA / TID are sent
from all the HW Tx queues (only one realistically), and only then call the
_cb. This will allow you to send the ADDBA req on the VO queue as it should
be according to spec.

[snip]

> +
> +void mwl_rx_recv(unsigned long data)
> +{

[snip]

> +
> +   if (unlikely(ieee80211_is_action(wh->frame_control) &&
> +mgmt->u.action.category ==
> +WLAN_CATEGORY_BACK &&
> +mgmt->u.action.u.addba_resp.action_code 
> ==
> +WLAN_ACTION_ADDBA_RESP)) {
> +   capab = mgmt->u.action.u.addba_resp.capab;
> +   if (le16_to_cpu(capab) & 1)
> +   mwl_rx_enable_sta_amsdu(priv, 
> mgmt->sa);

err... no. mac80211 knows how to do that today. Johannes already
reported a similar issue somewhere else in your code.

> +   }
> +   }
> +
> +   if (ieee80211_is_data_qos(wh->frame_control) &&
> +   ieee80211_has_a4(wh->frame_control)) {
> +   u8 *qc = ieee80211_get_qos_ctl(wh);
> +
> +   if (*qc & IEEE80211_QOS_CTL_A_MSDU_PRESENT)
> +   if 

RE: [PATCH v7] Add new mac80211 driver mwlwifi.

[David Lin]

> Emmanuel Grumbach [mailto:egrumb...@gmail.com] wrote:
> 
> Hi,
> 
> I was interested in the checking the A-MSDU implementation only, so I
> reviewed only that.
> 
> I am not sure I really followed your implementation though.
> In iwlwifi I chose the LSO mechanism to implement A-MSDU. I understand that
> for an AP it makes less sense since you don't really have locally generated
> traffic and LSO won't work well with packets forwarded by the IP layer.
> So you seem to have added a timeout mechanism inside the driver that
> accumulates the packet for a certain period of time and send them all when
> the max number of packets has been reached?
> But I didn't see any timer there, so that if you start an A-MSDU and then
> suddenly stop receiving packets for transmission, the packet already in the
> buffer will stay stale?
>

The flush mechanism is hooked on queue empty interrupt.

> A few more comments below.
> 
> On Thu, Nov 12, 2015 at 5:51 AM, David Lin  wrote:
> > This patch provides the mwlwifi driver for Marvell 8863, 8864 and 8897
> > chipsets.
> > This driver was developed as part of the openwrt.org project to
> > support Linksys WRT1900AC and is maintained on
> https://github.com/kaloz/mwlwifi.
> >
> > The mwlwifi driver differs from existing mwifiex driver:
> > o mwlwifi is a "softmac driver" using the kernel? mac802.11 subsystem
> > to provide full AP/Wireless Bridge functionality (routers).
> > o mwifiex is a "fullmac driver" which provides a comprehensive set of
> > client functions (laptops/embedded devices) o only mwlwifi supports
> > Marvell AP chip 886X series
> >
> 
> [snip]
> 
> > +
> > +static int mwl_mac80211_ampdu_action(struct ieee80211_hw *hw,
> > +struct ieee80211_vif *vif,
> > +enum
> ieee80211_ampdu_mlme_action action,
> > +struct ieee80211_sta *sta,
> > +u16 tid, u16 *ssn, u8 buf_size,
> > +bool amsdu) {
> > +   int rc = 0;
> > +   struct mwl_priv *priv = hw->priv;
> > +   struct mwl_ampdu_stream *stream;
> > +   u8 *addr = sta->addr, idx;
> > +   struct mwl_sta *sta_info;
> > +
> > +   sta_info = mwl_dev_get_sta(sta);
> > +
> > +   spin_lock_bh(>stream_lock);
> > +
> > +   stream = mwl_fwcmd_lookup_stream(hw, addr, tid);
> > +
> > +   switch (action) {
> > +   case IEEE80211_AMPDU_RX_START:
> > +   case IEEE80211_AMPDU_RX_STOP:
> > +   break;
> > +   case IEEE80211_AMPDU_TX_START:
> > +   if (!sta_info->is_ampdu_allowed) {
> > +   wiphy_warn(hw->wiphy, "ampdu not
> allowed\n");
> > +   rc = -EPERM;
> > +   break;
> > +   }
> > +
> > +   if (!stream) {
> > +   stream = mwl_fwcmd_add_stream(hw, sta,
> tid);
> > +   if (!stream) {
> > +   wiphy_warn(hw->wiphy, "no stream
> found\n");
> > +   rc = -EPERM;
> > +   break;
> > +   }
> > +   }
> > +
> > +   spin_unlock_bh(>stream_lock);
> > +   rc = mwl_fwcmd_check_ba(hw, stream, vif);
> > +   spin_lock_bh(>stream_lock);
> > +   if (rc) {
> > +   mwl_fwcmd_remove_stream(hw, stream);
> > +   wiphy_err(hw->wiphy,
> > + "ampdu start error code: %d\n",
> rc);
> > +   rc = -EPERM;
> > +   break;
> > +   }
> > +   stream->state = AMPDU_STREAM_IN_PROGRESS;
> > +   *ssn = 0;
> > +   ieee80211_start_tx_ba_cb_irqsafe(vif, addr, tid);
> 
> This is why you have the race you mention below. What you should really be
> doing is to wait until the all the packets for that RA / TID are sent from 
> all the
> HW Tx queues (only one realistically), and only then call the _cb. This will
> allow you to send the ADDBA req on the VO queue as it should be according to
> spec.
> 
> [snip]
> 
> > +
> > +void mwl_rx_recv(unsigned long data)
> > +{
> 
> [snip]
> 
> > +
> > +   if
> (unlikely(ieee80211_is_action(wh->frame_control) &&
> > +mgmt->u.action.category ==
> > +WLAN_CATEGORY_BACK &&
> > +
> mgmt->u.action.u.addba_resp.action_code ==
> > +WLAN_ACTION_ADDBA_RESP))
> {
> > +   capab =
> mgmt->u.action.u.addba_resp.capab;
> > +   if (le16_to_cpu(capab) & 1)
> > +
> mwl_rx_enable_sta_amsdu(priv,
> > + mgmt->sa);
> 
> err... no. mac80211 knows how to do that today. Johannes already reported a
> similar issue somewhere else in your code.

Yes. The patch is ready on 2015/9.

> 
> > +   }
> > +

RE: [PATCH v7] Add new mac80211 driver mwlwifi.

[David Lin]

> Kalle Valo [mailto:kv...@codeaurora.org] wrote:
> 
> David Lin  writes:
> 
> > On November 26, 2015 5:40 PM, Johannes Berg wrote:
> >> On Thu, 2015-11-26 at 08:27 +, David Lin wrote:
> >>
> >> > > > +#ifdef CONFIG_SUPPORT_MFG
> >> > >
> >> > > This Kconfig variable doesn't exist.
> >> > >
> >> >
> >> > The compile variable is used privately by Marvell and our customers
> >> > in production line.
> >>
> >> Yeah, still. Make it a proper Kconfig variable, defaulting to off and
> >> hidden under something, or remove it. It's extremely misleading to
> >> have something called CONFIG_* when it's not a Kconfig variable.
> >>
> >
> > I will change this compile variable from "CONFIG_SUPPORT_MFG" to
> > "SUPPORT_MFG".
> 
> Then it's still dead code which won't ever get compiled in upstream.
> Please follow what Johannes suggested.
> 

The code will be removed.

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

RE: [PATCH v7] Add new mac80211 driver mwlwifi.

[David Lin]

> Kan Yan writes:
> 
> David Lin  writes:
> 
> > +static inline struct sk_buff *mwl_tx_do_amsdu(struct mwl_priv *priv,
> > + int desc_num,
> > ...
> > +   amsdu_pkts = (struct sk_buff_head *)
> > +   kmalloc(sizeof(*amsdu_pkts), GFP_KERNEL);
> > +   if (!amsdu_pkts) {
> 
> Should GFP_ATOMIC be used here instead of GFP_KERNEL? This function could
> be called in interrupt context.
> 

Thanks. I will fix it.

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

Re: [PATCH 000/182] Rid struct gpio_chip from container_of() usage

[Dmitry Torokhov]

On Mon, Dec 14, 2015 at 1:18 AM, Linus Walleij  wrote:
> On Wed, Dec 9, 2015 at 8:30 PM, Dmitry Torokhov
>  wrote:
>> On Wed, Dec 09, 2015 at 02:08:35PM +0100, Linus Walleij wrote:
>>> This removes the use of container_of() constructions from *all*
>>> GPIO drivers in the kernel. It is done by instead adding an
>>> optional void *data pointer to the struct gpio_chip and an
>>> accessor function, gpiochip_get_data() to get it from a driver.
>>>
>>> WHY?
>>>
>>> Because we want to have a proper userspace ABI for GPIO chips,
>>> which involves using a character device that the user opens
>>> and closes. While the character device is open, the underlying
>>> kernel objects must not go away.
>>>
>>> Currently the GPIO drivers keep their state in the struct
>>> gpio_chip, and that is often allocated by the drivers, very
>>> often as a part of a containing per-instance state container
>>> struct for the driver:
>>>
>>> struct foo_state {
>>>struct gpio_chip chip;  <- OMG my state is there
>>> };
>>>
>>> Drivers cannot allocate and manage this state: if a user has the
>>> character device open, the objects allocated must stay around
>>> even if the driver goes away. Instead drivers need to pass a
>>> descriptor to the GPIO core, and then the core should allocate
>>> and manage the lifecycle of things related to the device, such
>>> as the chardev itself or the struct device related to the GPIO
>>> device.
>>
>> Yes, but it does not mean that the object that is being maintained by
>> the subsystem and that us attached to character device needs to be
>> gpio_chip itself. You can have something like
>>
>> struct gpio_chip_chardev {
>> struct cdev chardev;
>> struct gpio_chip *chip;
>> bool dead;
>> };
>
> There needs to be a struct device too, amongst other things.

Could be; I was not trying to provide finished data structure but just
illustrate possible solution.

>
>>
>> struct gpio_chip {
>> ...
>> struct gpio_chip_chardev *chardev;
>> ...
>> };
>>
>> You alloctae the new structure when you register/export gpio chip in
>> gpio subsystem core and leave all the individual drivers alone.
>
> The current idea I have is something in the middle. Drivers have to
> change a bit. The important part is that gpiolib handles allocation of
> anything containing states. I'm thinking along the lines of Russell's
> proposal to use netdev_alloc()'s design pattern.
>
> The problem is that currently gpio_chip contains a lot of
> stateful variables (like the dynamically allocated array of GPIO descriptors
> etc) and those are used by the gpiolib core, so they have to be moved away
> from gpio_chip.
>
> So what happens if I don't change the design pattern:
>
> int ret = gpiochip_add(_chip);
> ...
> gpiochip_remove(_chip);
>
> At this point we have to cross-reference the pointer to my chip to
> find the chip to remove. This goes for anything that takes the struct
> gpio_chip *
> as parameter, like gpiochip_add_pin_range(), gpiochip_request_own_desc()
> etc etc. So something inside gpiolib must take a gpio_chip * pointer and
> turn that into the actual state container, e.g, a struct gpio_device.
> Since struct gpio_chip needs to be static and stateless, it cannot contain
> a pointer back to its struct gpio_device.

Why does gpio_chip have to be stateless? I am not saying that it
should or should not, I just want to better understand what you are
trying to achieve.

>
> That means basically comparing pointers across a list of gpio_device's
> to find it. And that's ... very kludgy. But if people think it's better to 
> avoid
> changing all drivers I will consider it.
>
> I think it is better if the GPIO drivers get a handle on the
> real gpio_device * to be used when calling these gpiochip_* related
> functions and also in the callbacks, which is a bigger refactoring
> indeed.
>
> Part of this is trying to be elegant and mimic other subsystems and not
> have GPIO be too hopelessly wayward about things.
>
> If I compare to how struct input_dev is done, you appear to also use the
> pattern Russell suggested with input_dev_allocate() akin to
> netdev_alloc(), and the allocated struct holds all the vtable and states etc,
> and I think it is a good pattern, and that GPIO should conform.

The main difference between gpio_chip (at least as it stands
currently) and input devices and corresponding private driver data is
that input device and driver data has different lifetimes; input
devices may stick around even though driver is unbound from
corresponding device and driver's private data freed.

Thanks.

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

RE: [PATCH v7] Add new mac80211 driver mwlwifi.

[David Lin]

> Kalle Valo [mailto:kv...@codeaurora.org] wrote:
> 
> David Lin  writes:
> 
> > This patch provides the mwlwifi driver for Marvell 8863, 8864 and 8897
> > chipsets.
> > This driver was developed as part of the openwrt.org project to
> > support Linksys WRT1900AC and is maintained on
> https://github.com/kaloz/mwlwifi.
> >
> > The mwlwifi driver differs from existing mwifiex driver:
> > o mwlwifi is a "softmac driver" using the kernel? mac802.11 subsystem
> > to provide full AP/Wireless Bridge functionality (routers).
> > o mwifiex is a "fullmac driver" which provides a comprehensive set of
> > client functions (laptops/embedded devices) o only mwlwifi supports
> > Marvell AP chip 886X series
> >
> > NOTE: Users with Marvell 88W8897 chipsets currently should enable
> > (CONFIG=Y or M) either CONFIG_MWIFIEX or CONFIG_MWLWIFI, NOT
> BOTH.
> >
> > mwlwifi driver leveraged code from existing MWL8K driver in the
> > following areas:
> > - 802.11n setting for mac80211
> > - Functions needed to hook up to mac80211
> > - Interactions with mac80211 to establish BA streams
> > - Partial firmware APIs, some data fields
> > - Method to pass Rx packets to mac80211 except 11ac rates
> >
> > In addition, mwlwifi driver supports:
> > - future scalability and future development (refactored source code)
> > - Marvell 802.11ac chipsets, including combo BT devices
> > - 802.11ac related settings and functions
> > - concurrent AP+STA functionalities with single firmware per chip
> > - firmware APIs for the supported chipset
> > - communicating new mac80211 settings to firmware
> > - Different TX/RX datapath where applicable
> > - A-MSDU and A-MPDU
> > - mac80211-based MESH (work in progress)
> > - Refined the code to establish BA streams
> >
> > NOTE: MWLWIFI will be organized under new vendor specific
> > folder/marvell, as per request of the gate keeper and community.
> >
> > Signed-off-by: David Lin 
> 
> This seems to use base64 encoding, how did you submit this? 'git send-email'
> tool is strongly preferred.
> 
> Content-Transfer-Encoding: base64
> 
> I applied this to pending branch and saw few easy conflicts with Kconfig files
> and Makefiles, I guess you submitted this patch before I added the vendor
> directories. Let's see what kbuild finds but I already saw two
> warnings:
> 
> drivers/net/wireless/marvell/mwlwifi/main.c:160:20: warning: incorrect type
> in argument 1 (different address spaces)
> drivers/net/wireless/marvell/mwlwifi/main.c:160:20:expected void const
> *ptr
> drivers/net/wireless/marvell/mwlwifi/main.c:160:20:got void [noderef]
> *[assigned] addr
> drivers/net/wireless/marvell/mwlwifi/main.c:171:20: warning: incorrect type
> in argument 1 (different address spaces)
> drivers/net/wireless/marvell/mwlwifi/main.c:171:20:expected void const
> *ptr
> drivers/net/wireless/marvell/mwlwifi/main.c:171:20:got void [noderef]
> *[assigned] addr
>

I will fix it.

> --
> Kalle Valo

SUPPORTS_CLONED_SKBS question

[Janusz Dziedzic]

Hello Johannes,

During ath9k test we found a performance problem in TCP TX direction.
Seems a lot of time we spent in memcpy() and this is
because ath9k don't set SUPPORTS_CLONED_SKBS, and next
pskb_expand_head() is called for every TCP frame.

Base of SUPPORTS_CLONED_SKBS description, we can set this flag
in case driver will not touch payload or tailroom.
What exactly does it mean?

What in case of headroom, while ath9k already move 80211 header - add padding
after header (skb_push(hdrlen & 3) + memmove) and remove this padding
in tx_completion.

What in case of FCS?

I am not sure this is save to set this flag for ath9k?
Any hints?

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

RE: [PATCH 00/14] mwifiex fixes

[Amitkumar Karwar]

> From: Johannes Berg [mailto:johan...@sipsolutions.net]
> Sent: Monday, December 14, 2015 5:53 PM
> To: Amitkumar Karwar; linux-wireless@vger.kernel.org
> Cc: Cathy Luo; Nishant Sarmukadam
> Subject: Re: [PATCH 00/14] mwifiex fixes
> 
> On Mon, 2015-12-14 at 04:15 -0800, Amitkumar Karwar wrote:
> > These patches include few fixes for mwifiex and add a debugfs file for
> > chip reset.
> >
> 
> A lot of these "fixes" look like new firmware features to me (e.g.
> interface limits, sms4 cipher, pattern length).

These features are supported even with older firmwares. It’s just that they are 
advertised now to meet specific requirements from customer.

sms4 cipher - WAPI is supported in firmware for long time.
interface limits - Interface limit has been changed, but total number of 
maximum interfaces are same. Change is compatible with older firmware.
pattern length - User provided pattern length (wildcard bytes + actual bytes) 
has been increased to accommodate more wildcard bytes. No change in actual 
packet length supported by firmware.

> 
> First of all - is that really appropriate as "fixes", what tree are you
> targeting?

Most of the patches in this series are fixes. Hence I used word 'fixes'. I am 
targeting them for wireless-drivers-next tree only.

> 
> And secondly, how are you making sure the user won't have an older
> firmware version where this will presumably cause crashes?
> 

This patch series doesn’t include any new feature which aren't supported by 
older firmware.

Regards,
Amitkumar
N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

[PATCH] mac80211: avoid ROC during hw restart

[Emmanuel Grumbach]

From: Eliad Peller 

Defer ROC requests during hw restart, as the driver
might not be fully configured in this stage (e.g.
channel contexts were not added yet)

Signed-off-by: Eliad Peller 
Signed-off-by: Emmanuel Grumbach 
---
 net/mac80211/main.c   |  5 +
 net/mac80211/offchannel.c |  4 
 net/mac80211/util.c   | 11 +--
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 6bcf0fa..ed4c8e6 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -256,6 +256,11 @@ static void ieee80211_restart_work(struct work_struct 
*work)
list_for_each_entry(sdata, >interfaces, list)
flush_delayed_work(>dec_tailroom_needed_wk);
ieee80211_scan_cancel(local);
+
+   /* make sure any new ROC will consider local->in_reconfig */
+   flush_delayed_work(>roc_work);
+   flush_work(>hw_roc_done);
+
ieee80211_reconfig(local);
rtnl_unlock();
 }
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index fbc34e9..55a9c5b 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -408,6 +408,10 @@ void ieee80211_start_next_roc(struct ieee80211_local 
*local)
return;
}
 
+   /* defer roc if driver is not started (i.e. during reconfig) */
+   if (local->in_reconfig)
+   return;
+
roc = list_first_entry(>roc_list, struct ieee80211_roc_work,
   list);
 
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index f4b2c04..0186178 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2054,8 +2054,15 @@ int ieee80211_reconfig(struct ieee80211_local *local)
cfg80211_sched_scan_stopped_rtnl(local->hw.wiphy);
 
  wake_up:
-   local->in_reconfig = false;
-   barrier();
+   if (local->in_reconfig) {
+   local->in_reconfig = false;
+   barrier();
+
+   /* Restart deferred ROCs */
+   mutex_lock(>mtx);
+   ieee80211_start_next_roc(local);
+   mutex_unlock(>mtx);
+   }
 
if (local->monitors == local->open_count && local->monitors > 0)
ieee80211_add_virtual_monitor(local);
-- 
2.5.0

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

[PATCH 7/7] brcmfmac: introduce module parameter to force successful probe

[Arend van Spriel]

The module parameter can be used to ensure the probe succeeds thus
claiming the device and allowing post-mortem debugging in case of
firmware crash. It is only available when select CONFIG_BRCMDBG.

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

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index bb9e2b3..4265b50 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -67,6 +67,13 @@ static int brcmf_roamoff;
 module_param_named(roamoff, brcmf_roamoff, int, S_IRUSR);
 MODULE_PARM_DESC(roamoff, "Do not use internal roaming engine");
 
+#ifdef DEBUG
+/* always succeed brcmf_bus_start() */
+static int brcmf_ignore_probe_fail;
+module_param_named(ignore_probe_fail, brcmf_ignore_probe_fail, int, 0);
+MODULE_PARM_DESC(ignore_probe_fail, "always succeed probe for debugging");
+#endif
+
 struct brcmf_mp_global_t brcmf_mp_global;
 
 int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
@@ -232,7 +239,9 @@ int brcmf_mp_device_attach(struct brcmf_pub *drvr)
drvr->settings->feature_disable = brcmf_feature_disable;
drvr->settings->fcmode = brcmf_fcmode;
drvr->settings->roamoff = !!brcmf_roamoff;
-
+#ifdef DEBUG
+   drvr->settings->ignore_probe_fail = !!brcmf_ignore_probe_fail;
+#endif
return 0;
 }
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index abe3764..3b0a63b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -55,11 +55,24 @@ struct brcmf_mp_device {
int feature_disable;
int fcmode;
boolroamoff;
+   boolignore_probe_fail;
 };
 
 void brcmf_mp_attach(void);
 int brcmf_mp_device_attach(struct brcmf_pub *drvr);
 void brcmf_mp_device_detach(struct brcmf_pub *drvr);
+#ifdef DEBUG
+static inline bool brcmf_ignoring_probe_fail(struct brcmf_pub *drvr)
+{
+   return drvr->settings->ignore_probe_fail;
+}
+#else
+static inline bool brcmf_ignoring_probe_fail(struct brcmf_pub *drvr)
+{
+   return false;
+}
+#endif
+
 /* Sets dongle media info (drv_version, mac address). */
 int brcmf_c_preinit_dcmds(struct brcmf_if *ifp);
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 3fa7bc5..7c75b1a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -1183,6 +1183,8 @@ fail:
brcmf_net_detach(p2p_ifp->ndev);
drvr->iflist[0] = NULL;
drvr->iflist[1] = NULL;
+   if (brcmf_ignoring_probe_fail(drvr))
+   ret = 0;
return ret;
}
return 0;
-- 
1.9.1

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

[PATCH 6/7] brcmfmac: Move all module parameters to one place

[Arend van Spriel]

From: Hante Meuleman 

Module parameters are defined in several files. Move them in one
place and make them device specific or global. This makes it
easier to override device specific settings by external data like
platform data in the future.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 12 ++---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 13 ++---
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 63 ++
 .../wireless/broadcom/brcm80211/brcmfmac/common.h  | 43 +++
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 22 
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  5 +-
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 13 ++---
 .../broadcom/brcm80211/brcmfmac/firmware.c | 16 +++---
 .../broadcom/brcm80211/brcmfmac/fwsignal.c |  9 ++--
 9 files changed, 144 insertions(+), 52 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 410a664..5363739 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -47,6 +47,8 @@
 #include "debug.h"
 #include "sdio.h"
 #include "of.h"
+#include "core.h"
+#include "common.h"
 
 #define SDIOH_API_ACCESS_RETRY_LIMIT   2
 
@@ -57,7 +59,6 @@
 /* Maximum milliseconds to wait for F2 to come up */
 #define SDIO_WAIT_F2RDY3000
 
-#define BRCMF_DEFAULT_TXGLOM_SIZE  32  /* max tx frames in glom chain */
 #define BRCMF_DEFAULT_RXGLOM_SIZE  32  /* max rx frames in glom chain */
 
 struct brcmf_sdiod_freezer {
@@ -68,10 +69,6 @@ struct brcmf_sdiod_freezer {
struct completion resumed;
 };
 
-static int brcmf_sdiod_txglomsz = BRCMF_DEFAULT_TXGLOM_SIZE;
-module_param_named(txglomsz, brcmf_sdiod_txglomsz, int, 0);
-MODULE_PARM_DESC(txglomsz, "maximum tx packet chain size [SDIO]");
-
 static irqreturn_t brcmf_sdiod_oob_irqhandler(int irq, void *dev_id)
 {
struct brcmf_bus *bus_if = dev_get_drvdata(dev_id);
@@ -890,7 +887,8 @@ static void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev 
*sdiodev)
if (!sdiodev->sg_support)
return;
 
-   nents = max_t(uint, BRCMF_DEFAULT_RXGLOM_SIZE, brcmf_sdiod_txglomsz);
+   nents = max_t(uint, BRCMF_DEFAULT_RXGLOM_SIZE,
+ sdiodev->bus_if->drvr->settings->sdiod_txglomsz);
nents += (nents >> 4) + 1;
 
WARN_ON(nents > sdiodev->max_segment_count);
@@ -902,7 +900,7 @@ static void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev 
*sdiodev)
sdiodev->sg_support = false;
}
 
-   sdiodev->txglomsz = brcmf_sdiod_txglomsz;
+   sdiodev->txglomsz = sdiodev->bus_if->drvr->settings->sdiod_txglomsz;
 }
 
 #ifdef CONFIG_PM_SLEEP
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 6632e46..87c0a56 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -236,10 +236,6 @@ struct parsed_vndr_ies {
struct parsed_vndr_ie_info ie_info[VNDR_IE_PARSE_LIMIT];
 };
 
-static int brcmf_roamoff;
-module_param_named(roamoff, brcmf_roamoff, int, S_IRUSR);
-MODULE_PARM_DESC(roamoff, "do not use internal roaming engine");
-
 
 static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf,
   struct cfg80211_chan_def *ch)
@@ -5395,7 +5391,7 @@ static s32 brcmf_dongle_roam(struct brcmf_if *ifp)
__le32 roam_delta[2];
 
/* Configure beacon timeout value based upon roaming setting */
-   if (brcmf_roamoff)
+   if (ifp->drvr->settings->roamoff)
bcn_timeout = BRCMF_DEFAULT_BCN_TIMEOUT_ROAM_OFF;
else
bcn_timeout = BRCMF_DEFAULT_BCN_TIMEOUT_ROAM_ON;
@@ -5409,8 +5405,9 @@ static s32 brcmf_dongle_roam(struct brcmf_if *ifp)
 * roaming.
 */
brcmf_dbg(INFO, "Internal Roaming = %s\n",
- brcmf_roamoff ? "Off" : "On");
-   err = brcmf_fil_iovar_int_set(ifp, "roam_off", !!(brcmf_roamoff));
+ ifp->drvr->settings->roamoff ? "Off" : "On");
+   err = brcmf_fil_iovar_int_set(ifp, "roam_off",
+ ifp->drvr->settings->roamoff);
if (err) {
brcmf_err("roam_off error (%d)\n", err);
goto roam_setup_done;
@@ -6082,7 +6079,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct 
brcmf_if *ifp)
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_TDLS))

[PATCH 3/7] brcmfmac: Add support for scheduled scan mac randomization

[Arend van Spriel]

From: Hante Meuleman 

Scheduled scan be requested to use mac randomization. This patch
checks the flags and enables the randomization if desired.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 45 ++
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   | 17 
 2 files changed, 55 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 6b9339b..5964763 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3544,9 +3544,14 @@ static int brcmf_dev_pno_clean(struct net_device *ndev)
return ret;
 }
 
-static int brcmf_dev_pno_config(struct net_device *ndev)
+static int brcmf_dev_pno_config(struct brcmf_if *ifp,
+   struct cfg80211_sched_scan_request *request)
 {
struct brcmf_pno_param_le pfn_param;
+   struct brcmf_pno_macaddr_le pfn_mac;
+   s32 err;
+   u8 *mac_mask;
+   int i;
 
memset(_param, 0, sizeof(pfn_param));
pfn_param.version = cpu_to_le32(BRCMF_PNO_VERSION);
@@ -3559,8 +3564,37 @@ static int brcmf_dev_pno_config(struct net_device *ndev)
/* set up pno scan fr */
pfn_param.scan_freq = cpu_to_le32(BRCMF_PNO_TIME);
 
-   return brcmf_fil_iovar_data_set(netdev_priv(ndev), "pfn_set",
-   _param, sizeof(pfn_param));
+   err = brcmf_fil_iovar_data_set(ifp, "pfn_set", _param,
+  sizeof(pfn_param));
+   if (err) {
+   brcmf_err("pfn_set failed, err=%d\n", err);
+   return err;
+   }
+
+   /* Find out if mac randomization should be turned on */
+   if (!(request->flags & NL80211_SCAN_FLAG_RANDOM_ADDR))
+   return 0;
+
+   pfn_mac.version = BRCMF_PFN_MACADDR_CFG_VER;
+   pfn_mac.flags = BRCMF_PFN_MAC_OUI_ONLY | BRCMF_PFN_SET_MAC_UNASSOC;
+
+   memcpy(pfn_mac.mac, request->mac_addr, ETH_ALEN);
+   mac_mask = request->mac_addr_mask;
+   for (i = 0; i < ETH_ALEN; i++) {
+   pfn_mac.mac[i] &= mac_mask[i];
+   pfn_mac.mac[i] |= get_random_int() & ~(mac_mask[i]);
+   }
+   /* Clear multi bit */
+   pfn_mac.mac[0] &= 0xFE;
+   /* Set locally administered */
+   pfn_mac.mac[0] |= 0x02;
+
+   err = brcmf_fil_iovar_data_set(ifp, "pfn_macaddr", _mac,
+  sizeof(pfn_mac));
+   if (err)
+   brcmf_err("pfn_macaddr failed, err=%d\n", err);
+
+   return err;
 }
 
 static int
@@ -3614,11 +3648,8 @@ brcmf_cfg80211_sched_scan_start(struct wiphy *wiphy,
}
 
/* configure pno */
-   ret = brcmf_dev_pno_config(ndev);
-   if (ret < 0) {
-   brcmf_err("PNO setup failed!! ret=%d\n", ret);
+   if (brcmf_dev_pno_config(ifp, request))
return -EINVAL;
-   }
 
/* configure each match set */
for (i = 0; i < request->n_match_sets; i++) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 0b1e46d..bf2df49 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -128,6 +128,10 @@
 
 #defineBRCMF_MAXPMKID  16  /* max # PMKID cache 
entries */
 
+#define BRCMF_PFN_MACADDR_CFG_VER  1
+#define BRCMF_PFN_MAC_OUI_ONLY BIT(0)
+#define BRCMF_PFN_SET_MAC_UNASSOC  BIT(1)
+
 /* join preference types for join_pref iovar */
 enum brcmf_join_pref_types {
BRCMF_JOIN_PREF_RSSI = 1,
@@ -752,6 +756,19 @@ struct brcmf_pno_scanresults_le {
 };
 
 /**
+ * struct brcmf_pno_macaddr_le - to configure PNO macaddr randomization.
+ *
+ * @version: PNO version identifier.
+ * @flags: Flags defining how mac addrss should be used.
+ * @mac: MAC address.
+ */
+struct brcmf_pno_macaddr_le {
+   u8 version;
+   u8 flags;
+   u8 mac[ETH_ALEN];
+};
+
+/**
  * struct brcmf_pktcnt_le - packet counters.
  *
  * @rx_good_pkt: packets (MSDUs & MMPDUs) received from this station
-- 
1.9.1

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

[PATCH 2/7] brcmfmac: Add get_station support for IBSS

[Arend van Spriel]

From: Hante Meuleman 

When get_station is requested for IBSS then an error will be
printed and no information will be returned. This patch adds
IBSS specific get station information function.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 51 ++
 .../wireless/broadcom/brcm80211/brcmfmac/fwil.h|  1 +
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   | 17 
 3 files changed, 69 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 17658b3..6b9339b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2429,6 +2429,54 @@ static void brcmf_fill_bss_param(struct brcmf_if *ifp, 
struct station_info *si)
 }
 
 static s32
+brcmf_cfg80211_get_station_ibss(struct brcmf_if *ifp,
+   struct station_info *sinfo)
+{
+   struct brcmf_scb_val_le scbval;
+   struct brcmf_pktcnt_le pktcnt;
+   s32 err;
+   u32 rate;
+   u32 rssi;
+
+   /* Get the current tx rate */
+   err = brcmf_fil_cmd_int_get(ifp, BRCMF_C_GET_RATE, );
+   if (err < 0) {
+   brcmf_err("BRCMF_C_GET_RATE error (%d)\n", err);
+   return err;
+   }
+   sinfo->filled |= BIT(NL80211_STA_INFO_TX_BITRATE);
+   sinfo->txrate.legacy = rate * 5;
+
+   memset(, 0, sizeof(scbval));
+   err = brcmf_fil_cmd_data_get(ifp, BRCMF_C_GET_RSSI, ,
+sizeof(scbval));
+   if (err) {
+   brcmf_err("BRCMF_C_GET_RSSI error (%d)\n", err);
+   return err;
+   }
+   rssi = le32_to_cpu(scbval.val);
+   sinfo->filled |= BIT(NL80211_STA_INFO_SIGNAL);
+   sinfo->signal = rssi;
+
+   err = brcmf_fil_cmd_data_get(ifp, BRCMF_C_GET_GET_PKTCNTS, ,
+sizeof(pktcnt));
+   if (err) {
+   brcmf_err("BRCMF_C_GET_GET_PKTCNTS error (%d)\n", err);
+   return err;
+   }
+   sinfo->filled |= BIT(NL80211_STA_INFO_RX_PACKETS) |
+BIT(NL80211_STA_INFO_RX_DROP_MISC) |
+BIT(NL80211_STA_INFO_TX_PACKETS) |
+BIT(NL80211_STA_INFO_TX_FAILED);
+   sinfo->rx_packets = le32_to_cpu(pktcnt.rx_good_pkt);
+   sinfo->rx_dropped_misc = le32_to_cpu(pktcnt.rx_bad_pkt);
+   sinfo->tx_packets = le32_to_cpu(pktcnt.tx_good_pkt);
+   sinfo->tx_failed  = le32_to_cpu(pktcnt.tx_bad_pkt);
+
+   return 0;
+}
+
+static s32
 brcmf_cfg80211_get_station(struct wiphy *wiphy, struct net_device *ndev,
   const u8 *mac, struct station_info *sinfo)
 {
@@ -2445,6 +2493,9 @@ brcmf_cfg80211_get_station(struct wiphy *wiphy, struct 
net_device *ndev,
if (!check_vif_up(ifp->vif))
return -EIO;
 
+   if (brcmf_is_ibssmode(ifp->vif))
+   return brcmf_cfg80211_get_station_ibss(ifp, sinfo);
+
memset(_info_le, 0, sizeof(sta_info_le));
memcpy(_info_le, mac, ETH_ALEN);
err = brcmf_fil_iovar_data_get(ifp, "tdls_sta_info",
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
index b20fc0f..6b72df1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
@@ -70,6 +70,7 @@
 #define BRCMF_C_SET_WSEC   134
 #define BRCMF_C_GET_PHY_NOISE  135
 #define BRCMF_C_GET_BSS_INFO   136
+#define BRCMF_C_GET_GET_PKTCNTS137
 #define BRCMF_C_GET_BANDLIST   140
 #define BRCMF_C_SET_SCB_TIMEOUT158
 #define BRCMF_C_GET_ASSOCLIST  159
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index 94d34ad..0b1e46d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -751,4 +751,21 @@ struct brcmf_pno_scanresults_le {
__le32 count;
 };
 
+/**
+ * struct brcmf_pktcnt_le - packet counters.
+ *
+ * @rx_good_pkt: packets (MSDUs & MMPDUs) received from this station
+ * @rx_bad_pkt: failed rx packets
+ * @tx_good_pkt: packets (MSDUs & MMPDUs) transmitted to this station
+ * @tx_bad_pkt: failed tx packets
+ * @rx_ocast_good_pkt: unicast packets destined for others
+ */
+struct brcmf_pktcnt_le {
+   __le32 rx_good_pkt;
+   __le32 rx_bad_pkt;
+   __le32 tx_good_pkt;
+   __le32 tx_bad_pkt;
+   __le32 

[PATCH 5/7] brcmfmac: Fix warn trace on module unload while in ibss mode

[Arend van Spriel]

From: Hante Meuleman 

When the driver is being unloaded a situation can occur where the
wirelesss core (cfg80211) wants to remove the ibss, but the state
of brcmfmac has already been set to down. When an error is
returned in that situation then that will result in a stack
trace on removal of the wiphy object. This is avoided by
returning 0 when device is down on a leave_ibss call.

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

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 5964763..6632e46 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1448,8 +1448,13 @@ brcmf_cfg80211_leave_ibss(struct wiphy *wiphy, struct 
net_device *ndev)
struct brcmf_if *ifp = netdev_priv(ndev);
 
brcmf_dbg(TRACE, "Enter\n");
-   if (!check_vif_up(ifp->vif))
-   return -EIO;
+   if (!check_vif_up(ifp->vif)) {
+   /* When driver is being unloaded, it can end up here. If an
+* error is returned then later on a debug trace in the wireless
+* core module will be printed. To avoid this 0 is returned.
+*/
+   return 0;
+   }
 
brcmf_link_down(ifp->vif, WLAN_REASON_DEAUTH_LEAVING);
 
-- 
1.9.1

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

[PATCH 4/7] brcmfmac: obtain feature info using 'cap' firmware command

[Arend van Spriel]

Several features in the driver directly map to a firmware feature
listed in response of the 'cap' firmware command. For those features
this response will be examined instead of attempting individual
firmware commands.

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

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index d9d1ca4..08b7200 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -40,6 +40,17 @@ static const char *brcmf_feat_names[] = {
 };
 #undef BRCMF_FEAT_DEF
 
+struct brcmf_feat_fwcap {
+   enum brcmf_feat_id feature;
+   const char * const fwcap_id;
+};
+
+static const struct brcmf_feat_fwcap brcmf_fwcap_map[] = {
+   { BRCMF_FEAT_MBSS, "mbss" },
+   { BRCMF_FEAT_MCHAN, "mchan" },
+   { BRCMF_FEAT_P2P, "p2p" },
+};
+
 #ifdef DEBUG
 /*
  * expand quirk list to array of quirk strings.
@@ -104,25 +115,22 @@ static void brcmf_feat_iovar_int_get(struct brcmf_if *ifp,
}
 }
 
-/**
- * brcmf_feat_iovar_int_set() - determine feature through iovar set.
- *
- * @ifp: interface to query.
- * @id: feature id.
- * @name: iovar name.
- */
-static void brcmf_feat_iovar_int_set(struct brcmf_if *ifp,
-enum brcmf_feat_id id, char *name, u32 val)
+static void brcmf_feat_firmware_capabilities(struct brcmf_if *ifp)
 {
-   int err;
-
-   err = brcmf_fil_iovar_int_set(ifp, name, val);
-   if (err == 0) {
-   brcmf_dbg(INFO, "enabling feature: %s\n", brcmf_feat_names[id]);
-   ifp->drvr->feat_flags |= BIT(id);
-   } else {
-   brcmf_dbg(TRACE, "%s feature check failed: %d\n",
- brcmf_feat_names[id], err);
+   char caps[256];
+   enum brcmf_feat_id id;
+   int i;
+
+   brcmf_fil_iovar_data_get(ifp, "cap", caps, sizeof(caps));
+   brcmf_dbg(INFO, "[ %s]\n", caps);
+
+   for (i = 0; i < ARRAY_SIZE(brcmf_fwcap_map); i++) {
+   if (strnstr(caps, brcmf_fwcap_map[i].fwcap_id, sizeof(caps))) {
+   id = brcmf_fwcap_map[i].feature;
+   brcmf_dbg(INFO, "enabling feature: %s\n",
+ brcmf_feat_names[id]);
+   ifp->drvr->feat_flags |= BIT(id);
+   }
}
 }
 
@@ -130,13 +138,14 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
 {
struct brcmf_if *ifp = brcmf_get_ifp(drvr, 0);
 
-   brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_MCHAN, "mchan");
+   brcmf_feat_firmware_capabilities(ifp);
+
brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_PNO, "pfn");
if (drvr->bus_if->wowl_supported)
brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_WOWL, "wowl");
+   /* MBSS does not work for 43362 */
if (drvr->bus_if->chip != BRCM_CC_43362_CHIP_ID)
-   brcmf_feat_iovar_int_set(ifp, BRCMF_FEAT_MBSS, "mbss", 0);
-   brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_P2P, "p2p");
+   ifp->drvr->feat_flags &= BIT(BRCMF_FEAT_MBSS);
brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_RSDB, "rsdb_mode");
brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_TDLS, "tdls_enable");
 
-- 
1.9.1

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

[PATCH] mtd: nand: bcm47xxnflash: fix bcm47xxnflash_remove()

[Boris Brezillon]

bcm47xxnflash_remove() is supposed to unregister the NAND device previously
registered in bcm47xxnflash_probe(), but the current implementation just
test for the always NULL ->mtd platform data field (and does not call the
right function to unregister it).

Kill the useless ->mtd field in struct bcma_nflash, and release the real
NAND device in bcm47xxnflash_remove().

Signed-off-by: Boris Brezillon 
Fixes: a5401370c520 ("mtd: prepare place for BCMA NAND flash driver(s)")
Cc: Rafał Miłecki 
---
 drivers/mtd/nand/bcm47xxnflash/main.c   | 7 ---
 include/linux/bcma/bcma_driver_chipcommon.h | 4 
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/bcm47xxnflash/main.c 
b/drivers/mtd/nand/bcm47xxnflash/main.c
index 9ba0c0f..4a07e56 100644
--- a/drivers/mtd/nand/bcm47xxnflash/main.c
+++ b/drivers/mtd/nand/bcm47xxnflash/main.c
@@ -55,15 +55,16 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
return err;
}
 
+   platform_set_drvdata(pdev, b47n);
+
return 0;
 }
 
 static int bcm47xxnflash_remove(struct platform_device *pdev)
 {
-   struct bcma_nflash *nflash = dev_get_platdata(>dev);
+   struct bcm47xxnflash *b47n = platform_get_drvdata(pdev);
 
-   if (nflash->mtd)
-   mtd_device_unregister(nflash->mtd);
+   nand_release(nand_to_mtd(>nand_chip));
 
return 0;
 }
diff --git a/include/linux/bcma/bcma_driver_chipcommon.h 
b/include/linux/bcma/bcma_driver_chipcommon.h
index cf03843..3015432 100644
--- a/include/linux/bcma/bcma_driver_chipcommon.h
+++ b/include/linux/bcma/bcma_driver_chipcommon.h
@@ -592,13 +592,9 @@ struct bcma_sflash {
 #endif
 
 #ifdef CONFIG_BCMA_NFLASH
-struct mtd_info;
-
 struct bcma_nflash {
bool present;
bool boot;  /* This is the flash the SoC boots from */
-
-   struct mtd_info *mtd;
 };
 #endif
 
-- 
2.1.4

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

[ANN] wireless-regdb: master-2015-12-14

[Seth Forshee]

A new release of wireless-regdb (master-2015-12-14) is available at:

https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2015.12.14.tar.gz

The short log of changes since the 2015-10-22 release is below.

Thanks,
Seth

---

Anssi Hannula (1):
  wireless-regdb: Update regulatory rules for Finland (FI)

Johannes Berg (1):
  regulatory: fix world regdomain

Seth Forshee (1):
  wireless-regdb: update regulatory.bin based on preceding changes

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

Re: [PATCH] mtd: nand: bcm47xxnflash: fix bcm47xxnflash_remove()

[Brian Norris]

On Mon, Dec 14, 2015 at 06:14:10PM +0100, Boris Brezillon wrote:
> bcm47xxnflash_remove() is supposed to unregister the NAND device previously
> registered in bcm47xxnflash_probe(), but the current implementation just
> test for the always NULL ->mtd platform data field (and does not call the
> right function to unregister it).
> 
> Kill the useless ->mtd field in struct bcma_nflash, and release the real
> NAND device in bcm47xxnflash_remove().
> 
> Signed-off-by: Boris Brezillon 
> Fixes: a5401370c520 ("mtd: prepare place for BCMA NAND flash driver(s)")
> Cc: Rafał Miłecki 
> ---
>  drivers/mtd/nand/bcm47xxnflash/main.c   | 7 ---
>  include/linux/bcma/bcma_driver_chipcommon.h | 4 
>  2 files changed, 4 insertions(+), 7 deletions(-)

Hmm, looks awfully similar...

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

Re: [PATCH v7] Add new mac80211 driver mwlwifi.

[Kan Yan]

David Lin  writes:

> +static inline struct sk_buff *mwl_tx_do_amsdu(struct mwl_priv *priv,
> +   int desc_num,
> ...
> + amsdu_pkts = (struct sk_buff_head *)
> + kmalloc(sizeof(*amsdu_pkts), GFP_KERNEL);
> + if (!amsdu_pkts) {

Should GFP_ATOMIC be used here instead of GFP_KERNEL? This function could be
called in interrupt context.

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

[ANNOUNCE] Another round of NetDev 1.1 updates

[Pablo Neira Ayuso]

Hi!

We would like to share with you another round of incremental updates
on accepted sessions in netdev 1.1, the community-driven Linux
networking conference held back-to-back with netconf in Sevilla,
Spain, February 10-12, 2016.

= Keynote =

* "Hardware Checksumming: Less is More" (David S. Miller)

= BoF =

* "Unlocking SR-IOV in Linux" (John Fastabend)

= Talks =

* "Measuring wifi performance across all Google Fiber customers"
  (Avery Pennarun)

* "Load balancing with nftables" (Laura Garcia)

= Tutorials =

* "Running Cellular Network Infrastructure on Linux" (Harald Welte)

Remember session proposal submission is open until Dec 20th.

Registration is open at: https://www.netdevconf.org/1.1/registration.html

 _
/ If you miss netdev 1.1, \
\ you'll regret!  /
 -
\   ^__^
 \  (oo)\___
(__)\   )\/\
||w |
|| ||

For more info, visit:
* netdev 1.1: https://www.netdevconf.org/1.1/
* netconf 2016: http://vger.kernel.org/netconf2016.html

We would also like to thank those that already confirmed sponsorship:
Cumulus Networks, Facebook, VmWare, Google, Mellanox, Mojatatu
Networks, OISF/Suricata and Zen Load Balancer. Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] Add new mac80211 driver mwlwifi.

[Kalle Valo]

Grant Grundler  writes:

> Sorry for the late response...just one point below
>
> On Fri, Nov 20, 2015 at 3:22 AM, Johannes Berg 
> wrote:
>
> > +#define MWL_DRV_NAME KBUILD_MODNAME
> > +#define MWL_DRV_VERSION       "10.3.0.14"
>
> versions like that are generally fairly useless since you don't update
> them for every commit ...
>
>
> When backporting to other kernel trees, it's extremely handy to have a
> DRV_VERSION.
>
> Checking if a particular kernel build has the expected driver version trivial.
>  "mod_info" dumps the driver version for modules (which this will usually be
> too).
>
> And yes, it won't get updated for every commit only because other version
> control might encapsulate those changes. Not every distro makes their build
> versioning accessible to outsiders. So it's still helpful even if not perfect.
>
> Marvell can update this every time they resync with their own internal
> versions.

But the problem is that you cannot really trust this driver version
string. I found a perfect example from another Marvell driver:

5e6e3a92b9a4c drivers/net/wireless/mwifiex/main.c (Bing Zhao 2011-03-21 
18:00:50 -0700   25) #define VERSION   "1.0"

So nobody has updated that version string since the initial commit from
2011 and that driver has had over 900 non-merge commits after that.
Because of bad cases like this I think having a driver specific versions
in in-tree drivers are just noise and unnecessary extra work. When
porting a driver to another tree git commit ids, release tag names or
git-describe output are much better ways to identify the driver version.

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

Re: [PATCH] mtd: bcm47xxnflash: really unregister NAND on device removal

[Boris Brezillon]

On Tue,  8 Dec 2015 17:04:59 -0800
Brian Norris  wrote:

> The field bcma_nflash::mtd is never set to be non-zero anywhere, but we
> test for it in the removal path. So the MTD is never unregistered.
> 
> Also, we should use nand_release(), not mtd_device_unregister().
> 
> Finally, we don't need to use the 'platdata' for stashing/retrieving our
> *driver* data -- that's what *_{get,set}_drvdata() are for.
> 
> So, kill off bcm_nflash::mtd, and stash the struct bcm47xxnflash in
> drvdata instead. Also move the forward declaration of mtd_info up a bit,
> since struct bcma_sflash should be using it.
> 
> Caught while inspecting other changes being made to this driver. Compile
> tested only.
> 
> Signed-off-by: Brian Norris 
> Cc: "Rafał Miłecki" 
> Cc: linux-wireless@vger.kernel.org

Acked-by: Boris Brezillon 

> ---
> Might have some small conflict with Boris' NAND/MTD refactoring patch set. I
> can rebase this small one if his gets in proper shape. Just wanted to get this
> out there.
> 
>  drivers/mtd/nand/bcm47xxnflash/main.c   | 7 ---
>  include/linux/bcma/bcma_driver_chipcommon.h | 6 ++
>  2 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mtd/nand/bcm47xxnflash/main.c 
> b/drivers/mtd/nand/bcm47xxnflash/main.c
> index 9ba0c0f2cd9b..0b3acc439181 100644
> --- a/drivers/mtd/nand/bcm47xxnflash/main.c
> +++ b/drivers/mtd/nand/bcm47xxnflash/main.c
> @@ -49,6 +49,8 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
>   return err;
>   }
>  
> + platform_set_drvdata(pdev, b47n);
> +
>   err = mtd_device_parse_register(>mtd, probes, NULL, NULL, 0);
>   if (err) {
>   pr_err("Failed to register MTD device: %d\n", err);
> @@ -60,10 +62,9 @@ static int bcm47xxnflash_probe(struct platform_device 
> *pdev)
>  
>  static int bcm47xxnflash_remove(struct platform_device *pdev)
>  {
> - struct bcma_nflash *nflash = dev_get_platdata(>dev);
> + struct bcm47xxnflash *nflash = platform_get_drvdata(pdev);
>  
> - if (nflash->mtd)
> - mtd_device_unregister(nflash->mtd);
> + nand_release(>mtd);
>  
>   return 0;
>  }
> diff --git a/include/linux/bcma/bcma_driver_chipcommon.h 
> b/include/linux/bcma/bcma_driver_chipcommon.h
> index cf038431a5cc..db51a6ffb7d6 100644
> --- a/include/linux/bcma/bcma_driver_chipcommon.h
> +++ b/include/linux/bcma/bcma_driver_chipcommon.h
> @@ -579,6 +579,8 @@ struct bcma_pflash {
>  };
>  
>  #ifdef CONFIG_BCMA_SFLASH
> +struct mtd_info;
> +
>  struct bcma_sflash {
>   bool present;
>   u32 window;
> @@ -592,13 +594,9 @@ struct bcma_sflash {
>  #endif
>  
>  #ifdef CONFIG_BCMA_NFLASH
> -struct mtd_info;
> -
>  struct bcma_nflash {
>   bool present;
>   bool boot;  /* This is the flash the SoC boots from */
> -
> - struct mtd_info *mtd;
>  };
>  #endif
>  



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mtd: bcm47xxnflash: really unregister NAND on device removal

[Brian Norris]

On Mon, Dec 14, 2015 at 06:49:07PM +0100, Boris Brezillon wrote:
> On Tue,  8 Dec 2015 17:04:59 -0800
> Brian Norris  wrote:
> 
> > The field bcma_nflash::mtd is never set to be non-zero anywhere, but we
> > test for it in the removal path. So the MTD is never unregistered.
> > 
> > Also, we should use nand_release(), not mtd_device_unregister().
> > 
> > Finally, we don't need to use the 'platdata' for stashing/retrieving our
> > *driver* data -- that's what *_{get,set}_drvdata() are for.
> > 
> > So, kill off bcm_nflash::mtd, and stash the struct bcm47xxnflash in
> > drvdata instead. Also move the forward declaration of mtd_info up a bit,
> > since struct bcma_sflash should be using it.
> > 
> > Caught while inspecting other changes being made to this driver. Compile
> > tested only.
> > 
> > Signed-off-by: Brian Norris 
> > Cc: "Rafał Miłecki" 
> > Cc: linux-wireless@vger.kernel.org
> 
> Acked-by: Boris Brezillon 

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

Re: [PATCH] mtd: nand: bcm47xxnflash: fix bcm47xxnflash_remove()

[Boris Brezillon]

Hi Brian,

On Mon, 14 Dec 2015 09:30:11 -0800
Brian Norris  wrote:

> On Mon, Dec 14, 2015 at 06:14:10PM +0100, Boris Brezillon wrote:
> > bcm47xxnflash_remove() is supposed to unregister the NAND device previously
> > registered in bcm47xxnflash_probe(), but the current implementation just
> > test for the always NULL ->mtd platform data field (and does not call the
> > right function to unregister it).
> > 
> > Kill the useless ->mtd field in struct bcma_nflash, and release the real
> > NAND device in bcm47xxnflash_remove().
> > 
> > Signed-off-by: Boris Brezillon 
> > Fixes: a5401370c520 ("mtd: prepare place for BCMA NAND flash driver(s)")
> > Cc: Rafał Miłecki 
> > ---
> >  drivers/mtd/nand/bcm47xxnflash/main.c   | 7 ---
> >  include/linux/bcma/bcma_driver_chipcommon.h | 4 
> >  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> Hmm, looks awfully similar...
> 
> http://patchwork.ozlabs.org/patch/554164/

My bad, I completely overlooked it, even though I was in Cc of this
patch.
I acked it, could you apply it before my series so that I can can
adjust the bcma patch?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] Fixes for module parameters

[Larry Finger]

To: kv...@codeaurora.org
Cc: linux-wireless@vger.kernel.org
de...@driverdev.osuosl.org

Several of the rtlwifi-driver family have errors in the handling of
module parameters. These 8 patches for the -next repo contain fixes.

Signed-off-by: Larry Finger 

Larry Finger (8):
  rtlwifi: rtl8723be: Fix module parameter initialization
  rtlwifi: rtl8723ae: Fix initialization of module parameters
  rtlwifi: rtl8821ae: Fix errors in parameter initialization
  rtlwifi: rtl8188ee: Fix module parameter initialization
  rtlwifi: rtl8192de: Fix incorrect module parameter descriptions
  rtlwifi: rtl8192se: Fix module parameter initialization
  rtlwifi: rtl8192ce: Fix handling of module parameters
  rtlwifi: rtl8192cu: Add missing parameter setup

 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 7 +--
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 6 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 9 +
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 8 +++-
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 9 +
 8 files changed, 36 insertions(+), 11 deletions(-)

-- 
2.1.4

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

[PATCH 7/8] rtlwifi: rtl8192ce: Fix handling of module parameters

[Larry Finger]

The module parameter for software encryption was never transferred to
the location used by the driver.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
index de6cb6c..4780bdc 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
@@ -139,6 +139,8 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->psc.inactiveps = rtlpriv->cfg->mod_params->inactiveps;
rtlpriv->psc.swctrl_lps = rtlpriv->cfg->mod_params->swctrl_lps;
rtlpriv->psc.fwctrl_lps = rtlpriv->cfg->mod_params->fwctrl_lps;
+   rtlpriv->cfg->mod_params->sw_crypto =
+   rtlpriv->cfg->mod_params->sw_crypto;
if (!rtlpriv->psc.inactiveps)
pr_info("rtl8192ce: Power Save off (module option)\n");
if (!rtlpriv->psc.fwctrl_lps)
-- 
2.1.4

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

[PATCH 4/8] rtlwifi: rtl8188ee: Fix module parameter initialization

[Larry Finger]

In this driver, parameters disable_watchdog and sw_crypto are never
copied into the locations used in the main code. While modifying the
parameter handling, the copying of parameter msi_support is moved to
be with the rest.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
index 1134412..47e32cb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c
@@ -88,8 +88,6 @@ int rtl88e_init_sw_vars(struct ieee80211_hw *hw)
u8 tid;
 
rtl8188ee_bt_reg_init(hw);
-   rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
-
rtlpriv->dm.dm_initialgain_enable = 1;
rtlpriv->dm.dm_flag = 0;
rtlpriv->dm.disable_framebursting = 0;
@@ -138,6 +136,11 @@ int rtl88e_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->psc.inactiveps = rtlpriv->cfg->mod_params->inactiveps;
rtlpriv->psc.swctrl_lps = rtlpriv->cfg->mod_params->swctrl_lps;
rtlpriv->psc.fwctrl_lps = rtlpriv->cfg->mod_params->fwctrl_lps;
+   rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
+   rtlpriv->cfg->mod_params->sw_crypto =
+   rtlpriv->cfg->mod_params->sw_crypto;
+   rtlpriv->cfg->mod_params->disable_watchdog =
+   rtlpriv->cfg->mod_params->disable_watchdog;
if (rtlpriv->cfg->mod_params->disable_watchdog)
pr_info("watchdog disabled\n");
if (!rtlpriv->psc.inactiveps)
-- 
2.1.4

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

[PATCH 5/8] rtlwifi: rtl8192de: Fix incorrect module parameter descriptions

[Larry Finger]

Two of the module parameters are listed with incorrect default values.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
index b19d039..c6e09a1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c
@@ -376,8 +376,8 @@ module_param_named(swlps, rtl92de_mod_params.swctrl_lps, 
bool, 0444);
 module_param_named(fwlps, rtl92de_mod_params.fwctrl_lps, bool, 0444);
 MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
 MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
-MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
-MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 1)\n");
+MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 1)\n");
+MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 0)\n");
 MODULE_PARM_DESC(debug, "Set debug level (0-5) (default 0)");
 
 static SIMPLE_DEV_PM_OPS(rtlwifi_pm_ops, rtl_pci_suspend, rtl_pci_resume);
-- 
2.1.4

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

[PATCH 2/8] rtlwifi: rtl8723ae: Fix initialization of module parameters

[Larry Finger]

This driver has some errors in the handling of module parameters. These
include missing initialization for parameters msi_support and
disable_watchdog. In addition, neither of these parameters nor sw_crypto
are transferred into the locations used by the driver. A final fix is
adding parameter msi to the module named and description macros.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
index 3859b3e..ff49a8c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
@@ -150,6 +150,11 @@ int rtl8723e_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->psc.inactiveps = rtlpriv->cfg->mod_params->inactiveps;
rtlpriv->psc.swctrl_lps = rtlpriv->cfg->mod_params->swctrl_lps;
rtlpriv->psc.fwctrl_lps = rtlpriv->cfg->mod_params->fwctrl_lps;
+   rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
+   rtlpriv->cfg->mod_params->sw_crypto =
+   rtlpriv->cfg->mod_params->sw_crypto;
+   rtlpriv->cfg->mod_params->disable_watchdog =
+   rtlpriv->cfg->mod_params->disable_watchdog;
if (rtlpriv->cfg->mod_params->disable_watchdog)
pr_info("watchdog disabled\n");
rtlpriv->psc.reg_fwctrl_lps = 3;
@@ -267,6 +272,8 @@ static struct rtl_mod_params rtl8723e_mod_params = {
.swctrl_lps = false,
.fwctrl_lps = true,
.debug = DBG_EMERG,
+   .msi_support = false,
+   .disable_watchdog = false,
 };
 
 static struct rtl_hal_cfg rtl8723e_hal_cfg = {
@@ -383,12 +390,14 @@ module_param_named(debug, rtl8723e_mod_params.debug, int, 
0444);
 module_param_named(ips, rtl8723e_mod_params.inactiveps, bool, 0444);
 module_param_named(swlps, rtl8723e_mod_params.swctrl_lps, bool, 0444);
 module_param_named(fwlps, rtl8723e_mod_params.fwctrl_lps, bool, 0444);
+module_param_named(msi, rtl8723e_mod_params.msi_support, bool, 0444);
 module_param_named(disable_watchdog, rtl8723e_mod_params.disable_watchdog,
   bool, 0444);
 MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
 MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
 MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
 MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 1)\n");
+MODULE_PARM_DESC(msi, "Set to 1 to use MSI interrupts mode (default 0)\n");
 MODULE_PARM_DESC(debug, "Set debug level (0-5) (default 0)");
 MODULE_PARM_DESC(disable_watchdog, "Set to 1 to disable the watchdog (default 
0)\n");
 
-- 
2.1.4

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

[PATCH 1/8] rtlwifi: rtl8723be: Fix module parameter initialization

[Larry Finger]

This driver has a number of errors in the module initialization. These
include the following:

Parameter msi_support is stored in two places - one is removed.
Paramters sw_crypto and disable_watchdog were never stored in the final
locations, nor were they initialized properly.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
index d091f1d..a78eaed 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c
@@ -93,7 +93,6 @@ int rtl8723be_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
 
rtl8723be_bt_reg_init(hw);
-   rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
rtlpriv->btcoexist.btc_ops = rtl_btc_get_ops_pointer();
 
rtlpriv->dm.dm_initialgain_enable = 1;
@@ -151,6 +150,10 @@ int rtl8723be_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->psc.swctrl_lps = rtlpriv->cfg->mod_params->swctrl_lps;
rtlpriv->psc.fwctrl_lps = rtlpriv->cfg->mod_params->fwctrl_lps;
rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
+   rtlpriv->cfg->mod_params->sw_crypto =
+rtlpriv->cfg->mod_params->sw_crypto;
+   rtlpriv->cfg->mod_params->disable_watchdog =
+rtlpriv->cfg->mod_params->disable_watchdog;
if (rtlpriv->cfg->mod_params->disable_watchdog)
pr_info("watchdog disabled\n");
rtlpriv->psc.reg_fwctrl_lps = 3;
@@ -267,6 +270,9 @@ static struct rtl_mod_params rtl8723be_mod_params = {
.inactiveps = true,
.swctrl_lps = false,
.fwctrl_lps = true,
+   .msi_support = false,
+   .disable_watchdog = false,
+   .debug = DBG_EMERG,
 };
 
 static struct rtl_hal_cfg rtl8723be_hal_cfg = {
-- 
2.1.4

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

[PATCH 3/8] rtlwifi: rtl8821ae: Fix errors in parameter initialization

[Larry Finger]

This driver failed to copy parameters sw_crypto and disable_watchdog into
the locations actually used by the driver. In addition, msi_support was
initialized three times and one of them used the wrong variable. The
initialization of parameter int_clear was moved so that it is near that
of the rest of the parameters.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
index 142bdff..4159f9b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c
@@ -95,8 +95,6 @@ int rtl8821ae_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
 
rtl8821ae_bt_reg_init(hw);
-   rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
-   rtlpci->int_clear = rtlpriv->cfg->mod_params->int_clear;
rtlpriv->btcoexist.btc_ops = rtl_btc_get_ops_pointer();
 
rtlpriv->dm.dm_initialgain_enable = 1;
@@ -168,12 +166,15 @@ int rtl8821ae_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->psc.swctrl_lps = rtlpriv->cfg->mod_params->swctrl_lps;
rtlpriv->psc.fwctrl_lps = rtlpriv->cfg->mod_params->fwctrl_lps;
rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
-   rtlpci->msi_support = rtlpriv->cfg->mod_params->int_clear;
+   rtlpci->int_clear = rtlpriv->cfg->mod_params->int_clear;
+   rtlpriv->cfg->mod_params->sw_crypto =
+   rtlpriv->cfg->mod_params->sw_crypto;
+   rtlpriv->cfg->mod_params->disable_watchdog =
+   rtlpriv->cfg->mod_params->disable_watchdog;
if (rtlpriv->cfg->mod_params->disable_watchdog)
pr_info("watchdog disabled\n");
rtlpriv->psc.reg_fwctrl_lps = 3;
rtlpriv->psc.reg_max_lps_awakeintvl = 5;
-   rtlpci->msi_support = rtlpriv->cfg->mod_params->msi_support;
 
/* for ASPM, you can close aspm through
 * set const_support_pciaspm = 0
-- 
2.1.4

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

[PATCH 8/8] rtlwifi: rtl8192cu: Add missing parameter setup

[Larry Finger]

This driver fails to copy the module parameter for software encryption
to the locations used by the main code.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index fd4a535..7c6f7f0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -65,6 +65,8 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->dm.disable_framebursting = false;
rtlpriv->dm.thermalvalue = 0;
rtlpriv->dbg.global_debuglevel = rtlpriv->cfg->mod_params->debug;
+   rtlpriv->cfg->mod_params->sw_crypto =
+   rtlpriv->cfg->mod_params->sw_crypto;
 
/* for firmware buf */
rtlpriv->rtlhal.pfirmware = vzalloc(0x4000);
-- 
2.1.4

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

[PATCH 6/8] rtlwifi: rtl8192se: Fix module parameter initialization

[Larry Finger]

Two of the module parameter descriptions show incorrect default values.
In addition the value for software encryption is not transferred to
the locations used by the driver.

Signed-off-by: Larry Finger 
Cc: Stable 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
index e1fd27c..31baca41 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c
@@ -187,6 +187,8 @@ static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->psc.inactiveps = rtlpriv->cfg->mod_params->inactiveps;
rtlpriv->psc.swctrl_lps = rtlpriv->cfg->mod_params->swctrl_lps;
rtlpriv->psc.fwctrl_lps = rtlpriv->cfg->mod_params->fwctrl_lps;
+   rtlpriv->cfg->mod_params->sw_crypto =
+   rtlpriv->cfg->mod_params->sw_crypto;
if (!rtlpriv->psc.inactiveps)
pr_info("Power Save off (module option)\n");
if (!rtlpriv->psc.fwctrl_lps)
@@ -425,8 +427,8 @@ module_param_named(swlps, rtl92se_mod_params.swctrl_lps, 
bool, 0444);
 module_param_named(fwlps, rtl92se_mod_params.fwctrl_lps, bool, 0444);
 MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
 MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
-MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
-MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 1)\n");
+MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 1)\n");
+MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 0)\n");
 MODULE_PARM_DESC(debug, "Set debug level (0-5) (default 0)");
 
 static SIMPLE_DEV_PM_OPS(rtlwifi_pm_ops, rtl_pci_suspend, rtl_pci_resume);
-- 
2.1.4

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

Re: iwlwifi - L1 Enabled - LTR Enabled loop

[Johannes Berg]

On Mon, 2015-12-14 at 04:00 +, Grumbach, Emmanuel wrote:
> 
> This is really weird. I don't see how that could be firmware related.
> BTW, -10.ucode is fairly old :) we have -16.ucode out there.

I guess the question is how we get into this situation to start with?

About the only thing I can imagine is that we fail somehow during
initialization (without printing any other message) and higher layers
like wpa_supplicant/network-manager/... simply try to bring up the
device over and over again?

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

Re: [PATCH v2] wcn36xx: handle rx skb allocation failure to avoid system crash

[Julian Calaby]

Hi Fengwei,

On Mon, Dec 14, 2015 at 9:06 PM, Fengwei Yin  wrote:
> Lawrence reported that git clone could make system crash on a
> Qualcomm ARM soc based device (DragonBoard, 1G memory without
> swap) running 64bit Debian.
>
> It's turned out the crash is related with rx skb allocation
> failure. git could consume more than 600MB anonymous memory.
> And system is in extremely memory shortage case.
>
> But driver didn't handle the rx allocation failure case. This patch
> doesn't submit skb to upper layer if rx skb allocation fails.
> Instead, it reuse the old skb for rx DMA again. It's more like
> drop the packets if system is in memory shortage case.
>
> With this change, git clone is OOMed instead of system crash.
>
> Reported-by: King, Lawrence 
> Signed-off-by: Fengwei Yin 
> ---
> Changes from v1:
>  * Move switch block out of while loop.
>  * Remove the warning of unknown channel because we didn't deal with it.
>
>  drivers/net/wireless/ath/wcn36xx/dxe.c | 50 
> --
>  1 file changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
> b/drivers/net/wireless/ath/wcn36xx/dxe.c
> index f8dfa05..6b61874 100644
> --- a/drivers/net/wireless/ath/wcn36xx/dxe.c
> +++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
> @@ -467,6 +467,18 @@ out_err:
>
>  }
>
> +#defineGET_CH_CTRL_VALUE(x)\
> +   ({ u32 __v = WCN36XX_DXE_CTRL_RX_H; \
> +  if ((x) == WCN36XX_DXE_CH_RX_L)  \
> +   __v = WCN36XX_DXE_CTRL_RX_L;\
> +  __v; })
> +
> +#defineGET_CH_INT_MASK(x)  \
> +   ({ u32 __v = WCN36XX_DXE_INT_CH3_MASK;  \
> +  if ((x) == WCN36XX_DXE_CH_RX_L)  \
> +   __v = WCN36XX_DXE_INT_CH1_MASK; \
> +  __v; })
> +

Why add these ugly macros if you're only calling them once?

>  static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
>  struct wcn36xx_dxe_ch *ch)
>  {
> @@ -474,36 +486,34 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx 
> *wcn,
> struct wcn36xx_dxe_desc *dxe = ctl->desc;
> dma_addr_t  dma_addr;
> struct sk_buff *skb;
> +   int ret = 0, int_mask;
> +   u32 value;
> +

Surely something like:

if (ch->ch_type == WCN36XX_DXE_CH_RX_L) {
value = WCN36XX_DXE_CTRL_RX_L;
int_mask = WCN36XX_DXE_INT_CH1_MASK;
} else {
value = WCN36XX_DXE_CTRL_RX_H;
int_mask = WCN36XX_DXE_INT_CH3_MASK;
}

would be much cleaner.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html