Re: usb: dynamic suspend
On Mon, Aug 6, 2018 at 2:59 PM, Oliver Neukum wrote: > On Sa, 2018-08-04 at 23:10 +0530, Muni Sekhar wrote: >> >> Unloading the driver and killing the 'fwupd' daemon resulted that >> device to go into runtime suspend. Here I noticed that both the >> operations(i.e. rmmod btusb & kill -9 ) are mandatory to >> device to go into runtime suspend. I'd like to understand how the >> driver & daemon are preventing the device to go into suspend mode, can >> you please explain me on this? > > Hi, > > btusb has support for autosuspend. > > 1. Please check whether your device supports remote wake up and isn't > quirky Right now my device does not support remote wakeup, need firmware support for this. Once I receive the firmware then i'll give a try. > 2. Try a 'hciconfig hciX down' (with X for your number > > HTH > Oliver > -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Sa, 2018-08-04 at 23:10 +0530, Muni Sekhar wrote: > > Unloading the driver and killing the 'fwupd' daemon resulted that > device to go into runtime suspend. Here I noticed that both the > operations(i.e. rmmod btusb & kill -9 ) are mandatory to > device to go into runtime suspend. I'd like to understand how the > driver & daemon are preventing the device to go into suspend mode, can > you please explain me on this? Hi, btusb has support for autosuspend. 1. Please check whether your device supports remote wake up and isn't quirky 2. Try a 'hciconfig hciX down' (with X for your number HTH Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Mon, Aug 6, 2018 at 12:09 AM, Alan Stern wrote: > On Sat, 4 Aug 2018, Muni Sekhar wrote: > >> On Fri, Aug 3, 2018 at 1:15 AM, Alan Stern wrote: >> > On Thu, 2 Aug 2018, Muni Sekhar wrote: >> > >> >> I see that CONFIG_PM_RUNTIME & CONFIG_USB_SUSPEND are not enabled. Is >> >> that fine? >> > >> > The CONFIG_PM_RUNTIME and CONFIG_USB_SUSPEND symbols are no longer >> > used. >> > >> >> The device is using btusb driver. Does unloading the driver helps? >> > >> > It should. >> > >> >> I ran ‘lsof’ and and I see that the USB device was being held open by >> >> fwupd, not sure what is ‘fwupd’? >> > >> > It is a firmware update daemon. >> > >> >> # sudo lsof +D /dev/bus/usb >> >> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system >> >> /run/user/1000/gvfs >> >> Output information may be incomplete. >> >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> >> fwupd 1631 root 49u CHR 189,67 0t0 547 /dev/bus/usb/001/068 >> >> >> >> >> >> So I killed that process(fwupd), but still device is not going to SUSPEND >> >> mode. >> >> >> >> # sudo lsof +D /dev/bus/usb >> >> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system >> >> /run/user/1000/gvfs >> >> Output information may be incomplete. >> >> >> >> >> >> # cat /sys/bus/usb/devices/1-1.3/power/runtime_status >> >> active >> > >> > Well, keeping the device might or might not prevent it from being >> > suspended. It all depends on how the driver is written. But if you >> > unload the driver then the device certainly ought to go into runtime >> > suspend. >> Unloading the driver and killing the 'fwupd' daemon resulted that >> device to go into runtime suspend. Here I noticed that both the >> operations(i.e. rmmod btusb & kill -9 ) are mandatory to >> device to go into runtime suspend. I'd like to understand how the >> driver & daemon are preventing the device to go into suspend mode, can >> you please explain me on this? > > I do not know the details, and I am completely unfamiliar with both > btusb and fwupd (and the entire Bluetooth subsystem, for that matter). > So all I can do is give a general explanation. > > When a program like fwupd holds a device open, normally it also > prevents the driver from being unloaded. Is it really possible to > rmmod btusb without first killing fwupd? Thank you very much for this clarification Alan. Yes it is possible to rmmod btusb without first killing fwupd. # lsmod | grep btusb btusb 45056 0 btrtl 16384 1 btusb btbcm 16384 1 btusb btintel16384 1 btusb bluetooth 520192 10 bnep,btbcm,btrtl,btusb,btintel # ps -ax | grep fwupd 1900 ?Sl 0:00 /usr/lib/x86_64-linux-gnu/fwupd/fwupd 3806 pts/2S+ 0:00 grep --color=auto fwupd # modprobe -r btusb # ps -ax | grep fwupd 1900 ?Sl 0:00 /usr/lib/x86_64-linux-gnu/fwupd/fwupd 3819 pts/2S+ 0:00 grep --color=auto fwupd # lsmod | grep btusb > > In any case, when a driver uses a device, it tells the runtime PM core > that it needs the device to be at full power. This will prevent the > device from going into runtime suspend (and will wake it up if it is > already suspended). When the driver is finished using the device, it > tells the runtime PM core that the device may be suspended again. > > The question now becomes: when do these messages to the runtime PM core > get sent? Some drivers send them when the device is opened and closed; > some drivers send them when a command is issued to the device and when > the reply is received, and some drivers send them only when they are > loaded and unloaded. I don't know how btusb behaves. > > Alan Stern > -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Sat, 4 Aug 2018, Muni Sekhar wrote: > On Fri, Aug 3, 2018 at 1:15 AM, Alan Stern wrote: > > On Thu, 2 Aug 2018, Muni Sekhar wrote: > > > >> I see that CONFIG_PM_RUNTIME & CONFIG_USB_SUSPEND are not enabled. Is that > >> fine? > > > > The CONFIG_PM_RUNTIME and CONFIG_USB_SUSPEND symbols are no longer > > used. > > > >> The device is using btusb driver. Does unloading the driver helps? > > > > It should. > > > >> I ran ‘lsof’ and and I see that the USB device was being held open by > >> fwupd, not sure what is ‘fwupd’? > > > > It is a firmware update daemon. > > > >> # sudo lsof +D /dev/bus/usb > >> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs > >> Output information may be incomplete. > >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > >> fwupd 1631 root 49u CHR 189,67 0t0 547 /dev/bus/usb/001/068 > >> > >> > >> So I killed that process(fwupd), but still device is not going to SUSPEND > >> mode. > >> > >> # sudo lsof +D /dev/bus/usb > >> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs > >> Output information may be incomplete. > >> > >> > >> # cat /sys/bus/usb/devices/1-1.3/power/runtime_status > >> active > > > > Well, keeping the device might or might not prevent it from being > > suspended. It all depends on how the driver is written. But if you > > unload the driver then the device certainly ought to go into runtime > > suspend. > Unloading the driver and killing the 'fwupd' daemon resulted that > device to go into runtime suspend. Here I noticed that both the > operations(i.e. rmmod btusb & kill -9 ) are mandatory to > device to go into runtime suspend. I'd like to understand how the > driver & daemon are preventing the device to go into suspend mode, can > you please explain me on this? I do not know the details, and I am completely unfamiliar with both btusb and fwupd (and the entire Bluetooth subsystem, for that matter). So all I can do is give a general explanation. When a program like fwupd holds a device open, normally it also prevents the driver from being unloaded. Is it really possible to rmmod btusb without first killing fwupd? In any case, when a driver uses a device, it tells the runtime PM core that it needs the device to be at full power. This will prevent the device from going into runtime suspend (and will wake it up if it is already suspended). When the driver is finished using the device, it tells the runtime PM core that the device may be suspended again. The question now becomes: when do these messages to the runtime PM core get sent? Some drivers send them when the device is opened and closed; some drivers send them when a command is issued to the device and when the reply is received, and some drivers send them only when they are loaded and unloaded. I don't know how btusb behaves. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Fri, Aug 3, 2018 at 1:15 AM, Alan Stern wrote: > On Thu, 2 Aug 2018, Muni Sekhar wrote: > >> I see that CONFIG_PM_RUNTIME & CONFIG_USB_SUSPEND are not enabled. Is that >> fine? > > The CONFIG_PM_RUNTIME and CONFIG_USB_SUSPEND symbols are no longer > used. > >> The device is using btusb driver. Does unloading the driver helps? > > It should. > >> I ran ‘lsof’ and and I see that the USB device was being held open by >> fwupd, not sure what is ‘fwupd’? > > It is a firmware update daemon. > >> # sudo lsof +D /dev/bus/usb >> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs >> Output information may be incomplete. >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> fwupd 1631 root 49u CHR 189,67 0t0 547 /dev/bus/usb/001/068 >> >> >> So I killed that process(fwupd), but still device is not going to SUSPEND >> mode. >> >> # sudo lsof +D /dev/bus/usb >> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs >> Output information may be incomplete. >> >> >> # cat /sys/bus/usb/devices/1-1.3/power/runtime_status >> active > > Well, keeping the device might or might not prevent it from being > suspended. It all depends on how the driver is written. But if you > unload the driver then the device certainly ought to go into runtime > suspend. Unloading the driver and killing the 'fwupd' daemon resulted that device to go into runtime suspend. Here I noticed that both the operations(i.e. rmmod btusb & kill -9 ) are mandatory to device to go into runtime suspend. I'd like to understand how the driver & daemon are preventing the device to go into suspend mode, can you please explain me on this? > > Alan Stern > -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Thu, 2 Aug 2018, Muni Sekhar wrote: > I see that CONFIG_PM_RUNTIME & CONFIG_USB_SUSPEND are not enabled. Is that > fine? The CONFIG_PM_RUNTIME and CONFIG_USB_SUSPEND symbols are no longer used. > The device is using btusb driver. Does unloading the driver helps? It should. > I ran ‘lsof’ and and I see that the USB device was being held open by > fwupd, not sure what is ‘fwupd’? It is a firmware update daemon. > # sudo lsof +D /dev/bus/usb > lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs > Output information may be incomplete. > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > fwupd 1631 root 49u CHR 189,67 0t0 547 /dev/bus/usb/001/068 > > > So I killed that process(fwupd), but still device is not going to SUSPEND > mode. > > # sudo lsof +D /dev/bus/usb > lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs > Output information may be incomplete. > > > # cat /sys/bus/usb/devices/1-1.3/power/runtime_status > active Well, keeping the device might or might not prevent it from being suspended. It all depends on how the driver is written. But if you unload the driver then the device certainly ought to go into runtime suspend. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Thu, Aug 2, 2018 at 8:21 PM, Alan Stern wrote: > On Thu, 2 Aug 2018, Muni Sekhar wrote: > >> On Thu, Aug 2, 2018 at 7:08 PM, Alan Stern wrote: >> > On Thu, 2 Aug 2018, Muni Sekhar wrote: >> > >> >> [ Please keep me in CC as I'm not subscribed to the list] >> >> >> >> >> >> Hello All, >> >> >> >> >> >> I’ve an Ubuntu 16.04 LTS PC with 4.4.0-124-generic kernel version. >> >> >> >> I want to test the dynamic suspend for the below mentioned connected >> >> USB device. >> >> >> >> Bus 003 Device 028: ID 0cf3:e300 Atheros Communications, Inc. >> >> >> >> >> >> First I’d like to know the required configuration(kernel built) of the >> >> kernel for supporting the dynamic suspend for USB. >> >> >> >> My kernel had been built with the below mentioned configuration: >> >> CONFIG_SUSPEND=y >> >> CONFIG_HIBERNATION=y >> >> CONFIG_PM=y >> >> >> >> Any other kernel configuration required for supporting the dynamic >> >> suspend? >> > >> > No. >> > >> >> How can I suspend a particular USB device? >> > >> > You have to do something like: >> > >> > echo auto >/sys/bus/usb/devices/.../power/control >> > >> > where the "..." is filled in with the appropriate name for the >> > particular device. There are some programs, like powertop, which will >> > do this for you automatically. >> Thank you Alan for this information. I wrote 'auto' to power/control, >> but still device not going to suspend mode(power/runtime_status is >> 'active'). Any other factors needs to be considered? > > Yes, there are other factors. They depend on how device's driver is > written. > > I don't know exactly what kind of device you're talking about, what > driver it uses, or what the driver's requirements are. Since the > vendor is Atheros, I guess it's a wifi card. Perhaps turning wifi off > will allow the device to be suspended; you'll probably have to check > with the driver's author or maintainer to find out for certain. I see that CONFIG_PM_RUNTIME & CONFIG_USB_SUSPEND are not enabled. Is that fine? The device is using btusb driver. Does unloading the driver helps? T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 68 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e300 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I ran ‘lsof’ and and I see that the USB device was being held open by fwupd, not sure what is ‘fwupd’? # sudo lsof +D /dev/bus/usb lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME fwupd 1631 root 49u CHR 189,67 0t0 547 /dev/bus/usb/001/068 So I killed that process(fwupd), but still device is not going to SUSPEND mode. # sudo lsof +D /dev/bus/usb lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. # cat /sys/bus/usb/devices/1-1.3/power/runtime_status active > > Alan Stern > >> Here is the my log: >> >> # cat /sys/bus/usb/devices/1-1.3/idVendor >> 0cf3 >> # cat /sys/bus/usb/devices/1-1.3/idProduct >> e300 >> # cat /sys/bus/usb/devices/1-1.3/power/control >> on >> # cat /sys/bus/usb/devices/1-1.3/power/runtime_status >> active >> # cat /sys/bus/usb/devices/1-1.3/power/runtime_suspended_time >> 0 >> # echo auto > /sys/bus/usb/devices/1-1.3/power/control >> # cat /sys/bus/usb/devices/1-1.3/power/control >> auto >> # cat /sys/bus/usb/devices/1-1.3/power/runtime_status >> active > -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Thu, 2 Aug 2018, Muni Sekhar wrote: > On Thu, Aug 2, 2018 at 7:08 PM, Alan Stern wrote: > > On Thu, 2 Aug 2018, Muni Sekhar wrote: > > > >> [ Please keep me in CC as I'm not subscribed to the list] > >> > >> > >> Hello All, > >> > >> > >> I’ve an Ubuntu 16.04 LTS PC with 4.4.0-124-generic kernel version. > >> > >> I want to test the dynamic suspend for the below mentioned connected > >> USB device. > >> > >> Bus 003 Device 028: ID 0cf3:e300 Atheros Communications, Inc. > >> > >> > >> First I’d like to know the required configuration(kernel built) of the > >> kernel for supporting the dynamic suspend for USB. > >> > >> My kernel had been built with the below mentioned configuration: > >> CONFIG_SUSPEND=y > >> CONFIG_HIBERNATION=y > >> CONFIG_PM=y > >> > >> Any other kernel configuration required for supporting the dynamic suspend? > > > > No. > > > >> How can I suspend a particular USB device? > > > > You have to do something like: > > > > echo auto >/sys/bus/usb/devices/.../power/control > > > > where the "..." is filled in with the appropriate name for the > > particular device. There are some programs, like powertop, which will > > do this for you automatically. > Thank you Alan for this information. I wrote 'auto' to power/control, > but still device not going to suspend mode(power/runtime_status is > 'active'). Any other factors needs to be considered? Yes, there are other factors. They depend on how device's driver is written. I don't know exactly what kind of device you're talking about, what driver it uses, or what the driver's requirements are. Since the vendor is Atheros, I guess it's a wifi card. Perhaps turning wifi off will allow the device to be suspended; you'll probably have to check with the driver's author or maintainer to find out for certain. Alan Stern > Here is the my log: > > # cat /sys/bus/usb/devices/1-1.3/idVendor > 0cf3 > # cat /sys/bus/usb/devices/1-1.3/idProduct > e300 > # cat /sys/bus/usb/devices/1-1.3/power/control > on > # cat /sys/bus/usb/devices/1-1.3/power/runtime_status > active > # cat /sys/bus/usb/devices/1-1.3/power/runtime_suspended_time > 0 > # echo auto > /sys/bus/usb/devices/1-1.3/power/control > # cat /sys/bus/usb/devices/1-1.3/power/control > auto > # cat /sys/bus/usb/devices/1-1.3/power/runtime_status > active -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Thu, Aug 2, 2018 at 7:08 PM, Alan Stern wrote: > On Thu, 2 Aug 2018, Muni Sekhar wrote: > >> [ Please keep me in CC as I'm not subscribed to the list] >> >> >> Hello All, >> >> >> I’ve an Ubuntu 16.04 LTS PC with 4.4.0-124-generic kernel version. >> >> I want to test the dynamic suspend for the below mentioned connected >> USB device. >> >> Bus 003 Device 028: ID 0cf3:e300 Atheros Communications, Inc. >> >> >> First I’d like to know the required configuration(kernel built) of the >> kernel for supporting the dynamic suspend for USB. >> >> My kernel had been built with the below mentioned configuration: >> CONFIG_SUSPEND=y >> CONFIG_HIBERNATION=y >> CONFIG_PM=y >> >> Any other kernel configuration required for supporting the dynamic suspend? > > No. > >> How can I suspend a particular USB device? > > You have to do something like: > > echo auto >/sys/bus/usb/devices/.../power/control > > where the "..." is filled in with the appropriate name for the > particular device. There are some programs, like powertop, which will > do this for you automatically. Thank you Alan for this information. I wrote 'auto' to power/control, but still device not going to suspend mode(power/runtime_status is 'active'). Any other factors needs to be considered? Here is the my log: # cat /sys/bus/usb/devices/1-1.3/idVendor 0cf3 # cat /sys/bus/usb/devices/1-1.3/idProduct e300 # cat /sys/bus/usb/devices/1-1.3/power/control on # cat /sys/bus/usb/devices/1-1.3/power/runtime_status active # cat /sys/bus/usb/devices/1-1.3/power/runtime_suspended_time 0 # echo auto > /sys/bus/usb/devices/1-1.3/power/control # cat /sys/bus/usb/devices/1-1.3/power/control auto # cat /sys/bus/usb/devices/1-1.3/power/runtime_status active > >> How do I verify whether the device went to suspended mode or >> not(without connecting the USB analyzer)? > > cat /sys/bus/usb/devices/.../power/runtime_status > > will tell you whether or not the device is currently suspended. > > Alan Stern > -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Thu, 2 Aug 2018, Muni Sekhar wrote: > [ Please keep me in CC as I'm not subscribed to the list] > > > Hello All, > > > I’ve an Ubuntu 16.04 LTS PC with 4.4.0-124-generic kernel version. > > I want to test the dynamic suspend for the below mentioned connected > USB device. > > Bus 003 Device 028: ID 0cf3:e300 Atheros Communications, Inc. > > > First I’d like to know the required configuration(kernel built) of the > kernel for supporting the dynamic suspend for USB. > > My kernel had been built with the below mentioned configuration: > CONFIG_SUSPEND=y > CONFIG_HIBERNATION=y > CONFIG_PM=y > > Any other kernel configuration required for supporting the dynamic suspend? No. > How can I suspend a particular USB device? You have to do something like: echo auto >/sys/bus/usb/devices/.../power/control where the "..." is filled in with the appropriate name for the particular device. There are some programs, like powertop, which will do this for you automatically. > How do I verify whether the device went to suspended mode or > not(without connecting the USB analyzer)? cat /sys/bus/usb/devices/.../power/runtime_status will tell you whether or not the device is currently suspended. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb: dynamic suspend
[ Please keep me in CC as I'm not subscribed to the list] Hello All, I’ve an Ubuntu 16.04 LTS PC with 4.4.0-124-generic kernel version. I want to test the dynamic suspend for the below mentioned connected USB device. Bus 003 Device 028: ID 0cf3:e300 Atheros Communications, Inc. First I’d like to know the required configuration(kernel built) of the kernel for supporting the dynamic suspend for USB. My kernel had been built with the below mentioned configuration: CONFIG_SUSPEND=y CONFIG_HIBERNATION=y CONFIG_PM=y Any other kernel configuration required for supporting the dynamic suspend? How can I suspend a particular USB device? How do I verify whether the device went to suspended mode or not(without connecting the USB analyzer)? -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
