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 illici
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 wor
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 output
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.
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 key
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.)
Thi
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
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
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, 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 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 s
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
th
12 matches
Mail list logo
