There are now two lists:
- the previously existing list of user defined wakelocks to block
- a new list called "wakelock_blocker_default" which comes prepopulated with the most common
and safe wakelocks to block:
qcom_rx_wakelock;wlan;wlan_wow_wl;wlan_extscan_wl;netmgr_wl;NETLINK
A combination of both wakelock lists will be blocked finally.
Signed-off-by: djb77 <dwayne.bakewell@gmail.com>
Based on ideas of FranciscoFranco's non-generic driver.
Sysfs node:
/sys/class/misc/boeffla_wakelock_blocker/wakelock_blocker
- list of wakelocks to be blocked, separated by semicolons
/sys/class/misc/boeffla_wakelock_blocker/debug
- write: 0/1 to switch off and on debug logging into dmesg
- read: get current driver internals
/sys/class/misc/boeffla_wakelock_blocker/version
- show driver version
Signed-off-by: andip71 <andreasp@gmx.de>
Signed-off-by: djb77 <dwayne.bakewell@gmail.com>
[ Upstream commit dc351d4c5f4fe4d0f274d6d660227be0c3a03317 ]
The dev->power.direct_complete flag may become set in device_prepare() in
case the device don't have any PM callbacks (dev->power.no_pm_callbacks is
set). This leads to a broken behaviour, when there is child having wakeup
enabled and relies on its parent to be used in the wakeup path.
More precisely, when the direct complete path becomes selected for the
child in __device_suspend(), the propagation of the dev->power.wakeup_path
becomes skipped as well.
Let's address this problem, by checking if the device is a part the wakeup
path or has wakeup enabled, then prevent the direct complete path from
being used.
Reported-by: Loic Pallardy <loic.pallardy@st.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[ rjw: Comment cleanup ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
