Because mSBC frames do not need to be aligned to the SCO packet
boundary. Using USB ALT 3 let HCI payload >= 60 bytes, let mSBC
data satisfy 60 Bytes avoid payload unaligned situation and fixed
some headset no voise issue.

USB Alt 3 supported also need HFP support transparent MTU in 72 Bytes.
Signed-off-by: NHilda Wu <hildawu@realtek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch adds the 0cf3:e500 Bluetooth device (from a QCA9377 board) as a
QCA_ROME device.  It appears to be functionally identical to another device
ID, also from a QCA9377 board, which was previously marked as QCA_ROME in
0a03f98b
("Bluetooth: Add a new 04ca:3015 QCA_ROME device").

Without this patch, the WiFi side of the QCA9377 board is slow or unusable
when the Bluetooth side is in use.

See https://askubuntu.com/a/1137852 for another report of QCA_ROME fixing
this issue for this device ID.

/sys/kernel/debug/usb/devices:

T:  Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=e500 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
Signed-off-by: NDaniel Lenski <dlenski@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

If btusb_mtk_submit_wmt_recv_urb returns error, wc should be freed and
then error should be returned to prevent memory leak.

Addresses-Coverity: ("Prevent memory leak")
Fixes: 4cbb375e997d ("Bluetooth: btusb: Fixed too many in-token issue for Mediatek Chip.")
Signed-off-by: NMuhammad Usama Anjum <musamaanjum@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Add support for Lite-On Mediatek Chip (MT7921)
Lite On VID = 04CA.

* /sys/kernel/debug/usb/devices
T:  Bus=01 Lev=03 Prnt=04 Port=01 Cnt=02 Dev#=  8 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04ca ProdID=3802 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
Signed-off-by: Nmark-yw.chen <mark-yw.chen@mediatek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch reduce in-token during download patch procedure.
Don't submit urb for polling event before sending hci command.
Signed-off-by: Nmark-yw.chen <mark-yw.chen@mediatek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Some firmware when operation don't may have broken versions leading to
error like the following:

[    6.176482] Bluetooth: hci0: Firmware revision 0.0 build 121 week 7 2021
[    6.177906] bluetooth hci0: Direct firmware load for intel/ibt-20-0-0.sfi failed with error -2
[    6.177910] Bluetooth: hci0: Failed to load Intel firmware file intel/ibt-20-0-0.sfi (-2)

Since we load the firmware file just to check if its version had changed
comparing to the one already loaded we can just skip since the firmware
is already operation.

Fixes: ac056546 ("Bluetooth: btintel: Check firmware version before
download")
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Some models of the RTL8822ce utilize a different USB ID. Add this
new one to the Bluetooth driver.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

drivers/usb/core/hub.c: usb_new_device() contains the following:

        /* By default, forbid autosuspend for all devices.  It will be
         * allowed for hubs during binding.
         */
        usb_disable_autosuspend(udev);

So for anything which is not a hub, such as btusb devices, autosuspend is
disabled by default and we must call usb_enable_autosuspend(udev) to
enable it.

This means that the "Fix the autosuspend enable and disable" commit,
which drops the usb_enable_autosuspend() call when the enable_autosuspend
module option is true, is completely wrong, revert it.

This reverts commit 7bd9fb05.

Cc: Hui Wang <hui.wang@canonical.com>
Fixes: 7bd9fb05 ("Bluetooth: btusb: Fix the autosuspend enable and disable")
Acked-by: NHui Wang <hui.wang@canonical.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Adding support LE scatternet and WBS for Mediatek Chip
Signed-off-by: Nmark-yw.chen <mark-yw.chen@mediatek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This moves duplicated code for waiting firmware download completion to
a function that can be reused.
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: NTedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This moves duplicated code for waiting firmware download completion to
a function that can be reused.
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: NTedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This moves version checks of intel_version() to btintel_version_info().
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: NTedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This moves version checks of intel_version_tlv() to btintel_version_info_tlv().
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: NTedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In order to allow new firmware to load, it first needs to check if the
firmware version on file matches the one loaded if it doesn't, then it
needs to revert to bootloader mode in order to load the new firmware.
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: NTedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This checks the firmware build number, week and year against the
repective loaded version. If details are a match, skip the download
process.
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: NTedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

print the firmware file name on error loading from fie system
Signed-off-by: NKiran K <kiran.k@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Warnings: drivers/bluetooth/btusb.c:3775 btusb_mtk_setup() error:
uninitialized symbol 'fw_version'.
-> add initial value for fw_version.

Warnings: sparse: sparse: incorrect type in assignment (different base
types)
-> add le32_to_cpu to fix incorrect type in assignment.
Signed-off-by: Nmark-yw.chen <mark-yw.chen@mediatek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Some Xiaomi RedmiBook laptop models use the 0cb5:c547 USB identifier
for their Bluetooth device, so load the appropriate firmware for
Realtek 8822CE.

-Device(0cb5:c547) from /sys/kernel/debug/usb/devices
T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cb5 ProdID=c547 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=Bluetooth Radio
S:  SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
Signed-off-by: NRasmus Moorats <xx@nns.ee>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This issue starts from linux-5.10-rc1, I reproduced this issue on my
Dell Inspiron 7447 with BT adapter 0cf3:e005, the kernel will print
out: "Bluetooth: hci0: don't support firmware rome 0x31010000", and
someone else also reported the similar issue to bugzilla #211571.

I found this is a regression introduced by 'commit b40f58b9
("Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support"), the
patch assumed that if high ROM version is not zero, it is an adapter
on WCN6855, but many old adapters don't need to load rampatch or nvm,
and they have non-zero high ROM version.

To fix it, let the driver match the rom_version in the
qca_devices_table first, if there is no entry matched, check the
high ROM version, if it is not zero, we assume this adapter is ready
to work and no need to load rampatch and nvm like previously.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211571
Fixes: b40f58b9 ("Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support")
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Enlarging the size of 'struct btmtk_hci_wmt_cmd' makes it no longer
fit on the kernel stack, as seen from this compiler warning:

drivers/bluetooth/btusb.c:3365:12: error: stack frame size of 1036 bytes in function 'btusb_mtk_hci_wmt_sync' [-Werror,-Wframe-larger-than=]

Change the function to dynamically allocate the buffer instead.
As there are other sleeping functions called from the same location,
using GFP_KERNEL should be fine here, and the runtime overhead should
not matter as this is rarely called.

Unfortunately, I could not figure out why the message size is
increased in the previous patch. Using dynamic allocation means
any size is possible now, but there is still a range check that
limits the total size (including the five-byte header) to 255
bytes, so whatever was intended there is now undone.

Fixes: 48c13301 ("Bluetooth: btusb: Fine-tune mt7663 mechanism.")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Fix follow warning:
drivers/bluetooth/btusb.c:3479:9: warning: variable ‘fw_size’ set but not used [-Wunused-but-set-variable]
  size_t fw_size;
         ^~~~~~~
drivers/bluetooth/btusb.c:3473:29: warning: variable ‘patchhdr’ set but not used [-Wunused-but-set-variable]
  struct btmtk_patch_header *patchhdr = NULL;
                             ^~~~~~~~
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYe Bin <yebin10@huawei.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Change "deivice" to "device"

Correct "Unsupported support hardware variant (%08x)" to
"Unsupported hardware variant (%08x)"
Signed-off-by: NJupeng Zhong <zhongjupeng@yulong.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

I tried to disable the autosuspend on btusb through the module
parameter enable_autosuspend, this parameter is set to N, but the usb
bluetooth device is still runtime suspended.
$ cat /sys/module/btusb/parameters/enable_autosuspend
N
$ cat /sys/bus/usb/devices/3-10/power/runtime_status
suspended
$ cat /sys/bus/usb/devices/3-10/power/runtime_suspended_time
65187

We already set ".supports_autosuspend = 1" in the usb_driver, this
device will be set autosuspend enabled by usb core, we don't need
to call usb_enable_autosuspend() in the btusb_probe(). Instead if
users set the parameter enable_autosuspend to N, we need to call
usb_disable_autosuspend() in the btusb_probe(). After this change
and set the parameter to N, we could see the device is not runtime
suspended anymore.
$ cat /sys/module/btusb/parameters/enable_autosuspend
N
$ cat /sys/bus/usb/devices/3-10/power/runtime_status
active
$ cat /sys/bus/usb/devices/3-10/power/runtime_suspended_time
0

And if we disable the autosuspend in the btusb_probe(), we need to
enable the autosuspend in the disconnect(), this could guarantee
that the device could be runtime suspended after we rmmod the btusb.
Signed-off-by: NHui Wang <hui.wang@canonical.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In btusb_mtk_wmt_recv if skb_clone fails, the alocated skb should be
released.

Omit the labels “err_out” and “err_free_skb” in this function
implementation so that the desired exception handling code
would be directly specified in the affected if branches.

Fixes: a1c49c43 ("btusb: Add protocol support for MediaTek MT7668U USB devices")
Signed-off-by: NJupeng Zhong <zhongjupeng@yulong.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

There is mt7921 firmware download mechanism

1. Read Chip id from MT7921.

2. Download firmware by endpoint 0, it's the same mechanism with
mt7663/mt7668.
   (it's medaitek specific header format for downloading firmware.)

3. Enabling Bluetooth function.

The information in /sys/kernel/debug/usb/devices about the MT7921U
Bluetooth device is listed as the below.

  T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 40 Spd=480  MxCh= 0
  D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
  P:  Vendor=0e8d ProdID=7961 Rev= 1.00
  S:  Manufacturer=MediaTek Inc.
  S:  Product=Wireless_Device
  S:  SerialNumber=000000000
  C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
  A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
  I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
  E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
  E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
  E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
  I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
  E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
  E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
  I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
  E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
  E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
  I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
  E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
  E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
  I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
  E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
  E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
  I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
  E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
  E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
  I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
  E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
  E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
  I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
  E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
  E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
  I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
  E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
  E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
  I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
  E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
  E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Signed-off-by: NMark Chen <Mark-YW.Chen@mediatek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Fine-tune read register for mt7663/mt7921.
For mediatek chip spcific wmt protocol, we add more delay to send EP0
In-Token.
Signed-off-by: NMark Chen <Mark-YW.Chen@mediatek.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

VID:PID -> 8087:0033

cat /sys/kernel/debug/usb/devices:

T:  Bus=03 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=0033 Rev= 0.00
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
Signed-off-by: NKiran K <kiran.k@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The bt_dev_<level> macros already append a newline.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Intel JeffersonPeak, HarrisonPeak and CyclonePeak Bluetooth
controllers support the Microsoft vendor extension and they are using
0xFC1E for VsMsftOpCode.

< HCI Command: Vendor (0x3f|0x001e) plen 1
        00
> HCI Event: Command Complete (0x0e) plen 15
      Vendor (0x3f|0x001e) ncmd 1
        Status: Success (0x00)
        00 3f 00 00 00 00 00 00 00 01 50

The following test step was performed.
- Boot the test devices with HarrisonPeak and verify INFO print in
dmesg.
Signed-off-by: NMiao-chen Chou <mcchou@chromium.org>
Reviewed-by: NAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: NArchie Pusaka <apusaka@chromium.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

we should send hci reset command before bt turn off, which can reset bt
firmware status.
Signed-off-by: NTim Jiang <tjiang@codeaurora.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

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: NTrent Piepho <tpiepho@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

With the recent btusb change to detect and deal with more fake CSR
controllers, I decided to see if fake CSR controllers with Barrot
8041a02 chips would now work.

After much experimentation I came to the conclusion that it works, if I
have autosuspend enabled initially and then disable it after the device
has suspended at least once. Yes this is very weird, but I've tried many
things, like manually clearing the remote-wakeup feature. Doing a
runtime-resume + runtime suspend is the only way to get the receiver
to actually report received data (and/or pairing info) through its
bulk rx endpoint.

But the funkyness of the bulk-endpoint does not stop there, I mainly
found out about this problem, because with autosuspend enabled
(which usually ensures the suspend at least once condition is met),
the receiver stops reporting received data through its bulk rx endpoint
as soon as autosuspend kicks in. So I initially just disabled
autosuspend, but then the receiver does not work at all.

This was with a fake CSR receiver with a Barrot 8041a02 chip with a
bcdDevice value of 0x8891, a lmp_subver of 0x1012, a hci_rev of 0x0810
and a hci_ver of BLUETOOTH_VER_4_0.

Summarizing this specific fake CSR receiver has the following 2 issues:

1. The bulk rx endpoint will never report any data unless
the device was suspended at least once.

2. They will not wakeup when autosuspended and receiving data on their
bulk rx endpoint from e.g. a keyboard or mouse (IOW remote-wakeup support
is broken for the bulk endpoint).

Add a workaround for 1. which enables runtime-suspend, force-suspends
the hci and then wakes-it up by disabling runtime-suspend again.

Add a workaround for 2. which clears the hci's can_wake flag, this way
the hci will still be autosuspended when it is not open.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Commit cde1a8a9 ("Bluetooth: btusb: Fix and detect most of the
Chinese Bluetooth controllers") made the detection of fake controllers
more generic fixing it for much of the newer fakes / clones.

But this does not work for a fake CSR controller with a bcdDevice
value of 0x0134, which was correctly identified as fake before
this change.

Add an extra check for this special case, checking for a combination
of a bcdDevice value of 0x0134, together with a lmp_subver of 0x0c5c
and a hci_ver of BLUETOOTH_VER_2_0.

The chip inside this fake dongle is marked as with "clockwise cw6629d".

Fixes: cde1a8a9 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

we define many nvm files for wcn6855 btsoc and host driver
should find the correct nvm file based on board ID and then
download it.
Signed-off-by: NTim Jiang <tjiang@codeaurora.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Map Typhoon peak Intel controller to BTUSB_INTEL_NEWGEN
Signed-off-by: NKiran K <kiran.k@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Define a helper function to download firmware for new generation Intel
controllers
Signed-off-by: NKiran K <kiran.k@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Define a new function to construct firmware/ddc filename for new
generation Intel controllers
Signed-off-by: NKiran K <kiran.k@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Define a new  *setup* function for new generation Intel controllers
Signed-off-by: NKiran K <kiran.k@intel.com>
Signed-off-by: NAmit K Bag <amit.k.bag@intel.com>
Signed-off-by: NRaghuram Hegde <raghuram.hegde@intel.com>
Reviewed-by: NSathish Narasimman <Sathish.Narasimman@intel.com>
Reviewed-by: NChethan T N <chethan.tumkur.narayan@intel.com>
Reviewed-by: NSrivatsa Ravishankar <ravishankar.srivatsa@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

btusb_mtk_setup_firmware() misses to call release_firmware() in an error
path. Jump to err_release_fw to fix it.

Fixes: f6451257 ("Bluetooth: btusb: fix up firmware download sequence")
Signed-off-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Some Lenovo Ideapad laptop models use the 0bda:c123 USB identifier for
their Bluetooth device, so load the appropriate firmware for Realtek
8822CE.

-Device(0bda:c123) from /sys/kernel/debug/usb/devices
T:  Bus=03 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=c123 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=Bluetooth Radio
S:  SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
Signed-off-by: NCadel Watson <cadel@cadelwatson.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>