Skip to content
GitLab
  1. Dec 19, 2020
    • Trent Piepho's avatar
      Bluetooth: btusb: Always fallback to alt 1 for WBS · 517b6933
      Trent Piepho authored 
      When alt mode 6 is not available, fallback to the kernel <= 5.7 behavior
of always using alt mode 1.

Prior to kernel 5.8, btusb would always use alt mode 1 for WBS (Wide
Band Speech aka mSBC aka transparent SCO).  In commit baac6276
("Bluetooth: btusb: handle mSBC audio over USB Endpoints") this
was changed to use alt mode 6, which is the recommended mode in the
Bluetooth spec (Specifications of the Bluetooth System, v5.0, Vol 4.B
§2.2.1).  However, many if not most BT USB adapters do not support alt
mode 6.  In fact, I have been unable to find any which do.

In kernel 5.8, this was changed to use alt mode 6, and if not available,
use alt mode 0.  But mode 0 has a zero byte max packet length and can
not possibly work.  It is just there as a zero-bandwidth dummy mode to
work around a USB flaw that would prevent device enumeration if
insufficient bandwidth were available for the lowest isoc mode
supported.

In effect, WBS was broken for all USB-BT adapters that do not support
alt 6, which appears to nearly all of them.

Then in commit 461f95f0

 ("Bluetooth: btusb: USB alternate setting 1 for
WBS") the 5.7 behavior was restored, but only for Realtek adapters.

I've tested a Broadcom BRCM20702A and CSR 8510 adapter, both work with
the 5.7 behavior and do not with the 5.8.

So get rid of the Realtek specific flag and use the 5.7 behavior for all
adapters as a fallback when alt 6 is not available.  This was the
kernel's behavior prior to 5.8 and I can find no adapters for which it
is not correct.  And even if there is an adapter for which this does not
work, the current behavior would be to fall back to alt 0, which can not
possibly work either, and so is no better.

Signed-off-by: default avatarTrent Piepho <tpiepho@gmail.com>
Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      517b6933
    • Christophe JAILLET's avatar
      Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function · 9a39a927
      Christophe JAILLET authored 
      Some resource should be released in the error handling path of the probe
function, as already done in the remove function.

The remove function was fixed in commit 5052de8d ("soc: qcom: smd:
Transition client drivers from smd to rpmsg")

Fixes: 1511cc75

 ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9a39a927
  3. Dec 16, 2020