From: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Linux MMC List
<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Adrian Hunter
<adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
Wen Gong <wgong-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Erik Stromdahl
<erik.stromdahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Eyal Reizer <eyalreizer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-wireless
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Brian Norris
<briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH v2 1/3] mwifiex: Re-work support for SDIO HW reset
Date: Tue, 12 Nov 2019 13:13:21 +0100 [thread overview]
Message-ID: <CAPDyKFq-djJFyYu6Wzg9t9hLOQMuqff9KVhbx5Zp5i=Fsynsdw@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=WccuUCnQXHq-HuojCRAKVA02D7HBS9PgqSqq3+b2v4CA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 12 Nov 2019 at 01:33, Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>
> Hi,
>
> On Sat, Nov 9, 2019 at 2:31 AM Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >
> > The SDIO HW reset procedure in mwifiex_sdio_card_reset_work() is broken,
> > when the SDIO card is shared with another SDIO func driver. This is the
> > case when the Bluetooth btmrvl driver is being used in combination with
> > mwifiex. More precisely, when mwifiex_sdio_card_reset_work() runs to resets
> > the SDIO card, the btmrvl driver doesn't get notified about it. Beyond that
> > point, the btmrvl driver will fail to communicate with the SDIO card.
> >
> > This is a generic problem for SDIO func drivers sharing an SDIO card, which
> > are about to be addressed in subsequent changes to the mmc core and the
> > mmc_hw_reset() interface. In principle, these changes means the
> > mmc_hw_reset() interface starts to return 1 if the are multiple drivers for
> > the SDIO card, as to indicate to the caller that the reset needed to be
> > scheduled asynchronously through a hotplug mechanism of the SDIO card.
> >
> > Let's prepare the mwifiex driver to support the upcoming new behaviour of
> > mmc_hw_reset(), which means extending the mwifiex_sdio_card_reset_work() to
> > support the asynchronous SDIO HW reset path. This also means, we need to
> > allow the ->remove() callback to run, without waiting for the FW to be
> > loaded. Additionally, during system suspend, mwifiex_sdio_suspend() may be
> > called when a reset has been scheduled, but waiting to be executed. In this
> > scenario let's simply return -EBUSY to abort the suspend process, as to
> > allow the reset to be completed first.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > drivers/net/wireless/marvell/mwifiex/main.c | 6 +++-
> > drivers/net/wireless/marvell/mwifiex/main.h | 1 +
> > drivers/net/wireless/marvell/mwifiex/sdio.c | 33 ++++++++++++++-------
> > 3 files changed, 28 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> > index a9657ae6d782..dbdbdd6769a9 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/main.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> > @@ -76,6 +76,7 @@ static int mwifiex_register(void *card, struct device *dev,
> > *padapter = adapter;
> > adapter->dev = dev;
> > adapter->card = card;
> > + adapter->is_adapter_up = false;
>
> Probably not needed. The 'adapter' was kzalloc-ed a few lines above
> and there's no need to re-init to 0.
Right, let me re-spin and drop this.
>
>
> > diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> > index 24c041dad9f6..2417c94c29c0 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> > @@ -444,6 +444,9 @@ static int mwifiex_sdio_suspend(struct device *dev)
> > return 0;
> > }
> >
> > + if (!adapter->is_adapter_up)
> > + return -EBUSY;
>
> I'm moderately concerned that there might be cases where firmware
> never got loaded but we could suspend/resume OK. ...and now we never
> will? I'm not familiar enough with the code to know if this is a real
> concern, so I guess we can do this and then see...
There is a completion variable that is used to make sure the firmware
is loaded, before the mwifiex driver runs ->suspend|remove(). This is
needed, because during ->probe() the FW will be loaded asynchronously,
hence both mwifiex_sdio_remove() and mwifiex_sdio_suspend(), may be
called while waiting for the FW to be loaded.
If a HW reset has been scheduled but not completed, which would be the
case if mmc_hw_reset() gets called after mmc_pm_notify() with a
PM_SUSPEND_PREPARE. This is because mmc_pm_notify() then disables the
rescan work, but then re-kicks/enables it at PM_POST_SUSPEND (after
the system has resumed).
Returning -EBUSY, should allow the mmc rescan work to be completed
when the system have resumed.
Of course, one could also considering using pm_wakeup_event(), in case
mmc_hw_reset() needed to schedule the reset, as to prevent the system
for suspending for a small amount of time. As to make sure the rescan
work, gets to run. But I am not sure that's needed here.
>
>
> > @@ -2220,22 +2223,30 @@ static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
> > struct sdio_func *func = card->func;
> > int ret;
> >
> > + /* Prepare the adapter for the reset. */
> > mwifiex_shutdown_sw(adapter);
> > + clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags);
> > + clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &card->work_flags);
> >
> > - /* power cycle the adapter */
> > + /* Run a HW reset of the SDIO interface. */
> > sdio_claim_host(func);
> > - mmc_hw_reset(func->card->host);
> > + ret = mmc_hw_reset(func->card->host);
> > sdio_release_host(func);
> >
> > - /* Previous save_adapter won't be valid after this. We will cancel
> > - * pending work requests.
> > - */
> > - clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags);
> > - clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &card->work_flags);
>
> I don't know enough about the clearing of these bits to confirm that
> it's OK to move their clearing to be before the mmc_hw_reset().
> Possibly +Brian Norris does?
That shouldn't matter, because we are running in the path of the
mwifiex_sdio_work(), as work from the system_wq. Unless I am mistaken,
only one work of the type mwifiex_sdio_work() can execute at the same
time. By clearing these bits, we want to cancel any potential recently
scheduled work. It should matter if that's done before or after
mmc_hw_reset().
Moreover, this change makes it more consistent with how the pcie
driver clears the bits.
>
>
> I can't promise that I didn't miss anything, but to the best of my
> knowledge this is good now:
>
> Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Thanks!
Finally, if you want to verify that the above system suspend path
works fine, you could change the call to "_mmc_detect_change(host, 0,
false)" in mmc_sdio_hw_reset(), into "_mmc_detect_change(host,
msecs_to_jiffies(30000), false)", in patch3.
This should leave you a 30s window of where you can try to system
suspend the platform, while also waiting for the scheduled reset to be
completed.
Kind regards
Uffe
next prev parent reply other threads:[~2019-11-12 12:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-09 10:30 [PATCH v2 0/3] mmc: Fixup HW reset for SDIO cards Ulf Hansson
[not found] ` <20191109103046.26445-1-ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2019-11-09 10:30 ` [PATCH v2 1/3] mwifiex: Re-work support for SDIO HW reset Ulf Hansson
[not found] ` <20191109103046.26445-2-ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2019-11-12 0:33 ` Doug Anderson
[not found] ` <CAD=FV=WccuUCnQXHq-HuojCRAKVA02D7HBS9PgqSqq3+b2v4CA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-12 12:13 ` Ulf Hansson [this message]
[not found] ` <CAPDyKFq-djJFyYu6Wzg9t9hLOQMuqff9KVhbx5Zp5i=Fsynsdw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-12 18:04 ` Doug Anderson
[not found] ` <CAD=FV=VWdzqGY778SXZnC1YDyxc6EHPgRjkJ_2sOHrxHTams-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-13 15:00 ` Ulf Hansson
2019-11-09 10:30 ` [PATCH v2 2/3] mmc: core: Drop check for mmc_card_is_removable() in mmc_rescan() Ulf Hansson
2019-11-09 10:30 ` [PATCH v2 3/3] mmc: core: Re-work HW reset for SDIO cards Ulf Hansson
[not found] ` <20191109103046.26445-4-ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2019-11-12 0:33 ` Doug Anderson
[not found] ` <CAD=FV=VHReD5qnvcQLHvfgKHnHLbfDLZHwXtY-LV5uy_VCYpPA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-12 12:19 ` Ulf Hansson
2019-11-20 6:28 ` Kalle Valo
[not found] ` <CAPDyKFrCyJBz2=RzKPxqn0FSEq500=dEDsTUWYZeoFKWvSRAdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-20 6:28 ` Kalle Valo
[not found] ` <87zhgr5af6.fsf@codeaurora.org>
2019-11-20 7:10 ` wgong
[not found] ` <87zhgr5af6.fsf-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2019-11-20 7:10 ` wgong-sgV2jX0FEOL9JmXXK+q4OQ
[not found] ` <6e6b53b28581a8f1a2944ca0bc65311e@codeaurora.org>
2019-11-20 7:20 ` Kalle Valo
[not found] ` <6e6b53b28581a8f1a2944ca0bc65311e-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2019-11-20 7:20 ` Kalle Valo
[not found] ` <0101016e87aeb8b6-761ad812-5da7-4b0d-8cae-c69633d90de0-000000@us-west-2.amazonses.com>
[not found] ` <0101016e87aeb8b6-761ad812-5da7-4b0d-8cae-c69633d90de0-000000-j0qUFrXf9azQVAzzCBYphlNw9kRHFGba@public.gmane.org>
2019-11-20 12:10 ` Ulf Hansson
[not found] ` <CAPDyKFoWxw9r=GZhvF=TxHxo=zRfKr0hknEeQNPdfwPx4ORxuQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-20 16:41 ` Kalle Valo
2019-11-20 16:41 ` Kalle Valo
[not found] ` <87zhgqmref.fsf@kamboji.qca.qualcomm.com>
2019-11-21 2:29 ` wgong
[not found] ` <87zhgqmref.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
2019-11-21 2:29 ` wgong-sgV2jX0FEOL9JmXXK+q4OQ
2019-11-11 22:08 ` [PATCH v2 0/3] mmc: Fixup " Tony Lindgren
[not found] ` <20191111220812.GX43123-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2019-11-12 12:23 ` Ulf Hansson
[not found] ` <CAPDyKFq03X0hd5B6h6fuNht5OjSEWe6Ap4hH4a+0nVZsS4r3hw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-12 18:00 ` Tony Lindgren
2019-11-12 0:51 ` Doug Anderson
[not found] ` <CAD=FV=Wv9DgzQZZE8YvB+qjBzPsKdJvafSnFy8YAN_dN6UJbtQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-12 12:27 ` Ulf Hansson
[not found] ` <CAPDyKFq5=B8u=9awGaXuhTmYK6Sbbe6EmF9EMhBQQyyrD1bKRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-12 17:42 ` Doug Anderson
[not found] ` <CAD=FV=Xf5O_ew+hG9BLSZUM7bKAZvEvqaK4Cy1xUWgKdTGUMwA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-13 15:11 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPDyKFq-djJFyYu6Wzg9t9hLOQMuqff9KVhbx5Zp5i=Fsynsdw@mail.gmail.com' \
--to=ulf.hansson-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=erik.stromdahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=eyalreizer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
--cc=wgong-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).