> > What's the purpose of the card-counting loop in
> > host/omap.c:mmc_omap_switch_handler()? It looks like dead code.
> >
>
> I'm not too familiar with that driver, but they've been playing around
> with multiplexing several cards into one controller. Might be bits and
> pieces of that.
>
On Mon, 25 Feb 2008, Pierre Ossman wrote:
> > What do you think of the patch attached to comment #40 in the Bugzilla
> > entry?
> >
>
> Looks ok. As long as those two synchronization points are guaranteed,
> then I'm happy.
Maybe a better approach would be to leave the workqueue unfreezable,
On Mon, 25 Feb 2008 12:58:30 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> Thanks for the explanations.
>
> On Mon, 25 Feb 2008, Pierre Ossman wrote:
>
> > Trying to keep up with the PM changes is a full time job. For now I've
> > mostly ignored it as I don't even have time for the other
Thanks for the explanations.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
> Trying to keep up with the PM changes is a full time job. For now I've
> mostly ignored it as I don't even have time for the other stuff.
> Patches welcome.
What do you think of the patch attached to comment #40 in the
On Sun, 24 Feb 2008 10:33:34 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
>
> Well, the patch itself isn't really adequate; it was just a first pass
> intended to illustrate the nature of the problem.
>
> The problems in the MMC subsystem go deeper.
>
> The first is the way it uses
On Mon, 25 Feb 2008, Pavel Machek wrote:
> Hi!
>
> Alan thinks that `subj` is correct...
More precisely, reads and writes of pointers are always atomic. That
is, if a write and a read occur concurrently, it is guaranteed that the
read will obtain either the old or the new value of the
On Monday, 25 of February 2008, Zdenek Kabelac wrote:
> Hi
Hi,
[CCs restored, added CC to Dave]
> I'm finally going to test some kernel - because I'd been trying it
> against the HEAD - but unfortunately it looks like there is something
> seriously broken with -rc3 and sata merge - anyway -
On Monday, 25 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
> > > Very subtly wrong ;-).
> > >
> > > imagine suspending_task == 0xabcdef01. Now task "R" with current ==
> > > 0xabcd reads suspending_task while the other cpu is writing to it,
> > > and
On Monday, 25 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Pavel Machek wrote:
>
> > > > At the very least, you'd need rmb() before reading it and wmb() after
> > > > writing to it, but I'm not sure if that's enough on every obscure
> > > > architecture out there.
> > >
> > > No,
Hi!
Alan thinks that `subj` is correct...
> > > > At the very least, you'd need rmb() before reading it and wmb() after
> > > > writing to it, but I'm not sure if that's enough on every obscure
> > > > architecture out there.
> > >
> > > No, neither one is needed because of the way
On Monday, 25 of February 2008, Alan Stern wrote:
On Sun, 24 Feb 2008, Pavel Machek wrote:
At the very least, you'd need rmb() before reading it and wmb() after
writing to it, but I'm not sure if that's enough on every obscure
architecture out there.
No, neither one is needed
On Monday, 25 of February 2008, Alan Stern wrote:
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
Very subtly wrong ;-).
imagine suspending_task == 0xabcdef01. Now task R with current ==
0xabcd reads suspending_task while the other cpu is writing to it,
and sees 0xabcd
Hi!
Alan thinks that `subj` is correct...
At the very least, you'd need rmb() before reading it and wmb() after
writing to it, but I'm not sure if that's enough on every obscure
architecture out there.
No, neither one is needed because of the way suspending_task is used.
On Monday, 25 of February 2008, Zdenek Kabelac wrote:
Hi
Hi,
[CCs restored, added CC to Dave]
I'm finally going to test some kernel - because I'd been trying it
against the HEAD - but unfortunately it looks like there is something
seriously broken with -rc3 and sata merge - anyway - I'm
On Mon, 25 Feb 2008, Pavel Machek wrote:
Hi!
Alan thinks that `subj` is correct...
More precisely, reads and writes of pointers are always atomic. That
is, if a write and a read occur concurrently, it is guaranteed that the
read will obtain either the old or the new value of the pointer,
On Sun, 24 Feb 2008 10:33:34 -0500 (EST)
Alan Stern [EMAIL PROTECTED] wrote:
Well, the patch itself isn't really adequate; it was just a first pass
intended to illustrate the nature of the problem.
The problems in the MMC subsystem go deeper.
The first is the way it uses
Thanks for the explanations.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
Trying to keep up with the PM changes is a full time job. For now I've
mostly ignored it as I don't even have time for the other stuff.
Patches welcome.
What do you think of the patch attached to comment #40 in the
On Mon, 25 Feb 2008 12:58:30 -0500 (EST)
Alan Stern [EMAIL PROTECTED] wrote:
Thanks for the explanations.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
Trying to keep up with the PM changes is a full time job. For now I've
mostly ignored it as I don't even have time for the other stuff.
On Mon, 25 Feb 2008, Pierre Ossman wrote:
What do you think of the patch attached to comment #40 in the Bugzilla
entry?
Looks ok. As long as those two synchronization points are guaranteed,
then I'm happy.
Maybe a better approach would be to leave the workqueue unfreezable,
and keep
snip
What's the purpose of the card-counting loop in
host/omap.c:mmc_omap_switch_handler()? It looks like dead code.
I'm not too familiar with that driver, but they've been playing around
with multiplexing several cards into one controller. Might be bits and
pieces of that.
AFAIK,
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > Very subtly wrong ;-).
> >
> > imagine suspending_task == 0xabcdef01. Now task "R" with current ==
> > 0xabcd reads suspending_task while the other cpu is writing to it,
> > and sees 0xabcd (0xef01 was not yet written) -- and mistakenly
>
On Sun, 24 Feb 2008, Pavel Machek wrote:
> > > At the very least, you'd need rmb() before reading it and wmb() after
> > > writing to it, but I'm not sure if that's enough on every obscure
> > > architecture out there.
> >
> > No, neither one is needed because of the way suspending_task is used.
On Sunday, 24 of February 2008, Pavel Machek wrote:
> On Sun 2008-02-24 15:33:01, Alan Stern wrote:
> > On Sun, 24 Feb 2008, Pavel Machek wrote:
> >
> > > > > What locking protects this variable? What happens when suspending_task
> > > > > exits? (Hmm, that would probably be bug, anyway?)
> > > >
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Remove the code that acquires all device semaphores from the suspend
> > code path as it causes multiple problems to appear (most notably,
>
On Sun 2008-02-24 15:33:01, Alan Stern wrote:
> On Sun, 24 Feb 2008, Pavel Machek wrote:
>
> > > > What locking protects this variable? What happens when suspending_task
> > > > exits? (Hmm, that would probably be bug, anyway?)
> > >
> > > It's protected by whatever existing locking scheme
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Remove the code that acquires all device semaphores from the suspend
> code path as it causes multiple problems to appear (most notably,
> http://bugzilla.kernel.org/show_bug.cgi?id=10030) and revert
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Remove the code that acquires all device semaphores from the suspend
> > code path as it causes multiple problems to appear (most notably,
>
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Remove the code that acquires all device semaphores from the suspend
> code path as it causes multiple problems to appear (most notably,
> http://bugzilla.kernel.org/show_bug.cgi?id=10030) and revert
On Sun, 24 Feb 2008, Pavel Machek wrote:
> > > What locking protects this variable? What happens when suspending_task
> > > exits? (Hmm, that would probably be bug, anyway?)
> >
> > It's protected by whatever existing locking scheme allows only one
> > task to start a system sleep at a time.
On Sunday, 24 of February 2008, Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Alan Stern wrote:
> > On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> >
> > > On Sunday, 24 of February 2008, Alan Stern wrote:
> > > > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> > > >
> > > > >
On Sunday, 24 of February 2008, Zdenek Kabelac wrote:
> 2008/2/24, Alan Stern <[EMAIL PROTECTED]>:
> > On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> >
> >
> > > > You know, with this new patch we probably don't need
> > > > device_pm_schedule_removal() any more.
> > >
> > > No, we don't.
Hi!
> > > @@ -25,6 +25,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include "../base.h"
> > > #include "power.h"
> > > @@ -59,6 +60,13 @@ static DECLARE_RWSEM(pm_sleep_rwsem);
> > >
> > > int (*platform_enable_wakeup)(struct device *dev, int is_on);
2008/2/24, Alan Stern <[EMAIL PROTECTED]>:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
>
> > > You know, with this new patch we probably don't need
> > > device_pm_schedule_removal() any more.
> >
> > No, we don't. However, because of that dpm_suspend() and
> device_power_down()
> >
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > You know, with this new patch we probably don't need
> > device_pm_schedule_removal() any more.
>
> No, we don't. However, because of that dpm_suspend() and device_power_down()
> need to be changed not to assume that the removed devices will
On Sun, 24 Feb 2008, Pavel Machek wrote:
> Hi!
>
> > Index: usb-2.6/drivers/base/power/main.c
> > ===
> > --- usb-2.6.orig/drivers/base/power/main.c
> > +++ usb-2.6/drivers/base/power/main.c
> > @@ -25,6 +25,7 @@
> > #include
> >
Hi!
> Index: usb-2.6/drivers/base/power/main.c
> ===
> --- usb-2.6.orig/drivers/base/power/main.c
> +++ usb-2.6/drivers/base/power/main.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > In fact this turns out to be exactly the problem with the MMC
> > subsystem. It uses a dedicated workqueue (kmmcd) to handle state
> > changes, and mmc_suspend_host() does a flush_workqueue(). If the
> > workqueue contains an entry to register
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sat, 23 Feb 2008, Alan Stern wrote:
>
> > It happened in a workqueue. There could be lots of similar cases: Some
> > interrupt-driven event causes a hotplug action. Since the action can't
> > be carried out in interrupt context, the
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> > On Sunday, 24 of February 2008, Alan Stern wrote:
> > > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > > I still have no clear idea about what's going on with the ACPI bug in
> > > #9874.
>
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
>
> > On Sunday, 24 of February 2008, Alan Stern wrote:
> > > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> > >
> > > > Ultimately no, it's not. However, we are now late in the -rc2 time
> > > >
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
Ultimately no, it's not. However, we are now late in the -rc2 time
frame and
the
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
I still have no clear idea about what's going on with the ACPI bug in
#9874.
It seems
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sat, 23 Feb 2008, Alan Stern wrote:
It happened in a workqueue. There could be lots of similar cases: Some
interrupt-driven event causes a hotplug action. Since the action can't
be carried out in interrupt context, the driver has no
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
In fact this turns out to be exactly the problem with the MMC
subsystem. It uses a dedicated workqueue (kmmcd) to handle state
changes, and mmc_suspend_host() does a flush_workqueue(). If the
workqueue contains an entry to register or
Hi!
Index: usb-2.6/drivers/base/power/main.c
===
--- usb-2.6.orig/drivers/base/power/main.c
+++ usb-2.6/drivers/base/power/main.c
@@ -25,6 +25,7 @@
#include linux/pm.h
#include linux/resume-trace.h
#include linux/rwsem.h
On Sun, 24 Feb 2008, Pavel Machek wrote:
Hi!
Index: usb-2.6/drivers/base/power/main.c
===
--- usb-2.6.orig/drivers/base/power/main.c
+++ usb-2.6/drivers/base/power/main.c
@@ -25,6 +25,7 @@
#include linux/pm.h
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
You know, with this new patch we probably don't need
device_pm_schedule_removal() any more.
No, we don't. However, because of that dpm_suspend() and device_power_down()
need to be changed not to assume that the removed devices will end up on
2008/2/24, Alan Stern [EMAIL PROTECTED]:
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
You know, with this new patch we probably don't need
device_pm_schedule_removal() any more.
No, we don't. However, because of that dpm_suspend() and
device_power_down()
need to be changed
Hi!
@@ -25,6 +25,7 @@
#include linux/pm.h
#include linux/resume-trace.h
#include linux/rwsem.h
+#include linux/sched.h
#include ../base.h
#include power.h
@@ -59,6 +60,13 @@ static DECLARE_RWSEM(pm_sleep_rwsem);
int (*platform_enable_wakeup)(struct
On Sunday, 24 of February 2008, Zdenek Kabelac wrote:
2008/2/24, Alan Stern [EMAIL PROTECTED]:
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
You know, with this new patch we probably don't need
device_pm_schedule_removal() any more.
No, we don't. However, because of that
On Sunday, 24 of February 2008, Rafael J. Wysocki wrote:
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
Ultimately no, it's not.
On Sun, 24 Feb 2008, Pavel Machek wrote:
What locking protects this variable? What happens when suspending_task
exits? (Hmm, that would probably be bug, anyway?)
It's protected by whatever existing locking scheme allows only one
task to start a system sleep at a time. For example,
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove the code that acquires all device semaphores from the suspend
code path as it causes multiple problems to appear (most notably,
http://bugzilla.kernel.org/show_bug.cgi?id=10030) and revert the
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove the code that acquires all device semaphores from the suspend
code path as it causes multiple problems to appear (most notably,
http://bugzilla.kernel.org/show_bug.cgi?id=10030) and revert the
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove the code that acquires all device semaphores from the suspend
code path as it causes multiple problems to appear (most notably,
On Sun 2008-02-24 15:33:01, Alan Stern wrote:
On Sun, 24 Feb 2008, Pavel Machek wrote:
What locking protects this variable? What happens when suspending_task
exits? (Hmm, that would probably be bug, anyway?)
It's protected by whatever existing locking scheme allows only one
On Sunday, 24 of February 2008, Pavel Machek wrote:
On Sun 2008-02-24 15:33:01, Alan Stern wrote:
On Sun, 24 Feb 2008, Pavel Machek wrote:
What locking protects this variable? What happens when suspending_task
exits? (Hmm, that would probably be bug, anyway?)
It's
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove the code that acquires all device semaphores from the suspend
code path as it causes multiple problems to appear (most notably,
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
Very subtly wrong ;-).
imagine suspending_task == 0xabcdef01. Now task R with current ==
0xabcd reads suspending_task while the other cpu is writing to it,
and sees 0xabcd (0xef01 was not yet written) -- and mistakenly
believes
On Sun, 24 Feb 2008, Pavel Machek wrote:
At the very least, you'd need rmb() before reading it and wmb() after
writing to it, but I'm not sure if that's enough on every obscure
architecture out there.
No, neither one is needed because of the way suspending_task is used.
It's
On Sat, 23 Feb 2008, Alan Stern wrote:
> It happened in a workqueue. There could be lots of similar cases: Some
> interrupt-driven event causes a hotplug action. Since the action can't
> be carried out in interrupt context, the driver has no choice but to
> defer it to a workqueue or kernel
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Alan Stern wrote:
> > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> >
> > > Ultimately no, it's not. However, we are now late in the -rc2 time frame
> > > and
> > > the release of -rc3 seems to be imminent. At
On Sunday, 24 of February 2008, Alan Stern wrote:
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > Ultimately no, it's not. However, we are now late in the -rc2 time frame
> > and
> > the release of -rc3 seems to be imminent. At this point, IMO, that's the
> > safest thing to do. BTW,
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> Ultimately no, it's not. However, we are now late in the -rc2 time frame and
> the release of -rc3 seems to be imminent. At this point, IMO, that's the
> safest thing to do. BTW, appended is the patch I'd like to get applied.
In the interest of
On Saturday, 23 of February 2008, Alan Stern wrote:
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > Unfortunately, I missed your Bugzilla comment at
> > http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28
>
> Strange... But obviously you did see it eventually.
>
> > Well, in the face of
On Saturday, 23 of February 2008, Alan Stern wrote:
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
Unfortunately, I missed your Bugzilla comment at
http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28
Strange... But obviously you did see it eventually.
Well, in the face of it, I'm
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
Ultimately no, it's not. However, we are now late in the -rc2 time frame and
the release of -rc3 seems to be imminent. At this point, IMO, that's the
safest thing to do. BTW, appended is the patch I'd like to get applied.
In the interest of
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
Ultimately no, it's not. However, we are now late in the -rc2 time frame
and
the release of -rc3 seems to be imminent. At this point, IMO, that's the
safest thing to do. BTW, appended is
On Sun, 24 Feb 2008, Rafael J. Wysocki wrote:
On Sunday, 24 of February 2008, Alan Stern wrote:
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
Ultimately no, it's not. However, we are now late in the -rc2 time frame
and
the release of -rc3 seems to be imminent. At this point,
On Sat, 23 Feb 2008, Alan Stern wrote:
It happened in a workqueue. There could be lots of similar cases: Some
interrupt-driven event causes a hotplug action. Since the action can't
be carried out in interrupt context, the driver has no choice but to
defer it to a workqueue or kernel
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> Unfortunately, I missed your Bugzilla comment at
> http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28
Strange... But obviously you did see it eventually.
> Well, in the face of it, I'm considering to remove the code that
> acquires device
On Friday, 22 of February 2008, Alan Stern wrote:
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
>
> > BTW, below is a simplified version of the patch, without the mutex
> > protecting
> > suspending_task. I'd like to push it upstream if it looks good.
>
> It does look good. Go ahead and
On Friday, 22 of February 2008, Alan Stern wrote:
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
BTW, below is a simplified version of the patch, without the mutex
protecting
suspending_task. I'd like to push it upstream if it looks good.
It does look good. Go ahead and push.
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
Unfortunately, I missed your Bugzilla comment at
http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28
Strange... But obviously you did see it eventually.
Well, in the face of it, I'm considering to remove the code that
acquires device
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> > > --- linux-2.6.orig/drivers/base/core.c
> > > +++ linux-2.6/drivers/base/core.c
> > > @@ -929,6 +929,11 @@ void device_del(struct device *dev)
> > > struct device *parent = dev->parent;
> > > struct class_interface *class_intf;
> > >
> > >
On Thursday, 21 of February 2008, Alan Stern wrote:
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
>
> > > > +bool in_suspend_context(void)
> > > > +{
> > > > + bool result;
> > > > +
> > > > + mutex_lock(_task_mtx);
> > > > + result = (suspending_task == current);
> > > > +
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> > > +bool in_suspend_context(void)
> > > +{
> > > + bool result;
> > > +
> > > + mutex_lock(_task_mtx);
> > > + result = (suspending_task == current);
> > > + mutex_unlock(_task_mtx);
> > > + return result;
> > > +}
> >
> > If suspending_task ==
On Thursday, 21 of February 2008, Alan Stern wrote:
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
+bool in_suspend_context(void)
+{
+ bool result;
+
+ mutex_lock(suspending_task_mtx);
+ result = (suspending_task == current);
+
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
+bool in_suspend_context(void)
+{
+ bool result;
+
+ mutex_lock(suspending_task_mtx);
+ result = (suspending_task == current);
+ mutex_unlock(suspending_task_mtx);
+ return result;
+}
If suspending_task == current then
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -929,6 +929,11 @@ void device_del(struct device *dev)
struct device *parent = dev-parent;
struct class_interface *class_intf;
+ if
On Wednesday, 20 of February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
>
> > Well, below is an uncompiled and untested but illustrating the idea that
> > might allow people not to bother with device_pm_schedule_removal()
> > explicitly and can fix the issue at hand.
On Wednesday, 20 of February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
>
> > Well, below is an uncompiled and untested but illustrating the idea that
> > might allow people not to bother with device_pm_schedule_removal()
> > explicitly and can fix the issue at hand.
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> Well, below is an uncompiled and untested but illustrating the idea that
> might allow people not to bother with device_pm_schedule_removal()
> explicitly and can fix the issue at hand.
>
> [There are some cases that need handling and are not
On Wednesday, 20 of February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, Pierre Ossman wrote:
>
> > > And why not simply fail the suspend if the resume routine doesn't exist
> > > and the suspend routine does? Maybe with an error message in the
> > > system log.
> >
> > For the asymmetric
On Wed, 20 Feb 2008, Pierre Ossman wrote:
> > And why not simply fail the suspend if the resume routine doesn't exist
> > and the suspend routine does? Maybe with an error message in the
> > system log.
>
> For the asymmetric case, I guess that would do. But I still want to remove
> devices
On Wednesday, 20 of February 2008, Pierre Ossman wrote:
> On Wed, 20 Feb 2008 14:26:16 -0500 (EST)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> >
> > Do I understand this correctly? You've got special handling for the
> > case where a bus handler doesn't have a resume routine, but no special
>
On Wed, 20 Feb 2008 14:26:16 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
>
> Do I understand this correctly? You've got special handling for the
> case where a bus handler doesn't have a resume routine, but no special
> handling for the case where it doesn't have a suspend routine?
On Wed, 20 Feb 2008, Pierre Ossman wrote:
> Not really. But you have some things confused. What it checks is if
> the mmc bus handler (not a proper driver model, just a way of
> separating the MMC, SD and SDIO stuff) has a resume function. And if
> it doesn't, it removes the card (since it cannot
On Wed, 20 Feb 2008 11:42:56 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > --- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 ---
> > Thanks a lot for the debugging work!
> >
> > First, the patch triggers, which means that the problem discovered by Alan
> > is
> >
On Tue, 19 Feb 2008 [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=10030
>
>
>
>
>
> --- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 ---
> Thanks a lot for the debugging work!
>
> First, the patch triggers, which means that the problem discovered by
On Tue, 19 Feb 2008 [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=10030
--- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 ---
Thanks a lot for the debugging work!
First, the patch triggers, which means that the problem discovered by Alan is
On Wed, 20 Feb 2008 11:42:56 -0500 (EST)
Alan Stern [EMAIL PROTECTED] wrote:
--- Comment #14 from [EMAIL PROTECTED] 2008-02-19 15:23 ---
Thanks a lot for the debugging work!
First, the patch triggers, which means that the problem discovered by Alan
is
troubling us.
On Wed, 20 Feb 2008, Pierre Ossman wrote:
Not really. But you have some things confused. What it checks is if
the mmc bus handler (not a proper driver model, just a way of
separating the MMC, SD and SDIO stuff) has a resume function. And if
it doesn't, it removes the card (since it cannot
On Wed, 20 Feb 2008 14:26:16 -0500 (EST)
Alan Stern [EMAIL PROTECTED] wrote:
Do I understand this correctly? You've got special handling for the
case where a bus handler doesn't have a resume routine, but no special
handling for the case where it doesn't have a suspend routine?
Hmm...
On Wednesday, 20 of February 2008, Pierre Ossman wrote:
On Wed, 20 Feb 2008 14:26:16 -0500 (EST)
Alan Stern [EMAIL PROTECTED] wrote:
Do I understand this correctly? You've got special handling for the
case where a bus handler doesn't have a resume routine, but no special
handling
On Wed, 20 Feb 2008, Pierre Ossman wrote:
And why not simply fail the suspend if the resume routine doesn't exist
and the suspend routine does? Maybe with an error message in the
system log.
For the asymmetric case, I guess that would do. But I still want to remove
devices when the
On Wednesday, 20 of February 2008, Alan Stern wrote:
On Wed, 20 Feb 2008, Pierre Ossman wrote:
And why not simply fail the suspend if the resume routine doesn't exist
and the suspend routine does? Maybe with an error message in the
system log.
For the asymmetric case, I guess
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
Well, below is an uncompiled and untested but illustrating the idea that
might allow people not to bother with device_pm_schedule_removal()
explicitly and can fix the issue at hand.
[There are some cases that need handling and are not covered
On Wednesday, 20 of February 2008, Alan Stern wrote:
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
Well, below is an uncompiled and untested but illustrating the idea that
might allow people not to bother with device_pm_schedule_removal()
explicitly and can fix the issue at hand.
On Wednesday, 20 of February 2008, Alan Stern wrote:
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
Well, below is an uncompiled and untested but illustrating the idea that
might allow people not to bother with device_pm_schedule_removal()
explicitly and can fix the issue at hand.
1 - 100 of 104 matches
Mail list logo
