Why UASP isn't being used

Question

According to How can I check whether USB3.0 UASP mode is enabled in Linux?, UASP is not in use on my new HDD enclosure that says it supports UASP.

Also, my motherboard's (ASUS M5A99FX PRO R2.0) manual says:

USB 3.0 Boost ASUS USB 3.0 Boost technology supports UASP (USB Attached SCSI Protocol), the latest USB 3.0 standard. Witht USB 3.0 Boost technology, a USB device’s transmission speed is significantly increased up to 170%, adding to an already impressive fast USB 3.0 transfer speed. ASUS software automatically accelerates data speeds for compatible USB 3.0 peripherals without the need for any user interaction.

So with motherboard support and device support (and Linux support), why isn't UASP being used, and how can I make it be used?

Or perhaps it is being used, and I just don't know how to check it. Relevant output of lsusb -t:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

EDIT
I am running Linux 4.0.8 on Fedora 21 (64-bit).

EDIT 2
Here is the output of lsmod | grep uas:

uas                    24576  0 
usb_storage            65536  1 uas

Here is the all dmesg output generated by turning on the docking station (with a HDD in it):

[173791.566332] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd
[173791.581802] usb 2-2: New USB device found, idVendor=174c, idProduct=55aa
[173791.581809] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[173791.581814] usb 2-2: Product: ASMT1053
[173791.581818] usb 2-2: Manufacturer: asmedia
[173791.581822] usb 2-2: SerialNumber: 123456789012
[173791.583705] usb-storage 2-2:1.0: USB Mass Storage device detected
[173791.583933] usb-storage 2-2:1.0: Quirks match for vid 174c pid 55aa: 400000
[173791.583981] scsi host11: usb-storage 2-2:1.0
[173792.587494] scsi 11:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 6
[173792.588048] sd 11:0:0:0: Attached scsi generic sg3 type 0
[173792.589870] sd 11:0:0:0: [sdc] Spinning up disk...
[173793.589663] .......ready
[173799.606012] sd 11:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB)
[173799.606599] sd 11:0:0:0: [sdc] Write Protect is off
[173799.606606] sd 11:0:0:0: [sdc] Mode Sense: 43 00 00 00
[173799.607092] sd 11:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[173799.624914]  sdc: sdc2
[173799.626624] sd 11:0:0:0: [sdc] Attached SCSI disk

Answer 1

From looking at uas-detect.h I can see that the ASM1053 chip in your enclosure is indeed supported by the UAS driver (even if it has bugs with large transfers).

You might try modifying your modules.alias file to add support for your device ID. Unfortunately, if depmod is run again by anything on your system you'll have to redo those changes to the modules.alias file.

A second option might be to patch the UAS kernel module to advertise support for your device ID and rebuilding the module. If you did this and push a good patch back upstream, you might even get everyone with your HD enclosure Linux UAS support.

Answer 2

In case anyone with a similar problem stumbles across this thread...

Unlike most device-driver kernel modules, the usb-storage and uas drivers don't work based on a list of known device ids, but instead both use the detection logic found in the uas-detect.h file's uas_use_uas_driver() function which makes a decision based on whether the device claims to support the UAS protocol. (See also this linuxquestions.org thread regarding the device aliases.)

In this case, blacklisting one or the other module won't make any difference; if uas_use_uas_driver() returns true then uas.c will claim it and usb.c will reject it, and the reverse will happen if the function returns false.

(Instead, there is a configuration setting "usb-storage.quirks=VID:PID:u" which can be used to make sure a device does not get claimed by the uas driver, as documented in the The kernel's command line parameters document. [There is no flag to force in the other direction.])

For the OP's issue: the problem is that normally the kernel can straightforwardly use the USB ID to determine if a device needs special treatment... but in the case of ID 0x174c:0x55aa, ASMedia has reused the same ID for different chipsets with different levels of support for UAS. So the uas_use_uas_driver() function has to check for specific attributes of the device in order to try to determine which chipset is actually in use, and then based on that decide whether to use the uas driver for that device. Unfortunately when this happens there aren't any kernel messages generated to explicitly state what it has decided.

(Presumably one could use the output of "lsusb -v -d174c:55aa" in combination with the comments in the uas_use_uas_driver() function to determine what was happening with a particular device, and why.... But in any case, note that the detection logic does not look at the Product string [e.g. "ASMT1053"] that gets printed as part of the dmesg lines when the device is plugged in -- that name doesn't actually tell you anything about what the uas-detection logic will decide about that particular device.)