- Oct 01, 2021
-
-
Luiz Augusto von Dentz authored
prevent_wake logic is backward since what it is really checking is if the device may wakeup the system or not, not that it will prevent the to be awaken. Also looking on how other subsystems have the entry as power/wakeup this also renames the force_prevent_wake to force_wakeup in vhci driver. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Some un-support wakeup platforms keep USB power and suspend signal is coming late, this makes Realtek some chip keep its firmware, and make it never load new firmware. So use vendor specific HCI command to ask them drop its firmware after system shutdown or resume. Signed-off-by:
Hilda Wu <hildawu@realtek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Add support for TP-Link UB500 Adapter (RTL8761B) * /sys/kernel/debug/usb/devices T: Bus=01 Lev=02 Prnt=05 Port=01 Cnt=01 Dev#= 78 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2357 ProdID=0604 Rev= 2.00 S: Manufacturer= S: Product=TP-Link UB500 Adapter S: SerialNumber=E848B8C82000 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:
Nicholas Flintham <nick@flinny.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Sep 30, 2021
-
-
Marcel Holtmann authored
The rtl8821c class of Realtek devices does support the Microsoft extensions and thus enable them. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
- Sep 29, 2021
-
-
This adds force_prevent_wake which can be used to force a certain state while interacting with force_suspend. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
This adds force_suspend which can be used to force the controller into suspend/resume state. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Sep 28, 2021
-
-
btrsi.c hasn't use any macro or function declared in net/genetlink.h. Thus, these files can be removed from btrsi.c safely without affecting the compilation of the ./drivers/bluetooth module Signed-off-by:
Mianhan Liu <liumh1@shanghaitech.edu.cn> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The device table already has the option to hold device specific details and thus include the support for Microsoft extensions there as well. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
This Realtek device has both wifi and BT components. The latter reports a USB ID of 0bda:4852, which is not in the table. When adding the new device, I noticed that the RTL8852AE was mentioned in two places. These are now combined. The portion of /sys/kernel/debug/usb/devices pertaining to this device is T: Bus=06 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=4852 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 Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
This patch enables Realtek 8822C and 8852A to support the AOSP extension. Reviewed-by:
Miao-chen Chou <mcchou@chromium.org> Signed-off-by:
Joseph Hwang <josephsih@chromium.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
This patch enables Qualcomm WCN399x to support the AOSP extension. Reviewed-by:
Miao-chen Chou <mcchou@chromium.org> Signed-off-by:
Joseph Hwang <josephsih@chromium.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Sep 24, 2021
-
-
Since the hci_uart_register_device() call is the last thing we do in h5_serdev_probe() we can simply directly return its return-value. Cc: Archie Pusaka <apusaka@google.com> Suggested-by:
Archie Pusaka <apusaka@google.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
The recently added H5_WAKEUP_DISABLE h5->flags flag gets checked in h5_btrtl_open(), but it gets set in h5_serdev_probe() *after* calling hci_uart_register_device() and thus after h5_btrtl_open() is called, set this flag earlier. Also on devices where suspend/resume involves fully re-probing the HCI, runtime-pm suspend should not be used, make the runtime-pm setup conditional on the H5_WAKEUP_DISABLE flag too. This fixes the HCI being removed and then re-added every 10 seconds because it was being reprobed as soon as it was runtime-suspended. Fixes: 66f077dd ("Bluetooth: hci_h5: add WAKEUP_DISABLE flag") Fixes: d9dd833c ("Bluetooth: hci_h5: Add runtime suspend") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Archie Pusaka <apusaka@chromium.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Sep 22, 2021
-
-
Jiri Slaby authored
After the previous patch, there are no users of 'file' in n_tty_ioctl_helper. So remove it also from there. Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210914091134.17426-6-jslaby@suse.cz Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
bdev->evt_skb will get freed in the normal path and one error path of mtk_hci_wmt_sync, while the other error paths do not free it, which may cause a memleak. This bug is suggested by a static analysis tool, please advise. Fixes: e0b67035 ("Bluetooth: mediatek: update the common setup between MT7622 and other devices") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Any unprivileged user can attach N_HCI ldisc and send packets coming from a virtual controller by using PTYs. Require initial namespace CAP_NET_ADMIN to do that. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Sep 21, 2021
-
-
if platform provide gpio connect to BT_EN reset pin of qca btsoc chip, we can do hardware reset instead of usb port reset. Signed-off-by:
Tim Jiang <tjiang@codeaurora.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Sep 10, 2021
-
-
Syzbot hit general protection fault in h5_recv(). The problem was in missing NULL check. hu->serdev can be NULL and we cannot blindly pass &serdev->dev somewhere, since it can cause GPF. Fixes: d9dd833c ("Bluetooth: hci_h5: Add runtime suspend") Reported-and-tested-by:
<syzbot+7d41312fe3f123a6f605@syzkaller.appspotmail.com> Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Currently *ven_data is being assigned the return from a kmalloc call but the out-of-memory check is checking ven_data and not *ven_data. Fix this by adding the missing dereference * operator, Addresses-Coverity: ("Dereference null return") Fixes: 70dd9789 ("Bluetooth: btintel: Define a callback to fetch codec config data") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Sep 07, 2021
-
-
kirankrishnappa-intel authored
Define the callbacks required to support offload codecs Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
kirankrishnappa-intel authored
Define callback function to get codec config data. In HFP offload usecase, controllers need to be set codec details before opening SCO. This callback function is used to fetch vendor specific codec config data. Signed-off-by:
Kiran K <kiran.k@intel.com> Reviewed-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Reviewed-by:
Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
kirankrishnappa-intel authored
For Intel controllers supporting HFP offload usecase, define a callback function to fetch data_path_id Signed-off-by:
Kiran K <kiran.k@intel.com> Reviewed-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Reviewed-by:
Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
kirankrishnappa-intel authored
Read offload use cases supported by controller. Signed-off-by:
Kiran K <kiran.k@intel.com> Reviewed-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Reviewed-by:
Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
- Sep 02, 2021
-
-
Add support for another IMC Networks Mediatek Chip(MT7921) * /sys/kernel/debug/usb/devices T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3564 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:
mark-yw.chen <mark-yw.chen@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Sep 01, 2021
-
-
Add the new support ID(0x04c5, 0x165c) to usb_device_id table for Realtek RTL8852A. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04c5 ProdID=165c 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:
Max Chou <max.chou@realtek.com> Reviewed-by:
Christian Bauer <christian.bauer1.external@fujitsu.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
The information in /sys/kernel/debug/usb/devices about the MT7922U Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 18 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0e8d ProdID=7922 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:
mark-yw.chen <mark-yw.chen@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
The MediaTek chip support vendor specific HCI command(0xfc1a) to change the public address. Add hdev->set_bdaddr handler for MediaTek Chip. After doing a power cycle or MediaTek Bluetooth reset, BD_ADDR will bring back the original one. Signed-off-by:
mark-yw.chen <mark-yw.chen@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Aug 31, 2021
-
-
Boot address was not getting updated when controller is present in boot mode which is required to move the controller from boot mode to operation mode after firmware download. This patch reads boot address even if controller is present in boot mode. Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Cache Boot address present in firmware file which is later used in Intel_Soft_Reset command to bring controller from boot mode to operational mode. Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Aug 30, 2021
-
-
This patch sets up set_quality_report callback for Intel to set and reset the debug features. Reviewed-by:
Miao-chen Chou <mcchou@chromium.org> Signed-off-by:
Joseph Hwang <josephsih@chromium.org> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
This patch supports the link statistics telemetry events for intel controllers Reviewed-by:
Miao-chen Chou <mcchou@chromium.org> Signed-off-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
Joseph Hwang <josephsih@chromium.org> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
To avoid the overhead on both the controller and the host, the Intel link statistics telemetry events are disabled by default. Reviewed-by:
Miao-chen Chou <mcchou@chromium.org> Signed-off-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
Joseph Hwang <josephsih@chromium.org> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
- Aug 19, 2021
-
-
For the commit of 9e45524a, wakeup is always disabled for Realtek devices. However, there's the capability for Realtek devices to apply USB wakeup. In this commit, remove WAKEUP_DISABLE feature for Realtek devices. If users would switch wakeup, they should access "/sys/bus/usb/.../power/wakeup" In this commit, it also adds the feature as WAKEUP_AUTOSUSPEND for Realtek devices because it should set do_remote_wakeup on autosuspend. Signed-off-by:
Max Chou <max.chou@realtek.com> Tested-by:
Hilda Wu <hildawu@realtek.com> Reviewed-by:
Archie Pusaka <apusaka@chromium.org> Reviewed-by:
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Aug 16, 2021
-
-
Bluetooth on the BCM43752 needs a patchram file to function correctly. Signed-off-by:
Angus Ainslie <angus@akkea.ca> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Aug 10, 2021
-
-
P V authored
Some USB BT adapters don't satisfy the MTU requirement mentioned in commit e848dbd3 ("Bluetooth: btusb: Add support USB ALT 3 for WBS") and have ALT 3 setting that produces no/garbled audio. Some adapters with larger MTU were also reported to have problems with ALT 3. Add a flag and check it and MTU before selecting ALT 3, falling back to ALT 1. Enable the flag for Realtek, restoring the previous behavior for non-Realtek devices. Tested with USB adapters (mtu<72, no/garbled sound with ALT3, ALT1 works) BCM20702A1 0b05:17cb, CSR8510A10 0a12:0001, and (mtu>=72, ALT3 works) RTL8761BU 0bda:8771, Intel AX200 8087:0029 (after disabling ALT6). Also got reports for (mtu>=72, ALT 3 reported to produce bad audio) Intel 8087:0a2b. Signed-off-by:
Pauli Virtanen <pav@iki.fi> Fixes: e848dbd3 ("Bluetooth: btusb: Add support USB ALT 3 for WBS") Tested-by:
Michał Kępień <kernel@kempniu.pl> Tested-by:
Jonathan Lampérth <jon@h4n.dev> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
- Aug 06, 2021
-
-
Fix fall-through warnings: drivers/bluetooth/btusb.c: In function ‘btusb_recv_acl_mtk’: drivers/bluetooth/btusb.c:4033:3: warning: this statement may fall through [-Wimplicit-fallthrough=] 4033 | usb_disable_autosuspend(data->udev); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btusb.c:4034:2: note: here 4034 | case 0x05ff: /* Firmware debug logging 1 */ | ^~~~ Signed-off-by:
mark-yw.chen <mark-yw.chen@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- Aug 05, 2021
-
-
This patch combines the setting up MSFT extension for the legacy and TLV based bootloader into the common function based on hw_variant. Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
From the ThP, it supports both legacy and TLV based HCI_Intel_Read_Version command after downloading the operational firmware, and it causes the driver to choose the wrong setup routines and missing firmware/ddc file. So, as a workaround, this patch checks the fw variant from the TLV based version, and if the device is legacy bootloader device, the legacy HCI_Intel_Read_Version command is used to get the legacy version information and run the legacy bootloader setup with it. Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
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>
-
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 <tedd.an@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-