linux-toradex.git/drivers/bluetooth, branch v6.4-rc2

Bluetooth: btusb: Add WCN6855 devcoredump support

2023-04-24T05:07:27+00:00

WCN6855 will report memdump via ACL data or HCI event when
it get crashed, so we collect memdump to debug firmware.

Signed-off-by: Tim Jiang 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btnxpuart: Enable flow control before checking boot signature

2023-04-24T05:07:11+00:00

This enables flow control before checking for bootloader signature and
deciding whether FW download is needed or not. In case of V1 bootloader
chips w8987 and w8997, it is observed that if WLAN FW is downloaded first
and power save is enabled in wlan core, bootloader signatures are not
emitted by the BT core when the chip is put to sleep. As a result, the
driver skips FW download and subsequent HCI commands get timeout errors
in dmesg as shown below:

[  112.898867] Bluetooth: hci0: Opcode 0x c03 failed: -110
[  114.914865] Bluetooth: hci0: Setting baudrate failed (-110)
[  116.930856] Bluetooth: hci0: Setting wake-up method failed (-110)

By enabling the flow control, the host enables its RTS pin, and an
interrupt in chip's UART peripheral causes the bootloader to wake up,
enabling the bootloader signatures, which then helps in downloading
the bluetooth FW file.

This changes all instances of 0/1 for serdev_device_set_flow_control()
to false/true.

Signed-off-by: Neeraj Sanjay Kale 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btrtl: Add the support for RTL8851B

2023-04-24T05:06:40+00:00

Add the support for RTL8851B BT controller on USB interface.
The necessary firmware will be submitted to linux-firmware project.

Note that the Bluetooth devices WITH the VID=0x0bda would be set the
feature quirk in btrtl_setup_realtek(). It's able to ignore the
feature flag set for the specific VID and PID in blacklist_table[] of
btusb.c. (check [1])

If Realtek Bluetooth chips WITHOUT the VID=0x0bda, it shall be added
the feature flag for the specific VID and PID in blacklist_table[] of
btusb.c. (check [2])

[1] '9ab9235fe5cf ("Bluetooth: btrtl: Enable WBS for the specific
    Realtek devices")'
[2] '73280f13c9bb ("Bluetooth: btusb: Add the more support IDs for
    Realtek RTL8822CE")'

The device info from /sys/kernel/debug/usb/devices as below.

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 33 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=b851 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=802.11ax WLAN Adapter
S:  SerialNumber=00E04C885A01
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 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=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) 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=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
I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Signed-off-by: Max Chou 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btnxpuart: Fix sparse warnings

2023-04-24T05:06:24+00:00

This fixes the following sparse warnings:

   drivers/bluetooth/btnxpuart.c:681:23: sparse: sparse:
   restricted __le16 degrades to integer
   drivers/bluetooth/btnxpuart.c:690:82: sparse:
   sparse: incorrect type in argument 2 (different base types)
   @@     expected unsigned short [usertype] req_len
   @@     got restricted __le16 [usertype] len @@
   drivers/bluetooth/btnxpuart.c:690:82: sparse:
   expected unsigned short [usertype] req_len
   drivers/bluetooth/btnxpuart.c:690:82: sparse:
   got restricted __le16 [usertype] len
   drivers/bluetooth/btnxpuart.c:694:84: sparse:
   sparse: incorrect type in argument 2 (different base types)
   @@     expected unsigned short [usertype] req_len
   @@     got restricted __le16 [usertype] len @@
   drivers/bluetooth/btnxpuart.c:694:84: sparse:
   expected unsigned short [usertype] req_len
   drivers/bluetooth/btnxpuart.c:694:84: sparse:
   got restricted __le16 [usertype] len
   drivers/bluetooth/btnxpuart.c:708:23: sparse:
   sparse: incorrect type in assignment (different base types)
   @@     expected unsigned int [usertype] requested_len
   @@     got restricted __le16 [usertype] len @@
   drivers/bluetooth/btnxpuart.c:708:23: sparse:
   expected unsigned int [usertype] requested_len
   drivers/bluetooth/btnxpuart.c:708:23: sparse:
   got restricted __le16 [usertype] len
   drivers/bluetooth/btnxpuart.c:787:78: sparse:
   sparse: incorrect type in argument 2 (different base types)
   @@     expected unsigned short [usertype] chipid
   @@     got restricted __le16 [usertype] chip_id @@
   drivers/bluetooth/btnxpuart.c:787:78: sparse:
   expected unsigned short [usertype] chipid
   drivers/bluetooth/btnxpuart.c:787:78: sparse:
   got restricted __le16 [usertype] chip_id
   drivers/bluetooth/btnxpuart.c:810:74: sparse:
   sparse: incorrect type in argument 2 (different base types)
   @@     expected unsigned short [usertype] req_len
   @@     got restricted __le16 [usertype] len @@
   drivers/bluetooth/btnxpuart.c:810:74: sparse:
   expected unsigned short [usertype] req_len
   drivers/bluetooth/btnxpuart.c:810:74: sparse:
   got restricted __le16 [usertype] len
   drivers/bluetooth/btnxpuart.c:815:76: sparse:
   sparse: incorrect type in argument 2 (different base types)
   @@     expected unsigned short [usertype] req_len
   @@     got restricted __le16 [usertype] len @@
   drivers/bluetooth/btnxpuart.c:815:76: sparse:
   expected unsigned short [usertype] req_len
   drivers/bluetooth/btnxpuart.c:815:76: sparse:
   got restricted __le16 [usertype] len
   drivers/bluetooth/btnxpuart.c:834:16: sparse:
   sparse: restricted __le32 degrades to integer
   drivers/bluetooth/btnxpuart.c:843:55: sparse:
   sparse: restricted __le32 degrades to integer
   drivers/bluetooth/btnxpuart.c:844:36: sparse:
   sparse: incorrect type in argument 3 (different base types)
   @@     expected unsigned long [usertype]
   @@     got restricted __le16 [usertype] len @@
   drivers/bluetooth/btnxpuart.c:844:36: sparse:
   expected unsigned long [usertype]
   drivers/bluetooth/btnxpuart.c:844:36: sparse:
   got restricted __le16 [usertype] len

Reported-by: kernel test robot 
Link: https://lore.kernel.org/oe-kbuild-all/202304160736.Tsa0zTBU-lkp@intel.com/
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btrtl: Firmware format v2 support

2023-04-24T05:06:09+00:00

Realtek changed the format of the firmware file as v2. The driver
should implement the patch to extract the firmware data from the
firmware file. The future chips must apply this patch for firmware loading.
This patch is compatible with the both previous format and v2 as well.

Signed-off-by: Allen Chen 
Signed-off-by: Alex Lu 
Tested-by: Hilda Wu 
Signed-off-by: Max Chou 
Signed-off-by: Luiz Augusto von Dentz

Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work"

2023-04-24T05:04:52+00:00

This reverts commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f.

This patch introduces a possible null-ptr-def problem. Revert it. And the
fixed bug by this patch have resolved by commit 73f7b171b7c0 ("Bluetooth:
btsdio: fix use after free bug in btsdio_remove due to race condition").

Fixes: 1e9ac114c442 ("Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work")
Signed-off-by: Liu Jian 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Add new quirk for broken set random RPA timeout for ATS2851

2023-04-24T05:04:26+00:00

The ATS2851 based controller advertises support for command "LE Set Random
Private Address Timeout" but does not actually implement it, impeding the
controller initialization.

Add the quirk HCI_QUIRK_BROKEN_SET_RPA_TIMEOUT to unblock the controller
initialization.

< HCI Command: LE Set Resolvable Private... (0x08|0x002e) plen 2
        Timeout: 900 seconds
> HCI Event: Command Status (0x0f) plen 4
      LE Set Resolvable Private Address Timeout (0x08|0x002e) ncmd 1
        Status: Unknown HCI Command (0x01)

Co-developed-by: imoc 
Signed-off-by: imoc 
Signed-off-by: Raul Cheleguini 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: vhci: Fix info leak in force_devcd_write()

2023-04-24T05:02:57+00:00

There are a number of bugs here:

1) If "count" is less than sizeof(dump_data.data) then it copies
   uninitialized data.
2) If simple_write_to_buffer() returns -EFAULT then we run into a
   problem "ret < count" comparison.  "count" is an unsigned long so the
   comparison is type promoted to unsigned long and the negative returns
   become high positive values.  That also results in copying
   uninitialized data.
3) If "*ppos" is non-zero then the first part of the dump_data
   buffer is uninitialized.  Using copy_from_user() instead of
   simple_write_to_buffer() is more appropriate here.

Fixes: d5d5df6da0aa ("Bluetooth: Add vhci devcoredump support")
Signed-off-by: Dan Carpenter 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_qca: mark OF related data as maybe unused

2023-04-24T05:02:43+00:00

The driver can be compile tested with !CONFIG_OF making certain data
unused.

Signed-off-by: Steev Klimaszewski 
Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btnxpuart: No need to check the received bootloader signature

2023-04-24T05:01:59+00:00

We can never assume the uart will deliver a complete packet to the BT
layer at once, the expected packet may be divided into several parts by
uart as uart doesn't know the received packet size, the received data
count may mismatch with the expected packet size, so here
is_valid_bootloader_signature() check may always return false.

Even we remove the count check in is_valid_bootloader_signature(), then
the first part of the data which includes the packet type can pass the
is_valid_bootloader_signature() check, but the remaining parts don't
have the packet type data still cannot pass the check, here return
directly will cause the data loss.

So need to remove the received bootloader signature check here, the
h4_recv_buf() can help us combine the different data received into one
packet. If any out-of-sync or incomplete bootloader signature is received,
it is safe to ignore and discard it, and process the next bootloader
signature.

Co-developed-by: Sherry Sun 
Signed-off-by: Sherry Sun 
Signed-off-by: Neeraj Sanjay Kale 
Signed-off-by: Luiz Augusto von Dentz