| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [linux-usb-devel] Error recovery in Xen's paravirtualizi
On Thu, 8 Dec 2005, Harry Butterworth wrote:
> 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.
It is. For one thing, drivers aren't allowed to submit URBs to suspended
devices.
> Are the individual USB drivers actually involved in power management or
> is it managed by the hub driver transparently to the usb drivers?
Both. :-)
Drivers are involved in power management of their interfaces (remember,
drivers bind to USB interfaces, not to USB devices). The hub driver is
involved in power management of USB devices (and hub interfaces too, of
course).
> If
> it's managed transparently then I ought to be able to leave it all to
> the back-end, right?
I'm not sure what you mean by that. Do you _want_ to virtualize power
management operations? If not, have your virtual root hub pretend to
carry them out without actually doing anything. If yes, your virtual root
hub will have to forward suspend and resume requests to the actual parent
hub on the back-end.
A complication is that suspended USB devices may send remote wakeup
requests. If you only pretend to suspend the device then those wakeup
requests will never get sent. Maybe you don't care about such esoteric
details...
> 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.
That's right.
You have to do this sort of thing anyway. How else can you handle port
resets? They occur as a normal part of the device initialization sequence
and as part of error recovery in usb-storage, among other things.
> I'd prefer to let the back-end do it if at all possible.
Prefer to let the back-end do what?
You know, there are other awkward aspects to watch out for. For example,
the USB-over-IP patch included special code to check for Clear-Halt
requests and Set-Interface requests. It also needed (but forgot to
include) code to check for Set-Configuration requests.
Part of the problem is that the stub drivers on the back-end are forced to
bind to USB interfaces instead of USB devices. It would make life simpler
for you guys if the stub driver could bind to the entire device (replacing
the usb_generic driver). Do you think that's worth pursuing?
Alan Stern
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home