- 28 Sep, 2021 5 commits
-
-
Larry Finger authored
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>
-
Joseph Hwang authored
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:
-
Joseph Hwang authored
This patch enables Qualcomm WCN399x to support the AOSP extension. Reviewed-by:
-
Yun-Hao Chung authored
The returned opcode of command status of remove_adv is wrong when LL privacy is enabled. Signed-off-by:
Yun-Hao Chung <howardchung@chromium.org> Signed-off-by:
-
Manish Mandlik authored
During system suspend, advertisement monitoring is disabled by setting the HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable to False. This disables the monitoring during suspend, however, if the controller is monitoring a device, it sends HCI_VS_MSFT_LE_Monitor_Device_Event to indicate that the monitoring has been stopped for that particular device. This event may occur after suspend depending on the low_threshold_timeout and peer device advertisement frequency, which causes early wake up. Right way to disable the monitoring for suspend is by removing all the monitors before suspend and re-monitor after resume to ensure no events are received during suspend. This patch fixes this suspend/resume issue. Following tests are performed: - Add monitors before suspend and make sure DeviceFound gets triggered - Suspend the system and verify that all monitors are removed by kernel but not Released by bluetoothd - Wake up and verify that all monitors are added again and DeviceFound gets triggered Signed-off-by:
Manish Mandlik <mmandlik@google.com> Reviewed-by:
Archie Pusaka <apusaka@google.com> Reviewed-by:
Miao-chen Chou <mcchou@google.com> Signed-off-by:
-
- 24 Sep, 2021 2 commits
-
-
Hans de Goede authored
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:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
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:
Archie Pusaka <apusaka@chromium.org> Signed-off-by:
-
- 22 Sep, 2021 3 commits
-
-
Luiz Augusto von Dentz authored
This moves hci_debugfs_create_basic to hci_debugfs.c which is where all the others debugfs entries are handled. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Dinghao Liu authored
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:
-
Thadeu Lima de Souza Cascardo authored
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:
-
- 21 Sep, 2021 5 commits
-
-
tjiang@codeaurora.org authored
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:
-
Luiz Augusto von Dentz authored
The skb in modified by hci_send_sco which pushes SCO headers thus changing skb->len causing sco_sock_sendmsg to fail. Fixes: 0771cbb3 ("Bluetooth: SCO: Replace use of memcpy_from_msg with bt_skb_sendmsg") Tested-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
Passing NULL to PTR_ERR will result in 0 (success), also since the likes of bt_skb_sendmsg does never return NULL it is safe to replace the instances of IS_ERR_OR_NULL with IS_ERR when checking its return. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Tested-by:
-
Luiz Augusto von Dentz authored
This adds support for BT_{SND,RCV}BUF so userspace can set MTU based on the channel usage. Fixes: https://github.com/bluez/bluez/issues/201Signed-off-by: -
Luiz Augusto von Dentz authored
This moves functions manipulating EIR/Adv Data to its own file so it can be reused by other files. Signed-off-by:
-
- 13 Sep, 2021 4 commits
-
-
Luiz Augusto von Dentz authored
This makes use of bt_skb_sendmmsg instead using memcpy_from_msg which is not considered safe to be used when lock_sock is held. Also make rfcomm_dlc_send handle skb with fragments and queue them all atomically. Signed-off-by:
-
Luiz Augusto von Dentz authored
This makes use of bt_skb_sendmsg instead of allocating a different buffer to be used with memcpy_from_msg which cause one extra copy. Signed-off-by:
-
Luiz Augusto von Dentz authored
This works similarly to bt_skb_sendmsg but can split the msg into multiple skb fragments which is useful for stream sockets. Signed-off-by:
-
Luiz Augusto von Dentz authored
bt_skb_sendmsg helps takes care of allocation the skb and copying the the contents of msg over to the skb while checking for possible errors so it should be safe to call it without holding lock_sock. Signed-off-by:
-
- 10 Sep, 2021 3 commits
-
-
Pavel Skripkin authored
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:
-
Colin Ian King authored
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:
-
Miao-chen Chou authored
This splits the msft_do_{open/close} to msft_do_{open/close} and msft_{register/unregister}. With this change it is possible to retain the MSFT extension info irrespective of controller power on/off state. This helps bluetoothd to report correct 'supported features' of the controller to the D-Bus clients event if the controller is off. It also re-reads the MSFT info upon every msft_do_open(). The following test steps were performed. 1. Boot the test device and verify the MSFT support debug log in syslog. 2. Power off the controller and read the 'supported features', power on and read again. 3. Restart the bluetoothd and verify the 'supported features' value. Signed-off-by:Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by:
Alain Michaud <alainm@chromium.org> Signed-off-by:
-
- 07 Sep, 2021 13 commits
-
-
Kiran K authored
Define the callbacks required to support offload codecs Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
-
Chethan T N authored
Currently usb tranport is not allowed to suspend when SCO over HCI tranport is active. This patch shall enable the usb tranport to suspend when SCO link use non-HCI transport. Signed-off-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
-
Kiran K authored
Allow user level process to enable / disable codec offload feature through mgmt interface. By default offload codec feature is disabled. Signed-off-by:
Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by:
-
Kiran K authored
In Enhanced_Setup_Synchronous_Command, add support for msbc coding format Signed-off-by:
-
Kiran K 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 authored
For HFP offload use case, codec needs to be configured before opening SCO connection. This patch sends HCI_CONFIGURE_DATA_PATH command to configure doec before opening SCO connection. Signed-off-by:
-
Kiran K authored
< HCI Command: Enhanced Setup Synchronous Connection (0x01|0x003d) plen 59 Handle: 256 Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Packet type: 0x0380 3-EV3 may not be used 2-EV5 may not be used 3-EV5 may not be used Retransmission effort: Optimize for link quality (0x02) > HCI Event: Command Status (0x0f) plen 4 Enhanced Setup Synchronous Connection (0x01|0x003d) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 Status: Success (0x00) Handle: 257 Address: CC:98:8B:92:04:FD (SONY Visual Products Inc.) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x06 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) Signed-off-by: -
Kiran K authored
This patch allows user space to set the codec that needs to be used for HFP offload use case. The codec details are cached and the controller is configured before opening the SCO connection. Signed-off-by:
-
Kiran K authored
For Intel controllers supporting HFP offload usecase, define a callback function to fetch data_path_id Signed-off-by:
-
Kiran K authored
Add BT_CODEC option for getsockopt systemcall to get the details of offload codecs supported over SCO socket Signed-off-by:
-
Kiran K authored
Read offload use cases supported by controller. Signed-off-by:
-
Kiran K authored
Use V2 version of read local supported command is controller supports snoop: > HCI Event: Command Complete (0x0e) plen 20 Read Local Supported Codecs V2 (0x04|0x000d) ncmd 1 Status: Success (0x00) Number of supported codecs: 7 Codec: u-law log (0x00) Logical Transport Type: 0x02 Codec supported over BR/EDR SCO and eSCO Codec: A-law log (0x01) Logical Transport Type: 0x02 Codec supported over BR/EDR SCO and eSCO Codec: CVSD (0x02) Logical Transport Type: 0x02 Codec supported over BR/EDR SCO and eSCO Codec: Transparent (0x03) Logical Transport Type: 0x02 Codec supported over BR/EDR SCO and eSCO Codec: Linear PCM (0x04) Logical Transport Type: 0x02 Codec supported over BR/EDR SCO and eSCO Codec: Reserved (0x08) Logical Transport Type: 0x03 Codec supported over BR/EDR ACL Codec supported over BR/EDR SCO and eSCO Codec: mSBC (0x05) Logical Transport Type: 0x03 Codec supported over BR/EDR ACL Codec supported over BR/EDR SCO and eSCO Number of vendor codecs: 0 ...... < HCI Command: Read Local Suppor.. (0x04|0x000e) plen 7 Codec: mSBC (0x05) Logical Transport Type: 0x00 Direction: Input (Host to Controller) (0x00) > HCI Event: Command Complete (0x0e) plen 12 Read Local Supported Codec Capabilities (0x04|0x000e) ncmd 1 Status: Success (0x00) Number of codec capabilities: 1 Capabilities #0: 00 00 11 15 02 33 Signed-off-by: -
Kiran K authored
Move reading of supported local codecs into a separate init function, query codecs capabilities and cache the data Signed-off-by:
-
- 03 Sep, 2021 2 commits
-
-
Desmond Cheong Zhi Xi authored
Before freeing struct sco_conn, all delayed timeout work should be cancelled. Otherwise, sco_sock_timeout could potentially use the sco_conn after it has been freed. Additionally, sco_conn.timeout_work should be initialized when the connection is allocated, not when the channel is added. This is because an sco_conn can create channels with multiple sockets over its lifetime, which happens if sockets are released but the connection isn't deleted. Fixes: ba316be1 ("Bluetooth: schedule SCO timeouts with delayed_work") Signed-off-by:
Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by:
-
Desmond Cheong Zhi Xi authored
In sco_conn_del, conn->sk is read while holding on to the sco_conn.lock to avoid races with a socket that could be released concurrently. However, in between unlocking sco_conn.lock and calling sock_hold, it's possible for the socket to be freed, which would cause a use-after-free write when sock_hold is finally called. To fix this, the reference count of the socket should be increased while the sco_conn.lock is still held. Signed-off-by:
-
- 02 Sep, 2021 1 commit
-
-
mark-yw.chen authored
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:
-
- 01 Sep, 2021 2 commits
-
-
Max Chou authored
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:
-
mark-yw.chen authored
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:
-
