Harry Butterworth
2005-Mar-16 17:14 UTC
[Xen-devel] Re: dispatch_usb_reset & more usb 2.6 status
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel