* [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
@ 2011-07-22 21:46 ` Kevin Hilman
0 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-07-22 21:46 UTC (permalink / raw)
To: linux-pm; +Cc: linux-omap, linux-arm-kernel, Colin Cross, Nishanth Menon
Currently the use of pm_runtime_put_sync() is not safe from
interrupts-disabled context because rpm_idle() will release the
spinlock and enable interrupts for the idle callbacks. This enables
interrupts during a time where interrupts were expected to be
disabled, and can have strange side effects on drivers that expected
interrupts to be disabled.
This is not a bug since the documentation clearly states that only
_put_sync_suspend() is safe in IRQ-safe mode.
However, pm_runtime_put_sync() could be made safe when in IRQ-safe
mode by releasing the spinlock but not re-enabling interrupts, which
is what this patch aims to do.
Problem was found when using some buggy drivers that set
pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
context.
The offending drivers have been fixed to use _put_sync_suspend(),
But this patch is an RFC to see if it might make sense to allow
using _put_sync() from interrupts-disabled context.
Reported-by: Colin Cross <ccross@google.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
v2: update documentation also
Documentation/power/runtime_pm.txt | 10 +++++-----
drivers/base/power/runtime.c | 10 ++++++++--
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 14dd3c6..4ce5450 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -54,11 +54,10 @@ referred to as subsystem-level callbacks in what follows.
By default, the callbacks are always invoked in process context with interrupts
enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
-callbacks should be invoked in atomic context with interrupts disabled
-(->runtime_idle() is still invoked the default way). This implies that these
-callback routines must not block or sleep, but it also means that the
-synchronous helper functions listed at the end of Section 4 can be used within
-an interrupt handler or in an atomic context.
+callbacks should be invoked in atomic context with interrupts disabled.
+This implies that these callback routines must not block or sleep, but it also
+means that the synchronous helper functions listed at the end of Section 4 can
+be used within an interrupt handler or in an atomic context.
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
the suspend of the device as appropriate, which may, but need not include
@@ -483,6 +482,7 @@ pm_runtime_suspend()
pm_runtime_autosuspend()
pm_runtime_resume()
pm_runtime_get_sync()
+pm_runtime_put_sync()
pm_runtime_put_sync_suspend()
5. Runtime PM Initialization, Device Probing and Removal
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 8dc247c..acb3f83 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -226,11 +226,17 @@ static int rpm_idle(struct device *dev, int rpmflags)
callback = NULL;
if (callback) {
- spin_unlock_irq(&dev->power.lock);
+ if (dev->power.irq_safe)
+ spin_unlock(&dev->power.lock);
+ else
+ spin_unlock_irq(&dev->power.lock);
callback(dev);
- spin_lock_irq(&dev->power.lock);
+ if (dev->power.irq_safe)
+ spin_lock(&dev->power.lock);
+ else
+ spin_lock_irq(&dev->power.lock);
}
dev->power.idle_notification = false;
--
1.7.6
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
@ 2011-07-22 21:46 ` Kevin Hilman
0 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-07-22 21:46 UTC (permalink / raw)
To: linux-arm-kernel
Currently the use of pm_runtime_put_sync() is not safe from
interrupts-disabled context because rpm_idle() will release the
spinlock and enable interrupts for the idle callbacks. This enables
interrupts during a time where interrupts were expected to be
disabled, and can have strange side effects on drivers that expected
interrupts to be disabled.
This is not a bug since the documentation clearly states that only
_put_sync_suspend() is safe in IRQ-safe mode.
However, pm_runtime_put_sync() could be made safe when in IRQ-safe
mode by releasing the spinlock but not re-enabling interrupts, which
is what this patch aims to do.
Problem was found when using some buggy drivers that set
pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
context.
The offending drivers have been fixed to use _put_sync_suspend(),
But this patch is an RFC to see if it might make sense to allow
using _put_sync() from interrupts-disabled context.
Reported-by: Colin Cross <ccross@google.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
v2: update documentation also
Documentation/power/runtime_pm.txt | 10 +++++-----
drivers/base/power/runtime.c | 10 ++++++++--
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 14dd3c6..4ce5450 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -54,11 +54,10 @@ referred to as subsystem-level callbacks in what follows.
By default, the callbacks are always invoked in process context with interrupts
enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
-callbacks should be invoked in atomic context with interrupts disabled
-(->runtime_idle() is still invoked the default way). This implies that these
-callback routines must not block or sleep, but it also means that the
-synchronous helper functions listed at the end of Section 4 can be used within
-an interrupt handler or in an atomic context.
+callbacks should be invoked in atomic context with interrupts disabled.
+This implies that these callback routines must not block or sleep, but it also
+means that the synchronous helper functions listed at the end of Section 4 can
+be used within an interrupt handler or in an atomic context.
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
the suspend of the device as appropriate, which may, but need not include
@@ -483,6 +482,7 @@ pm_runtime_suspend()
pm_runtime_autosuspend()
pm_runtime_resume()
pm_runtime_get_sync()
+pm_runtime_put_sync()
pm_runtime_put_sync_suspend()
5. Runtime PM Initialization, Device Probing and Removal
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 8dc247c..acb3f83 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -226,11 +226,17 @@ static int rpm_idle(struct device *dev, int rpmflags)
callback = NULL;
if (callback) {
- spin_unlock_irq(&dev->power.lock);
+ if (dev->power.irq_safe)
+ spin_unlock(&dev->power.lock);
+ else
+ spin_unlock_irq(&dev->power.lock);
callback(dev);
- spin_lock_irq(&dev->power.lock);
+ if (dev->power.irq_safe)
+ spin_lock(&dev->power.lock);
+ else
+ spin_lock_irq(&dev->power.lock);
}
dev->power.idle_notification = false;
--
1.7.6
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-07-22 21:46 ` Kevin Hilman
(?)
@ 2011-07-23 23:02 ` Rafael J. Wysocki
-1 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-07-23 23:02 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-pm, linux-omap, linux-arm-kernel, Colin Cross
On Friday, July 22, 2011, Kevin Hilman wrote:
> Currently the use of pm_runtime_put_sync() is not safe from
> interrupts-disabled context because rpm_idle() will release the
> spinlock and enable interrupts for the idle callbacks. This enables
> interrupts during a time where interrupts were expected to be
> disabled, and can have strange side effects on drivers that expected
> interrupts to be disabled.
>
> This is not a bug since the documentation clearly states that only
> _put_sync_suspend() is safe in IRQ-safe mode.
>
> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> mode by releasing the spinlock but not re-enabling interrupts, which
> is what this patch aims to do.
>
> Problem was found when using some buggy drivers that set
> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> context.
>
> The offending drivers have been fixed to use _put_sync_suspend(),
> But this patch is an RFC to see if it might make sense to allow
> using _put_sync() from interrupts-disabled context.
OK, I'm going to take this for 3.2.
Thanks,
Rafael
> Reported-by: Colin Cross <ccross@google.com>
> Tested-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> v2: update documentation also
>
> Documentation/power/runtime_pm.txt | 10 +++++-----
> drivers/base/power/runtime.c | 10 ++++++++--
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
> index 14dd3c6..4ce5450 100644
> --- a/Documentation/power/runtime_pm.txt
> +++ b/Documentation/power/runtime_pm.txt
> @@ -54,11 +54,10 @@ referred to as subsystem-level callbacks in what follows.
> By default, the callbacks are always invoked in process context with interrupts
> enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
> to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
> -callbacks should be invoked in atomic context with interrupts disabled
> -(->runtime_idle() is still invoked the default way). This implies that these
> -callback routines must not block or sleep, but it also means that the
> -synchronous helper functions listed at the end of Section 4 can be used within
> -an interrupt handler or in an atomic context.
> +callbacks should be invoked in atomic context with interrupts disabled.
> +This implies that these callback routines must not block or sleep, but it also
> +means that the synchronous helper functions listed at the end of Section 4 can
> +be used within an interrupt handler or in an atomic context.
>
> The subsystem-level suspend callback is _entirely_ _responsible_ for handling
> the suspend of the device as appropriate, which may, but need not include
> @@ -483,6 +482,7 @@ pm_runtime_suspend()
> pm_runtime_autosuspend()
> pm_runtime_resume()
> pm_runtime_get_sync()
> +pm_runtime_put_sync()
> pm_runtime_put_sync_suspend()
>
> 5. Runtime PM Initialization, Device Probing and Removal
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 8dc247c..acb3f83 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -226,11 +226,17 @@ static int rpm_idle(struct device *dev, int rpmflags)
> callback = NULL;
>
> if (callback) {
> - spin_unlock_irq(&dev->power.lock);
> + if (dev->power.irq_safe)
> + spin_unlock(&dev->power.lock);
> + else
> + spin_unlock_irq(&dev->power.lock);
>
> callback(dev);
>
> - spin_lock_irq(&dev->power.lock);
> + if (dev->power.irq_safe)
> + spin_lock(&dev->power.lock);
> + else
> + spin_lock_irq(&dev->power.lock);
> }
>
> dev->power.idle_notification = false;
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-07-22 21:46 ` Kevin Hilman
@ 2011-07-23 23:02 ` Rafael J. Wysocki
-1 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-07-23 23:02 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-pm, linux-omap, linux-arm-kernel, Alan Stern, Colin Cross
On Friday, July 22, 2011, Kevin Hilman wrote:
> Currently the use of pm_runtime_put_sync() is not safe from
> interrupts-disabled context because rpm_idle() will release the
> spinlock and enable interrupts for the idle callbacks. This enables
> interrupts during a time where interrupts were expected to be
> disabled, and can have strange side effects on drivers that expected
> interrupts to be disabled.
>
> This is not a bug since the documentation clearly states that only
> _put_sync_suspend() is safe in IRQ-safe mode.
>
> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> mode by releasing the spinlock but not re-enabling interrupts, which
> is what this patch aims to do.
>
> Problem was found when using some buggy drivers that set
> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> context.
>
> The offending drivers have been fixed to use _put_sync_suspend(),
> But this patch is an RFC to see if it might make sense to allow
> using _put_sync() from interrupts-disabled context.
OK, I'm going to take this for 3.2.
Thanks,
Rafael
> Reported-by: Colin Cross <ccross@google.com>
> Tested-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> v2: update documentation also
>
> Documentation/power/runtime_pm.txt | 10 +++++-----
> drivers/base/power/runtime.c | 10 ++++++++--
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
> index 14dd3c6..4ce5450 100644
> --- a/Documentation/power/runtime_pm.txt
> +++ b/Documentation/power/runtime_pm.txt
> @@ -54,11 +54,10 @@ referred to as subsystem-level callbacks in what follows.
> By default, the callbacks are always invoked in process context with interrupts
> enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
> to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
> -callbacks should be invoked in atomic context with interrupts disabled
> -(->runtime_idle() is still invoked the default way). This implies that these
> -callback routines must not block or sleep, but it also means that the
> -synchronous helper functions listed at the end of Section 4 can be used within
> -an interrupt handler or in an atomic context.
> +callbacks should be invoked in atomic context with interrupts disabled.
> +This implies that these callback routines must not block or sleep, but it also
> +means that the synchronous helper functions listed at the end of Section 4 can
> +be used within an interrupt handler or in an atomic context.
>
> The subsystem-level suspend callback is _entirely_ _responsible_ for handling
> the suspend of the device as appropriate, which may, but need not include
> @@ -483,6 +482,7 @@ pm_runtime_suspend()
> pm_runtime_autosuspend()
> pm_runtime_resume()
> pm_runtime_get_sync()
> +pm_runtime_put_sync()
> pm_runtime_put_sync_suspend()
>
> 5. Runtime PM Initialization, Device Probing and Removal
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 8dc247c..acb3f83 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -226,11 +226,17 @@ static int rpm_idle(struct device *dev, int rpmflags)
> callback = NULL;
>
> if (callback) {
> - spin_unlock_irq(&dev->power.lock);
> + if (dev->power.irq_safe)
> + spin_unlock(&dev->power.lock);
> + else
> + spin_unlock_irq(&dev->power.lock);
>
> callback(dev);
>
> - spin_lock_irq(&dev->power.lock);
> + if (dev->power.irq_safe)
> + spin_lock(&dev->power.lock);
> + else
> + spin_lock_irq(&dev->power.lock);
> }
>
> dev->power.idle_notification = false;
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
@ 2011-07-23 23:02 ` Rafael J. Wysocki
0 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-07-23 23:02 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, July 22, 2011, Kevin Hilman wrote:
> Currently the use of pm_runtime_put_sync() is not safe from
> interrupts-disabled context because rpm_idle() will release the
> spinlock and enable interrupts for the idle callbacks. This enables
> interrupts during a time where interrupts were expected to be
> disabled, and can have strange side effects on drivers that expected
> interrupts to be disabled.
>
> This is not a bug since the documentation clearly states that only
> _put_sync_suspend() is safe in IRQ-safe mode.
>
> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> mode by releasing the spinlock but not re-enabling interrupts, which
> is what this patch aims to do.
>
> Problem was found when using some buggy drivers that set
> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> context.
>
> The offending drivers have been fixed to use _put_sync_suspend(),
> But this patch is an RFC to see if it might make sense to allow
> using _put_sync() from interrupts-disabled context.
OK, I'm going to take this for 3.2.
Thanks,
Rafael
> Reported-by: Colin Cross <ccross@google.com>
> Tested-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> v2: update documentation also
>
> Documentation/power/runtime_pm.txt | 10 +++++-----
> drivers/base/power/runtime.c | 10 ++++++++--
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
> index 14dd3c6..4ce5450 100644
> --- a/Documentation/power/runtime_pm.txt
> +++ b/Documentation/power/runtime_pm.txt
> @@ -54,11 +54,10 @@ referred to as subsystem-level callbacks in what follows.
> By default, the callbacks are always invoked in process context with interrupts
> enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
> to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
> -callbacks should be invoked in atomic context with interrupts disabled
> -(->runtime_idle() is still invoked the default way). This implies that these
> -callback routines must not block or sleep, but it also means that the
> -synchronous helper functions listed at the end of Section 4 can be used within
> -an interrupt handler or in an atomic context.
> +callbacks should be invoked in atomic context with interrupts disabled.
> +This implies that these callback routines must not block or sleep, but it also
> +means that the synchronous helper functions listed at the end of Section 4 can
> +be used within an interrupt handler or in an atomic context.
>
> The subsystem-level suspend callback is _entirely_ _responsible_ for handling
> the suspend of the device as appropriate, which may, but need not include
> @@ -483,6 +482,7 @@ pm_runtime_suspend()
> pm_runtime_autosuspend()
> pm_runtime_resume()
> pm_runtime_get_sync()
> +pm_runtime_put_sync()
> pm_runtime_put_sync_suspend()
>
> 5. Runtime PM Initialization, Device Probing and Removal
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 8dc247c..acb3f83 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -226,11 +226,17 @@ static int rpm_idle(struct device *dev, int rpmflags)
> callback = NULL;
>
> if (callback) {
> - spin_unlock_irq(&dev->power.lock);
> + if (dev->power.irq_safe)
> + spin_unlock(&dev->power.lock);
> + else
> + spin_unlock_irq(&dev->power.lock);
>
> callback(dev);
>
> - spin_lock_irq(&dev->power.lock);
> + if (dev->power.irq_safe)
> + spin_lock(&dev->power.lock);
> + else
> + spin_lock_irq(&dev->power.lock);
> }
>
> dev->power.idle_notification = false;
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-07-23 23:02 ` Rafael J. Wysocki
(?)
@ 2011-07-27 0:28 ` Kevin Hilman
-1 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-07-27 0:28 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, linux-omap, linux-arm-kernel, Colin Cross
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, July 22, 2011, Kevin Hilman wrote:
>> Currently the use of pm_runtime_put_sync() is not safe from
>> interrupts-disabled context because rpm_idle() will release the
>> spinlock and enable interrupts for the idle callbacks. This enables
>> interrupts during a time where interrupts were expected to be
>> disabled, and can have strange side effects on drivers that expected
>> interrupts to be disabled.
>>
>> This is not a bug since the documentation clearly states that only
>> _put_sync_suspend() is safe in IRQ-safe mode.
>>
>> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> mode by releasing the spinlock but not re-enabling interrupts, which
>> is what this patch aims to do.
>>
>> Problem was found when using some buggy drivers that set
>> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> context.
>>
>> The offending drivers have been fixed to use _put_sync_suspend(),
>> But this patch is an RFC to see if it might make sense to allow
>> using _put_sync() from interrupts-disabled context.
>
> OK, I'm going to take this for 3.2.
>
OK, great. Thanks.
Might want to just drop the last paragraph from the changelog since it
doesn't really belong in the permanant history.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-07-23 23:02 ` Rafael J. Wysocki
@ 2011-07-27 0:28 ` Kevin Hilman
-1 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-07-27 0:28 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-pm, linux-omap, linux-arm-kernel, Alan Stern, Colin Cross
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, July 22, 2011, Kevin Hilman wrote:
>> Currently the use of pm_runtime_put_sync() is not safe from
>> interrupts-disabled context because rpm_idle() will release the
>> spinlock and enable interrupts for the idle callbacks. This enables
>> interrupts during a time where interrupts were expected to be
>> disabled, and can have strange side effects on drivers that expected
>> interrupts to be disabled.
>>
>> This is not a bug since the documentation clearly states that only
>> _put_sync_suspend() is safe in IRQ-safe mode.
>>
>> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> mode by releasing the spinlock but not re-enabling interrupts, which
>> is what this patch aims to do.
>>
>> Problem was found when using some buggy drivers that set
>> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> context.
>>
>> The offending drivers have been fixed to use _put_sync_suspend(),
>> But this patch is an RFC to see if it might make sense to allow
>> using _put_sync() from interrupts-disabled context.
>
> OK, I'm going to take this for 3.2.
>
OK, great. Thanks.
Might want to just drop the last paragraph from the changelog since it
doesn't really belong in the permanant history.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
@ 2011-07-27 0:28 ` Kevin Hilman
0 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-07-27 0:28 UTC (permalink / raw)
To: linux-arm-kernel
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, July 22, 2011, Kevin Hilman wrote:
>> Currently the use of pm_runtime_put_sync() is not safe from
>> interrupts-disabled context because rpm_idle() will release the
>> spinlock and enable interrupts for the idle callbacks. This enables
>> interrupts during a time where interrupts were expected to be
>> disabled, and can have strange side effects on drivers that expected
>> interrupts to be disabled.
>>
>> This is not a bug since the documentation clearly states that only
>> _put_sync_suspend() is safe in IRQ-safe mode.
>>
>> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> mode by releasing the spinlock but not re-enabling interrupts, which
>> is what this patch aims to do.
>>
>> Problem was found when using some buggy drivers that set
>> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> context.
>>
>> The offending drivers have been fixed to use _put_sync_suspend(),
>> But this patch is an RFC to see if it might make sense to allow
>> using _put_sync() from interrupts-disabled context.
>
> OK, I'm going to take this for 3.2.
>
OK, great. Thanks.
Might want to just drop the last paragraph from the changelog since it
doesn't really belong in the permanant history.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-07-27 0:28 ` Kevin Hilman
(?)
(?)
@ 2011-07-27 9:22 ` Rafael J. Wysocki
-1 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-07-27 9:22 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-pm, linux-omap, linux-arm-kernel, Colin Cross
On Wednesday, July 27, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Friday, July 22, 2011, Kevin Hilman wrote:
> >> Currently the use of pm_runtime_put_sync() is not safe from
> >> interrupts-disabled context because rpm_idle() will release the
> >> spinlock and enable interrupts for the idle callbacks. This enables
> >> interrupts during a time where interrupts were expected to be
> >> disabled, and can have strange side effects on drivers that expected
> >> interrupts to be disabled.
> >>
> >> This is not a bug since the documentation clearly states that only
> >> _put_sync_suspend() is safe in IRQ-safe mode.
> >>
> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> >> mode by releasing the spinlock but not re-enabling interrupts, which
> >> is what this patch aims to do.
> >>
> >> Problem was found when using some buggy drivers that set
> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> >> context.
> >>
> >> The offending drivers have been fixed to use _put_sync_suspend(),
> >> But this patch is an RFC to see if it might make sense to allow
> >> using _put_sync() from interrupts-disabled context.
> >
> > OK, I'm going to take this for 3.2.
> >
>
> OK, great. Thanks.
>
> Might want to just drop the last paragraph from the changelog since it
> doesn't really belong in the permanant history.
OK
Thanks,
Rafael
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-07-27 0:28 ` Kevin Hilman
@ 2011-07-27 9:22 ` Rafael J. Wysocki
-1 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-07-27 9:22 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-pm, linux-omap, linux-arm-kernel, Alan Stern, Colin Cross
On Wednesday, July 27, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Friday, July 22, 2011, Kevin Hilman wrote:
> >> Currently the use of pm_runtime_put_sync() is not safe from
> >> interrupts-disabled context because rpm_idle() will release the
> >> spinlock and enable interrupts for the idle callbacks. This enables
> >> interrupts during a time where interrupts were expected to be
> >> disabled, and can have strange side effects on drivers that expected
> >> interrupts to be disabled.
> >>
> >> This is not a bug since the documentation clearly states that only
> >> _put_sync_suspend() is safe in IRQ-safe mode.
> >>
> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> >> mode by releasing the spinlock but not re-enabling interrupts, which
> >> is what this patch aims to do.
> >>
> >> Problem was found when using some buggy drivers that set
> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> >> context.
> >>
> >> The offending drivers have been fixed to use _put_sync_suspend(),
> >> But this patch is an RFC to see if it might make sense to allow
> >> using _put_sync() from interrupts-disabled context.
> >
> > OK, I'm going to take this for 3.2.
> >
>
> OK, great. Thanks.
>
> Might want to just drop the last paragraph from the changelog since it
> doesn't really belong in the permanant history.
OK
Thanks,
Rafael
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
@ 2011-07-27 9:22 ` Rafael J. Wysocki
0 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-07-27 9:22 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday, July 27, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Friday, July 22, 2011, Kevin Hilman wrote:
> >> Currently the use of pm_runtime_put_sync() is not safe from
> >> interrupts-disabled context because rpm_idle() will release the
> >> spinlock and enable interrupts for the idle callbacks. This enables
> >> interrupts during a time where interrupts were expected to be
> >> disabled, and can have strange side effects on drivers that expected
> >> interrupts to be disabled.
> >>
> >> This is not a bug since the documentation clearly states that only
> >> _put_sync_suspend() is safe in IRQ-safe mode.
> >>
> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> >> mode by releasing the spinlock but not re-enabling interrupts, which
> >> is what this patch aims to do.
> >>
> >> Problem was found when using some buggy drivers that set
> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> >> context.
> >>
> >> The offending drivers have been fixed to use _put_sync_suspend(),
> >> But this patch is an RFC to see if it might make sense to allow
> >> using _put_sync() from interrupts-disabled context.
> >
> > OK, I'm going to take this for 3.2.
> >
>
> OK, great. Thanks.
>
> Might want to just drop the last paragraph from the changelog since it
> doesn't really belong in the permanant history.
OK
Thanks,
Rafael
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-07-23 23:02 ` Rafael J. Wysocki
` (3 preceding siblings ...)
(?)
@ 2011-08-04 23:29 ` Kevin Hilman
-1 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-08-04 23:29 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, linux-omap, linux-arm-kernel, Colin Cross
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, July 22, 2011, Kevin Hilman wrote:
>> Currently the use of pm_runtime_put_sync() is not safe from
>> interrupts-disabled context because rpm_idle() will release the
>> spinlock and enable interrupts for the idle callbacks. This enables
>> interrupts during a time where interrupts were expected to be
>> disabled, and can have strange side effects on drivers that expected
>> interrupts to be disabled.
>>
>> This is not a bug since the documentation clearly states that only
>> _put_sync_suspend() is safe in IRQ-safe mode.
>>
>> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> mode by releasing the spinlock but not re-enabling interrupts, which
>> is what this patch aims to do.
>>
>> Problem was found when using some buggy drivers that set
>> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> context.
>>
>> The offending drivers have been fixed to use _put_sync_suspend(),
>> But this patch is an RFC to see if it might make sense to allow
>> using _put_sync() from interrupts-disabled context.
>
> OK, I'm going to take this for 3.2.
Rafael,
Since you're planning to merge this, maybe we should consider merging
this as a fix for v3.1, and possibly even for v3.0 stable. That way,
any current drivers using irq_safe and the normal _put_sync() will not
have this problem.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-07-23 23:02 ` Rafael J. Wysocki
@ 2011-08-04 23:29 ` Kevin Hilman
-1 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-08-04 23:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-pm, linux-omap, linux-arm-kernel, Alan Stern, Colin Cross
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, July 22, 2011, Kevin Hilman wrote:
>> Currently the use of pm_runtime_put_sync() is not safe from
>> interrupts-disabled context because rpm_idle() will release the
>> spinlock and enable interrupts for the idle callbacks. This enables
>> interrupts during a time where interrupts were expected to be
>> disabled, and can have strange side effects on drivers that expected
>> interrupts to be disabled.
>>
>> This is not a bug since the documentation clearly states that only
>> _put_sync_suspend() is safe in IRQ-safe mode.
>>
>> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> mode by releasing the spinlock but not re-enabling interrupts, which
>> is what this patch aims to do.
>>
>> Problem was found when using some buggy drivers that set
>> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> context.
>>
>> The offending drivers have been fixed to use _put_sync_suspend(),
>> But this patch is an RFC to see if it might make sense to allow
>> using _put_sync() from interrupts-disabled context.
>
> OK, I'm going to take this for 3.2.
Rafael,
Since you're planning to merge this, maybe we should consider merging
this as a fix for v3.1, and possibly even for v3.0 stable. That way,
any current drivers using irq_safe and the normal _put_sync() will not
have this problem.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
@ 2011-08-04 23:29 ` Kevin Hilman
0 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-08-04 23:29 UTC (permalink / raw)
To: linux-arm-kernel
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, July 22, 2011, Kevin Hilman wrote:
>> Currently the use of pm_runtime_put_sync() is not safe from
>> interrupts-disabled context because rpm_idle() will release the
>> spinlock and enable interrupts for the idle callbacks. This enables
>> interrupts during a time where interrupts were expected to be
>> disabled, and can have strange side effects on drivers that expected
>> interrupts to be disabled.
>>
>> This is not a bug since the documentation clearly states that only
>> _put_sync_suspend() is safe in IRQ-safe mode.
>>
>> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> mode by releasing the spinlock but not re-enabling interrupts, which
>> is what this patch aims to do.
>>
>> Problem was found when using some buggy drivers that set
>> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> context.
>>
>> The offending drivers have been fixed to use _put_sync_suspend(),
>> But this patch is an RFC to see if it might make sense to allow
>> using _put_sync() from interrupts-disabled context.
>
> OK, I'm going to take this for 3.2.
Rafael,
Since you're planning to merge this, maybe we should consider merging
this as a fix for v3.1, and possibly even for v3.0 stable. That way,
any current drivers using irq_safe and the normal _put_sync() will not
have this problem.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-08-04 23:29 ` Kevin Hilman
(?)
(?)
@ 2011-08-05 19:22 ` Rafael J. Wysocki
-1 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-08-05 19:22 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-pm, linux-omap, linux-arm-kernel, Colin Cross
On Friday, August 05, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Friday, July 22, 2011, Kevin Hilman wrote:
> >> Currently the use of pm_runtime_put_sync() is not safe from
> >> interrupts-disabled context because rpm_idle() will release the
> >> spinlock and enable interrupts for the idle callbacks. This enables
> >> interrupts during a time where interrupts were expected to be
> >> disabled, and can have strange side effects on drivers that expected
> >> interrupts to be disabled.
> >>
> >> This is not a bug since the documentation clearly states that only
> >> _put_sync_suspend() is safe in IRQ-safe mode.
> >>
> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> >> mode by releasing the spinlock but not re-enabling interrupts, which
> >> is what this patch aims to do.
> >>
> >> Problem was found when using some buggy drivers that set
> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> >> context.
> >>
> >> The offending drivers have been fixed to use _put_sync_suspend(),
> >> But this patch is an RFC to see if it might make sense to allow
> >> using _put_sync() from interrupts-disabled context.
> >
> > OK, I'm going to take this for 3.2.
>
> Rafael,
>
> Since you're planning to merge this, maybe we should consider merging
> this as a fix for v3.1, and possibly even for v3.0 stable. That way,
> any current drivers using irq_safe and the normal _put_sync() will not
> have this problem.
I think I can push it for 3.1, but I don't think it's stable material.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-08-04 23:29 ` Kevin Hilman
@ 2011-08-05 19:22 ` Rafael J. Wysocki
-1 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-08-05 19:22 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-pm, linux-omap, linux-arm-kernel, Alan Stern, Colin Cross
On Friday, August 05, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Friday, July 22, 2011, Kevin Hilman wrote:
> >> Currently the use of pm_runtime_put_sync() is not safe from
> >> interrupts-disabled context because rpm_idle() will release the
> >> spinlock and enable interrupts for the idle callbacks. This enables
> >> interrupts during a time where interrupts were expected to be
> >> disabled, and can have strange side effects on drivers that expected
> >> interrupts to be disabled.
> >>
> >> This is not a bug since the documentation clearly states that only
> >> _put_sync_suspend() is safe in IRQ-safe mode.
> >>
> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> >> mode by releasing the spinlock but not re-enabling interrupts, which
> >> is what this patch aims to do.
> >>
> >> Problem was found when using some buggy drivers that set
> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> >> context.
> >>
> >> The offending drivers have been fixed to use _put_sync_suspend(),
> >> But this patch is an RFC to see if it might make sense to allow
> >> using _put_sync() from interrupts-disabled context.
> >
> > OK, I'm going to take this for 3.2.
>
> Rafael,
>
> Since you're planning to merge this, maybe we should consider merging
> this as a fix for v3.1, and possibly even for v3.0 stable. That way,
> any current drivers using irq_safe and the normal _put_sync() will not
> have this problem.
I think I can push it for 3.1, but I don't think it's stable material.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
@ 2011-08-05 19:22 ` Rafael J. Wysocki
0 siblings, 0 replies; 20+ messages in thread
From: Rafael J. Wysocki @ 2011-08-05 19:22 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, August 05, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Friday, July 22, 2011, Kevin Hilman wrote:
> >> Currently the use of pm_runtime_put_sync() is not safe from
> >> interrupts-disabled context because rpm_idle() will release the
> >> spinlock and enable interrupts for the idle callbacks. This enables
> >> interrupts during a time where interrupts were expected to be
> >> disabled, and can have strange side effects on drivers that expected
> >> interrupts to be disabled.
> >>
> >> This is not a bug since the documentation clearly states that only
> >> _put_sync_suspend() is safe in IRQ-safe mode.
> >>
> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
> >> mode by releasing the spinlock but not re-enabling interrupts, which
> >> is what this patch aims to do.
> >>
> >> Problem was found when using some buggy drivers that set
> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
> >> context.
> >>
> >> The offending drivers have been fixed to use _put_sync_suspend(),
> >> But this patch is an RFC to see if it might make sense to allow
> >> using _put_sync() from interrupts-disabled context.
> >
> > OK, I'm going to take this for 3.2.
>
> Rafael,
>
> Since you're planning to merge this, maybe we should consider merging
> this as a fix for v3.1, and possibly even for v3.0 stable. That way,
> any current drivers using irq_safe and the normal _put_sync() will not
> have this problem.
I think I can push it for 3.1, but I don't think it's stable material.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-08-05 19:22 ` Rafael J. Wysocki
(?)
@ 2011-08-05 23:40 ` Kevin Hilman
-1 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-08-05 23:40 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, linux-omap, linux-arm-kernel, Colin Cross
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, August 05, 2011, Kevin Hilman wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>> > On Friday, July 22, 2011, Kevin Hilman wrote:
>> >> Currently the use of pm_runtime_put_sync() is not safe from
>> >> interrupts-disabled context because rpm_idle() will release the
>> >> spinlock and enable interrupts for the idle callbacks. This enables
>> >> interrupts during a time where interrupts were expected to be
>> >> disabled, and can have strange side effects on drivers that expected
>> >> interrupts to be disabled.
>> >>
>> >> This is not a bug since the documentation clearly states that only
>> >> _put_sync_suspend() is safe in IRQ-safe mode.
>> >>
>> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> >> mode by releasing the spinlock but not re-enabling interrupts, which
>> >> is what this patch aims to do.
>> >>
>> >> Problem was found when using some buggy drivers that set
>> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> >> context.
>> >>
>> >> The offending drivers have been fixed to use _put_sync_suspend(),
>> >> But this patch is an RFC to see if it might make sense to allow
>> >> using _put_sync() from interrupts-disabled context.
>> >
>> > OK, I'm going to take this for 3.2.
>>
>> Rafael,
>>
>> Since you're planning to merge this, maybe we should consider merging
>> this as a fix for v3.1, and possibly even for v3.0 stable. That way,
>> any current drivers using irq_safe and the normal _put_sync() will not
>> have this problem.
>
> I think I can push it for 3.1, but I don't think it's stable material.
>
OK, fair enough.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
2011-08-05 19:22 ` Rafael J. Wysocki
@ 2011-08-05 23:40 ` Kevin Hilman
-1 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-08-05 23:40 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-pm, linux-omap, linux-arm-kernel, Alan Stern, Colin Cross
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, August 05, 2011, Kevin Hilman wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>> > On Friday, July 22, 2011, Kevin Hilman wrote:
>> >> Currently the use of pm_runtime_put_sync() is not safe from
>> >> interrupts-disabled context because rpm_idle() will release the
>> >> spinlock and enable interrupts for the idle callbacks. This enables
>> >> interrupts during a time where interrupts were expected to be
>> >> disabled, and can have strange side effects on drivers that expected
>> >> interrupts to be disabled.
>> >>
>> >> This is not a bug since the documentation clearly states that only
>> >> _put_sync_suspend() is safe in IRQ-safe mode.
>> >>
>> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> >> mode by releasing the spinlock but not re-enabling interrupts, which
>> >> is what this patch aims to do.
>> >>
>> >> Problem was found when using some buggy drivers that set
>> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> >> context.
>> >>
>> >> The offending drivers have been fixed to use _put_sync_suspend(),
>> >> But this patch is an RFC to see if it might make sense to allow
>> >> using _put_sync() from interrupts-disabled context.
>> >
>> > OK, I'm going to take this for 3.2.
>>
>> Rafael,
>>
>> Since you're planning to merge this, maybe we should consider merging
>> this as a fix for v3.1, and possibly even for v3.0 stable. That way,
>> any current drivers using irq_safe and the normal _put_sync() will not
>> have this problem.
>
> I think I can push it for 3.1, but I don't think it's stable material.
>
OK, fair enough.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
* [linux-pm] [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context
@ 2011-08-05 23:40 ` Kevin Hilman
0 siblings, 0 replies; 20+ messages in thread
From: Kevin Hilman @ 2011-08-05 23:40 UTC (permalink / raw)
To: linux-arm-kernel
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Friday, August 05, 2011, Kevin Hilman wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>> > On Friday, July 22, 2011, Kevin Hilman wrote:
>> >> Currently the use of pm_runtime_put_sync() is not safe from
>> >> interrupts-disabled context because rpm_idle() will release the
>> >> spinlock and enable interrupts for the idle callbacks. This enables
>> >> interrupts during a time where interrupts were expected to be
>> >> disabled, and can have strange side effects on drivers that expected
>> >> interrupts to be disabled.
>> >>
>> >> This is not a bug since the documentation clearly states that only
>> >> _put_sync_suspend() is safe in IRQ-safe mode.
>> >>
>> >> However, pm_runtime_put_sync() could be made safe when in IRQ-safe
>> >> mode by releasing the spinlock but not re-enabling interrupts, which
>> >> is what this patch aims to do.
>> >>
>> >> Problem was found when using some buggy drivers that set
>> >> pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
>> >> context.
>> >>
>> >> The offending drivers have been fixed to use _put_sync_suspend(),
>> >> But this patch is an RFC to see if it might make sense to allow
>> >> using _put_sync() from interrupts-disabled context.
>> >
>> > OK, I'm going to take this for 3.2.
>>
>> Rafael,
>>
>> Since you're planning to merge this, maybe we should consider merging
>> this as a fix for v3.1, and possibly even for v3.0 stable. That way,
>> any current drivers using irq_safe and the normal _put_sync() will not
>> have this problem.
>
> I think I can push it for 3.1, but I don't think it's stable material.
>
OK, fair enough.
Kevin
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-08-05 23:40 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-22 21:46 [RFC/PATCH v2] PM / Runtime: allow _put_sync() from interrupts-disabled context Kevin Hilman
2011-07-22 21:46 ` Kevin Hilman
2011-07-23 23:02 ` Rafael J. Wysocki
2011-07-23 23:02 ` [linux-pm] " Rafael J. Wysocki
2011-07-23 23:02 ` Rafael J. Wysocki
2011-07-27 0:28 ` Kevin Hilman
2011-07-27 0:28 ` [linux-pm] " Kevin Hilman
2011-07-27 0:28 ` Kevin Hilman
2011-07-27 9:22 ` Rafael J. Wysocki
2011-07-27 9:22 ` Rafael J. Wysocki
2011-07-27 9:22 ` Rafael J. Wysocki
2011-08-04 23:29 ` [linux-pm] " Kevin Hilman
2011-08-04 23:29 ` Kevin Hilman
2011-08-05 19:22 ` Rafael J. Wysocki
2011-08-05 19:22 ` Rafael J. Wysocki
2011-08-05 23:40 ` Kevin Hilman
2011-08-05 23:40 ` [linux-pm] " Kevin Hilman
2011-08-05 23:40 ` Kevin Hilman
2011-08-05 19:22 ` Rafael J. Wysocki
2011-08-04 23:29 ` Kevin Hilman
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.