[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-wireless
Subject:    Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From:       Kalle Valo <kvalo () codeaurora ! org>
Date:       2016-12-30 11:28:16
Message-ID: 87mvfdk65r.fsf () kamboji ! qca ! qualcomm ! com
[Download RAW message or body]

Amitkumar Karwar <akarwar@marvell.com> writes:

> Hi Kalle,
> 
> > Failed to apply:
> > 
> > fatal: sha1 information is lacking or useless
> > (drivers/net/wireless/marvell/mwifiex/pcie.c).
> > Applying: mwifiex: get rid of global user_rmmod flag Repository lacks
> > necessary blobs to fall back on 3-way merge.
> > Cannot fall back to three-way merge.
> > Patch failed at 0001 mwifiex: get rid of global user_rmmod flag
> > 
> > 2 patches set to Changes Requested.
> > 
> > 9454491 [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
> > 9454493 [2/2] mwifiex: get rid of global user_rmmod flag
> > 
> > --
> > https://patchwork.kernel.org/patch/9454491/
> > 
> > Documentation about submitting wireless patches and checking status
> > from patchwork:
> > 
> > https://wireless.wiki.kernel.org/en/developers/documentation/submitting
> > patches
> 
> 
> These two patches have dependency with other patch series. I want you to consider \
> patches in following order(first being recent). 
> mwifiex: sdio: fix use after free issue for save_adapter

This applied fine.

> mwifiex: use module_*_driver helper macros
> 
> [2/2] mwifiex: get rid of global user_rmmod flag
> [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
> 
> [v3,5/5] mwifiex: move pcie_work and related variables inside card -------- This \
> series can be accepted if there are no further concerns/comments from Brian/Dmitry. \
>  [v3,4/5] mwifiex: wait firmware dump complete during card remove process
> [v3,3/5] mwifiex: get rid of drv_info* adapter variables
> [v3,2/5] mwifiex: do not free firmware dump memory in shutdown_drv
> [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv

But these didn't. Can you please rebase these and resubmit in one
patchset? Less conflicts that way.

-- 
Kalle Valo


[prev in list] [next in list] [prev in thread] [next in thread]