As I was playing with a few FTDI devices of mine, I noticed each was pulling 100 mA or more. Considering they were intended for use in a laptop, that made me worry a bit. Darn IC should have suspend and these numbers should not be the norm. So I went to investigate on how to reduce this a bit.

The first tool is, of course, lsusb. Using lsusb -tv I got the following output:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M`
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 3: Dev 60, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
        ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
    |__ Port 7: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:5634 Realtek Semiconductor Corp.
    |__ Port 7: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:5634 Realtek Semiconductor Corp.
    |__ Port 9: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 12M
        ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd.
    |__ Port 10: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0026 Intel Corp. AX201 Bluetooth
    |__ Port 10: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0026 Intel Corp. AX201 Bluetooth
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 0bc2:ab30 Seagate RSS LLC
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub

Device I wanted to analyze was at bus 3, port 3. This knowledge allowed me to check its power level.

cat /sys/bus/usb/drivers/usb/3-3/power/level

Value on that was returned immediately confirmed what I suspected. The port standby was disabled. Another test was to write auto inside the same file and current consumption fell down after 2-3 seconds (essentially, USB standby timeout), as expected.

Unfortunately, as soon as the device was plugged back in, it reset its behavior to always-on. Well, udev rules to the rescue.

Only, I already had FTDI udev rules present on my system (/etc/udev/rules.d/99-libftdi.rules). It seems that one of the tools I used (ftdidev library being the prime suspect) already installed some rules. Any rules I add to that file might get overwritten eventually. So, I decided to create a new file for both FT232R and X Series chips.

cat << EOF | sudo tee /etc/udev/rules.d/42-ftdi.rules
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTR{power/control}:="auto"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTR{power/control}:="auto"
EOF

This will turn on auto standby handling for my FTDI devices while making sure that subsequent rule doesn’t overwrite it (thus :=). Exactly what I needed to make my laptop battery happy.

To apply this without reboot, you can use the following command:

sudo udevadm control --reload-rules && sudo udevadm trigger