- 05 Aug, 2021 11 commits
-
-
Tedd Ho-Jeong An authored
This patch changes the exported functions to static if they are no longer used by others. Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Tedd Ho-Jeong An authored
This patch moves the hci quirks for Intel devices into the setup routines and cleaned up the driver flags. Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch refactors the setup routines for legacy and TLV based bootloader devices to the combined setup, and move the related functions from btusb to btintel. Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch adds a combined set_diag functions. It also changes the btintel_set_diag_mfg() to static since it is no longer used by others. Signed-off-by:
-
Tedd Ho-Jeong An authored
Some platforms have an issue with BT LED when the interface is down or BT radio is turned off, which takes 5 seconds to BT LED goes off. This command turns off the BT LED immediately. This patch sends the Intel vendor command to turn off the LED. Signed-off-by:
-
Tedd Ho-Jeong An authored
The some legacy ROM controllers have a bug with the first HCI command sent to it returning number of completed commands as zero, which would stall the command processing in the Bluetooth core. As a workaround, send HCI Rest command first which will reset the controller to fix the issue. Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch adds a data structure for btintel for btintel object, and the definition of bootloder states. It also adds macros to set/test/clear the flags. Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch refactors the setup routines for legacy ROM product into combined setup, and move the related functions from btusb to btintel. Signed-off-by:
-
Tedd Ho-Jeong An authored
There are multiple setup and shutdown functions for Intel device and the setup function to be used is depends on the USB PID/VID, which makes difficult to maintain the code and increases the code size. This patch adds combined setup and shutdown functions to provide a single entry point for all Intel devices and choose the setup functions based on the information read with HCI_Intel_Read_Version command. Starting from TyP device, the command and response parameters for HCI_Intel_Read_Version command are changed even though OCF remains same. However, the legacy devices still can handle the command without error even if it has a extra parameter, so to simplify the flow, the new command format is used to read the version information for both legacy and new (tlv based) format. Also, it also adds a routine to setup the hdev callbacks in btintel. Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch adds support hdev to allocate extra size for private data. The size of private data is specified in the hdev_alloc_size(priv_size) and the allocated buffer can be accessed with hci_get_priv(hdev). Signed-off-by:
-
Colin Ian King authored
An earlier commit replaced using batostr to using %pMR sprintf for the construction of session->name. Static analysis detected that this new method can use a total of 21 characters (including the trailing '\0') so we need to increase the BTNAMSIZ from 18 to 21 to fix potential buffer overflows. Addresses-Coverity: ("Out-of-bounds write") Fixes: fcb73338 ("Bluetooth: Use %pMR in sprintf/seq_printf instead of batostr") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
- 04 Aug, 2021 4 commits
-
-
Larry Finger authored
This Realtek device has both wifi and BT components. The latter reports a USB ID of 04ca:4006, which is not in the table. The portion of /sys/kernel/debug/usb/devices pertaining to this device is T: Bus=02 Lev=01 Prnt=01 Port=12 Cnt=04 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=4006 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:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
-
mark-yw.chen authored
When the firmware hang or command no response, driver can reset the bluetooth mcu via USB to recovery it. The reset steps as follows. 1. Cancel USB transfer requests before reset. 2. It use speicific USB HW Register to reset Bluetooth MCU, at the same time, the USB Endpoint0 still keep alive. 3. Poll the USB HW register until reset is completed by Endpoint0. 4. To recovery unexpected USB state and behavior during resetting the Bluetooth MCU, the driver need to reset the USB device for MT7921. 5. After the reset is completed, the Bluetooth MCU need to re-setup, such as download patch, power-on sequence and etc. Signed-off-by:
mark-yw.chen <mark-yw.chen@mediatek.com> Reviewed-by:
Michael Sun <michaelfsun@google.com> Reviewed-by:
Archie Pusaka <apusaka@chromium.org> Signed-off-by:
-
mark-yw.chen authored
Mediatek Bluetooth controller sends the FW log and FW dump via EP2. This patch creates an MTK specified callback(btusb_recv_acl_mtk) to replace the original one (hci_recv_frame) when an MTK controller is detected. The new callback will separate the firmware dump traffics from the ACL data to have them process separately. 1. Add a new field (recv_acl) to the btusb_data struct to store vendor-specific ACL callback handler. 2. Add the MTK-specific ACL callback handler (btusb_recv_acl_mtk) to process ACL data, debug log, and firmware dump. 3. The debug log traces LMP/LL events and connection quality reports. 4. The upper layer can use hci_channel_monitor to receive these packets. Example btmon: firmware debug log. 1. Enable firmware debug log. < HCI Command: Vendor (0x3f|0x005d) plen 4 00 00 02 02 .... > HCI Event: Command Complete (0x0e) plen 8 Vendor (0x3f|0x005d) ncmd 1 Status: Success (0x00) 00 00 02 02 .... 2. Diagnostic packet from controller = Vendor Diagnostic (len 500) ff 05 f0 01 fd ff 02 0e 08 01 5d fc 00 00 00 02 02 aa aa aa cb e3 f0 15 b0 0c 5f 01 00 d1 0f 33 01 7f 00 08 57 61 0c 00 00 00 00 00 23 37 17 00 fd ff 00 00 29 60 ff ff b1 56 e8 00 57 40 0a 40 39 95 f2 00 47 40 43 00 fc f0 16 00 57 61 0c 00 00 00 00 00 23 37 17 00 fd ff 00 00 29 60 ff ff 65 95 f2 00 57 40 0a 40 ec d3 fc 00 47 40 3b 00 2c f1 17 00 57 61 0c 00 00 00 00 00 23 37 17 00 fd ff 00 00 29 60 ff ff 19 d4 fc 00 57 40 76 1c b2 61 01 01 47 40 b3 04 0b 63 18 00 fe ff 02 01 04 05 33 8b 9e 08 00 aa aa aa aa aa 27 38 01 02 01 00 00 00 02 e0 10 00 20 00 20 00 2a 08 40 00 20 00 20 08 2a 08 02 00 40 00 00 01 2e 08 40 00 01 67 b0 c2 2e 08 3e 07 ff ff ff ff 40 08 01 00 02 00 00 00 34 08 a3 00 00 00 00 00 34 08 a3 00 00 00 00 00 35 08 45 01 00 00 00 00 2e 08 40 00 01 67 b0 c2 30 35 01 02 00 00 00 00 2c 31 01 00 02 00 00 40 2d 19 03 00 00 40 00 00 fd ff 02 0f 04 00 01 01 04 aa aa aa aa aa aa aa 57 61 0c 00 00 00 00 00 23 46 32 00 01 00 00 00 2f 35 00 02 00 00 00 00 29 35 ff 02 00 22 00 00 2d 31 a6 02 02 00 00 00 31 6c 40 00 14 63 18 1b 31 6c 40 00 14 63 18 23 51 08 53 00 12 63 18 00 2c 35 12 01 fe 00 00 00 2b 35 fe 02 02 00 00 00 2f 31 21 00 00 00 02 00 75 61 01 00 4c 1b 93 00 79 61 01 00 00 00 00 00 12 e3 63 18 20 31 86 01 74 61 68 03 00 00 04 00 a1 73 ff 00 b9 01 00 00 a1 73 04 00 00 00 00 00 a1 73 00 00 00 00 00 00 a1 73 00 00 02 00 00 00 31 6c 40 00 16 63 18 0c 31 6c 40 00 16 63 18 1c 77 61 40 00 48 33 40 00 14 e3 63 18 40 31 86 01 00 d1 02 c5 07 23 a1 34 73 61 37 02 02 00 00 a1 Signed-off-by: -
Andy Shevchenko authored
Kernel doc validator complains about few missed parameter descriptions. Fill the gap by describing them. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
- 03 Aug, 2021 2 commits
-
-
Luiz Augusto von Dentz authored
Code was checking if random_addr and hdev->rpa match without first checking if the RPA has not been set (BDADDR_ANY), furthermore it was clearing HCI_RPA_EXPIRED before the command completes and the RPA is actually programmed which in case of failure would leave the expired RPA still set. Since advertising instance have a similar problem the clearing of HCI_RPA_EXPIRED has been moved to hci_event.c after checking the random address is in fact the hdev->rap and then proceed to set the expire timeout. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
This adds a field to track if advertising instances are enabled or not and only clear HCI_LE_ADV flag if there is no instance left advertising. Signed-off-by:
-
- 02 Aug, 2021 1 commit
-
-
mark-yw.chen authored
The Mdiatek MT7921(7961) support MSFT HCI extensions, we are using 0xFD30 for VsMsftOpCode. Signed-off-by:
-
- 29 Jul, 2021 6 commits
-
-
Ismael Ferreras Morezuelas authored
Turns out Hans de Goede completed the work I started last year trying to improve Chinese-clone detection of CSR controller chips. Quirk after quirk these Bluetooth dongles are more usable now. Even after a few BlueZ regressions; these clones are so fickle that some days they stop working altogether. Except on Windows, they work fine. But this force-suspend initialization quirk seems to mostly do the trick, after a lot of testing Bluetooth now seems to work *all* the time. The only problem is that the solution ended up being masked under a very stringent check; when there are probably hundreds of fake dongle models out there that benefit from a good reset. Make it so. Fixes: 81cac64b ("Bluetooth: Deal with USB devices that are faking CSR vendor") Fixes: cde1a8a9 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers") Fixes: d74e0ae7 ("Bluetooth: btusb: Fix detection of some fake CSR controllers with a bcdDevice val of 0x0134") Fixes: 0671c066 ("Bluetooth: btusb: Add workaround for remote-wakeup issues with Barrot 8041a02 fake CSR controllers") Cc: stable@vger.kernel.org Cc: Hans de Goede <hdegoede@redhat.com> Tested-by:
Ismael Ferreras Morezuelas <swyterzone@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Chethan T N authored
The Intel TyphoonPeak, GarfieldPeak Bluetooth controllers support the Microsoft vendor extension and they are using 0xFC1E for VsMsftOpCode. Verified on a GarfieldPeak device through bluetoothctl show Signed-off-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
-
Michael Sun authored
The Qualcomm WCN6855 Bluetooth controller supports the Microsoft vendor extension, enable them by setting VsMsftOpCode to 0xFD70. Verified on a WCN6855 device through bluetoothctl show Signed-off-by:
-
Ian Mackinnon authored
Remove the btusb_table entry for 413c:8197 so the device is handled by the later Dell vendor entry, which specifies patchram loading. T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=413c ProdID=8197 Rev= 1.12 S: Manufacturer=Dell Computer Corp S: Product=DW380 Bluetooth Module S: SerialNumber=74E54354F609 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=btusb E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by:
Ian Mackinnon <imackinnon@gmail.com> Tested-By:
Aathif Naseer <aathif394@gmail.com> Signed-off-by:
-
Len Baker authored
strcpy() performs no bounds checking on the destination buffer. This could result in linear overflows beyond the end of the buffer, leading to all kinds of misbehaviors. The safe replacement is strscpy() but in this case it is better to use the scnprintf to simplify the arithmetic. This is a previous step in the path to remove the strcpy() function entirely from the kernel. Signed-off-by:
Len Baker <len.baker@gmx.com> Signed-off-by:
-
Desmond Cheong Zhi Xi authored
Syzbot reported a corrupted list in kobject_add_internal [1]. This happens when multiple HCI_EV_SYNC_CONN_COMPLETE event packets with status 0 are sent for the same HCI connection. This causes us to register the device more than once which corrupts the kset list. As this is forbidden behavior, we add a check for whether we're trying to process the same HCI_EV_SYNC_CONN_COMPLETE event multiple times for one connection. If that's the case, the event is invalid, so we report an error that the device is misbehaving, and ignore the packet. Link: https://syzkaller.appspot.com/bug?extid=66264bf2fd0476be7e6c [1] Reported-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com Tested-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com Signed-off-by:
Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by:
-
- 28 Jul, 2021 2 commits
-
-
Tedd Ho-Jeong An authored
This patch fixes the MGMT add_advertising command repsones with the wrong opcode when it is trying to return the not supported error. Fixes: cbbdfa6f ("Bluetooth: Enable controller RPA resolution using Experimental feature") Signed-off-by:
-
Tetsuo Handa authored
syzbot is hitting might_sleep() warning at hci_sock_dev_event() due to calling lock_sock() with rw spinlock held [1]. It seems that history of this locking problem is a trial and error. Commit b40df574 ("[PATCH] bluetooth: fix socket locking in hci_sock_dev_event()") in 2.6.21-rc4 changed bh_lock_sock() to lock_sock() as an attempt to fix lockdep warning. Then, commit 4ce61d1c ("[BLUETOOTH]: Fix locking in hci_sock_dev_event().") in 2.6.22-rc2 changed lock_sock() to local_bh_disable() + bh_lock_sock_nested() as an attempt to fix sleep in atomic context warning. Then, commit 4b5dd696 ("Bluetooth: Remove local_bh_disable() from hci_sock.c") in 3.3-rc1 removed local_bh_disable(). Then, commit e305509e ("Bluetooth: use correct lock to prevent UAF of hdev object") in 5.13-rc5 again changed bh_lock_sock_nested() to lock_sock() as an attempt to fix CVE-2021-3573. This difficulty comes from current implementation that hci_sock_dev_event(HCI_DEV_UNREG) is responsible for dropping all references from sockets because hci_unregister_dev() immediately reclaims resources as soon as returning from hci_sock_dev_event(HCI_DEV_UNREG). But the history suggests that hci_sock_dev_event(HCI_DEV_UNREG) was not doing what it should do. Therefore, instead of trying to detach sockets from device, let's accept not detaching sockets from device at hci_sock_dev_event(HCI_DEV_UNREG), by moving actual cleanup of resources from hci_unregister_dev() to hci_release_dev() which is called by bt_host_release when all references to this unregistered device (which is a kobject) are gone. Link: https://syzkaller.appspot.com/bug?extid=a5df189917e79d5e59c9 [1] Reported-by:
syzbot <syzbot+a5df189917e79d5e59c9@syzkaller.appspotmail.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by:
-
- 24 Jul, 2021 1 commit
-
-
Michael Sun authored
Add the valid le states quirk for WCN6855 and GarfieldPeak controller so the 'central-peripheral' role is exposed in userspace. Signed-off-by:
-
- 23 Jul, 2021 3 commits
-
-
Archie Pusaka authored
This patch allows the controller to suspend after a short period of inactivity. Signed-off-by:
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by:
Hilda Wu <hildawu@realtek.com> Signed-off-by:
-
Archie Pusaka authored
For chips that doesn't reset on suspend, we need to provide the correct value of flow_control when it resumes. Therefore, store the flow control value when reading from the config file to be reused upon suspend. Signed-off-by:
-
Archie Pusaka authored
Some RTL chips resets the FW on suspend, so wakeup is disabled on those chips. This patch introduces this WAKEUP_DISABLE flag so that chips that doesn't reset FW on suspend can leave the flag unset and is allowed to wake the host. This patch also left RTL8822 WAKEUP_DISABLE flag unset, therefore allowing it to wake the host, and preventing reprobing on resume. Signed-off-by:
-
- 22 Jul, 2021 10 commits
-
-
Aaron Ma authored
Add support for another Foxconn / Hon Hai device with MT7921 chip. T: Bus=05 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e0cd 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:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
-
Randy Dunlap authored
kernel-doc complains about a non-kernel-doc comment that uses "/**" to begin the comment, so change it to just "/*". drivers/bluetooth/btrsi.c:2: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Copyright (c) 2017 Redpine Signals Inc. Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Cc: Aditya Srivastava <yashsri421@gmail.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: linux-bluetooth@vger.kernel.org Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Cc: Sanjay Kumar Konduri <sanjay.konduri@redpinesignals.com> Cc: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Archie Pusaka authored
RTL8852 support MSFT HCI extension, therefore set the proper MSFT opcode. Signed-off-by:
Miao-chen Chou <mcchou@chromium.org> Reviewed-by:
-
Colin Ian King authored
The bounds check of id is off-by-one and the comparison should be >= rather >. Currently the WARN_ON_ONCE check does not stop the out of range indexing of &ldev->ctx.table[id] so also add a return path if the bounds are out of range. Addresses-Coverity: ("Illegal address computation"). Fixes: 5609c185 ("6lowpan: iphc: add support for stateful compression") Signed-off-by: -
Forest Crossman authored
The LG LGSBWAC92/TWCM-K505D/EAT64454801/EAT64454802 (it goes by many names) is a combo WiFi/Bluetooth module that's used in several models of LG TVs. It uses the MediaTek MT7668AUN, which is already supported in btusb, but this device has a non-MediaTek VID:PID pair so to get it to work we just need to add it to the list of devices to probe. Device from /sys/kernel/debug/usb/devices: T: Bus=09 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=043e ProdID=3109 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA 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=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= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) 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 Signed-off-by:
Forest Crossman <cyrozap@gmail.com> Signed-off-by:
-
Jun Miao authored
When reading the support debug features failed, there are not available features init. Continue to set the debug features is illogical, we should skip btintel_set_debug_features(), even if check it by "if (!features)". Fixes: c453b10c ("Bluetooth: btusb: Configure Intel debug feature based on available support") Signed-off-by:
Jun Miao <jun.miao@windriver.com> Signed-off-by:
-
Dan Carpenter authored
Smatch complains that some of these struct members are not initialized leading to a stack information disclosure: net/bluetooth/sco.c:778 sco_conn_defer_accept() warn: check that 'cp.retrans_effort' doesn't leak information This seems like a valid warning. I've added a default case to fix this issue. Fixes: 2f69a82a ("Bluetooth: Use voice setting in deferred SCO connection request") Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Wai Paulo Valerio Wang authored
This add supports for IMC Networks Wireless_Device Media Chip which contains the MT7921 chipset. $ lsusb Bus 001 Device 004: ID 13d3:3563 IMC Networks Wireless_Device $ cat /sys/kernel/debug/usb/devices T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3563 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:
Wai Paulo Valerio Wang <waicool20@gmail.com> Signed-off-by:
-
Hans de Goede authored
The hci_suspend_notifier which was introduced last year, is causing problems for uart attached btrtl devices. These devices may loose their firmware and their baudrate setting over a suspend/resume. Since we don't even know the baudrate after a suspend/resume recovering from this is tricky. The driver solves this by treating these devices the same as USB BT HCIs which drop of the bus during suspend. Specifically the driver: 1. Simply unconditionally turns the device fully off during system-suspend to save maximum power. 2. Calls device_reprobe() from a workqueue to fully re-init the device from scratch on system-resume (unregistering the old HCI and registering a new HCI). This means that 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 in practice this is actually causing problems: 1. These btrtl devices seem to not like the HCI_OP_WRITE_SCAN_ENABLE( SCAN_DISABLED) request being send to them when entering the BT_SUSPEND_CONFIGURE_WAKE state. The same request send on BT_SUSPEND_DISCONNECT works fine, but the second one send (unnecessarily?) from the BT_SUSPEND_CONFIGURE_WAKE transition causes the device to hang: [ 573.497754] PM: suspend entry (s2idle) [ 573.554615] Filesystems sync: 0.056 seconds [ 575.837753] Bluetooth: hci0: Timed out waiting for suspend events [ 575.837801] Bluetooth: hci0: Suspend timeout bit: 4 [ 575.837925] Bluetooth: hci0: Suspend notifier action (3) failed: -110 2. The PM_POST_SUSPEND / BT_RUNNING transition races with the driver-unbinding done by the device_reprobe() work. If the hci_suspend_notifier wins the race it is talking to a dead device leading to the following errors being logged: [ 598.686060] Bluetooth: hci0: Timed out waiting for suspend events [ 598.686124] Bluetooth: hci0: Suspend timeout bit: 5 [ 598.686237] Bluetooth: hci0: Suspend notifier action (4) failed: -110 In both cases things still work, but the suspend-notifier is causing these ugly errors getting logged and ut increase both the suspend- and the resume-time by 2 seconds. This commit avoids these problems by disabling the hci_suspend_notifier. Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Vasily Khoruzhick <anarsoul@gmail.com> Cc: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by:
-
Niklas Söderlund authored
The return type of the function is bool and while NULL do evaluate to false it's not very nice, fix this by explicitly returning false. There is no functional change. Signed-off-by:
Niklas Söderlund <niklas.soderlund@corigine.com> Signed-off-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
