Re: [rft]power management for usbtouch

On Tue, Jul 01, 2008 at 06:57:01PM +0200, Oliver Neukum wrote:

Am Dienstag 01 Juli 2008 14:56:30 schrieb Dmitry Torokhov:

quoted

On Tue, Jul 01, 2008 at 11:08:47AM +0200, Oliver Neukum wrote:

quoted

Am Dienstag 01 Juli 2008 09:59:01 schrieb Jiri Kosina:

quoted

quoted

quoted

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?

Yes, therefore I suggested doing the logical disconnect.

Would the persistence flag affect this? That is would the forced
suspend cause a reset_resume instead if the driver supports it?

-- 
Ville Syrjälä
syrjala-ORSVBvAovxo@public.gmane.org
http://www.sci.fi/~syrjala/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 1 Jul 2008, Ville Syrjälä wrote:

quoted

quoted

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?

Yes, therefore I suggested doing the logical disconnect.

Would the persistence flag affect this? That is would the forced
suspend cause a reset_resume instead if the driver supports it?

There are only two reasons why a reset-resume might occur:

	A normal resume couldn't be carried out (for example, if
	the USB host controller had to be reset) or failed;

	The RESET_RESUME quirk flag is set for the device.

The first reason doesn't apply if the usb_persist flag isn't set, but 
the second reason does.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html