Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
Dear Linux USB Subsystem Community, I hope this email finds you well. We are currently working on a USB device driver in the Linux kernel space, which supports the suspend/resume functionality for a USB device using the struct usb_driver's .suspend and .resume callbacks. In our driver code, we perform a check to determine if the device has remote wakeup capability. If the device supports remote wakeup, we enable the device's autosuspend mode by setting the struct usb_device->dev.power.autosuspend_delay parameter and then calling usb_enable_autosuspend(). Similarly, to resume the suspended device, we expose an API to user space via IOCTL. In this process, we set struct usb_device->dev.power.autosuspend_delay to -1 and then call usb_disable_autosuspend(). While we have successfully converted most of the USB device driver functionality from kernel space to user space using libusb, we are now seeking guidance on how to implement USB device suspend/resume in user space. Specifically, we would like to know if libusb provides support for achieving the suspend/resume functionality mentioned above. Additionally, any insights or suggestions on how to accomplish this task would be greatly appreciated. It's worth mentioning that our USB device driver also supports Bulk\Coontrol I/O transfers and other functionalities. Thank you in advance for any assistance you can provide. I look forward to your valuable inputs and recommendations. -- Thanks, Sekhar
On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
Dear Linux USB Subsystem Community,
I hope this email finds you well. We are currently working on a USB device driver in the Linux kernel space, which supports the suspend/resume functionality for a USB device using the struct usb_driver's .suspend and .resume callbacks.
In our driver code, we perform a check to determine if the device has remote wakeup capability. If the device supports remote wakeup, we enable the device's autosuspend mode by setting the struct usb_device->dev.power.autosuspend_delay parameter and then calling usb_enable_autosuspend().
Similarly, to resume the suspended device, we expose an API to user space via IOCTL. In this process, we set struct usb_device->dev.power.autosuspend_delay to -1 and then call usb_disable_autosuspend().
While we have successfully converted most of the USB device driver functionality from kernel space to user space using libusb, we are now seeking guidance on how to implement USB device suspend/resume in user space. Specifically, we would like to know if libusb provides support for achieving the suspend/resume functionality mentioned above. Additionally, any insights or suggestions on how to accomplish this task would be greatly appreciated.
Your question is about libusb, right? So you'll get better answers if you post it on the libusb mailing list rather than the linux-usb mailing list. Alan Stern
It's worth mentioning that our USB device driver also supports Bulk\Coontrol I/O transfers and other functionalities.
Thank you in advance for any assistance you can provide. I look forward to your valuable inputs and recommendations.
-- Thanks, Sekhar
On Mon, 6 May, 2024, 7:59 pm Alan Stern, <stern@rowland.harvard.edu> wrote:
On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
Dear Linux USB Subsystem Community,
I hope this email finds you well. We are currently working on a USB device driver in the Linux kernel space, which supports the suspend/resume functionality for a USB device using the struct usb_driver's .suspend and .resume callbacks.
In our driver code, we perform a check to determine if the device has remote wakeup capability. If the device supports remote wakeup, we enable the device's autosuspend mode by setting the struct usb_device->dev.power.autosuspend_delay parameter and then calling usb_enable_autosuspend().
Similarly, to resume the suspended device, we expose an API to user space via IOCTL. In this process, we set struct usb_device->dev.power.autosuspend_delay to -1 and then call usb_disable_autosuspend().
While we have successfully converted most of the USB device driver functionality from kernel space to user space using libusb, we are now seeking guidance on how to implement USB device suspend/resume in user space. Specifically, we would like to know if libusb provides support for achieving the suspend/resume functionality mentioned above. Additionally, any insights or suggestions on how to accomplish this task would be greatly appreciated.
Your question is about libusb, right? So you'll get better answers if you post it on the libusb mailing list rather than the linux-usb mailing list.
Can USB device suspend\resume be implemented in user space driver using software other than libusb? Alan Stern
It's worth mentioning that our USB device driver also supports Bulk\Coontrol I/O transfers and other functionalities.
Thank you in advance for any assistance you can provide. I look forward to your valuable inputs and recommendations.
-- Thanks, Sekhar
On Mon, May 6, 2024 at 7:59 PM Alan Stern <stern@rowland.harvard.edu> wrote:
On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
Dear Linux USB Subsystem Community,
I hope this email finds you well. We are currently working on a USB device driver in the Linux kernel space, which supports the suspend/resume functionality for a USB device using the struct usb_driver's .suspend and .resume callbacks.
In our driver code, we perform a check to determine if the device has remote wakeup capability. If the device supports remote wakeup, we enable the device's autosuspend mode by setting the struct usb_device->dev.power.autosuspend_delay parameter and then calling usb_enable_autosuspend().
Similarly, to resume the suspended device, we expose an API to user space via IOCTL. In this process, we set struct usb_device->dev.power.autosuspend_delay to -1 and then call usb_disable_autosuspend().
While we have successfully converted most of the USB device driver functionality from kernel space to user space using libusb, we are now seeking guidance on how to implement USB device suspend/resume in user space. Specifically, we would like to know if libusb provides support for achieving the suspend/resume functionality mentioned above. Additionally, any insights or suggestions on how to accomplish this task would be greatly appreciated.
Your question is about libusb, right? So you'll get better answers if you post it on the libusb mailing list rather than the linux-usb mailing list.
Can USB device suspend\resume be implemented in user space driver using software other than libusb? If so, what are those methods or techniques to achieve USB device suspend\resume , can you please provide clarity on this.
Alan Stern
It's worth mentioning that our USB device driver also supports Bulk\Coontrol I/O transfers and other functionalities.
Thank you in advance for any assistance you can provide. I look forward to your valuable inputs and recommendations.
-- Thanks, Sekhar
-- Thanks, Sekhar
On Mon, May 06, 2024 at 09:44:52PM +0530, Muni Sekhar wrote:
On Mon, May 6, 2024 at 7:59 PM Alan Stern <stern@rowland.harvard.edu> wrote:
On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
While we have successfully converted most of the USB device driver functionality from kernel space to user space using libusb, we are now seeking guidance on how to implement USB device suspend/resume in user space. Specifically, we would like to know if libusb provides support for achieving the suspend/resume functionality mentioned above. Additionally, any insights or suggestions on how to accomplish this task would be greatly appreciated.
Your question is about libusb, right? So you'll get better answers if you post it on the libusb mailing list rather than the linux-usb mailing list.
Can USB device suspend\resume be implemented in user space driver using software other than libusb?
Yes, a userspace driver can use the usbfs interface and can employ the ioctl commands listed in /usr/include/linux/usbdevfs.h. It's possible that libusb also provides facilities for controlling suspend and resume; I don't know whether it does.
If so, what are those methods or techniques to achieve USB device suspend\resume , can you please provide clarity on this.
As far as I know, these usbfs ioctl commands are not documented anywhere. The USBDEVFS_FORBID_SUSPEND ioctl prevents the device from being suspended, and wakes it up if it is currently suspended. The USBDEVFS_ALLOW_SUSPEND ioctl allows the device to be suspended. The suspend may not happen immediately; it is controlled by the settings in the device's power/control and power/autosuspend (or power/autosuspend_delay_ms) sysfs attribute files. The USBDEVFS_WAIT_FOR_RESUME ioctl waits until the device resumes, whether because of a remote wakeup or because another process has resumed it, and then forbids the device from suspending again until you perform another USBDEVFS_ALLOW_SUSPEND ioctl. Alan Stern
On Tue, May 7, 2024 at 1:20 AM Alan Stern <stern@rowland.harvard.edu> wrote:
On Mon, May 06, 2024 at 09:44:52PM +0530, Muni Sekhar wrote:
On Mon, May 6, 2024 at 7:59 PM Alan Stern <stern@rowland.harvard.edu> wrote:
On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
While we have successfully converted most of the USB device driver functionality from kernel space to user space using libusb, we are now seeking guidance on how to implement USB device suspend/resume in user space. Specifically, we would like to know if libusb provides support for achieving the suspend/resume functionality mentioned above. Additionally, any insights or suggestions on how to accomplish this task would be greatly appreciated.
Your question is about libusb, right? So you'll get better answers if you post it on the libusb mailing list rather than the linux-usb mailing list.
Can USB device suspend\resume be implemented in user space driver using software other than libusb?
Yes, a userspace driver can use the usbfs interface and can employ the ioctl commands listed in /usr/include/linux/usbdevfs.h. It's possible that libusb also provides facilities for controlling suspend and resume; I don't know whether it does.
If so, what are those methods or techniques to achieve USB device suspend\resume , can you please provide clarity on this.
As far as I know, these usbfs ioctl commands are not documented anywhere.
The USBDEVFS_FORBID_SUSPEND ioctl prevents the device from being suspended, and wakes it up if it is currently suspended.
The USBDEVFS_ALLOW_SUSPEND ioctl allows the device to be suspended. The suspend may not happen immediately; it is controlled by the settings in the device's power/control and power/autosuspend (or power/autosuspend_delay_ms) sysfs attribute files.
The USBDEVFS_WAIT_FOR_RESUME ioctl waits until the device resumes, whether because of a remote wakeup or because another process has resumed it, and then forbids the device from suspending again until you perform another USBDEVFS_ALLOW_SUSPEND ioctl.
Thank you, it is very helpful. To verify the USB device suspend\resume functionality, I configured the USB Power Management variables as follows: # cat /sys/bus/usb/devices/2-1.7/power/wakeup enabled # cat /sys/bus/usb/devices/2-1.7/power/control on # cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms 0 # cat /sys/module/usbcore/parameters/autosuspend 2 So, I configured the system to autosuspend the USB device as soon as it becomes idle, with no transactions running through the USB device. Now, how can I verify that the USB device has entered suspend mode from user space? When checking /var/log/kern.log, there are no relevant print statements. Are there any other log files related to power management or USB subsystems? Please correct me if anything in the test procedure mentioned above is incorrect.
Alan Stern
-- Thanks, Sekhar
On Tue, May 07, 2024 at 05:14:25PM +0530, Muni Sekhar wrote:
Thank you, it is very helpful.
To verify the USB device suspend\resume functionality, I configured the USB Power Management variables as follows:
# cat /sys/bus/usb/devices/2-1.7/power/wakeup enabled
# cat /sys/bus/usb/devices/2-1.7/power/control on
This means that the device will be permanently on, and so it will never be suspended. If you want to allow the device to be suspended, you have to write "auto" to the file.
# cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms 0
# cat /sys/module/usbcore/parameters/autosuspend 2
So, I configured the system to autosuspend the USB device as soon as it becomes idle, with no transactions running through the USB device. Now, how can I verify that the USB device has entered suspend mode from user space? When checking /var/log/kern.log, there are no relevant print statements. Are there any other log files related to power management or USB subsystems? Please correct me if anything in the test procedure mentioned above is incorrect.
You can see the device's current state by reading the power/runtime_status attribute file in sysfs. There are lots of other informative files in that directory; you should look at them. If you want to get more debugging information in the kernel log, you can enable dynamic debugging for usbcore: echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control Alan Stern
On Tue, May 7, 2024 at 7:50 PM Alan Stern <stern@rowland.harvard.edu> wrote:
On Tue, May 07, 2024 at 05:14:25PM +0530, Muni Sekhar wrote:
Thank you, it is very helpful.
To verify the USB device suspend\resume functionality, I configured the USB Power Management variables as follows:
# cat /sys/bus/usb/devices/2-1.7/power/wakeup enabled
# cat /sys/bus/usb/devices/2-1.7/power/control on
This means that the device will be permanently on, and so it will never be suspended. If you want to allow the device to be suspended, you have to write "auto" to the file.
Thanks a lot for these inputs. Now, I can verify USB device auto-suspend and auto-resume through the kernel log. In my test system, I found three buses "Bus 001, 002, and 003" using the lsusb command. The USB device I want to test is located on "Bus 002". # lsusb | grep "Bus 002" | wc 4 37 224 As per the output of the above command, there are 4 USB devices on "Bus 002" in my test system. # ls -l /sys/bus/usb/devices/2* lrwxrwxrwx 1 root root 0 Feb 14 14:48 /sys/bus/usb/devices/2-0:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.7 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.7/2-1.7:1.0 # ls -l /sys/bus/usb/devices/2* | wc 7 77 892 The above command shows seven nodes in /sys/bus/usb/devices/2* directory. The wakeup, control, and autosuspend_delay_ms attribute files are controlled via /sys/bus/usb/devices/.../power/, where "..." represents the device's ID. I identified my test device in /sys/bus/usb/devices/.../power/ by iterating through all the directories, reading the idVendor attribute file, and then manipulating the power management attribute files. Is there a way to manually map /sys/bus/usb/devices/.../power/ from the lsusb output? Can this mapping be done from a user space program as well? Do you have any reference examples for this? If so, could you share their GitHub location?
# cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms 0
# cat /sys/module/usbcore/parameters/autosuspend 2
So, I configured the system to autosuspend the USB device as soon as it becomes idle, with no transactions running through the USB device. Now, how can I verify that the USB device has entered suspend mode from user space? When checking /var/log/kern.log, there are no relevant print statements. Are there any other log files related to power management or USB subsystems? Please correct me if anything in the test procedure mentioned above is incorrect.
You can see the device's current state by reading the power/runtime_status attribute file in sysfs. There are lots of other informative files in that directory; you should look at them.
If you want to get more debugging information in the kernel log, you can enable dynamic debugging for usbcore:
echo module usbcore =p >/sys/kernel/debug/dynamic_debug/control
Alan Stern
-- Thanks, Sekhar
On Tue, May 07, 2024 at 10:08:13PM +0530, Muni Sekhar wrote:
Now, I can verify USB device auto-suspend and auto-resume through the kernel log.
In my test system, I found three buses "Bus 001, 002, and 003" using the lsusb command.
The USB device I want to test is located on "Bus 002".
# lsusb | grep "Bus 002" | wc 4 37 224
As per the output of the above command, there are 4 USB devices on "Bus 002" in my test system.
# ls -l /sys/bus/usb/devices/2* lrwxrwxrwx 1 root root 0 Feb 14 14:48 /sys/bus/usb/devices/2-0:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.7 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.7/2-1.7:1.0
# ls -l /sys/bus/usb/devices/2* | wc 7 77 892
The above command shows seven nodes in /sys/bus/usb/devices/2* directory.
The wakeup, control, and autosuspend_delay_ms attribute files are controlled via /sys/bus/usb/devices/.../power/, where "..." represents the device's ID.
I identified my test device in /sys/bus/usb/devices/.../power/ by iterating through all the directories, reading the idVendor attribute file, and then manipulating the power management attribute files.
Is there a way to manually map /sys/bus/usb/devices/.../power/ from the lsusb output? Can this mapping be done from a user space program as well? Do you have any reference examples for this? If so, could you share their GitHub location?
libusb already can do this for you. However, if you want to do it by hand then you can match up devices based on the devnum attribute file in the devices sysfs directory. For example, if you were trying to identify which device corresonds to the lsusb entry for device 003 on bus 002, you should look through all the directories in /sys/bus/usb/devices/2-* and see which one has "3" in its devnum file. There's another way of doing it more directly, using the output from "lsusb -t". For example, on my system: $ lsusb -t /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M Let's say we want to locate the Human Interface Device in sysfs. According to the listing, it is on port 002 below port 001 below bus 004. You reverse the numbers, put a '-' after the bus number, and separate the port numbers with a '.', which gives "4-1.2": $ cat /sys/bus/usb/devices/4-1.2/product Microsoft 5-Button Mouse with IntelliEye(TM) Alan Stern
On Tue, May 7, 2024 at 11:21 PM Alan Stern <stern@rowland.harvard.edu> wrote:
On Tue, May 07, 2024 at 10:08:13PM +0530, Muni Sekhar wrote:
Now, I can verify USB device auto-suspend and auto-resume through the kernel log.
In my test system, I found three buses "Bus 001, 002, and 003" using the lsusb command.
The USB device I want to test is located on "Bus 002".
# lsusb | grep "Bus 002" | wc 4 37 224
As per the output of the above command, there are 4 USB devices on "Bus 002" in my test system.
# ls -l /sys/bus/usb/devices/2* lrwxrwxrwx 1 root root 0 Feb 14 14:48 /sys/bus/usb/devices/2-0:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.1:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.7 lrwxrwxrwx 1 root root 0 May 7 13:16 /sys/bus/usb/devices/2-1.7:1.0 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.7/2-1.7:1.0
# ls -l /sys/bus/usb/devices/2* | wc 7 77 892
The above command shows seven nodes in /sys/bus/usb/devices/2* directory.
The wakeup, control, and autosuspend_delay_ms attribute files are controlled via /sys/bus/usb/devices/.../power/, where "..." represents the device's ID.
I identified my test device in /sys/bus/usb/devices/.../power/ by iterating through all the directories, reading the idVendor attribute file, and then manipulating the power management attribute files.
Is there a way to manually map /sys/bus/usb/devices/.../power/ from the lsusb output? Can this mapping be done from a user space program as well? Do you have any reference examples for this? If so, could you share their GitHub location?
libusb already can do this for you.
However, if you want to do it by hand then you can match up devices based on the devnum attribute file in the devices sysfs directory. For example, if you were trying to identify which device corresonds to the lsusb entry for device 003 on bus 002, you should look through all the directories in /sys/bus/usb/devices/2-* and see which one has "3" in its devnum file.
There's another way of doing it more directly, using the output from "lsusb -t". For example, on my system:
$ lsusb -t /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M
Let's say we want to locate the Human Interface Device in sysfs. According to the listing, it is on port 002 below port 001 below bus 004. You reverse the numbers, put a '-' after the bus number, and separate the port numbers with a '.', which gives "4-1.2":
$ cat /sys/bus/usb/devices/4-1.2/product Microsoft 5-Button Mouse with IntelliEye(TM)
Thank you for the clear explanation on how to identify devices associated with root hubs. Could you please provide clarity on whether the root hub devices have attribute files in the devices sysfs directory? Upon checking the sysfs directory, I couldn't find any relevant information about these attribute files. Thank you again for your assistance.
Alan Stern
-- Thanks, Sekhar
On Wed, May 08, 2024 at 11:08:11AM +0530, Muni Sekhar wrote:
Thank you for the clear explanation on how to identify devices associated with root hubs. Could you please provide clarity on whether the root hub devices have attribute files in the devices sysfs directory? Upon checking the sysfs directory, I couldn't find any relevant information about these attribute files.
Root hubs have different names in sysfs from all other USB devices. The root hub on bus N is named "usbN". For example, the root hub on bus 4 is named "usb4". Alan Stern
On Tue, May 7, 2024 at 5:14 PM Muni Sekhar <munisekharrms@gmail.com> wrote:
On Tue, May 7, 2024 at 1:20 AM Alan Stern <stern@rowland.harvard.edu> wrote:
On Mon, May 06, 2024 at 09:44:52PM +0530, Muni Sekhar wrote:
On Mon, May 6, 2024 at 7:59 PM Alan Stern <stern@rowland.harvard.edu> wrote:
On Mon, May 06, 2024 at 04:44:30PM +0530, Muni Sekhar wrote:
While we have successfully converted most of the USB device driver functionality from kernel space to user space using libusb, we are now seeking guidance on how to implement USB device suspend/resume in user space. Specifically, we would like to know if libusb provides support for achieving the suspend/resume functionality mentioned above. Additionally, any insights or suggestions on how to accomplish this task would be greatly appreciated.
Your question is about libusb, right? So you'll get better answers if you post it on the libusb mailing list rather than the linux-usb mailing list.
Can USB device suspend\resume be implemented in user space driver using software other than libusb?
Yes, a userspace driver can use the usbfs interface and can employ the ioctl commands listed in /usr/include/linux/usbdevfs.h. It's possible
In the context of the Linux kernel and USB devices, what are the similarities and differences between usbfs and sysfs? Before invoking the ioctl() system call, we need to obtain a file descriptor by invoking the open() system call. How do we identify the device node in the usbfs interface? For example, can you please explain how to identify the device node location of a Human Interface Device(shown below in lsusb -t output) as the first argument in the open() system call. $ lsusb -t /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M
that libusb also provides facilities for controlling suspend and resume; I don't know whether it does.
If so, what are those methods or techniques to achieve USB device suspend\resume , can you please provide clarity on this.
As far as I know, these usbfs ioctl commands are not documented anywhere.
The USBDEVFS_FORBID_SUSPEND ioctl prevents the device from being suspended, and wakes it up if it is currently suspended.
The USBDEVFS_ALLOW_SUSPEND ioctl allows the device to be suspended. The suspend may not happen immediately; it is controlled by the settings in the device's power/control and power/autosuspend (or power/autosuspend_delay_ms) sysfs attribute files.
The USBDEVFS_WAIT_FOR_RESUME ioctl waits until the device resumes, whether because of a remote wakeup or because another process has resumed it, and then forbids the device from suspending again until you perform another USBDEVFS_ALLOW_SUSPEND ioctl.
Thank you, it is very helpful.
To verify the USB device suspend\resume functionality, I configured the USB Power Management variables as follows:
# cat /sys/bus/usb/devices/2-1.7/power/wakeup enabled
# cat /sys/bus/usb/devices/2-1.7/power/control on
# cat /sys/bus/usb/devices/2-1.7/power/autosuspend_delay_ms 0
# cat /sys/module/usbcore/parameters/autosuspend 2
So, I configured the system to autosuspend the USB device as soon as it becomes idle, with no transactions running through the USB device. Now, how can I verify that the USB device has entered suspend mode from user space? When checking /var/log/kern.log, there are no relevant print statements. Are there any other log files related to power management or USB subsystems? Please correct me if anything in the test procedure mentioned above is incorrect.
Alan Stern
-- Thanks, Sekhar
-- Thanks, Sekhar
On Mon, May 13, 2024 at 11:14:44PM +0530, Muni Sekhar wrote:
In the context of the Linux kernel and USB devices, what are the similarities and differences between usbfs and sysfs?
They are totally different. usbfs gives you direct communication with the various USB devices on your system. sysfs presents interfaces for monitoring and controlling your entire system (including information about how it manages its USB devices) but doesn't provide a way to communicate with the devices.
Before invoking the ioctl() system call, we need to obtain a file descriptor by invoking the open() system call. How do we identify the device node in the usbfs interface? For example, can you please explain how to identify the device node location of a Human Interface Device(shown below in lsusb -t output) as the first argument in the open() system call.
$ lsusb -t /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/4p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/15p, 480M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M
The Human Interface Device is Device 003 on Bus 004. Therefore the device node is /dev/bus/usb/004/003. Alan Stern
participants (2)
-
Alan Stern -
Muni Sekhar