UASPが使用されていない理由
LinuxでUSB3.0 UASPモードが有効になっているかどうかを確認するにはどうすればよいですか？ によると、UASPは新しいHDDエンクロージャーで使用されていません つまり UASPをサポートしています。
また、私のマザーボード（ASUS M5A99FX PRO R2.0）のマニュアルには次のように書かれています。
USB 3.0 Boost ASUS USB 3.0 Boostテクノロジーは、最新のUSB 3.0規格であるUASP（USB Attached SCSI Protocol）をサポートしています。 USB 3.0 Boostテクノロジーを使用すると、USBデバイスの伝送速度が最大170％まで大幅に向上し、すでに印象的な高速USB3.0転送速度が追加されます。 ASUSソフトウェアは、ユーザーの操作を必要とせずに、互換性のあるUSB3.0周辺機器のデータ速度を自動的に加速します。
では、マザーボードのサポートとデバイスのサポート（および Linuxのサポート ）では、なぜUASPが使用されないのですか？また、どうすれば使用できるようになりますか？
あるいは、使用されているのかもしれませんが、確認方法がわかりません。 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
[〜＃〜]編集[〜＃〜]
Fedora 21（64ビット）でLinux4.0.8を実行しています。
編集2
これがlsmod | grep uasの出力です。
uas 24576 0
usb_storage 65536 1 uas
ドッキングステーション（HDDを搭載）をオンにすると、すべてのdmesg出力が生成されます。
[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
as-detect.h を見ると、エンクロージャー内のASM1053チップがUASドライバーによって実際にサポートされていることがわかります（大規模な転送にバグがある場合でも）。
Modules.aliasファイルを変更して、デバイスIDのサポートを追加してみてください。残念ながら、システム上の何かによってdepmodが再度実行された場合は、modules.aliasファイルへの変更をやり直す必要があります。
2番目のオプションは、UASカーネルモジュールにパッチを適用して、デバイスIDのサポートをアドバタイズし、モジュールを再構築することです。これを実行して適切なパッチをアップストリームにプッシュバックすると、HD Enclosure LinuxUASサポートをすべての人に提供できる可能性があります。
同様の問題を抱えている人がこのスレッドに遭遇した場合...
ほとんどのデバイスドライバーカーネルモジュールとは異なり、usb-storageドライバーとuasドライバーは、既知のデバイスIDのリストに基づいて機能しませんが、代わりに as-detect.h にある検出ロジックを使用します。ファイルのuas_use_uas_driver（）関数は、デバイスがUASプロトコルをサポートしていると主張しているかどうかに基づいて決定を下します。 （デバイスエイリアスについては、 このlinuxquestions.orgスレッド も参照してください。）
この場合、いずれかのモジュールをブラックリストに登録しても違いはありません。 uas_use_uas_driver（）がtrueを返す場合、uas.cはそれを要求し、usb.cはそれを拒否し、関数がfalseを返す場合は逆になります。
（代わりに、デバイスがnotを実行することを確認するために使用できる構成設定「usb-storage.quirks = VID：PID：u」があります。 カーネルのコマンドラインパラメーター ドキュメントに記載されているように、uasドライバーによって要求されます。[他の方向に強制するフラグはありません。]）
OPの問題の場合：問題は、通常、カーネルがUSB IDを直接使用して、デバイスに特別な処理が必要かどうかを判断できることです...しかし、ID 0x174c：0x55aaの場合、ASMediaは異なるチップセットに同じIDを再利用しています。 UASのサポートレベル。したがって、uas_use_uas_driver（）関数は、実際に使用されているチップセットを判別するためにデバイスの特定の属性をチェックし、それに基づいてそのデバイスにuasドライバーを使用するかどうかを決定する必要があります。残念ながら、これが発生した場合、決定した内容を明示的に示すカーネルメッセージは生成されません。
（おそらく、"lsusb -v -d174c:55aa"の出力をuas_use_uas_driver（）関数のコメントと組み合わせて使用して、特定のデバイスで何が起こっているのか、そしてその理由を判断できます。しかし、いずれの場合も、検出ロジックに注意してください。デバイスが接続されたときにdmesg行の一部として出力される製品文字列[例： "ASMT1053"]は調べません。その名前は、uas-detectionロジックがそれについて何を決定するかについて実際には何も教えてくれません。特定のデバイス。）