From: Sven Neumann <s.neumann@raumfeld.com>
To: Ohad Ben-Cohen <ohad@wizery.com>, libertas-dev@lists.infradead.org
Cc: Chris Ball <cjb@laptop.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
Daniel Mack <daniel@caiaq.de>, Colin Cross <ccross@android.com>,
Greg Kroah-Hartman <gregkh@suse.de>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Maxim Levitsky <maximlevitsky@gmail.com>
Subject: Re: 2.6.35.6 fails to suspend (pxa2xx-mci.0)
Date: Mon, 11 Oct 2010 11:11:55 +0200 [thread overview]
Message-ID: <1286788315.3101.11.camel@sven> (raw)
In-Reply-To: <AANLkTinf-8jeaV6GZ2+pQ2FztrXDv7QhEn3brPN3osBT@mail.gmail.com>
On Mon, 2010-10-11 at 10:45 +0200, Ohad Ben-Cohen wrote:
> On Mon, Oct 11, 2010 at 10:31 AM, Sven Neumann <s.neumann@raumfeld.com> wrote:
> > On Sat, 2010-10-09 at 03:07 +0200, Ohad Ben-Cohen wrote:
> >> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> >> index c94565d..515ff39 100644
> >> --- a/drivers/mmc/core/core.c
> >> +++ b/drivers/mmc/core/core.c
> >> @@ -1682,6 +1682,19 @@ int mmc_suspend_host(struct mmc_host *host)
> >> if (host->bus_ops && !host->bus_dead) {
> >> if (host->bus_ops->suspend)
> >> err = host->bus_ops->suspend(host);
> >> + if (err == -ENOSYS || !host->bus_ops->resume) {
> >> + /*
> >> + * We simply "remove" the card in this case.
> >> + * It will be redetected on resume.
> >> + */
> >> + if (host->bus_ops->remove)
> >> + host->bus_ops->remove(host);
> >> + mmc_claim_host(host);
> >> + mmc_detach_bus(host);
> >> + mmc_release_host(host);
> >> + host->pm_flags = 0;
> >> + err = 0;
> >> + }
> >> }
> >> mmc_bus_put(host);
> >>
> >> The reason I'm asking this is because it seems like commit
> >> 4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e "mmc: fix all hangs related
> >> to mmc/sd card insert/removal during suspend/resume" has broken
> >> suspending SDIO function drivers which don't have a suspend handler
> >> (or do have one, but for some reason it returns -ENOSYS, like
> >> libertas_sdio's does).
> >
> > Yes, this patch fixes the problem. Tested with v2.6.35-rc7. With above
> > patch applied, suspend (and resume!) work again with and without
> > pm_async=0.
> >
> > Thanks a lot to all of you for your help with this problem.
>
> Thanks a lot for testing this Sven !
>
> It is completely fixing the regression, but I must say the end result
> is not very beautiful. We may eventually still use it, at least as an
> interim solution, but I'd at least like to explain what's going on
> here.
>
> Patch 4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e "mmc: fix all hangs
> related to mmc/sd card insert/removal during suspend/resume" (which
> was introduced in 2.6.36 and backported to stable kernels) moved the
> card remove/insert mechanism out of the suspend/resume path and into
> mmc_pm_notify (which uses pm notifiers; needed in order to let user
> space sync the card upon removal).
>
> It broke (part of) SDIO suspend because SDIO relied on
> mmc_suspend_host() to remove the card, and squash the error, in case
> -ENOSYS is returned from the bus suspend handler (mmc_sdio_suspend()
> in this case).
>
> mmc_sdio_suspend() is using this whenever one of the card's SDIO
> function drivers does not have suspend/resume handlers - in that case
> it is agreed to force removal of the entire card.
>
> So the trivial thing to do here was to bring back that part of
> mmc_suspend_host(), which was removed by
> 4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e.
>
> The reason I said the end result is not too beautiful is because now
> we have two places in the mmc suspend execution path that can remove
> the card: mmc_pm_notify and mmc_suspend_host, where the second is
> probably useful only for SDIO. The card re-insertion, btw, will only
> take place in mmc_pm_notify, and be used by all scenarios (so it's
> becoming asymmetric for SDIO).
>
> To use mmc_pm_notify's card-removal code also for SDIO, we need to
> check there if all the SDIO functions have suspend handlers. That
> would probably make us add a new bus_ops handler (something like
> host->bus_ops->remove_card_on_suspend ?).
>
> It's starting to be a bit complicated though, and I'm not sure it
> would make the code a lot more readable.
>
> And, it would still not work for drivers like libertas sdio, which do
> have a suspend hander, but sometimes let it return -ENOSYS, expecting
> the MMC core to remove the card and squash the error. For those cases,
> we still need the old card-removal logic in mmc_suspend_host().
>
> Btw, it makes me wonder: does libertas_sdio really needs this
> functionality ? When MMC_PM_KEEP_POWER is not needed, why can't
> libertas_sdio just return 0 (and as a result the card will be powered
> off, but not removed) ?
Perhaps we should bring up this question on the libertas-dev list. I am
Cc'ing them in the hope that someone can answer this question.
Sven
WARNING: multiple messages have this Message-ID (diff)
From: s.neumann@raumfeld.com (Sven Neumann)
To: linux-arm-kernel@lists.infradead.org
Subject: 2.6.35.6 fails to suspend (pxa2xx-mci.0)
Date: Mon, 11 Oct 2010 11:11:55 +0200 [thread overview]
Message-ID: <1286788315.3101.11.camel@sven> (raw)
In-Reply-To: <AANLkTinf-8jeaV6GZ2+pQ2FztrXDv7QhEn3brPN3osBT@mail.gmail.com>
On Mon, 2010-10-11 at 10:45 +0200, Ohad Ben-Cohen wrote:
> On Mon, Oct 11, 2010 at 10:31 AM, Sven Neumann <s.neumann@raumfeld.com> wrote:
> > On Sat, 2010-10-09 at 03:07 +0200, Ohad Ben-Cohen wrote:
> >> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> >> index c94565d..515ff39 100644
> >> --- a/drivers/mmc/core/core.c
> >> +++ b/drivers/mmc/core/core.c
> >> @@ -1682,6 +1682,19 @@ int mmc_suspend_host(struct mmc_host *host)
> >> if (host->bus_ops && !host->bus_dead) {
> >> if (host->bus_ops->suspend)
> >> err = host->bus_ops->suspend(host);
> >> + if (err == -ENOSYS || !host->bus_ops->resume) {
> >> + /*
> >> + * We simply "remove" the card in this case.
> >> + * It will be redetected on resume.
> >> + */
> >> + if (host->bus_ops->remove)
> >> + host->bus_ops->remove(host);
> >> + mmc_claim_host(host);
> >> + mmc_detach_bus(host);
> >> + mmc_release_host(host);
> >> + host->pm_flags = 0;
> >> + err = 0;
> >> + }
> >> }
> >> mmc_bus_put(host);
> >>
> >> The reason I'm asking this is because it seems like commit
> >> 4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e "mmc: fix all hangs related
> >> to mmc/sd card insert/removal during suspend/resume" has broken
> >> suspending SDIO function drivers which don't have a suspend handler
> >> (or do have one, but for some reason it returns -ENOSYS, like
> >> libertas_sdio's does).
> >
> > Yes, this patch fixes the problem. Tested with v2.6.35-rc7. With above
> > patch applied, suspend (and resume!) work again with and without
> > pm_async=0.
> >
> > Thanks a lot to all of you for your help with this problem.
>
> Thanks a lot for testing this Sven !
>
> It is completely fixing the regression, but I must say the end result
> is not very beautiful. We may eventually still use it, at least as an
> interim solution, but I'd at least like to explain what's going on
> here.
>
> Patch 4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e "mmc: fix all hangs
> related to mmc/sd card insert/removal during suspend/resume" (which
> was introduced in 2.6.36 and backported to stable kernels) moved the
> card remove/insert mechanism out of the suspend/resume path and into
> mmc_pm_notify (which uses pm notifiers; needed in order to let user
> space sync the card upon removal).
>
> It broke (part of) SDIO suspend because SDIO relied on
> mmc_suspend_host() to remove the card, and squash the error, in case
> -ENOSYS is returned from the bus suspend handler (mmc_sdio_suspend()
> in this case).
>
> mmc_sdio_suspend() is using this whenever one of the card's SDIO
> function drivers does not have suspend/resume handlers - in that case
> it is agreed to force removal of the entire card.
>
> So the trivial thing to do here was to bring back that part of
> mmc_suspend_host(), which was removed by
> 4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e.
>
> The reason I said the end result is not too beautiful is because now
> we have two places in the mmc suspend execution path that can remove
> the card: mmc_pm_notify and mmc_suspend_host, where the second is
> probably useful only for SDIO. The card re-insertion, btw, will only
> take place in mmc_pm_notify, and be used by all scenarios (so it's
> becoming asymmetric for SDIO).
>
> To use mmc_pm_notify's card-removal code also for SDIO, we need to
> check there if all the SDIO functions have suspend handlers. That
> would probably make us add a new bus_ops handler (something like
> host->bus_ops->remove_card_on_suspend ?).
>
> It's starting to be a bit complicated though, and I'm not sure it
> would make the code a lot more readable.
>
> And, it would still not work for drivers like libertas sdio, which do
> have a suspend hander, but sometimes let it return -ENOSYS, expecting
> the MMC core to remove the card and squash the error. For those cases,
> we still need the old card-removal logic in mmc_suspend_host().
>
> Btw, it makes me wonder: does libertas_sdio really needs this
> functionality ? When MMC_PM_KEEP_POWER is not needed, why can't
> libertas_sdio just return 0 (and as a result the card will be powered
> off, but not removed) ?
Perhaps we should bring up this question on the libertas-dev list. I am
Cc'ing them in the hope that someone can answer this question.
Sven
next prev parent reply other threads:[~2010-10-11 9:12 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 7:30 2.6.35.6 fails to suspend (pxa2xx-mci.0) Sven Neumann
2010-10-04 7:30 ` Sven Neumann
2010-10-04 7:48 ` Eric Miao
2010-10-04 7:48 ` Eric Miao
2010-10-06 18:59 ` Maciej Rutecki
2010-10-06 18:59 ` Maciej Rutecki
2010-10-06 23:55 ` Daniel Mack
2010-10-06 23:55 ` Daniel Mack
2010-10-07 0:18 ` Rafael J. Wysocki
2010-10-07 0:18 ` Rafael J. Wysocki
2010-10-07 15:03 ` Sven Neumann
2010-10-07 15:03 ` Sven Neumann
2010-10-07 21:23 ` Rafael J. Wysocki
2010-10-07 21:23 ` Rafael J. Wysocki
2010-10-08 8:23 ` Sven Neumann
2010-10-08 8:23 ` Sven Neumann
2010-10-08 20:08 ` Rafael J. Wysocki
2010-10-08 20:08 ` Rafael J. Wysocki
2010-10-09 1:07 ` Ohad Ben-Cohen
2010-10-09 1:07 ` Ohad Ben-Cohen
2010-10-09 23:20 ` Sven Neumann
2010-10-09 23:20 ` Sven Neumann
2010-10-11 8:31 ` Sven Neumann
2010-10-11 8:31 ` Sven Neumann
2010-10-11 8:45 ` Ohad Ben-Cohen
2010-10-11 8:45 ` Ohad Ben-Cohen
2010-10-11 9:11 ` Sven Neumann [this message]
2010-10-11 9:11 ` Sven Neumann
2010-10-13 7:31 ` [PATCH] sdio: fix suspend/resume regression Ohad Ben-Cohen
2010-10-13 7:31 ` Ohad Ben-Cohen
2010-10-13 7:31 ` Ohad Ben-Cohen
2010-10-13 7:54 ` Vitaly Wool
2010-10-13 7:54 ` Vitaly Wool
2010-10-13 8:55 ` Ohad Ben-Cohen
2010-10-13 8:55 ` Ohad Ben-Cohen
2010-10-13 9:06 ` Vitaly Wool
2010-10-13 9:06 ` Vitaly Wool
2010-10-13 9:46 ` Ohad Ben-Cohen
2010-10-13 9:46 ` Ohad Ben-Cohen
2010-10-13 20:00 ` Nicolas Pitre
2010-10-13 20:00 ` Nicolas Pitre
2010-10-13 20:08 ` Nicolas Pitre
2010-10-13 20:08 ` Nicolas Pitre
2010-10-14 15:28 ` Ohad Ben-Cohen
2010-10-14 15:28 ` Ohad Ben-Cohen
2010-10-14 2:24 ` Chris Ball
2010-10-14 2:24 ` Chris Ball
2010-10-14 4:49 ` Ohad Ben-Cohen
2010-10-14 4:49 ` Ohad Ben-Cohen
2010-10-21 23:47 ` Maxim Levitsky
2010-10-21 23:47 ` Maxim Levitsky
2010-10-21 23:55 ` Nicolas Pitre
2010-10-21 23:55 ` Nicolas Pitre
2010-10-22 0:25 ` Maxim Levitsky
2010-10-22 0:25 ` Maxim Levitsky
2010-10-21 23:57 ` Nicolas Pitre
2010-10-21 23:57 ` Nicolas Pitre
2010-10-23 10:09 ` Ohad Ben-Cohen
2010-10-23 10:09 ` Ohad Ben-Cohen
2010-10-23 14:18 ` Maxim Levitsky
2010-10-23 14:18 ` Maxim Levitsky
2010-10-23 14:44 ` Ohad Ben-Cohen
2010-10-23 14:44 ` Ohad Ben-Cohen
2010-10-11 8:10 ` 2.6.35.6 fails to suspend (pxa2xx-mci.0) Sven Neumann
2010-10-11 8:10 ` Sven Neumann
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=1286788315.3101.11.camel@sven \
--to=s.neumann@raumfeld.com \
--cc=ccross@android.com \
--cc=cjb@laptop.org \
--cc=daniel@caiaq.de \
--cc=gregkh@suse.de \
--cc=libertas-dev@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=ohad@wizery.com \
--cc=rjw@sisk.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.