[Xen-devel] Re: [linux-usb-devel] Error recovery in Xen's paravirtualizing USB driver for Linux - Harry Butterworth - com.xensource.lists.xen-devel

17 messages in com.xensource.lists.xen-devel[Xen-devel] Re: [linux-usb-devel] Err...

From	Sent On	Attachments
harry	07 Dec 2005 10:30
Alan Stern	07 Dec 2005 11:34
Harry Butterworth	07 Dec 2005 14:14
Pete Zaitcev	07 Dec 2005 15:00
Harry Butterworth	07 Dec 2005 15:24
Alan Stern	08 Dec 2005 07:19
Harry Butterworth	08 Dec 2005 07:59
Alan Stern	08 Dec 2005 08:20
Harry Butterworth	08 Dec 2005 09:40
Alan Stern	08 Dec 2005 10:53
Harry Butterworth	08 Dec 2005 14:24
Greg KH	08 Dec 2005 16:43
Harry Butterworth	09 Dec 2005 03:02
Alan Stern	09 Dec 2005 08:10
Harry Butterworth	09 Dec 2005 10:50
Alan Stern	09 Dec 2005 11:02
Greg KH	09 Dec 2005 20:10

Subject:	[Xen-devel] Re: [linux-usb-devel] Error recovery in Xen's paravirtualizing USB driver for Linux
From:	Harry Butterworth (har...@hebutterworth.freeserve.co.uk)
Date:	12/08/2005 07:59:28 AM
List:	com.xensource.lists.xen-devel

On Thu, 2005-12-08 at 10:20 -0500, Alan Stern wrote:

On Wed, 7 Dec 2005, Harry Butterworth wrote:

Suspend/resume is liable to cause trouble. For instance, what happens to the various front-ends if the back-end decides to suspend a USB device?

I don't know. Could you explain this scenario in more detail (imagine that none of the 800 page USB spec sunk in when I read it :-). What should happen in this case?

Suspend and reset are both troublemakers, because they act not on a device but on the device's parent hub. However resets are pretty self-contained, so provided you recognize them and handle them properly you should be okay. The back-end won't reset a device all by itself.

The problems with USB suspend are just a small subset of the problems with suspend in general. What happens to a front-end if a back-end goes to sleep, for example?

In the current implementation, the virtual hub in the front-end ignores or fakes up anything to do with power management and doesn't pass it to the back-end.

I was assuming that the back-end would do it's own power management and that if it put anything to sleep it would wake it up again for me when my driver submitted an URB. This is probably totally naive.

Are the individual USB drivers actually involved in power management or is it managed by the hub driver transparently to the usb drivers? If it's managed transparently then I ought to be able to leave it all to the back-end, right?

Your best approach is to make sure that a back-end never tries to suspend an exported device. Then the front-end will be completely responsible for device power management, and no confusion will arise.

I'm not actually giving the front-end access to the back-end hub, only to a device plugged into the hub. The front-end gets its own virtual hub. So, if I have to have the front-end do the power management then I'll have to handle the power management requests to the front-end virtual hub and forward them to the backend and translate them into requests to the back-end hub.

I'd prefer to let the back-end do it if at all possible.

Thoughts?