I think @WayneWWW’s method is what you need, but I want to add something related: Upon plug-in to USB, it is the “udev” system which is triggering read and broadcast of any “plug-n-play” type description which drivers would use to know what is plugged in, and to decide what to do with the hardware. “udev” has abilities such as:
- Renaming the device special file produced from what is plugged in.
- Looking at serial numbers or other details to filter actions such as renaming or picking a driver.
- Adding arguments used for the driver.
There are default
udev files/triggers. There is also the “
/etc/udev/” content, and files in the “
rules.d/” subdirectory can:
- Be a symbolic link to the original system file.
- Be a modified copy of the original file, in which case this takes precedence.
- If the file in “
/etc/udev” is a modified file, then removing it (or temporarily disabling it with something
gzip), then the behavior will revert to the default.
The application for working with
udev manually is
udevadm. An example is that if you changed a
udev file in “
/etc/udev/”, and you want the result to immediately run, you could use “
sudo udevadm trigger”. Often it is useful to work with this while monitoring “
One reason this might be useful to you is that if there is a way to disable USB3 for just one item, then a
udev rule could be created which triggers only on your particular USB devices. Such a trigger could be limited to a class of devices, or to particular devices; in the case of a block device, I think it could be limited to partitions of a given UUID.
If you just want USB3 disabled, then the device tree is what you want. If you want to tailor this to specific devices, then you want to use
udev (but I don’t know what
udev would do to force USB2, although I suspect
udev could force the driver for USB2 instead of USB3).
The hard answer, and the one you’d really need if you want to know what is truly going on, is that you’d need a hardware USB3 analyzer.