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