summaryrefslogtreecommitdiffstats
path: root/fs/omfs
diff options
context:
space:
mode:
authorHans de Goede <hdegoede@redhat.com>2021-01-28 17:33:12 +0100
committerMarcel Holtmann <marcel@holtmann.org>2021-01-29 16:37:00 +0100
commit219991e6be7f4a31d471611e265b72f75b2d0538 (patch)
treeb621ebf7e8cb7ad6cd56f5d0230f937bcd101d18 /fs/omfs
parentBluetooth: L2CAP: Try harder to accept device not knowing options (diff)
downloadlinux-219991e6be7f4a31d471611e265b72f75b2d0538.tar.xz
linux-219991e6be7f4a31d471611e265b72f75b2d0538.zip
Bluetooth: Add new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk
Some devices, e.g. the RTL8723BS bluetooth part, some USB attached devices, completely drop from the bus on a system-suspend. These devices will have their driver unbound and rebound on resume (when the dropping of the bus gets detected) and will show up as a new HCI after resume. These devices do not benefit from the suspend / resume handling work done by the hci_suspend_notifier. At best this unnecessarily adds some time to the suspend/resume time. But this may also actually cause problems, if the code doing the driver unbinding runs after the pm-notifier then the hci_suspend_notifier code will try to talk to a device which is now in an uninitialized state. This commit adds a new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk which allows drivers to opt-out of the hci_suspend_notifier when they know beforehand that their device will be fully re-initialized / reprobed on resume. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'fs/omfs')
0 files changed, 0 insertions, 0 deletions