On Tue, Jul 01, 2008 at 11:08:47AM +0200, Oliver Neukum wrote: > Am Dienstag 01 Juli 2008 09:59:01 schrieb Jiri Kosina: > > On Tue, 1 Jul 2008, Oliver Neukum wrote: > > > > >> Ok, I see... So what does a device do when it is suspended and a > > >> request comes in? Does it automatically resume and service the request > > >> (and potentially goes back to sleep)? Does it queue the request for > > >> later? Ignore it? Is it a system-wide policy or up to the device > > >> [class]? > > > Return an error. If you queue, how much would you queue? > > > There's no sane answer, so you better fail right away. > > > > I guess that Dmitry's question was about the behavior of the driver, > > right? For example in situation when the LED state changes on PS/2 > > keyboard, what should the USB keyboard driver do for a suspended USB > > keyboard. > > I understood it that way. > > > I really don't think we want to return error in such cases. Either resume > > the device, or queue some requests (maybe depending on the type of > > requests), right? > > We are talking about forcibly suspended devices, so they cannot be > resumed. We could queue, but where would we end queuing? And we > have to decide to stop it at some point, or we create a DoS problem. > > The user has decided to put the device in a state in which the driver > cannot properly function. If the user wanted the driver to work, he should > select autosuspend. > That is the thing with the forced suspend - it leaves device out of sync with the rest of the system. If user really does not want to use the device it should probably be completely disconnected? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
