-power.entry, dpm_locked);
- mutex_unlock(dpm_list_mtx);
break;
}
mutex_lock(dpm_list_mtx);
Acked-by: Alan Stern [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message
that the kobject is still registered, then you also
know that there is already a reference to it. So you have no reason to
take an additional reference.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo
, then the routine should only be called directly or indirectly
from a suspend or resume method or from the suspend or resume core.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
to change anything.
The USB autosuspend code affects only the controller's USB interface --
it doesn't touch the PCI side. An autosuspended controller will remain
in D0. Until somebody tries writing autosuspend code for PCI
devices...
Alan Stern
-
To unsubscribe from this list: send the line
On Wed, 9 Jan 2008, Carlos Corbacho wrote:
On Wednesday 09 January 2008 16:07:04 Alan Stern wrote:
Currently there's no need to change anything.
Ok.
The USB autosuspend code affects only the controller's USB interface --
it doesn't touch the PCI side. An autosuspended controller
for destroy_suspended_device() should contain an
extra paragraph warning that the routine should never be called except
within the scope of a system sleep transition. In practice this means
it has to be directly or indirectly invoked by a suspend or resume
method.
It looks good.
Alan Stern
details. Once we have settled on the correct
approach for 1-4, the implementation should be relatively easy.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
violation. With an
asynchronous approach, on the other hand, this wouldn't be a problem.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
On Monday, 7 of January 2008, Alan Stern wrote:
On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
Please see the patch at: http://lkml.org/lkml/2008/1/6/298 . It
represents my
current idea about how to do that.
It has some problems
leaning towards the asynchronous approach.
I'll prepare a new patch and send it later today.
Okay.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
are (1) messing up the PM device list pointers, and
(2) calling a driver's suspend/resume methods while its remove method
is running. (1) is handled by the pm_list_mutex and (2) is handled by
locking dev-sem.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi
wrong with it. All that will happen is that the
removal will start before the suspend and finish after the resume.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
On Saturday, 5 of January 2008, Alan Stern wrote:
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
Another thing to watch out for: Just in case somebody ends up calling
destroy_suspended_device(dev) from within dev's own resume method, you
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
On Saturday, 5 of January 2008, Alan Stern wrote:
On Sat, 5 Jan 2008, Rafael J. Wysocki wrote:
Still, even doing that is not enough, since someone can call
destroy_suspended_device() from a .suspend() routine and then the device
will end
to unregister_dropped_devices()
in the error path of device_suspend() -- in theory even an aborted
suspend might cause a device to malfunction.
Otherwise this looks okay.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED
-pm-acquire-device-locks-prior-to-suspending.patch
installed. That patch conflicts with this one.
One of the these two patches will have to be rewritten to apply on top
of the other. Which do you think should be changed?
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe
or after tasks leave the freezer? -- I'm not sure.)
So the idea is send appropriate announcements at the usual time for
CPUs that do come back up normally, and don't send anything right away
for CPUs that fail to come up. Just keep track of which ones failed,
and then later take care of them.
Alan
it was
beforehand? Is any special handling needed for this, or is it already
accounted for?
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
, and when the call returns the system has already left
that state. But with a low-performance On state, when the call returns
the system will still be in the new state.
Is the PM core prepared to handle this difference?
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux
-performance run state? Or should that
be handled automatically within the kernel?
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Restarting tasks... show this, and the last two lines show the root
hub's interface being resumed.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
would handle it already.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
a user's point of view, I get the feeling that plug and unplug
aren't useful wakeup events. But I may be wrong... and desktop users
are likely to have different requirements from laptop users.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message
the
target state) that it can pass to the provider.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-- and I think a cookie would be better than a
struct.
There are other possible ways to disseminate the information. The
details don't matter much, and relatively few drivers would care.
However the form of the information is a legitimate concern at this
point.
Alan Stern
-
To unsubscribe from
On Thu, 21 Jun 2007, David Brownell wrote:
On Thursday 21 June 2007, Alan Stern wrote:
On Thu, 21 Jun 2007, David Brownell wrote:
If a driver wants to find out whether some resource will be available
in the target system state, the only way is to ask the resource's
provider
On Thu, 21 Jun 2007, Rafael J. Wysocki wrote:
Does anyone have any objections to adding a new pm_op that will tell
the ACPI core (or generally, a platform core code) what target system sleep
state we are going to enter?
Go for it!
Alan Stern
-
To unsubscribe from this list: send the line
or whether wakeup should be enabled?
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
and immediate resume. To reduce
the amount of clutter you might want to rmmod uhci-hcd before starting
the test.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
try turning off the HAL
daemon and renaming the usblp.ko file so that it won't get loaded
automatically. Then after plugging in the printer you could insmod the
renamed driver file by hand, and see whether that causes the oops. Then
start HAL by hand and see whether that causes the oops.
Alan Stern
really works on that. Would be nice if someone gives this a
try...
Alan Stern has been working on USB autosuspend for quite some time
and there are some patches in -mm and in the recent mainline, AFAICT.
Rafael is right. 2.6.19-rc1 already contains code that will suspend ports
if the attached
another reason not to do this: Power Management Event handling for
PCI devices isn't working. So the controller would not automatically go
back into D0 when you plugged in a new USB device.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message
be set to 0, so that the routine will
call down_trylock() instead of down() or schedule_timeout_interruptible().
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
compile.
Along with the other changes to include/acpi/platform/aclinux.h, you need
to define acpi_size. The easiest way is to #include acpi/actypes.h and
then remove the unneeded definitions of acpi_cpu_flags and acpi_thread_id.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe
in e-mail, or the one checked into git?
My appologies if they don't match. I've compiled
this into a few dozen kernels at this point.
I was referring to the patch in the email.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message
report. Let's continue
further discussion there, off-list.
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
on
a patch for ACPI (a couple of routines that make blocking calls with
interrupts disabled) and I'd like to know what to do with it. Should I
just send it to Len and linux-acpi as is?
Alan Stern
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message
On Thu, 6 Apr 2006, Bjorn Helgaas wrote:
Alan, could you give me a hint about what you mean? ACPI doesn't
ioremap device registers, so I'm not sure what the problem is.
After posting the above request to the linux-usb list, Alan Stern
responded
38 matches
Mail list logo
