[PW_SID:1151352] Bluetooth: btmtksdio: Do not fail probe on wakeup init failure - #651
[PW_SID:1151352] Bluetooth: btmtksdio: Do not fail probe on wakeup init failure#651BluezTestBot wants to merge 6 commits into
Conversation
This patch adds workflow files for ci: [sync.yml] - The workflow file for scheduled work - Sync the repo with upstream repo and rebase the workflow branch - Review the patches in the patchwork and creates the PR if needed [ci.yml] - The workflow file for CI tasks - Run CI tests when PR is created Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
This replaces the bzcafe action with bluez/action-ci so we can maintain everything in the github bluez organization Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This attempts to sync every 5 minutes instead of 30. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
bluez/action-ci uses master as default branch for workflow which is incorrect for kernel Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The CI action now creates individual GitHub Check Runs per test, which requires 'checks: write' permission on the GITHUB_TOKEN. Also make the pull_request trigger types explicit to include 'reopened', allowing CI to be retriggered by closing and reopening a PR.
devm_device_init_wakeup() merely marks the device as wakeup-capable; it is only consulted later through device_may_wakeup() in the ->wakeup callback to decide whether wake-on-bluetooth can be used. When it fails, the controller itself still works normally and only the ability to wake up the system is lost. Therefore the failure is not fatal for probe(), which is why the existing code only logs the error instead of bailing out. However, the negative error code returned by devm_device_init_wakeup() is never cleared, so if the subsequent devm_gpiod_get_optional() succeeds, probe() ends up returning the stale error even though probing actually succeeded and the HCI device has already been registered. The SDIO core then wrongly treats the function as broken and unbinds the driver. Make the non-fatal semantics explicit: clear the error after logging it and keep probing. Fixes: ce64b3e ("Bluetooth: mt7921s: Support wake on bluetooth") Signed-off-by: Gongwei Li <ligongwei@kylinos.cn>
|
CheckPatch |
|
VerifyFixes |
|
VerifySignedoff |
|
GitLint |
|
SubjectPrefix |
|
BuildKernel |
|
CheckAllWarning |
|
CheckSparse |
|
BuildKernel32 |
|
CheckKernelLLVM |
|
TestRunnerSetup |
|
IncrementalBuild |
616126a to
d3899e4
Compare
4 participants
From: Gongwei Li ligongwei@kylinos.cn
devm_device_init_wakeup() merely marks the device as wakeup-capable;
it is only consulted later through device_may_wakeup() in the ->wakeup
callback to decide whether wake-on-bluetooth can be used. When it
fails, the controller itself still works normally and only the ability
to wake up the system is lost. Therefore the failure is not fatal for
probe(), which is why the existing code only logs the error instead of
bailing out.
However, the negative error code returned by devm_device_init_wakeup()
is never cleared, so if the subsequent devm_gpiod_get_optional()
succeeds, probe() ends up returning the stale error even though
probing actually succeeded and the HCI device has already been
registered. The SDIO core then wrongly treats the function as broken
and unbinds the driver.
Make the non-fatal semantics explicit: clear the error after logging
it and keep probing.
Fixes: ce64b3e ("Bluetooth: mt7921s: Support wake on bluetooth")
Signed-off-by: Gongwei Li ligongwei@kylinos.cn
drivers/bluetooth/btmtksdio.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)