Message ID | 20220518123252.Bluez.1.Ie61d0e985d42728b2e705ca6dfd000385cf3870a@changeid (mailing list archive) |
---|---|
State | Accepted |
Commit | c159d790e8786581cfa5e5a9e7bd71458a343e44 |
Headers | show |
Series | [Bluez] input/device: Notify failure if ctrl disconnect when waiting intr | expand |
Context | Check | Description |
---|---|---|
tedd_an/pre-ci_am | success | Success |
Hello: This patch was applied to bluetooth/bluez.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Wed, 18 May 2022 12:33:07 +0800 you wrote: > From: Archie Pusaka <apusaka@chromium.org> > > On some rare occasions, the peer HID device might disconnect the ctrl > channel when we are trying to connect the intr channel. If this > happens, interrupt_connect_cb() will not be called by btio, and we > will be stuck in "connecting" state. Any future connection attempt to > the peer device will fail because of "busy". > > [...] Here is the summary with links: - [Bluez] input/device: Notify failure if ctrl disconnect when waiting intr https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=c159d790e878 You are awesome, thank you!
diff --git a/profiles/input/device.c b/profiles/input/device.c index ff4aa771ac..e2ac6ea603 100644 --- a/profiles/input/device.c +++ b/profiles/input/device.c @@ -581,6 +581,13 @@ static gboolean ctrl_watch_cb(GIOChannel *chan, GIOCondition cond, gpointer data if (idev->intr_io && !(cond & G_IO_NVAL)) g_io_channel_shutdown(idev->intr_io, TRUE, NULL); + /* It's possible this is triggered while the intr channel is not even + * connected yet, therefore we are still in the connecting state. + */ + if (btd_service_get_state(idev->service) == + BTD_SERVICE_STATE_CONNECTING) + btd_service_connecting_complete(idev->service, -EIO); + if (!idev->intr_io && idev->virtual_cable_unplug) virtual_cable_unplug(idev);