> -----Original Message----- > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, April 01, 2010 11:23 PM > To: Hrant Dalalyan > Cc: USB mailing list; USB storage mailing list; Sarah Sharp; Matthew > Dharm; Greg Kroah-Hartman; Paul Zimmerman; John Youn; Ashot Madatyan > Subject: Re: [PATCH/RFC] UASP enhancement to usb-storage > > On Thu, 1 Apr 2010, Hrant Dalalyan wrote: > > > Implementation of USB Attached SCSI Protocol per UASP Specification > > (Rev.1, July 9, 2008). Below is the list of the enhancements made to > > the usb-storage driver. > > In my opinion the UAS protocol is so different from the older USB > mass-storage protocols (it has almost nothing in common) that you'd be > better off writing a whole new driver instead of grafting this stuff > onto usb-storage. Yes, I agree with you. But the reason of adding the UASP support to the usb-storage driver is that the usb-storage contains the most common and well-known protocol implementations, e.g. CBI, CB, BBB. The second reason is the code reuse. But if there is a need to make it standalone then, considering the UASP class design and implementation, it'll be not so hard work to implement. > > > - Enhanced probe routine to identify UASP devices. > > - Allocation/deallocation of UASP specific resources. > > - Various enhancements to existing infrastructure to invoke UASP > > specific routines. > > - Added SCSI command queueing mechanism and state machine for > > handling multiple commands. > > - Implemented 'abort task' and 'reset nexus' task management > > functions. > > None of this should clutter up the usb-storage driver. That's part of > the reason why an entirely new driver would be better. > > > Limitations: > > > > - Considered that the endpoint descriptors are received from the > device > > side in the following order: > > - Command endpoint descriptor. > > - Bulk in endpoint descriptor. > > - Bulk out endpoint descriptor. > > - Status endpoint descriptor. > > because in the noted revision of the UASP Specification were not > defined > > pipe usage descriptors. > > They are defined in Revision 2 (March 21, 2009 -- I can send you a > copy if you can't find it). You should use them. Of course, this is one of my next steps. > > > - The max number of streams are not retrieved through the superspeed > > endpoint companion descriptor and are fixed to 2 streams per > > endpoint. > > Why not use the descriptor? This is the one of my next steps too. > > > - Device supported LUNs are assumed to be 1. > > - Concurrent processing of SCSI commands is not yet tested due to due > > to some device limitations. The driver is currently set to process > > only 1 command at a time. > > - Abort task, Reset nexus task management functions, as well as some > > error conditions and recovery situations are not yet tested. > > These limitations should be removed as quickly as possible. Can be tested only after the respective hw/sw environment is available. > > Alan Stern Thanks, Hrant. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
