On Mon, Dec 05, 2011 at 09:55:13AM +0100, Sebastian Andrzej Siewior wrote: > On 12/05/2011 09:39 AM, Felipe Balbi wrote: > >Hi, > Hi, > > >On Mon, Dec 05, 2011 at 09:23:26AM +0100, Sebastian Andrzej Siewior wrote: > >>* Sebastian Andrzej Siewior | 2011-12-05 09:20:47 [+0100]: > >> > >>>* Shimrit Malichi | 2011-12-04 21:53:09 [+0200]: > >>> > >>>>This patch implements the infrastructure for the UAS gadget driver. > >>>>The UAS gadget driver registers as a second configuration of the MS > >>>>gadet driver. > >>>hch said to use target framework and you haven't done so. This is what I > >>>have so far. It is not yet complete. What I need to do is: > >>>- wire up command processing (currently here) > >>>- wire up data processing > >>>- check it works => post v1 > >>>- wire up command tagging => v2 > >>>- remove hard codings and fix whatever people complained about. > > > >This is much better, indeed, but the way it is now, it's only usable by > >the gadget framework because you have put the function driver on the > >transport layer. I wonder if there wouldn't be a simple way to split the > >"SCSI Over USB" part in a more generic way which could be shared between > >gadget side UASP and host side UASP drivers ?!? Maybe ?!? > > > >The drivers/target/uasp_*.c would really be just a transport layer and > >gadget/host drivers would make calls to that "library" ? Something like > >that ?? > > There is very little code that is not host specific. For instance > uas_alloc_cmd_urb() is something that could be used on both side but > the host is boxing the command and I need to unbox it. So I don't see > how I could share things except for the defines. > Most of the things are usb specific. So UAS gets the commands from the > scsi framework, puts the usb layer around it and sends them. k, fair enough ;-) Just thought there'd be a better way to share this code with host side implementation. Nevermind then -- balbi
Attachment:
signature.asc
Description: Digital signature
