* [PATCH] PCMCIA / PM: Combine system resume callbacks
@ 2018-02-20 11:47 Rafael J. Wysocki
2018-02-20 21:38 ` Dominik Brodowski
0 siblings, 1 reply; 7+ messages in thread
From: Rafael J. Wysocki @ 2018-02-20 11:47 UTC (permalink / raw)
To: Linux PM; +Cc: LKML, Dominik Brodowski
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is a problem with PCMCIA system resume callbacks with respect
to suspend-to-idle in which the ->suspend_noirq() callback may be
invoked after the ->resume_noirq() one without resuming the system
entirely in some cases. This doesn't work for PCMCIA because of
the lack of symmetry between its system suspend and system resume
"noirq" callbacks.
The system resume handling in PCMCIA is split between
socket_early_resume() and socket_late_resume() which are called in
different phases of system resume and both need to run for
socket_suspend() (invoked by the system suspend "noirq" callback)
to work. Specifically, socket_suspend() returns an error when
called after socket_early_resume() without socket_late_resume(),
so if the suspend-to-idle core detects a spurious wakeup event and
attempts to put the system back to sleep, that is aborted by the
error coming from socket_suspend().
This design doesn't follow the power management documentation
stating that the "noirq" resume callback is expected to reverse
the changes made by the "noirq" suspend one. Moreover, I don't see
a reason for splitting the PCMCIA socket system resume handling this
way and since it has become problematic in practice, replace both
socket_early_resume() and socket_late_resume() with one routine,
__socket_resume(), that will run all of the code from them in one
go, and point the "noirq" system suspend callback for the socket to
it.
This change has been tested on my venerable Toshiba Portege R500
(which is where the problem has been discovered in the first place),
but admittedly I have no PCMCIA cards to test along with the socket
itself.
Fixes: 33e4f80ee69b (ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/pcmcia/cs.c | 26 +++++---------------------
1 file changed, 5 insertions(+), 21 deletions(-)
Index: linux-pm/drivers/pcmcia/cs.c
===================================================================
--- linux-pm.orig/drivers/pcmcia/cs.c
+++ linux-pm/drivers/pcmcia/cs.c
@@ -467,23 +467,17 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-static int socket_early_resume(struct pcmcia_socket *skt)
+static int __socket_resume(struct pcmcia_socket *skt)
{
+ int ret = 0;
+
mutex_lock(&skt->ops_mutex);
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
if (skt->state & SOCKET_PRESENT)
skt->resume_status = socket_setup(skt, resume_delay);
- mutex_unlock(&skt->ops_mutex);
- return 0;
-}
-static int socket_late_resume(struct pcmcia_socket *skt)
-{
- int ret = 0;
-
- mutex_lock(&skt->ops_mutex);
skt->state &= ~SOCKET_SUSPEND;
mutex_unlock(&skt->ops_mutex);
@@ -546,8 +540,7 @@ static int socket_resume(struct pcmcia_s
if (!(skt->state & SOCKET_SUSPEND))
return -EBUSY;
- socket_early_resume(skt);
- err = socket_late_resume(skt);
+ err = __socket_resume(skt);
if (!err)
err = socket_complete_resume(skt);
return err;
@@ -853,12 +846,7 @@ static int pcmcia_socket_dev_suspend_noi
static int pcmcia_socket_dev_resume_noirq(struct device *dev)
{
- return __pcmcia_pm_op(dev, socket_early_resume);
-}
-
-static int __used pcmcia_socket_dev_resume(struct device *dev)
-{
- return __pcmcia_pm_op(dev, socket_late_resume);
+ return __pcmcia_pm_op(dev, __socket_resume);
}
static void __used pcmcia_socket_dev_complete(struct device *dev)
@@ -868,10 +856,6 @@ static void __used pcmcia_socket_dev_com
}
static const struct dev_pm_ops pcmcia_socket_pm_ops = {
- /* dev_resume may be called with IRQs enabled */
- SET_SYSTEM_SLEEP_PM_OPS(NULL,
- pcmcia_socket_dev_resume)
-
/* late suspend must be called with IRQs disabled */
.suspend_noirq = pcmcia_socket_dev_suspend_noirq,
.freeze_noirq = pcmcia_socket_dev_suspend_noirq,
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PCMCIA / PM: Combine system resume callbacks
2018-02-20 11:47 [PATCH] PCMCIA / PM: Combine system resume callbacks Rafael J. Wysocki
@ 2018-02-20 21:38 ` Dominik Brodowski
2018-02-21 9:09 ` Rafael J. Wysocki
2018-02-21 12:24 ` [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle Rafael J. Wysocki
0 siblings, 2 replies; 7+ messages in thread
From: Dominik Brodowski @ 2018-02-20 21:38 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux PM, LKML
On Tue, Feb 20, 2018 at 12:47:27PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> There is a problem with PCMCIA system resume callbacks with respect
> to suspend-to-idle in which the ->suspend_noirq() callback may be
> invoked after the ->resume_noirq() one without resuming the system
> entirely in some cases. This doesn't work for PCMCIA because of
> the lack of symmetry between its system suspend and system resume
> "noirq" callbacks.
>
> The system resume handling in PCMCIA is split between
> socket_early_resume() and socket_late_resume() which are called in
> different phases of system resume and both need to run for
> socket_suspend() (invoked by the system suspend "noirq" callback)
> to work. Specifically, socket_suspend() returns an error when
> called after socket_early_resume() without socket_late_resume(),
> so if the suspend-to-idle core detects a spurious wakeup event and
> attempts to put the system back to sleep, that is aborted by the
> error coming from socket_suspend().
>
> This design doesn't follow the power management documentation
> stating that the "noirq" resume callback is expected to reverse
> the changes made by the "noirq" suspend one. Moreover, I don't see
> a reason for splitting the PCMCIA socket system resume handling this
> way
Unless I am mistaken, this split was introduced by commit
9905d1b411946 . So we should take into account the reasons stated
in that commit message.
Thanks,
Dominik
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PCMCIA / PM: Combine system resume callbacks
2018-02-20 21:38 ` Dominik Brodowski
@ 2018-02-21 9:09 ` Rafael J. Wysocki
2018-02-21 12:24 ` [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle Rafael J. Wysocki
1 sibling, 0 replies; 7+ messages in thread
From: Rafael J. Wysocki @ 2018-02-21 9:09 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: Rafael J. Wysocki, Linux PM, LKML
On Tue, Feb 20, 2018 at 10:38 PM, Dominik Brodowski
<linux@dominikbrodowski.net> wrote:
> On Tue, Feb 20, 2018 at 12:47:27PM +0100, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> There is a problem with PCMCIA system resume callbacks with respect
>> to suspend-to-idle in which the ->suspend_noirq() callback may be
>> invoked after the ->resume_noirq() one without resuming the system
>> entirely in some cases. This doesn't work for PCMCIA because of
>> the lack of symmetry between its system suspend and system resume
>> "noirq" callbacks.
>>
>> The system resume handling in PCMCIA is split between
>> socket_early_resume() and socket_late_resume() which are called in
>> different phases of system resume and both need to run for
>> socket_suspend() (invoked by the system suspend "noirq" callback)
>> to work. Specifically, socket_suspend() returns an error when
>> called after socket_early_resume() without socket_late_resume(),
>> so if the suspend-to-idle core detects a spurious wakeup event and
>> attempts to put the system back to sleep, that is aborted by the
>> error coming from socket_suspend().
>>
>> This design doesn't follow the power management documentation
>> stating that the "noirq" resume callback is expected to reverse
>> the changes made by the "noirq" suspend one. Moreover, I don't see
>> a reason for splitting the PCMCIA socket system resume handling this
>> way
>
> Unless I am mistaken, this split was introduced by commit
> 9905d1b411946 . So we should take into account the reasons stated
> in that commit message.
Well, I should have done more research, thanks for reminding me about that.
I guess I'll need to add one more state flag, then.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle
2018-02-20 21:38 ` Dominik Brodowski
2018-02-21 9:09 ` Rafael J. Wysocki
@ 2018-02-21 12:24 ` Rafael J. Wysocki
2018-02-22 16:45 ` Dominik Brodowski
1 sibling, 1 reply; 7+ messages in thread
From: Rafael J. Wysocki @ 2018-02-21 12:24 UTC (permalink / raw)
To: Dominik Brodowski, Linux PM; +Cc: LKML
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is a problem with PCMCIA system resume callbacks with respect
to suspend-to-idle in which the ->suspend_noirq() callback may be
invoked after the ->resume_noirq() one without resuming the system
entirely in some cases. This doesn't work for PCMCIA because of
the lack of symmetry between its system suspend and system resume
"noirq" callbacks.
The system resume handling in PCMCIA is split between
socket_early_resume() and socket_late_resume() which are called in
different phases of system resume and both need to run for
socket_suspend() (invoked by the system suspend "noirq" callback)
to work. Specifically, socket_suspend() returns an error when
called after socket_early_resume() without socket_late_resume(),
so if the suspend-to-idle core detects a spurious wakeup event and
attempts to put the system back to sleep, that is aborted by the
error coming from socket_suspend().
Avoid that by using a new socket state flag, SOCKET_IN_RESUME,
to indicate that socket_early_resume() has already run for the
socket in which case socket_suspend() will do minimum handling
and return 0.
This change has been tested on my venerable Toshiba Portege R500
(which is where the problem has been discovered in the first place),
but admittedly I have no PCMCIA cards to test along with the socket
itself.
Fixes: 33e4f80ee69b (ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
This replaces https://patchwork.kernel.org/patch/10229821/
---
drivers/pcmcia/cs.c | 11 ++++++++++-
drivers/pcmcia/cs_internal.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
Index: linux-pm/drivers/pcmcia/cs.c
===================================================================
--- linux-pm.orig/drivers/pcmcia/cs.c
+++ linux-pm/drivers/pcmcia/cs.c
@@ -452,6 +452,14 @@ static int socket_insert(struct pcmcia_s
static int socket_suspend(struct pcmcia_socket *skt)
{
+ if (skt->state & SOCKET_IN_RESUME) {
+ mutex_lock(&skt->ops_mutex);
+ skt->socket = dead_socket;
+ skt->ops->set_socket(skt, &skt->socket);
+ mutex_unlock(&skt->ops_mutex);
+ return 0;
+ }
+
if (skt->state & SOCKET_SUSPEND)
return -EBUSY;
@@ -475,6 +483,7 @@ static int socket_early_resume(struct pc
skt->ops->set_socket(skt, &skt->socket);
if (skt->state & SOCKET_PRESENT)
skt->resume_status = socket_setup(skt, resume_delay);
+ skt->state |= SOCKET_IN_RESUME;
mutex_unlock(&skt->ops_mutex);
return 0;
}
@@ -484,7 +493,7 @@ static int socket_late_resume(struct pcm
int ret = 0;
mutex_lock(&skt->ops_mutex);
- skt->state &= ~SOCKET_SUSPEND;
+ skt->state &= ~(SOCKET_SUSPEND | SOCKET_IN_RESUME);
mutex_unlock(&skt->ops_mutex);
if (!(skt->state & SOCKET_PRESENT)) {
Index: linux-pm/drivers/pcmcia/cs_internal.h
===================================================================
--- linux-pm.orig/drivers/pcmcia/cs_internal.h
+++ linux-pm/drivers/pcmcia/cs_internal.h
@@ -70,6 +70,7 @@ struct pccard_resource_ops {
/* Flags in socket state */
#define SOCKET_PRESENT 0x0008
#define SOCKET_INUSE 0x0010
+#define SOCKET_IN_RESUME 0x0040
#define SOCKET_SUSPEND 0x0080
#define SOCKET_WIN_REQ(i) (0x0100<<(i))
#define SOCKET_CARDBUS 0x8000
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle
2018-02-21 12:24 ` [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle Rafael J. Wysocki
@ 2018-02-22 16:45 ` Dominik Brodowski
2018-02-22 17:32 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Dominik Brodowski @ 2018-02-22 16:45 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux PM, LKML
On Wed, Feb 21, 2018 at 01:24:16PM +0100, Rafael J. Wysocki wrote:
> Avoid that by using a new socket state flag, SOCKET_IN_RESUME,
> to indicate that socket_early_resume() has already run for the
> socket in which case socket_suspend() will do minimum handling
> and return 0.
That looks to be *too* minimal: For example, yenta_socket does some
socket set-up in ->init(), which is called by socket_early_resume().
That needs to be undone by ->suspend(). What about this variant
(untested, not even compile-tested)?
Oh, and
a) does this need -stable tags, and
b) do you want to push it yourself, or should it go through the
PCMCIA tree?
Thanks,
Dominik
---
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Date: Wed, 21 Feb 2018 13:24:16 +0100
Subject: [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during
suspend-to-idle
There is a problem with PCMCIA system resume callbacks with respect
to suspend-to-idle in which the ->suspend_noirq() callback may be
invoked after the ->resume_noirq() one without resuming the system
entirely in some cases. This doesn't work for PCMCIA because of
the lack of symmetry between its system suspend and system resume
"noirq" callbacks.
The system resume handling in PCMCIA is split between
socket_early_resume() and socket_late_resume() which are called in
different phases of system resume and both need to run for
socket_suspend() (invoked by the system suspend "noirq" callback)
to work. Specifically, socket_suspend() returns an error when
called after socket_early_resume() without socket_late_resume(),
so if the suspend-to-idle core detects a spurious wakeup event and
attempts to put the system back to sleep, that is aborted by the
error coming from socket_suspend().
Avoid that by using a new socket state flag, SOCKET_IN_RESUME,
to indicate that socket_early_resume() has already run for the
socket in which case socket_suspend() will do minimum handling
and return 0.
This change has been tested on my venerable Toshiba Portege R500
(which is where the problem has been discovered in the first place),
but admittedly I have no PCMCIA cards to test along with the socket
itself.
Fixes: 33e4f80ee69b (ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[linux@dominikbrodowski.net: follow same codepaths for both suspend variants; call ->suspend()]
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c
index c3b615c94b4b..513b2d4d5b20 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -452,17 +452,20 @@ static int socket_insert(struct pcmcia_socket *skt)
static int socket_suspend(struct pcmcia_socket *skt)
{
- if (skt->state & SOCKET_SUSPEND)
+ if ((skt->state & SOCKET_SUSPEND) && !(skt->state & SOCKET_IN_RESUME))
return -EBUSY;
mutex_lock(&skt->ops_mutex);
- skt->suspended_state = skt->state;
+ /* store state on first suspend, but not after spurious wakeups */
+ if !(skt->state & SOCKET_IN_RESUME)
+ skt->suspended_state = skt->state;
skt->socket = dead_socket;
skt->ops->set_socket(skt, &skt->socket);
if (skt->ops->suspend)
skt->ops->suspend(skt);
skt->state |= SOCKET_SUSPEND;
+ skt->state &= ~(SOCKET_IN_RESUME);
mutex_unlock(&skt->ops_mutex);
return 0;
}
@@ -475,6 +478,7 @@ static int socket_early_resume(struct pcmcia_socket *skt)
skt->ops->set_socket(skt, &skt->socket);
if (skt->state & SOCKET_PRESENT)
skt->resume_status = socket_setup(skt, resume_delay);
+ skt->state |= SOCKET_IN_RESUME;
mutex_unlock(&skt->ops_mutex);
return 0;
}
@@ -484,7 +488,7 @@ static int socket_late_resume(struct pcmcia_socket *skt)
int ret = 0;
mutex_lock(&skt->ops_mutex);
- skt->state &= ~SOCKET_SUSPEND;
+ skt->state &= ~(SOCKET_SUSPEND | SOCKET_IN_RESUME);
mutex_unlock(&skt->ops_mutex);
if (!(skt->state & SOCKET_PRESENT)) {
diff --git a/drivers/pcmcia/cs_internal.h b/drivers/pcmcia/cs_internal.h
index 6765beadea95..03ec43802909 100644
--- a/drivers/pcmcia/cs_internal.h
+++ b/drivers/pcmcia/cs_internal.h
@@ -70,6 +70,7 @@ struct pccard_resource_ops {
/* Flags in socket state */
#define SOCKET_PRESENT 0x0008
#define SOCKET_INUSE 0x0010
+#define SOCKET_IN_RESUME 0x0040
#define SOCKET_SUSPEND 0x0080
#define SOCKET_WIN_REQ(i) (0x0100<<(i))
#define SOCKET_CARDBUS 0x8000
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle
2018-02-22 16:45 ` Dominik Brodowski
@ 2018-02-22 17:32 ` Rafael J. Wysocki
2018-02-22 21:49 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Rafael J. Wysocki @ 2018-02-22 17:32 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: Rafael J. Wysocki, Linux PM, LKML
On Thu, Feb 22, 2018 at 5:45 PM, Dominik Brodowski
<linux@dominikbrodowski.net> wrote:
> On Wed, Feb 21, 2018 at 01:24:16PM +0100, Rafael J. Wysocki wrote:
>> Avoid that by using a new socket state flag, SOCKET_IN_RESUME,
>> to indicate that socket_early_resume() has already run for the
>> socket in which case socket_suspend() will do minimum handling
>> and return 0.
>
> That looks to be *too* minimal: For example, yenta_socket does some
> socket set-up in ->init(), which is called by socket_early_resume().
> That needs to be undone by ->suspend().
I see.
> What about this variant (untested, not even compile-tested)?
It looks fine to me, I'll test it later today.
> Oh, and
> a) does this need -stable tags, and
Not right away I guess, but I will ask the -stable maintainers to pick
it up at one point if there are no problems reported with it.
> b) do you want to push it yourself, or should it go through the
> PCMCIA tree?
I'll take care of it.
Thanks,
Rafael
> ---
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> Date: Wed, 21 Feb 2018 13:24:16 +0100
> Subject: [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during
> suspend-to-idle
>
> There is a problem with PCMCIA system resume callbacks with respect
> to suspend-to-idle in which the ->suspend_noirq() callback may be
> invoked after the ->resume_noirq() one without resuming the system
> entirely in some cases. This doesn't work for PCMCIA because of
> the lack of symmetry between its system suspend and system resume
> "noirq" callbacks.
>
> The system resume handling in PCMCIA is split between
> socket_early_resume() and socket_late_resume() which are called in
> different phases of system resume and both need to run for
> socket_suspend() (invoked by the system suspend "noirq" callback)
> to work. Specifically, socket_suspend() returns an error when
> called after socket_early_resume() without socket_late_resume(),
> so if the suspend-to-idle core detects a spurious wakeup event and
> attempts to put the system back to sleep, that is aborted by the
> error coming from socket_suspend().
>
> Avoid that by using a new socket state flag, SOCKET_IN_RESUME,
> to indicate that socket_early_resume() has already run for the
> socket in which case socket_suspend() will do minimum handling
> and return 0.
>
> This change has been tested on my venerable Toshiba Portege R500
> (which is where the problem has been discovered in the first place),
> but admittedly I have no PCMCIA cards to test along with the socket
> itself.
>
> Fixes: 33e4f80ee69b (ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle)
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> [linux@dominikbrodowski.net: follow same codepaths for both suspend variants; call ->suspend()]
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
>
> diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c
> index c3b615c94b4b..513b2d4d5b20 100644
> --- a/drivers/pcmcia/cs.c
> +++ b/drivers/pcmcia/cs.c
> @@ -452,17 +452,20 @@ static int socket_insert(struct pcmcia_socket *skt)
>
> static int socket_suspend(struct pcmcia_socket *skt)
> {
> - if (skt->state & SOCKET_SUSPEND)
> + if ((skt->state & SOCKET_SUSPEND) && !(skt->state & SOCKET_IN_RESUME))
> return -EBUSY;
>
> mutex_lock(&skt->ops_mutex);
> - skt->suspended_state = skt->state;
> + /* store state on first suspend, but not after spurious wakeups */
> + if !(skt->state & SOCKET_IN_RESUME)
> + skt->suspended_state = skt->state;
>
> skt->socket = dead_socket;
> skt->ops->set_socket(skt, &skt->socket);
> if (skt->ops->suspend)
> skt->ops->suspend(skt);
> skt->state |= SOCKET_SUSPEND;
> + skt->state &= ~(SOCKET_IN_RESUME);
> mutex_unlock(&skt->ops_mutex);
> return 0;
> }
> @@ -475,6 +478,7 @@ static int socket_early_resume(struct pcmcia_socket *skt)
> skt->ops->set_socket(skt, &skt->socket);
> if (skt->state & SOCKET_PRESENT)
> skt->resume_status = socket_setup(skt, resume_delay);
> + skt->state |= SOCKET_IN_RESUME;
> mutex_unlock(&skt->ops_mutex);
> return 0;
> }
> @@ -484,7 +488,7 @@ static int socket_late_resume(struct pcmcia_socket *skt)
> int ret = 0;
>
> mutex_lock(&skt->ops_mutex);
> - skt->state &= ~SOCKET_SUSPEND;
> + skt->state &= ~(SOCKET_SUSPEND | SOCKET_IN_RESUME);
> mutex_unlock(&skt->ops_mutex);
>
> if (!(skt->state & SOCKET_PRESENT)) {
> diff --git a/drivers/pcmcia/cs_internal.h b/drivers/pcmcia/cs_internal.h
> index 6765beadea95..03ec43802909 100644
> --- a/drivers/pcmcia/cs_internal.h
> +++ b/drivers/pcmcia/cs_internal.h
> @@ -70,6 +70,7 @@ struct pccard_resource_ops {
> /* Flags in socket state */
> #define SOCKET_PRESENT 0x0008
> #define SOCKET_INUSE 0x0010
> +#define SOCKET_IN_RESUME 0x0040
> #define SOCKET_SUSPEND 0x0080
> #define SOCKET_WIN_REQ(i) (0x0100<<(i))
> #define SOCKET_CARDBUS 0x8000
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle
2018-02-22 17:32 ` Rafael J. Wysocki
@ 2018-02-22 21:49 ` Rafael J. Wysocki
0 siblings, 0 replies; 7+ messages in thread
From: Rafael J. Wysocki @ 2018-02-22 21:49 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: Linux PM, LKML
On Thu, Feb 22, 2018 at 6:32 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Thu, Feb 22, 2018 at 5:45 PM, Dominik Brodowski
> <linux@dominikbrodowski.net> wrote:
>> On Wed, Feb 21, 2018 at 01:24:16PM +0100, Rafael J. Wysocki wrote:
>>> Avoid that by using a new socket state flag, SOCKET_IN_RESUME,
>>> to indicate that socket_early_resume() has already run for the
>>> socket in which case socket_suspend() will do minimum handling
>>> and return 0.
>>
>> That looks to be *too* minimal: For example, yenta_socket does some
>> socket set-up in ->init(), which is called by socket_early_resume().
>> That needs to be undone by ->suspend().
>
> I see.
>
>> What about this variant (untested, not even compile-tested)?
>
> It looks fine to me, I'll test it later today.
I had to make it compile (by fixing a typo), but it works for me after
that, so I'll queue it up.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-02-22 21:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-20 11:47 [PATCH] PCMCIA / PM: Combine system resume callbacks Rafael J. Wysocki
2018-02-20 21:38 ` Dominik Brodowski
2018-02-21 9:09 ` Rafael J. Wysocki
2018-02-21 12:24 ` [PATCH] PCMCIA / PM: Avoid noirq suspend aborts during suspend-to-idle Rafael J. Wysocki
2018-02-22 16:45 ` Dominik Brodowski
2018-02-22 17:32 ` Rafael J. Wysocki
2018-02-22 21:49 ` Rafael J. Wysocki
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).