Raspberry Pi USB Power Management (wake up USB port)

Hi Guys,

I am running into a problem where unless I unplug and re-plug my USB peripheral it will not be detected on my Raspberry Pi Zero 2. Note I am using an externally powered USB hub for my use case.

After researching this, apparently if there is no activity from the USB port, the kernel may decide to sleep the port for power savings. My questions is, is there any way to ‘wake’ up the port?

From my understanding you cannot cut power to individual ports as they are all on the same bus so that would not be a solution for me for reasons I rather not get into!

I am looking for a software solution rather than a hardware solution i.e. relay to external powered USB hub.

Cheers!

4 Likes

Hey Samuil,

There’s some good background info here: Power Management for USB — The Linux Kernel documentation

A bit of a search on the Pi Forums lead me to this post, which might be your solution :crossed_fingers:
https://forums.raspberrypi.com/viewtopic.php?t=6256&start=1125#p213497

6 Likes

Hi Oliver,

Thank you for forwarding those links, I did actually already end up on that thread but was confused because I could not find 8192cu in the module directory.

In the thread it says to go to: /sys/module/8192cu/parameters/rtw_power_mgnt

I do see a kernel folder which I am assuming could be it but was worried about messing around with it.

Please see the directories that exist within /sys/module:

I am also confused when he says

I was able to disable power management completely by creating /etc/modprobe.d/8192cu.conf with the following contents:
#Disable power saving
options 8192cu rtw_power_mgnt=0

How would I actually go about doing this?

Cheers!

3 Likes

The 8192cu is related to the specific USB device (and accompanying device driver) they’re using.

Actually, after a closer reading of the Docs I linked above, it looks like you should be able to disable power management for that specific USB device by creating file called control here:
/sys/bus/usb/devices/.../power/control which contains only the word on; where ‘…’ is the device’s ID.

See:
https://www.kernel.org/doc/html/v4.13/driver-api/usb/power-management.html#the-user-interface-for-dynamic-pm

According to the warnings section power management is actually part of the USB spec (which does ring a bell for me), so it may be just that your device is not properly compliant with the USB spec.

5 Likes

Thank you Oliver,

Please see my screenshot at the very end of this post.

I have navigated to /sys/bus/usb/devices/ and it shows a bunch of numbers.

To try pin point which one is my device, I used both the lusb and usb-devices command to see if it comes back with anything that helps me identify this - nothing too apparent.

Any thoughts?

Cheers!

Edit: I forgot to mention the USB device I am after is the first one noted when I run the lsusb command (Bus 001 Device 125)

3 Likes

Which device are you trying to disable Power management for?

Here’s a good stack-exchange link that explains how to understand the numbering scheme (and a few suggestions on identifying which device you want): how to get bus id of an usb device - Unix & Linux Stack Exchange

And another handy link:

To summarise, the USB sysfs device naming scheme is:

root_hub - hub_port : config . interface

As the devices go further down in the USB tree, and as more and more USB hubs are used, the hub port number is added to the string following the previous hub port number in the chain. For a two-deep tree, the device name looks like:

root_hub - hub_port . hub_port : config . interface

From: 13.2. USB and Sysfs

5 Likes

Hi Oliver,

Thank you for that,

I am trying to identify ‘Bus 001 Device 015: ID 04b0:043f Nikon Corp.’ specifically.

I was a little confused because that device I just mentioned above is connected into the ‘Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub’ but I now understand it is unrelated because of its method of displaying as a tree.

I am trying to wrap my head around the info you sent as we speak.

Cheers!

4 Likes

Ah, I believe your device ID then is 1-1.3.4.2:1.0

So circling back, you’ll need to make a file: /sys/bus/usb/devices/1-1.3.4.2:1.0/power/control containing the word on.

I suspect this solution will probably work ok if you’ve got a semi-permanent setup and aren’t moving your devices around much, but if you’re regularly changing its USB port you’ll want a better option that can automatically do this for that specific USB device.

This isn’t my area of expertise, sorry! Someone else may be able to jump in with a better solution :slight_smile:

5 Likes

Hi Oliver,

Actually the USB device will be connected permanently so this is the perfect solution for me! :slight_smile:

When you say create a file containing the word ‘on,’ would this process be correct:

cd /sys/bus/usb/devices/1-1.3.4.2:1.0/power
sudo nano power
write ‘on’ in the file
save

Just confirming I am not meant to be doing .txt? i.e. sudo nano power.txt

I am getting permission error when trying to save the file either method, assuming I must be root?

Cheers!

4 Likes

Ah, no worries then! :slight_smile: The filename should be control. You should be able to do it with:

sudo bash -c "echo 'on' > /sys/bus/usb/devices/1-1.3.4.2:1.0/power/control"

or

cd /sys/bus/usb/devices/1-1.3.4.2:1.0/power
sudo nano control
on
Ctrl+O

(I’m on a windows machine so I haven’t actually tested any of these commands)

5 Likes

Fair enough :slight_smile:

It seems I am unable to write a file using either methods in the /power folder.

Since I can show the CML text for the first method, here is what it returned:

pi@raspberrypi:~ sudo bash -c "echo 'on' > /sys/bus/usb/devices/1-1.3.4.2:1.0/power/control" bash: /sys/bus/usb/devices/1-1.3.4.2:1.0/power/control: Permission denied pi@raspberrypi:~ sudo su
root@raspberrypi:/home/pi# bash -c “echo ‘on’ > /sys/bus/usb/devices/1-1.3.4.2:1.0/power/control”
bash: /sys/bus/usb/devices/1-1.3.4.2:1.0/power/control: Permission denied
root@raspberrypi:/home/pi#

5 Likes

You might also try:

echo 'on' | sudo tee /sys/bus/usb/devices/1-1.3.4.2:1.0/power/control

It also might need to be: 1-1.3.4.2 and not 1-1.3.4.2:1.0 :thinking:

5 Likes

It appears I am just totally restricted in general regardless of which device I select

pi@raspberrypi:~ $ sudo su
root@raspberrypi:/home/pi# echo ‘on’ | sudo tee /sys/bus/usb/devices/1-1.3.4.2:1.0/power/control
tee: ‘/sys/bus/usb/devices/1-1.3.4.2:1.0/power/control’: Permission denied
on
root@raspberrypi:/home/pi#

Which is really odd as I am in root :face_with_monocle:

Edit:

I forgot to mention, I have also disconnected the USB and listed the devices in /sys/bus/usb/devices and re-connected the USB and once again listed the devices to compare. Upon reconnecting, two additional lines appear, specifically 1-1.3.4.2 and 1-1.3.4.2:1:0

4 Likes

Hmm, it’s odd. Might have to check the permissions on that file.

Did you have any luck?

4 Likes

Hi Oliver,

I am still new to the Linux space so I haven’t had much luck.

From trying to research myself all I could find was ‘chmod +x ‘file name’’ but since I cannot even create the file within the folder I don’t see how that method could work. I would give the folder chmod +x permission but from my understanding it does not work with directories?

Cannot emphasise enough how helpful you have been by the way, absolute legend :slight_smile:

2 Likes

Hi Samuil, You cannot write/mod the file in the /sys directory even as root because the system is using it and will not let it to be modified. That is why the earlier post you mentioned some other guy created a .conf file that will be read and incorporated into the appropriate system file.

Try lsusb -v (verbatim) to see if you can see the devices descriptions and go from there.

4 Likes

Thank you mate I will try this soon!

4 Likes

Might be some good answers here

3 Likes

@G177630 :man_facepalming: Of course! Sorry for leading you down the garden path a bit @Samuil155885

Nice finds @Oliver33 :slight_smile:

PowerTop sounds like it could be useful: GitHub - fenrus75/powertop: The Linux PowerTOP tool -- please post patches to the mailing list instead of using github pull requests

And some people here have suggested they managed to do it with a udev rule:

2 Likes