On Mon, Aug 6, 2018 at 12:09 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 4 Aug 2018, Muni Sekhar wrote: > >> On Fri, Aug 3, 2018 at 1:15 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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 <pid of fwupd>) 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 btintel 16384 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/2 S+ 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/2 S+ 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
