* Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
@ 2024-05-06 11:14 Muni Sekhar
2024-05-06 14:29 ` Alan Stern
0 siblings, 1 reply; 12+ messages in thread
From: Muni Sekhar @ 2024-05-06 11:14 UTC (permalink / raw
To: linux-usb; +Cc: kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-06 11:14 Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver Muni Sekhar
@ 2024-05-06 14:29 ` Alan Stern
2024-05-06 16:14 ` Muni Sekhar
0 siblings, 1 reply; 12+ messages in thread
From: Alan Stern @ 2024-05-06 14:29 UTC (permalink / raw
To: Muni Sekhar; +Cc: linux-usb, kernelnewbies
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-06 14:29 ` Alan Stern
@ 2024-05-06 16:14 ` Muni Sekhar
2024-05-06 19:50 ` Alan Stern
0 siblings, 1 reply; 12+ messages in thread
From: Muni Sekhar @ 2024-05-06 16:14 UTC (permalink / raw
To: Alan Stern; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-06 16:14 ` Muni Sekhar
@ 2024-05-06 19:50 ` Alan Stern
2024-05-07 11:44 ` Muni Sekhar
0 siblings, 1 reply; 12+ messages in thread
From: Alan Stern @ 2024-05-06 19:50 UTC (permalink / raw
To: Muni Sekhar; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-06 19:50 ` Alan Stern
@ 2024-05-07 11:44 ` Muni Sekhar
2024-05-07 14:20 ` Alan Stern
2024-05-13 17:44 ` Muni Sekhar
0 siblings, 2 replies; 12+ messages in thread
From: Muni Sekhar @ 2024-05-07 11:44 UTC (permalink / raw
To: Alan Stern; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-07 11:44 ` Muni Sekhar
@ 2024-05-07 14:20 ` Alan Stern
2024-05-07 16:38 ` Muni Sekhar
2024-05-13 17:44 ` Muni Sekhar
1 sibling, 1 reply; 12+ messages in thread
From: Alan Stern @ 2024-05-07 14:20 UTC (permalink / raw
To: Muni Sekhar; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-07 14:20 ` Alan Stern
@ 2024-05-07 16:38 ` Muni Sekhar
2024-05-07 17:51 ` Alan Stern
0 siblings, 1 reply; 12+ messages in thread
From: Muni Sekhar @ 2024-05-07 16:38 UTC (permalink / raw
To: Alan Stern; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-07 16:38 ` Muni Sekhar
@ 2024-05-07 17:51 ` Alan Stern
2024-05-08 5:38 ` Muni Sekhar
0 siblings, 1 reply; 12+ messages in thread
From: Alan Stern @ 2024-05-07 17:51 UTC (permalink / raw
To: Muni Sekhar; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-07 17:51 ` Alan Stern
@ 2024-05-08 5:38 ` Muni Sekhar
2024-05-08 13:58 ` Alan Stern
0 siblings, 1 reply; 12+ messages in thread
From: Muni Sekhar @ 2024-05-08 5:38 UTC (permalink / raw
To: Alan Stern; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-08 5:38 ` Muni Sekhar
@ 2024-05-08 13:58 ` Alan Stern
0 siblings, 0 replies; 12+ messages in thread
From: Alan Stern @ 2024-05-08 13:58 UTC (permalink / raw
To: Muni Sekhar; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-07 11:44 ` Muni Sekhar
2024-05-07 14:20 ` Alan Stern
@ 2024-05-13 17:44 ` Muni Sekhar
2024-05-13 18:09 ` Alan Stern
1 sibling, 1 reply; 12+ messages in thread
From: Muni Sekhar @ 2024-05-13 17:44 UTC (permalink / raw
To: Alan Stern; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver
2024-05-13 17:44 ` Muni Sekhar
@ 2024-05-13 18:09 ` Alan Stern
0 siblings, 0 replies; 12+ messages in thread
From: Alan Stern @ 2024-05-13 18:09 UTC (permalink / raw
To: Muni Sekhar; +Cc: linux-usb, kernelnewbies
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-05-13 18:09 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-06 11:14 Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver Muni Sekhar
2024-05-06 14:29 ` Alan Stern
2024-05-06 16:14 ` Muni Sekhar
2024-05-06 19:50 ` Alan Stern
2024-05-07 11:44 ` Muni Sekhar
2024-05-07 14:20 ` Alan Stern
2024-05-07 16:38 ` Muni Sekhar
2024-05-07 17:51 ` Alan Stern
2024-05-08 5:38 ` Muni Sekhar
2024-05-08 13:58 ` Alan Stern
2024-05-13 17:44 ` Muni Sekhar
2024-05-13 18:09 ` Alan Stern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).