Add UAS blacklist for 0080:a001

[MichaIng]

Preamble
I am not sure how adding such USB quirks on RPi kernel is handled, in which cases patch are better send upstream and how the implementation looks like based on the vendor:product ID. In case please advise me how to handle such better and how this is added to code to send a PR directly.

Describe the bug
Drives attached via 0080:a001 bridge to USB3 port cannot be used for USB boot. Adding a quirk for UAS blacklist solves the issue.

System

• Which model of Raspberry Pi? RPi 4 B
• Which OS and version (cat /etc/rpi-issue)? Raspbian Buster
• Which kernel version (uname -a)? 5.4.51-v7l+ #1333

Additional context

• Report on DietPi: DietPi-Drive_Manager | Add UAS blacklist control MichaIng/DietPi#3754
• Report on RPi forum: https://www.raspberrypi.org/forums/viewtopic.php?p=1704847
• Random find (and there are many more) to further verify that this drive causes issues with UAS driver: https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/comment-page-16/#comment-6447

[timg236]

Maintaining compatibility lists for USB devices is undesirable because it will always be out of date.

I did wonder whether a raspi-config or similar UI to disable UAS by default might be useful i.e. it's slow by default and you can enable UAS after testing that it works ok. I'll leave that for UAS experts to comment on.

[MichaIng]

Maintaining compatibility lists for USB devices is undesirable because it will always be out of date.

I at least found several commits for adding USB quirks to the RPi kernel, basically lists are there already: ffeb58a#diff-0e4dc4e375eb944c0dcabef4c1073cfa
I guess those supplement what is present upstream already and I agree that it makes sense to aim patching everything upstream, where possible, but that is the longer way of course and cannot solve anything shot/mid-term for RPi users then.

If is not long ago that UAS module was added to solve some USB drive scenarios: #2813

I'm not sure whether this breaks more than it solves. The module is loaded by default (at least as long as a USB drive is attached), probably it should not be, not sure if some dtoverlay would be a solution. raspi-config has no switch, I personally do blacklist uas on my machine, but for our users I generally stick with defaults, assuming that those are most reasonable for generic use cases.

[P33M]

I agree that we shouldn't be adding downstream quirks (which is not a compatibility list, but ends up getting treated the same as one if you want to maintain it).

Manufacturers may ship multiple firmware versions for the same controller reporting the same VID:PID - some with patched/fixed UAS implementations that have no issue with Pi 4 - so you may have to override added quirks for a fixed version if you want better performance.

The existing flow is simple - UAS is enabled by default, and if there's an issue with it - follow instructions in the thread you linked to disable it. It could be made simpler/easier with a raspi-config switch, or via some sort of provisioning step when building the USB mass storage boot filesystem, but all you need is a text editor on any Pi/PC/Mac platform to access cmdline.txt.

[MichaIng]

Manufacturers may ship multiple firmware versions for the same controller reporting the same VID:PID

That is a good argument. Okay I was not sure how this is handled, many thanks for clarification.

It could be made simpler/easier with a raspi-config switch.

I was thinking to write a little whiptail UI to add UAS blacklists to cmdline based on lsusb output and alternatively blacklist the uas kernel module itself. Could be added to raspi-config then as well as kinda USB drive troubleshooting menu. Alternatively this topic might find some place in the help/troubleshoot/documentation area: https://www.raspberrypi.org/help/