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? 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
