[Xen-devel] Re: dispatch_usb_reset & more usb 2.6 status

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, 2005-03-16 at 16:32 +0000, M.A. Williamson wrote:
> Incidentally, are you chucking all the ring interfacing code from the 2.4 
> driver? That should all be reusable and mostly complete, so you should be 
> able to reuse it and concentrate on the really hard stuff - the Linux USB 
> layer.

I started from scratch by building the device framework for 2.6 and then
imported bits of your code into it bit by bit, testing each bit as I
went along.  The ring interfacing code is mostly there but rearranged
and I've been fixing the bugs that I've been pointing out to you
including the problem where you were failing to check if the ring was
full when queueing probes which required some restructuring to get the
resource management right.

I have done some bits differently, for example: I don't think the reset
should be synchronous.  I think the correct implementation is for the
reset request to clear the port enable bit and set the port reset bit
and then for the reset to complete asynchronously by setting the port
enable bit, clearing the reset bit and setting the c_reset bit.

I think this is the behaviour specified by the USB spec, it seems to
work and it avoids a busy wait in the front-end code.

I have structured the 2.6 code as follows:

usbfront_module:

   provides init and exit routines to init/exit components below

usbfront_bus:

   implements a virtual bus device representing the control plane to
which the USB driver domains are attached.

usbfront_discovery:

    finds USB driver domains and creates a usbfront_device for each
driver domain.

usbfront_device:

    represents a USB driver domain. Encapsulates the ring mechanism.
Provides a software interface to the usbfront_driver which looks like a
USB host controller.

usbfront_driver:

    a driver to drive the usbfront_device.

The idea here is that when the device discovery and interdomain
communication APIs change, the code in the usbfront_driver component
will not need to be modified.

The module, bus, discovery and device code is mostly done with the
exception that the module shutdown doesn't work because of the protocol
issues (missing functionality in xend?) also, the discovery can only
cope with a single driver domain since the domain controller protocol is
lacking the required IDs for more.

The driver code is done to the extent that Linux finds a USB device
attached and tries to submit an URB.

The next step is to forward port your urb to usbif_request mangling
code.

I'm hoping it's going to be possible to back-port the new 2.6 code to
2.4 to re-common up the code.  At least I ought to understand it all
pretty well by then.

Once the 2.6 code is working and the code is commoned up again I can
start working on fixing the limitations in the protocol and shutdown
etc.

Harry.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel