Am Dienstag, 22. Mai 2007 18:50 schrieb Jiri Kosina:
I think that this is unfortunately not true. Let's take system with
multiple keyboards and their LEDs as an excellent example again. If you
kill the interrupt URB, there is nothing what will prevent other keyboard
(PS/2 or even USB
Am Dienstag, 22. Mai 2007 19:18 schrieb Alan Stern:
On Tue, 22 May 2007, Oliver Neukum wrote:
Yes, but if you are in pre_reset, chances are something is wrong
with the devices. Outright slaughter of all outstanding URBs is better
than waiting for them to complete.
Fair enough. I
Am Dienstag, 22. Mai 2007 18:50 schrieb Jiri Kosina:
On Tue, 22 May 2007, Alan Stern wrote:
But if you kill the interrupt URB then there will be no more inputs and
hence nothing to generate any more output. Thus, when suspending you
should kill the inputs and wait for the outputs to
On Wed, 23 May 2007, Oliver Neukum wrote:
That gives me an idea.
Resumption of a device has to be done in task context. So if I allocate
a private freezable work queue for HID resumption, the freezer would
guard against illicit resumptions, wouldn't it?
You can use the ksuspend_usb_wq
Am Mittwoch, 23. Mai 2007 17:42 schrieb Alan Stern:
On Wed, 23 May 2007, Oliver Neukum wrote:
That gives me an idea.
Resumption of a device has to be done in task context. So if I allocate
a private freezable work queue for HID resumption, the freezer would
guard against illicit
Hi,
this is the newest version of autosuspend for HID devices. It fixes:
- Pete: removal of dead members of a struct
- Alan: open/suspend race
- Jiri: PID devices are exempt
- Jiri: any device that is served by hiddev is exempt
- fixed a race between close and resume
- proper error handling in
On Tue, 22 May 2007, Oliver Neukum wrote:
- Jiri, is there a _category_ of HID devices that should not be
autosuspended at all?
Hi Oliver,
thanks for updating the patch. I am not quite sure right now whether I can
come up with a category that should not be suspended at all, but I will
Am Dienstag, 22. Mai 2007 13:28 schrieb Jiri Kosina:
Hi,
There is a principal issue. What is to be done with output requests?
Starting the queue as soon as one arrives seems the safest thing to do,
but it is fatal in a subset of situations, that is, it must not be done
during
On Tue, 22 May 2007, Oliver Neukum wrote:
- Alan, do you have strong feelings about putting all conditions
for failing to suspend into one condition? I consider it conceptually
cleaner to have seperate branches for wanting to check for failure
It looks like you've got two conditions for
Am Dienstag, 22. Mai 2007 16:59 schrieb Alan Stern:
On Tue, 22 May 2007, Oliver Neukum wrote:
On the other hand, I still think you'd be better off with only one
spin_lock_irq() call in hid_suspend(). After all, you always have to
synchronize with the error handler, no matter what kind of
On Tue, 22 May 2007, Alan Stern wrote:
But if you kill the interrupt URB then there will be no more inputs and
hence nothing to generate any more output. Thus, when suspending you
should kill the inputs and wait for the outputs to drain (or else
explicitly plug the output queue). Then it
On Tue, 22 May 2007, Oliver Neukum wrote:
TODO
- pre/post_reset is currently broken, it can no longer be a parasite
on suspend/resume
Why not? The only difference I can see is that you're allowed to fail
a suspend but not a pre_reset.
Yes, but if you are in pre_reset,
On Tue, 22 May 2007, Alan Stern wrote:
- adapt to hibernate
What adaptations are needed?
Do I need to kill remote wakeup?
No. It should be handled at a higher level. (Right now we don't
really handle it properly; this is partly the fault of the PM core.)
This isn't is bad
13 matches
Mail list logo
