RE: [PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()
> From: Ricky Liang [mailto:jcli...@chromium.org] > Sent: Wednesday, November 09, 2016 9:07 AM > Cc: Ricky Liang; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; open > list:MARVELL MWIFIEX WIRELESS DRIVER; open list:NETWORKING DRIVERS; open > list > Subject: [PATCH] mwifiex: fix memory leak in > mwifiex_save_hidden_ssid_channels() > > kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels(): > > unreferenced object 0xffc0a2914780 (size 192): > comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s) > hex dump (first 32 bytes): > 00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@ > 07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04 ..TW 4..d.$..$.. > backtrace: > [] create_object+0x164/0x2b4 > [] kmemleak_alloc+0x50/0x88 > [] __kmalloc_track_caller+0x1bc/0x264 > [] kmemdup+0x38/0x64 > [] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex] > [] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex] > [] > mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex] > [] mwifiex_process_sta_event+0x378/0x898 [mwifiex] > [] mwifiex_process_event+0x1a8/0x1e8 [mwifiex] > [] mwifiex_main_process+0x258/0x534 [mwifiex] > [] 0xffbffc258858 > [] process_sdio_pending_irqs+0xf8/0x160 > [] sdio_irq_thread+0x9c/0x1a4 > [] kthread+0xf4/0x100 > [] ret_from_fork+0xc/0x50 > [] 0x > > Signed-off-by: Ricky Liang <jcli...@chromium.org> > --- > drivers/net/wireless/marvell/mwifiex/scan.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c > b/drivers/net/wireless/marvell/mwifiex/scan.c > index 97c9765..98ce072 100644 > --- a/drivers/net/wireless/marvell/mwifiex/scan.c > +++ b/drivers/net/wireless/marvell/mwifiex/scan.c > @@ -1671,6 +1671,10 @@ static int > mwifiex_save_hidden_ssid_channels(struct mwifiex_private *priv, > } > > done: > + /* beacon_ie buffer was allocated in function > + * mwifiex_fill_new_bss_desc(). Free it now. > + */ > + kfree(bss_desc->beacon_buf); > kfree(bss_desc); > return 0; > } Acked-by: Amitkumar Karwar <akar...@marvell.com> Regards, Amitkumar
RE: [PATCH v2] mwifiex: report wakeup for wowlan
> From: Rajat Jain [mailto:raja...@google.com]
> Sent: Wednesday, September 28, 2016 7:15 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; linux-
> wirel...@vger.kernel.org; netdev@vger.kernel.org
> Cc: Rajat Jain; Wei-Ning Huang; Brian Norris; Eric Caruso;
> rajatxj...@gmail.com
> Subject: [PATCH v2] mwifiex: report wakeup for wowlan
>
> Enable notifying wakeup source to the PM core in case of a wake on
> wireless LAN event.
>
> Signed-off-by: Wei-Ning Huang <wnhu...@google.com>
> Signed-off-by: Rajat Jain <raja...@google.com>
> Tested-by: Wei-Ning Huang <wnhu...@chromium.org>
> Reviewed-by: Eric Caruso <ejcar...@chromium.org>
> ---
> v2: Fix the commit log
>
> drivers/net/wireless/marvell/mwifiex/sdio.c | 8
> drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c
> b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index d3e1561..a5f63e4 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void
> *priv)
> disable_irq_nosync(irq);
> }
>
> + /* Notify PM core we are wakeup source */
> + pm_wakeup_event(cfg->dev, 0);
> +
> return IRQ_HANDLED;
> }
>
> @@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev,
> struct sdio_mmc_card *card)
> GFP_KERNEL);
> cfg = card->plt_wake_cfg;
> if (cfg && card->plt_of_node) {
> + cfg->dev = dev;
> cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
> if (!cfg->irq_wifi) {
> dev_dbg(dev,
> @@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device
> *dev, struct sdio_mmc_card *card)
> }
> }
>
> + ret = device_init_wakeup(dev, true);
> + if (ret)
> + dev_err(dev, "fail to init wakeup for mwifiex");
> +
> return 0;
> }
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h
> b/drivers/net/wireless/marvell/mwifiex/sdio.h
> index db837f1..07cdd23 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.h
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
> @@ -155,6 +155,7 @@
> } while (0)
>
> struct mwifiex_plt_wake_cfg {
> + struct device *dev;
> int irq_wifi;
> bool wake_by_wifi;
> };
> --
> 2.8.0.rc3.226.g39d4020
Acked-by: Amitkumar Karwar <akar...@marvell.com>
Regards,
Amitkumar
RE: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()
Hi Javier,
> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Tuesday, September 06, 2016 5:43 PM
> To: Kalle Valo
> Cc: linux-ker...@vger.kernel.org; Amitkumar Karwar;
> netdev@vger.kernel.org; linux-wirel...@vger.kernel.org; Nishant
> Sarmukadam; Arend van Spriel
> Subject: Re: mwifiex: propagate error if IRQ request fails in
> mwifiex_sdio_of()
>
> Hello Kalle,
>
> On 09/03/2016 12:35 PM, Kalle Valo wrote:
> > Javier Martinez Canillas <jav...@osg.samsung.com> wrote:
> >> If request_irq() fails in mwifiex_sdio_probe_of(), only an error
> >> message is printed but the actual error is not propagated to the
> caller function.
> >>
> >> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> >
> > What's the conclusion with this patch? Should I drop it or take it?
> >
> > (The discussion is available from the patchwork link in the
> > signature.)
> >
>
> My understanding is that Arend agrees with the patch and that the
> question raised was caused by looking at an older kernel version. IOW,
> the patch is OK and should be picked.
>
> I'm adding Arend to cc, so can comment in case I misunderstood him
> though.
>
This error doesn't affect actual wifi functionality. Only thing is wakeup on
interrupt when system is in suspended state won't work.
I think, we can make below change.
--
@@ -122,9 +122,11 @@ static int mwifiex_sdio_probe_of(struct device *dev,
struct sdio_mmc_card *card)
IRQF_TRIGGER_LOW,
"wifi_wake", cfg);
if (ret) {
-dev_err(dev,
+dev_dbg(dev,
"Failed to request irq_wifi %d (%d)\n",
cfg->irq_wifi, ret);
+card->plt_wake_cfg = NULL;
+return 0;
}
disable_irq(cfg->irq_wifi);
}
-
Regards,
Amitkumar
RE: [PATCH 1/1] mwifiex: remove superfluous condition
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Sunday, July 31, 2016 4:09 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-wirel...@vger.kernel.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; Heinrich Schuchardt
> Subject: [PATCH 1/1] mwifiex: remove superfluous condition
>
> for_each_property_of_node is only executed if the property prop is not
> NULL.
>
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> ---
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index 7897037..128add8 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1482,7 +1482,7 @@ int mwifiex_dnld_dt_cfgdata(struct mwifiex_private
> *priv,
> continue;
>
> /* property header is 6 bytes, data must fit in cmd buffer
> */
> - if (prop && prop->value && prop->length > 6 &&
> + if (prop->value && prop->length > 6 &&
> prop->length <= MWIFIEX_SIZE_OF_CMD_BUFFER - S_DS_GEN) {
> ret = mwifiex_send_cmd(priv, HostCmd_CMD_CFG_DATA,
> HostCmd_ACT_GEN_SET, 0,
Thanks. The patch looks fine to me.
Acked-by: Amitkumar Karwar <akar...@marvell.com>
Regards,
Amitkumar
RE: [PATCH 1/1] mwifiex: key_material_v2 remove superfluous condition
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Sunday, July 31, 2016 5:41 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-wirel...@vger.kernel.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; Heinrich Schuchardt
> Subject: [PATCH 1/1] mwifiex: key_material_v2 remove superfluous
> condition
>
> We are using mac as source address in a memcpy.
> In the lines below we can assume mac is not NULL.
>
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> ---
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index 128add8..0d4f9fe 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -706,15 +706,10 @@ mwifiex_cmd_802_11_key_material_v2(struct
> mwifiex_private *priv,
> (priv->wep_key_curr_index & KEY_INDEX_MASK))
> key_info |= KEY_DEFAULT;
> } else {
> - if (mac) {
> - if (is_broadcast_ether_addr(mac))
> - key_info |= KEY_MCAST;
> - else
> - key_info |= KEY_UNICAST |
> - KEY_DEFAULT;
> - } else {
> + if (is_broadcast_ether_addr(mac))
> key_info |= KEY_MCAST;
> - }
> + else
> + key_info |= KEY_UNICAST | KEY_DEFAULT;
> }
> }
> km->key_param_set.key_info = cpu_to_le16(key_info);
> --
> 2.8.1
Looks ok to me.
Acked-by: Amitkumar Karwar <akar...@marvell.com>
Regards,
Amitkumar
RE: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station ioctl file
Hi Kalle/Javier,
> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Friday, June 10, 2016 8:07 PM
> To: Kalle Valo
> Cc: linux-ker...@vger.kernel.org; Julian Calaby; Shengzhen Li; Enric
> Balletbo i Serra; Amitkumar Karwar; netdev@vger.kernel.org; linux-
> wirel...@vger.kernel.org; Nishant Sarmukadam
> Subject: Re: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station
> ioctl file
>
> Hello Kalle,
>
> On 06/10/2016 10:30 AM, Kalle Valo wrote:
> > Javier Martinez Canillas <jav...@osg.samsung.com> writes:
> >
> >> From: Shengzhen Li <s...@marvell.com>
> >>
> >> Most cfg80211 operations are just a wrappers to functions defined in
> >> the sta_ioctl.c file, so for consistency move the .get_tx_power logic
> there.
> >>
> >> Signed-off-by: Shengzhen Li <s...@marvell.com>
> >> Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> >> [javier: update the subject line and commit message]
> >> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> >
> > [...]
> >
> >> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> >> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> >> @@ -385,18 +385,10 @@ mwifiex_cfg80211_get_tx_power(struct wiphy
> *wiphy,
> >> int *dbm)
> >> {
> >>struct mwifiex_adapter *adapter =
> mwifiex_cfg80211_get_adapter(wiphy);
> >> - struct mwifiex_private *priv = mwifiex_get_priv(adapter,
> >> - MWIFIEX_BSS_ROLE_ANY);
> >> - int ret = mwifiex_send_cmd(priv, HostCmd_CMD_RF_TX_PWR,
> >> - HostCmd_ACT_GEN_GET, 0, NULL, true);
> >> -
> >> - if (ret < 0)
> >> - return ret;
> >> -
> >> - /* tx_power_level is set in HostCmd_CMD_RF_TX_PWR command handler
> */
> >> - *dbm = priv->tx_power_level;
> >> + struct mwifiex_private *priv;
> >>
> >> - return 0;
> >> + priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
> >> + return mwifiex_get_tx_power(priv, dbm);
> >> }
> >
> > So in patch 1 you added the patch and in patch 2 you move it to a
> > different location? That doesn't make any sense, can't you just fold
> > the two patches into one so that the function is added only once.
> >
>
> I posted this patch in v1 but then Amitkumar shared his patch with me
> that was very similar to mine, only that the logic was in a different
> location.
>
> So I included his delta as a separate patch to try keeping attribution
> as best as possible.
>
This patch (2/3) is only for code rearrangement and adds an unnecessary wrapper
function. We can simply drop the patch.
Regards,
Amitkumar
RE: [PATCH 7/8] mwifiex: don't print an error if an optional DT property is missing
> From: Julian Calaby [mailto:julian.cal...@gmail.com] > Sent: Thursday, June 02, 2016 4:44 AM > To: Javier Martinez Canillas; Xinming Hu > Cc: linux-ker...@vger.kernel.org; Amitkumar Karwar; Kalle Valo; netdev; > linux-wireless; Nishant Sarmukadam > Subject: Re: [PATCH 7/8] mwifiex: don't print an error if an optional DT > property is missing > > Hi Javier, > > On Wed, Jun 1, 2016 at 11:51 PM, Javier Martinez Canillas > <jav...@osg.samsung.com> wrote: > > Hello Julian, > > > > Thanks a lot for your feedback and reviews. > > > > On 06/01/2016 12:20 AM, Julian Calaby wrote: > >> Hi All, > >> > >> On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas > >> <jav...@osg.samsung.com> wrote: > >>> The > >>> Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT > >>> binding document say that the "interrupts" property in the child > node is optional. So the property being missed shouldn't be treated as > an error. > >> > >> Have you checked whether it is truly optional? I.e. nothing else > >> breaks if this property isn't set? > >> > > > > That's what the DT binding says and the IRQ is only used as a wakeup > > source during system suspend, it is not used during runtime. And that > > is why the > > mwifiex_sdio_probe_of() function does not fail if the IRQ is missing. > > Awesome, that's what I wanted to know. > > > Now, I just got to that conclusion by reading the binding docs, the > > message in the commits that introduced this and the driver code. > > Xinming Hu should comment on how critical this feature is for systems > that needs to be wakeup. > > Xinming, could you review this also? > Yes. IRQ is the optional parameter. System has a flexibility to not use it, but it still can configure other device tree parameters. The patch looks good. Regards, Amitkumar
RE: [PATCH 0/8] mwifiex: Fix some error handling issues in mwifiex_sdio_probe() function
> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com] > Sent: Friday, May 27, 2016 7:48 PM > To: linux-ker...@vger.kernel.org > Cc: Xinming Hu; Javier Martinez Canillas; Amitkumar Karwar; Kalle Valo; > netdev@vger.kernel.org; linux-wirel...@vger.kernel.org; Nishant > Sarmukadam > Subject: [PATCH 0/8] mwifiex: Fix some error handling issues in > mwifiex_sdio_probe() function > > Hello, > > While booting a system with a mwifiex WiFi card, I noticed the following > missleading error message: > > [ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available > > This error only applies to platforms that define a child node for the > SDIO device, but it's currently shown even in platforms that don't have > a child node defined. > > So this series fixes this issue and others I found in the .probe > function (mostly related to error handling and the error path) while > looking at it. > > Best regards, > Javier > > > Javier Martinez Canillas (8): > mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node > mwifiex: propagate sdio_enable_func() errno code in > mwifiex_sdio_probe() > mwifiex: propagate mwifiex_add_card() errno code in > mwifiex_sdio_probe() > mwifiex: consolidate mwifiex_sdio_probe() error paths > mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe() > mwifiex: check if mwifiex_sdio_probe_of() fails and return error > mwifiex: don't print an error if an optional DT property is missing > mwifiex: use better message and error code when OF node doesn't match > > drivers/net/wireless/marvell/mwifiex/sdio.c | 46 ++ > --- > 1 file changed, 28 insertions(+), 18 deletions(-) > Thanks for fixing the error handling code. These patches look fine to me. Acked-by: Amitkumar Karwar <akar...@marvell.com> Regards, Amitkumar
RE: [PATCH 1/1] mwifiex: illegal assignment
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Wednesday, May 18, 2016 4:32 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: Xinming Hu; Cathy Luo; linux-wirel...@vger.kernel.org;
> netdev@vger.kernel.org; linux-ker...@vger.kernel.org; Heinrich
> Schuchardt
> Subject: [PATCH 1/1] mwifiex: illegal assignment
>
> Variable adapter is incorrectly initialized.
>
> Fixes: bf00dc22bc7a ("mwifiex: AMSDU Rx frame handling in AP mode")
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> ---
> drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> index 666e91a..bf5660e 100644
> --- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> +++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> @@ -272,7 +272,7 @@ int mwifiex_handle_uap_rx_forward(struct
> mwifiex_private *priv, int mwifiex_uap_recv_packet(struct
> mwifiex_private *priv,
> struct sk_buff *skb)
> {
> - struct mwifiex_adapter *adapter = adapter;
> + struct mwifiex_adapter *adapter = priv->adapter;
> struct mwifiex_sta_node *src_node;
> struct ethhdr *p_ethhdr;
> struct sk_buff *skb_uap;
> --
> 2.1.4
Acked-by: Amitkumar Karwar <akar...@marvell.com>
Regards,
Amitkumar
RE: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
Hi Eric, Thanks for the comments. > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Tuesday, March 29, 2016 6:29 PM > To: Wei-Ning Huang > Cc: Kalle Valo; Linux Wireless; LKML; Amitkumar Karwar; Nishant > Sarmukadam; Sameer Nanda; netdev@vger.kernel.org; Sonny Rao; Douglas > Anderson > Subject: Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call > > On Tue, 2016-03-29 at 17:27 +0800, Wei-Ning Huang wrote: > > Adding some chromium devs to the thread. > > > > In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152 > > > > The default mm retry allocation when 'order <= > > PAGE_ALLOC_COSTLY_ORDER' of gfp_mask contains __GFP_REPEAT. > > PAGE_ALLOC_COSTLY_ORDER is defined to be 3. On systems with page size > > = 4K, this means memory compaction and retry is only done when the > > size of allocation is <= 32K In mwifiex, the allocation size is 64K. > > > > > When we have system with > > memory fragmentation and allocation failed, there will be no retry. > > This is why we need to add __GFP_REPEAT here to allow the system to > > perform memory compaction and retry allocation. > > > > Maybe Amit@marvell can comment on if this is a good fix on this issue. > > I'm also aware that marvell is the progress of implementing > > scatter/gatter for mwifiex, which can also fix the issue. > > Before SG is implemented, you really need to copy incoming frames into > smallest chunks (to get lowest skb->truesize) and leave the 64KB > allocated stuff forever in the driver. We do have a 64KB pre-allocated buffer for receiving Rx data in our driver. > > __GFP_REPEAT wont really solve the issue. > > It seems the problem comes from the fact that the drivers calls > dev_kfree_skb_any() after calling mwifiex_deaggr_sdio_pkt(), instead of > recycling this very precious 64KB skb once memory gets fragmented. Our one time allocated 64k buffer read from firmware contains multiple data chunks. We have a feature called single port aggregation in which firmware attaches an aggregated buffer to single port. So sometimes a single data chunk can exceed 32k. dev_kfree_skb_any() is called to free those data chunks. > > Another problem is that mwifiex_deaggr_sdio_pkt() uses > mwifiex_alloc_dma_align_buf() with GFP_KERNEL | GFP_DMA > > Really GFP_DMA makes no sense here, since the skb is going to be > processed by the stack, which has no such requirement. > > Please use normal skb allocations there. Sure. I will submit a patch for this. Regards, Amitkumar
RE: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
> From: Wei-Ning Huang [mailto:wnhu...@google.com] > Sent: Tuesday, March 29, 2016 2:57 PM > To: Kalle Valo > Cc: Linux Wireless; LKML; Amitkumar Karwar; Nishant Sarmukadam; Sameer > Nanda; netdev@vger.kernel.org; Sonny Rao; Douglas Anderson > Subject: Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call > > Adding some chromium devs to the thread. > > In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152 > > The default mm retry allocation when 'order <= PAGE_ALLOC_COSTLY_ORDER' > of gfp_mask contains __GFP_REPEAT. > PAGE_ALLOC_COSTLY_ORDER is defined to be 3. On systems with page size = > 4K, this means memory compaction and retry is only done when the size of > allocation is <= 32K In mwifiex, the allocation size is 64K. When we > have system with memory fragmentation and allocation failed, there will > be no retry. > This is why we need to add __GFP_REPEAT here to allow the system to > perform memory compaction and retry allocation. > > Maybe Amit@marvell can comment on if this is a good fix on this issue. > I'm also aware that marvell is the progress of implementing > scatter/gatter for mwifiex, which can also fix the issue. > > Wei-Ning > This fix would be useful. We have a feature called single port aggregation in which sometimes data received from SDIO interface can be >32k (but less than 64k). This feature improves throughput performance. We are preparing patches for scatter/gather feature. but scatter/gather won't be supported by some platforms. Hence this fix would still be needed. Regards, Amitkumar
RE: [PATCH v2] mwifiex: advertise low priority scan feature
> From: Wei-Ning Huang [mailto:wnhu...@chromium.org] > Sent: Tuesday, March 22, 2016 9:40 AM > To: Linux Wireless > Cc: LKML; Amitkumar Karwar; djku...@chromium.org; Wei-Ning Huang; > Nishant Sarmukadam; kv...@codeaurora.org; netdev@vger.kernel.org > Subject: [PATCH v2] mwifiex: advertise low priority scan feature > > From: Amitkumar Karwar <akar...@marvell.com> > > Low priority scan handling code which delays or aborts scan operation > based on Tx traffic is removed recently. The reason is firmware already > takes care of it in our new feature scan channel gap. Hence we should > advertise low priority scan support to cfg80211. > > This patch fixes a problem in which OBSS scan request from > wpa_supplicant was being rejected by cfg80211. > > Signed-off-by: Amitkumar Karwar <akar...@marvell.com> > Signed-off-by: Wei-Ning Huang <wnhu...@chromium.org> > --- > drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c > b/drivers/net/wireless/marvell/mwifiex/cfg80211.c > index bb7235e..7dafc5b 100644 > --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c > +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c > @@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct > mwifiex_adapter *adapter) > > wiphy->features |= NL80211_FEATURE_HT_IBSS | > NL80211_FEATURE_INACTIVITY_TIMER | > +NL80211_FEATURE_LOW_PRIORITY_SCAN | > NL80211_FEATURE_NEED_OBSS_SCAN; > > if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info)) > -- > 2.8.0.rc3.226.g39d4020 Acked-by: Amitkumar Karwar <akar...@marvell.com> Regards, Amitkumar
RE: [PATCH] mwifiex: advertise low priority scan feature
> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] On Behalf Of Wei-Ning Huang > Sent: Monday, March 21, 2016 1:37 PM > To: Linux Wireless > Cc: LKML; Amitkumar Karwar; djku...@chromium.org; Wei-Ning Huang; > Nishant Sarmukadam; kv...@codeaurora.org; netdev@vger.kernel.org > Subject: [PATCH] mwifiex: advertise low priority scan feature > > From: Amitkumar Karwar <akar...@marvell.com> > > Low priority scan handling code which delays or aborts scan operation > based on Tx traffic is removed recently. The reason is firmware already > takes care of it in our new feature scan channel gap. Hence we should > advertise low priority scan support to cfg80211. > > This patch fixes a problem in which OBSS scan request from > wpa_supplicant was being rejected by cfg80211. > > Signed-off-by: Wei-Ning Huang <wnhu...@chromium.org> > --- > drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c > b/drivers/net/wireless/marvell/mwifiex/cfg80211.c > index bb7235e..7dafc5b 100644 > --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c > +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c > @@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct > mwifiex_adapter *adapter) > > wiphy->features |= NL80211_FEATURE_HT_IBSS | > NL80211_FEATURE_INACTIVITY_TIMER | > +NL80211_FEATURE_LOW_PRIORITY_SCAN | > NL80211_FEATURE_NEED_OBSS_SCAN; > > if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info)) Acked-by: Amitkumar Karwar <akar...@marvell.com> Regards, Amitkumar
RE: [PATCH 04/12] mwifiex: use ktime_get_real for timestamping
Hi Arnd,
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Wednesday, September 30, 2015 4:57 PM
> To: netdev@vger.kernel.org
> Cc: y2...@lists.linaro.org; linux-ker...@vger.kernel.org; David S.
> Miller; Arnd Bergmann; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo;
> linux-wirel...@vger.kernel.org
> Subject: [PATCH 04/12] mwifiex: use ktime_get_real for timestamping
>
> The mwifiex_11n_aggregate_pkt() function creates a ktime_t from a
> timeval returned by do_gettimeofday, which is slow and causes an
> overflow in 2038 on 32-bit architectures.
>
> This solves both problems by using the appropriate ktime_get_real()
> function.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Cc: Amitkumar Karwar <akar...@marvell.com>
> Cc: Nishant Sarmukadam <nisha...@marvell.com>
> Cc: Kalle Valo <kv...@codeaurora.org>
> Cc: linux-wirel...@vger.kernel.org
> ---
> drivers/net/wireless/mwifiex/11n_aggr.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/11n_aggr.c
> b/drivers/net/wireless/mwifiex/11n_aggr.c
> index f7c717253a66..78853c51774d 100644
> --- a/drivers/net/wireless/mwifiex/11n_aggr.c
> +++ b/drivers/net/wireless/mwifiex/11n_aggr.c
> @@ -173,7 +173,6 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private
> *priv,
> int pad = 0, aggr_num = 0, ret;
> struct mwifiex_tx_param tx_param;
> struct txpd *ptx_pd = NULL;
> - struct timeval tv;
> int headroom = adapter->iface_type == MWIFIEX_USB ? 0 :
> INTF_HEADER_LEN;
>
> skb_src = skb_peek(_list->skb_head); @@ -203,8 +202,7 @@
> mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
> tx_info_aggr->flags |= MWIFIEX_BUF_FLAG_AGGR_PKT;
> skb_aggr->priority = skb_src->priority;
>
> - do_gettimeofday();
> - skb_aggr->tstamp = timeval_to_ktime(tv);
> + skb_aggr->tstamp = ktime_get_real();
>
> do {
> /* Check if AMSDU can accommodate this MSDU */
> --
> 2.1.0.rc2
Looks good.
Acked-by: Amitkumar Karwar <akar...@marvell.com>
Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/12] mwifiex: avoid gettimeofday in ba_threshold setting
Hi Arnd,
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Wednesday, September 30, 2015 4:57 PM
> To: netdev@vger.kernel.org
> Cc: y2...@lists.linaro.org; linux-ker...@vger.kernel.org; David S.
> Miller; Arnd Bergmann; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo;
> linux-wirel...@vger.kernel.org
> Subject: [PATCH 05/12] mwifiex: avoid gettimeofday in ba_threshold
> setting
>
> mwifiex_get_random_ba_threshold() uses a complex homegrown
> implementation to generate a pseudo-random number from the current time
> as returned from do_gettimeofday().
>
> This currently requires two 32-bit divisions plus a couple of other
> computations that are eventually discarded as only eight bits of the
> microsecond portion are used at all.
>
> We could replace this with a call to get_random_bytes(), but that might
> drain the entropy pool too fast if this is called for each packet.
>
> Instead, this patch converts it to use ktime_get_ns(), which is a bit
> faster than do_gettimeofday(), and then uses a similar algorithm as
> before, but in a way that takes both the nanosecond and second portion
> into account for slightly-more-but-still-not-very-random
> pseudorandom number.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Cc: Amitkumar Karwar <akar...@marvell.com>
> Cc: Nishant Sarmukadam <nisha...@marvell.com>
> Cc: Kalle Valo <kv...@codeaurora.org>
> Cc: linux-wirel...@vger.kernel.org
> ---
> drivers/net/wireless/mwifiex/wmm.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/wmm.c
> b/drivers/net/wireless/mwifiex/wmm.c
> index 173d3663c2e0..878d358063dc 100644
> --- a/drivers/net/wireless/mwifiex/wmm.c
> +++ b/drivers/net/wireless/mwifiex/wmm.c
> @@ -117,22 +117,15 @@ mwifiex_wmm_allocate_ralist_node(struct
> mwifiex_adapter *adapter, const u8 *ra)
> */
> static u8 mwifiex_get_random_ba_threshold(void)
> {
> - u32 sec, usec;
> - struct timeval ba_tstamp;
> - u8 ba_threshold;
> -
> + u64 ns;
> /* setup ba_packet_threshold here random number between
>* [BA_SETUP_PACKET_OFFSET,
>* BA_SETUP_PACKET_OFFSET+BA_SETUP_MAX_PACKET_THRESHOLD-1]
>*/
> + ns = ktime_get_ns();
> + ns += (ns >> 32) + (ns >> 16);
>
> - do_gettimeofday(_tstamp);
> - sec = (ba_tstamp.tv_sec & 0x) + (ba_tstamp.tv_sec >> 16);
> - usec = (ba_tstamp.tv_usec & 0x) + (ba_tstamp.tv_usec >> 16);
> - ba_threshold = (((sec << 16) + usec) %
> BA_SETUP_MAX_PACKET_THRESHOLD)
> - + BA_SETUP_PACKET_OFFSET;
> -
> - return ba_threshold;
> + return ((u8)ns % BA_SETUP_MAX_PACKET_THRESHOLD) +
> +BA_SETUP_PACKET_OFFSET;
> }
>
> /*
> --
Looks fine to me.
Acked-by: Amitkumar Karwar <akar...@marvell.com>
Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: question about potential integer truncation in mwifiex_set_wapi_ie and mwifiex_set_wps_ie
Hi James/PaX Team,
> -Original Message-
> From: qu...@laptop.org [mailto:qu...@laptop.org]
> Sent: Wednesday, September 30, 2015 4:41 AM
> To: PaX Team
> Cc: Amitkumar Karwar; Avinash Patil; Kalle Valo; linux-
> wirel...@vger.kernel.org; netdev@vger.kernel.org; re.em...@gmail.com;
> spen...@grsecurity.net
> Subject: Re: question about potential integer truncation in
> mwifiex_set_wapi_ie and mwifiex_set_wps_ie
>
> On Tue, Sep 29, 2015 at 05:21:28PM +0200, PaX Team wrote:
> > hi all,
> >
> > in drivers/net/wireless/mwifiex/sta_ioctl.c the following functions
> >
> > mwifiex_set_wpa_ie_helper
> > mwifiex_set_wapi_ie
> > mwifiex_set_wps_ie
> >
> > can truncate the incoming ie_len argument from u16 to u8 when it gets
> > stored in mwifiex_private.wpa_ie_len, mwifiex_private.wapi_ie_len and
> > mwifiex_private.wps_ie_len, respectively. based on some light code
> > reading it seems a length value of 256 is valid (IEEE_MAX_IE_SIZE and
> > MWIFIEX_MAX_VSIE_LEN seem to limit it) and thus would get truncated to
> > 0 when stored in those u8 fields. the question is whether this is
> > intentional or a bug somewhere.
>
> i agree, while there is a test to ensure ie_len is not greater than 256,
> there is a possibility that it will be exactly 256, which means
> 256 bytes will be given to memcpy but
> mwifiex_private.{wpa,wapi,wps}_ie_len will be zero.
>
> i suggest changing the lengths to u16. not tested.
>
> diff --git a/drivers/net/wireless/mwifiex/main.h
> b/drivers/net/wireless/mwifiex/main.h
> index fe12560..b66e9a7 100644
> --- a/drivers/net/wireless/mwifiex/main.h
> +++ b/drivers/net/wireless/mwifiex/main.h
> @@ -512,14 +512,14 @@ struct mwifiex_private {
> struct mwifiex_wep_key wep_key[NUM_WEP_KEYS];
> u16 wep_key_curr_index;
> u8 wpa_ie[256];
> - u8 wpa_ie_len;
> + u16 wpa_ie_len;
> u8 wpa_is_gtk_set;
> struct host_cmd_ds_802_11_key_material aes_key;
> struct host_cmd_ds_802_11_key_material_v2 aes_key_v2;
> u8 wapi_ie[256];
> - u8 wapi_ie_len;
> + u16 wapi_ie_len;
> u8 *wps_ie;
> - u8 wps_ie_len;
> + u16 wps_ie_len;
> u8 wmm_required;
> u8 wmm_enabled;
> u8 wmm_qosinfo;
>
This change makes sense. Also, we should not typecast the length to v8 while
copying to mwifiex_private variable.
./sta_ioctl.c:761: priv->wpa_ie_len = (u8) ie_len;
Eventually the length stored in 'wapi_ie_len' is copied to a u16 variable.
/join.c:304:ie_header.len = cpu_to_le16(priv->wapi_ie_len);
I will submit a patch to fix this.
Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mwifiex: fix a comment typo
> From: Geliang Tang [mailto:geliangt...@163.com] > Sent: Sunday, October 04, 2015 2:17 PM > To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo > Cc: Geliang Tang; linux-wirel...@vger.kernel.org; > netdev@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: [PATCH] mwifiex: fix a comment typo > > Just fix a typo in the code comment. > > Signed-off-by: Geliang Tang <geliangt...@163.com> > --- > drivers/net/wireless/mwifiex/cfg80211.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/mwifiex/cfg80211.c > b/drivers/net/wireless/mwifiex/cfg80211.c > index 30cbafb..b7ac45f 100644 > --- a/drivers/net/wireless/mwifiex/cfg80211.c > +++ b/drivers/net/wireless/mwifiex/cfg80211.c > @@ -2374,7 +2374,7 @@ mwifiex_cfg80211_leave_ibss(struct wiphy *wiphy, > struct net_device *dev) > * CFG802.11 operation handler for scan request. > * > * This function issues a scan request to the firmware based upon > - * the user specified scan configuration. On successfull completion, > + * the user specified scan configuration. On successful completion, > * it also informs the results. > */ > static int > -- > 2.5.0 > Acked-by: Amitkumar Karwar <akar...@marvell.com> Regards, Amitkumar -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 21/38] mwifiex: fix comparison expression
Hi Andrzej,
> From: Andrzej Hajda [mailto:a.ha...@samsung.com]
> Sent: Monday, September 21, 2015 7:04 PM
> To: linux-ker...@vger.kernel.org
> Cc: Andrzej Hajda; Bartlomiej Zolnierkiewicz; Marek Szyprowski;
> Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; linux-
> wirel...@vger.kernel.org; netdev@vger.kernel.org
> Subject: [PATCH 21/38] mwifiex: fix comparison expression
>
> To avoid underflows signed variables should be used in expression.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
>
> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
> drivers/net/wireless/mwifiex/11n_rxreorder.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/mwifiex/11n_rxreorder.c
> b/drivers/net/wireless/mwifiex/11n_rxreorder.c
> index 2906cd5..b3970a8 100644
> --- a/drivers/net/wireless/mwifiex/11n_rxreorder.c
> +++ b/drivers/net/wireless/mwifiex/11n_rxreorder.c
> @@ -615,10 +615,10 @@ int mwifiex_11n_rx_reorder_pkt(struct
> mwifiex_private *priv,
> ((end_win > start_win) && ((seq_num > end_win) ||
> (seq_num < start_win {
> end_win = seq_num;
> - if (((seq_num - win_size) + 1) >= 0)
> + if (((end_win - win_size) + 1) >= 0)
> start_win = (end_win - win_size) + 1;
> else
> - start_win = (MAX_TID_VALUE - (win_size - seq_num)) +
> 1;
> + start_win = (MAX_TID_VALUE - (win_size - end_win)) +
> 1;
> mwifiex_11n_dispatch_pkt_until_start_win(priv, tbl,
> start_win);
> }
>
Acked-by: Amitkumar Karwar <akar...@marvell.com>
Regards,
Amitkumar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mwifiex: usb: Fix double add error when submitting rx urb
Hi Reyad, From: Reyad Attiyat [mailto:reyad.atti...@gmail.com] Sent: Monday, June 29, 2015 6:38 AM To: Amitkumar Karwar; pat...@marvell.com; kv...@codeaurora.org; bz...@marvell.com Cc: linux-wirel...@vger.kernel.org; netdev@vger.kernel.org; linux- ker...@vger.kernel.org; Reyad Attiyat Subject: [PATCH] mwifiex: usb: Fix double add error when submitting rx urb There is an error that can occur where the driver adds the same URB to USB submission list twice. This happens since mwifiex_usb_submit_rem_rx can submit packets at same time as an rx urb complete callback. This causes list corruption and is fixed by not setting the skb to NULL when submitting an rx packet. [ 84.461242] WARNING: CPU: 1 PID: 748 at lib/list_debug.c:36 __list_add+0xcb/0xd0() [ 84.461245] list_add double add: new=8800c92b0c50, prev=8800c92b0c50, next=8800ced6c430. [ 84.461247] Modules linked in: rfcomm fuse cmac nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bnep iptable_mangle iptable_security iptable_raw btusb btintel bluetooth mwifiex_usb mwifiex x86_pkg_temp_thermal cfg80211 coretemp r8712u(C) kvm_intel kvm hid_sensor_als hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger hid_sensor_iio_common industrialio_triggered_buffer kfifo_buf rfkill iTCO_wdt industrialio iTCO_vendor_support [ 84.461316] crc32_pclmul crc32c_intel ghash_clmulni_intel microcode snd_hda_codec_realtek vfat snd_hda_codec_generic fat snd_hda_codec_hdmi snd_hda_intel snd_hda_controller uvcvideo snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hwdep videobuf2_core snd_hda_core joydev v4l2_common videodev hid_sensor_hub snd_seq hid_multitouch media snd_seq_device snd_pcm snd_timer mei_me snd i2c_i801 lpc_ich mei soundcore tpm_infineon tpm_tis tpm i2c_hid i2c_designware_platform i2c_designware_core nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel i915 i2c_algo_bit drm_kms_helper drm xhci_pci xhci_hcd ehci_pci sd_mod ehci_hcd video [ 84.461383] CPU: 1 PID: 748 Comm: kworker/u9:0 Tainted: G C 4.1.0-rc5+ #163 [ 84.461386] Hardware name: Microsoft Corporation Surface Pro 2/Surface Pro 2, BIOS 2.05.0250 04/10/2015 [ 84.461396] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 84.461399] 81a8150e 8801174cf8e8 817df830 [ 84.461405] 8801174cf938 8801174cf928 810a54ba 8800c86bd750 [ 84.461410] 8800c92b0c50 8800c92b0c50 8800ced6c430 88010c057178 [ 84.461416] Call Trace: [ 84.461421] [817df830] dump_stack+0x4f/0x7b [ 84.461428] [810a54ba] warn_slowpath_common+0x8a/0xc0 [ 84.461432] [810a5536] warn_slowpath_fmt+0x46/0x50 [ 84.461436] [814109fb] __list_add+0xcb/0xd0 [ 84.461442] [815c551a] ? usb_hcd_link_urb_to_ep+0x2a/0xa0 [ 84.461446] [815c5570] usb_hcd_link_urb_to_ep+0x80/0xa0 [ 84.461459] [a004318a] prepare_transfer+0xaa/0x130 [xhci_hcd] [ 84.461470] [a0044cf7] xhci_queue_bulk_tx+0xb7/0x7a0 [xhci_hcd] [ 84.461480] [a003b67f] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd] [ 84.461489] [a003b67f] ? xhci_urb_enqueue+0x50f/0x660 [xhci_hcd] [ 84.461498] [a003b735] xhci_urb_enqueue+0x5c5/0x660 [xhci_hcd] [ 84.461503] [815c7ad3] usb_hcd_submit_urb+0x93/0xa70 [ 84.461507] [8168dde8] ? __alloc_skb+0x78/0x1f0 [ 84.461511] [8168d301] ? __kmalloc_reserve.isra.26+0x31/0x90 [ 84.461515] [8168ddbc] ? __alloc_skb+0x4c/0x1f0 [ 84.461519] [8168ddfc] ? __alloc_skb+0x8c/0x1f0 [ 84.461523] [8168badd] ? skb_dequeue+0x5d/0x80 [ 84.461527] [815c987e] usb_submit_urb+0x42e/0x5f0 [ 84.461531] [816931d9] ? __alloc_rx_skb+0x39/0x100 [ 84.461536] [a05aa372] mwifiex_usb_submit_rx_urb+0xb2/0x170 [mwifiex_usb] [ 84.461542] [a05aa5f5] mwifiex_usb_submit_rem_rx_urbs+0x45/0x50 [mwifiex_usb] [ 84.461550] [a07094be] mwifiex_rx_work_queue+0x10e/0x140 [mwifiex] [ 84.461556] [810c4429] process_one_work+0x229/0x890 [ 84.461559] [810c438c] ? process_one_work+0x18c/0x890 [ 84.461565] [810c4ae3] worker_thread+0x53/0x470 [ 84.461569] [810c4a90] ? process_one_work+0x890/0x890 [ 84.461572] [810cb162] kthread+0xf2/0x110 [ 84.461577] [811031ad] ? trace_hardirqs_on+0xd/0x10 [ 84.461581] [810cb070] ? kthread_create_on_node+0x230/0x230 [ 84.461586] [817e9662] ret_from_fork+0x42/0x70
