summaryrefslogtreecommitdiff
path: root/net/bluetooth/hci_request.c
diff options
context:
space:
mode:
authorTakashi Sakamoto <o-takashi@sakamocchi.jp>2019-11-01 22:13:21 +0900
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-12-31 16:44:32 +0100
commit86b2eb94b0fc535a62f67666bab8fc4cb81a886c (patch)
tree1f61f4bacdb3c6440caf433b62b2c3679c513ed4 /net/bluetooth/hci_request.c
parente9cd798d6300a14e48ef46bbfa1b5bcf5d97c87c (diff)
ALSA: bebob: expand sleep just after breaking connections for protocol version 1
[ Upstream commit d3eabe939aee3ffd5b133766a932629a9746298c ] As long as I investigated, some devices with BeBoB protocol version 1 can be freezed during several hundreds milliseconds after breaking connections. When accessing during the freezed time, any transaction is corrupted. In the worst case, the device is going to reboot. I can see this issue in: * Roland FA-66 * M-Audio FireWire Solo This commit expands sleep just after breaking connections to avoid the freezed time as much as possible. I note that the freeze/reboot behaviour is similar to below models: * Focusrite Saffire Pro 10 I/O * Focusrite Saffire Pro 26 I/O The above models certainly reboot after breaking connections. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191101131323.17300-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'net/bluetooth/hci_request.c')
0 files changed, 0 insertions, 0 deletions