Hi Sarah > On Thu, Apr 14, 2011 at 04:36:15PM +0300, Tatyana Brokhman wrote: > > This patch implements the infrastructure for the UAS gadget driver. > > The UAS gadget driver registers as a second configuration of the MS > > gadet driver. > > > > A new module parameter was added to the mass_storage module: > > bool use_uasp. (default = 0) > > If this parameter is set to true, the mass_storage module will > register > > with the UAS configuration as the devices first configuration and > > operate according to the UAS protocol. > > I'm a bit confused by this statement. Do you mean the UAS alternate > interface setting, rather than the UAS configuration? I thought that > UAS devices would have one configuration with two alternate interface > settings: a bulk-only-transport interface, and a UAS interface. > > Wasn't there a requirement in the USB-IF UAS compliance test that UAS > devices have the UAS alternate interface setting as the second > alternate > interface setting, to make sure OSes without UAS support would still be > able to operate with the device? Is that what you're doing in these > patches? Our idea was that UAS supporting devices register with 2 configurations (not a second alternate setting to the MS interface). Upon enumeration the host will choose the operational mode/protocol (BOT/UAS) by choosing the configuration it wishes to operate in. As a first development phase it was easier for us to register only 1 configuration and that's why we added the module parameter. We're now working on removing this hack and registering 2 configurations the host can choose from. From what I saw in the host side implementation the host always prefers the first configuration so right now we set the UAS config from user-space via sysfs. I looked into USB-IF UAS compliance test document and you're right. There is something that mentions "Configuration Descriptor shall report B NUM INTERFACES > 0". Unfortunately in our version of the file this is the only reference I found for this demand so I need to look into that and get more details. In the meanwhile: will this work with the existing UAS driver implementation? How will I be able to "force" the host to choose the UAS protocol? I can compile just cdc_ncm but I prefer to have my host support both UAS and BOT and be able to choose. As mentioned before, at the moment I achieved that by manually setting the device configuration to UAS from user space. > > The other comment I saw was that you chose to run a thread per LUN: > > > + * Several kernel threads are created as part of the init sequence: > > + * - UASP main thread > > + * - A thread for each of the existing LUNs > > + * The UASP main thread handles all of the generic commands/task > > + * management requests and routes LUN specific requests to be > handled by > > + * the appropriate LUNs task. > > + * The approach of "task per LUN" was chosen due to the UAS protocol > > + * enhancement over the BOT protocol. The main retouch of the UAS > > + * protocol of the BOT protocol is the fact that independent > commands can > > + * be performed in parallel. For example a READ command for two > different > > + * LUNS. Thus in order to implement this concurrency a separate > thread is > > + * needed for each of the existing LUNS. > > + * As long as the LUN threads are alive they keep an open reference > to the > > + * backing file. This prevents the unmounting of the backing file's > > + * underlying file system and cause problems during system shutdown. > > Why not a thread per SCSI command TAG (i.e. per stream ID)? I think > that most USB storage devices only have one LUN. You would get better > performance if you could, say, kick off several READ commands for the > same LUN when you receive two separate SCSI commands on different > stream > IDs. I wasn't aware of the "one LUN" issue. I'm afraid that creating a thread per SCSI command won't be that efficient because we will spend too much CPU on 1. creating/killing the thread 2. context switch between the threads Perhaps the better solution will be the combination of the two approaches: create X threads that will handle the received SCSI commands. This way X can be a maximum between number of LUNS and some max_threads_val we decide on. How does this sound? Best regards, Tanya Brokhman Consultant for Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- 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
