- 06 Mar, 2024 40 commits
-
-
Andrey Skvortsov authored
The problem is detected by KASAN. btrtl driver uses private hci data to store 'struct btrealtek_data'. If btrtl driver is used with btusb, then memory for private hci data is allocated in btusb. But no private data is allocated after hci_dev, when btrtl is used with hci_h5. This commit adds memory allocation for hci_h5 case. ================================================================== BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl] Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76 Hardware name: Pine64 PinePhone (1.2) (DT) Workqueue: hci0 hci_power_on [bluetooth] Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_store8+0x9c/0xc0 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 53: kasan_save_stack+0x3c/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x68/0x78 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x1b4/0x3b0 hci_alloc_dev_priv+0x28/0xa58 [bluetooth] hci_uart_register_device+0x118/0x4f8 [hci_uart] h5_serdev_probe+0xf4/0x178 [hci_uart] serdev_drv_probe+0x54/0xa0 really_probe+0x254/0x588 __driver_probe_device+0xc4/0x210 driver_probe_device+0x64/0x160 __driver_attach_async_helper+0x88/0x158 async_run_entry_fn+0xd0/0x388 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x33c/0x960 queue_work_on+0x98/0xc0 hci_recv_frame+0xc8/0x1e8 [bluetooth] h5_complete_rx_pkt+0x2c8/0x800 [hci_uart] h5_rx_payload+0x98/0xb8 [hci_uart] h5_recv+0x158/0x3d8 [hci_uart] hci_uart_receive_buf+0xa0/0xe8 [hci_uart] ttyport_receive_buf+0xac/0x178 flush_to_ldisc+0x130/0x2c8 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Second to last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x788/0x960 queue_work_on+0x98/0xc0 __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth] __hci_cmd_sync+0x24/0x38 [bluetooth] btrtl_initialize+0x760/0x958 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 ================================================================== Fixes: 5b355944 ("Bluetooth: btrtl: Add btrealtek data struct") Fixes: 044014ce ("Bluetooth: btrtl: Add Realtek devcoredump support") Signed-off-by:
Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Andrey Skvortsov authored
In some cases uart-base drivers may need to use priv data. For example, to store information needed for devcoredump. Fixes: 044014ce ("Bluetooth: btrtl: Add Realtek devcoredump support") Signed-off-by:
-
Luiz Augusto von Dentz authored
In a few cases the stack may generate commands as responses to events which would happen to overwrite the sent_cmd, so this attempts to store the request in req_skb so even if sent_cmd is replaced with a new command the pending request will remain in stored in req_skb. Fixes: 6a98e383 ("Bluetooth: Add helper for serialized HCI command execution") Signed-off-by:
-
Luiz Augusto von Dentz authored
This used the hci_conn QoS to determine which PHY to scan when creating a PA Sync. Signed-off-by: -
Luiz Augusto von Dentz authored
If HCI_PA_SYNC flag is set it means there is a Periodic Advertising Synchronization pending, so this attempts to locate the address passed to HCI_OP_LE_PA_CREATE_SYNC and program it in the accept list so only reports with that address are processed. Signed-off-by: -
Iulia Tanasescu authored
This adds support to reassemble PA data for a Broadcast Sink listening socket. This is needed in case the BASE is received fragmented in multiple PA reports. PA data is first reassembled inside the hcon, before the BASE is extracted and stored inside the socket. The length of the le_per_adv_data hcon array has been raised to 1650, to accommodate the maximum PA data length that can come fragmented, according to spec. Signed-off-by:
Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by:
-
Iulia Tanasescu authored
This creates a hcon instance at bis listen, before the PA sync procedure is started. Signed-off-by:
-
Luiz Augusto von Dentz authored
This fixes the following build regression: drivers-bluetooth-btintel.c-btintel_read_version()-warn: passing-zero-to-PTR_ERR Fixes: b79e0409 ("Bluetooth: btintel: Fix null ptr deref in btintel_read_version") Signed-off-by:
-
Bartosz Golaszewski authored
The optional variants for the gpiod_get() family of functions return NULL if the GPIO in question is not associated with this device. They return ERR_PTR() on any other error. NULL descriptors are graciously handled by GPIOLIB and can be safely passed to any of the GPIO consumer interfaces as they will return 0 and act as if the function succeeded. If one is using the optional variant, then there's no point in checking for NULL. Fixes: 68456671 ("Bluetooth: hci_qca: Fix NULL vs IS_ERR_OR_NULL check in qca_serdev_probe") Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by:
-
Kiran K authored
Firmware sequencer (FSEQ) is a common code shared across Bluetooth and Wifi. Printing FSEQ will help to debug if there is any mismatch between Bluetooth and Wifi FSEQ. Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
While waiting for hci_dev_lock the hci_conn object may be cleanup causing the following trace: BUG: KASAN: slab-use-after-free in hci_connect_le_scan_cleanup+0x29/0x350 Read of size 8 at addr ffff888001a50a30 by task kworker/u3:1/111 CPU: 0 PID: 111 Comm: kworker/u3:1 Not tainted 6.8.0-rc2-00701-g8179b15ab3fd-dirty #6418 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x21/0x70 print_report+0xce/0x620 ? preempt_count_sub+0x13/0xc0 ? __virt_addr_valid+0x15f/0x310 ? hci_connect_le_scan_cleanup+0x29/0x350 kasan_report+0xdf/0x110 ? hci_connect_le_scan_cleanup+0x29/0x350 hci_connect_le_scan_cleanup+0x29/0x350 create_le_conn_complete+0x25c/0x2c0 Fixes: 881559af ("Bluetooth: hci_sync: Attempt to dequeue connection attempt") Signed-off-by:
-
Luiz Augusto von Dentz authored
Fixes the following trace where hci_acl_create_conn_sync attempts to call hci_abort_conn_sync after timeout: BUG: KASAN: slab-use-after-free in hci_abort_conn_sync (net/bluetooth/hci_sync.c:5439) Read of size 2 at addr ffff88800322c032 by task kworker/u3:2/36 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:67 ./arch/x86/include/asm/irqflags.h:127 lib/dump_stack.c:107) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) ? preempt_count_sub (kernel/sched/core.c:5889) ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:103 (discriminator 1) ./include/linux/rcupdate.h:865 (discriminator 1) ./include/linux/mmzone.h:2026 (discriminator 1) arch/x86/mm/physaddr.c:65 (discriminator 1)) ? hci_abort_conn_sync (net/bluetooth/hci_sync.c:5439) kasan_report (mm/kasan/report.c:603) ? hci_abort_conn_sync (net/bluetooth/hci_sync.c:5439) hci_abort_conn_sync (net/bluetooth/hci_sync.c:5439) ? __pfx_hci_abort_conn_sync (net/bluetooth/hci_sync.c:5433) hci_acl_create_conn_sync (net/bluetooth/hci_sync.c:6681) Fixes: 45340097 ("Bluetooth: hci_conn: Only do ACL connections sequentially") Signed-off-by:
-
Ricardo B. Marliere authored
Since commit aed65af1 ("drivers: make device_type const"), the driver core can properly handle constant struct device_type. Move the bt_type and bnep_type variables to be constant structures as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ricardo B. Marliere <ricardo@marliere.net> Signed-off-by:
-
Christophe JAILLET authored
Use devm_kstrdup() instead of hand-writing it. It is less verbose. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
Use strreplace() instead of hand-writing it. It is less verbose. Signed-off-by:
-
Luiz Augusto von Dentz authored
If connection is still queued/pending in the cmd_sync queue it means no command has been generated and it should be safe to just dequeue the callback when it is being aborted. Signed-off-by: -
Luiz Augusto von Dentz authored
This adds functions to queue, dequeue and lookup into the cmd_sync list. Signed-off-by: -
Luiz Augusto von Dentz authored
This fixes the UAF on __hci_acl_create_connection_sync caused by connection abortion, it uses the same logic as to LE_LINK which uses hci_cmd_sync_cancel to prevent the callback to run if the connection is abort prematurely. Reported-by: syzbot+3f0a39be7a2035700868@syzkaller.appspotmail.com Fixes: 45340097 ("Bluetooth: hci_conn: Only do ACL connections sequentially") Signed-off-by:
-
Luiz Augusto von Dentz authored
This aligns the use socket sk_timeo as conn_timeout when initiating a connection and then use it when scheduling the resulting HCI command, that way the command is actually aborted synchronously thus not blocking commands generated by hci_abort_conn_sync to inform the controller the connection is to be aborted. Signed-off-by: -
Lukas Bulwahn authored
Commit cec9f3c5561d ("Bluetooth: Remove BT_HS") removes config BT_HS, but misses two "ifdef BT_HS" blocks in hci_event.c. Remove this dead code from this removed config option. Signed-off-by:Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Jonas Dreßler authored
With the last commit we moved to using the hci_sync queue for "Create Connection" requests, removing the need for retrying the paging after finished/failed "Create Connection" requests and after the end of inquiries. hci_conn_check_pending() was used to trigger this retry, we can remove it now. Note that we can also remove the special handling for COMMAND_DISALLOWED errors in the completion handler of "Create Connection", because "Create Connection" requests are now always serialized. This is somewhat reverting commit 4c67bc74 ("[Bluetooth] Support concurrent connect requests"). With this, the BT_CONNECT2 state of ACL hci_conn objects should now be back to meaning only one thing: That we received a "Connection Request" from another device (see hci_conn_request_evt), but the response to that is going to be deferred. Signed-off-by:
Jonas Dreßler <verdre@v0yd.nl> Signed-off-by:
-
Jonas Dreßler authored
Pretty much all bluetooth chipsets only support paging a single device at a time, and if they don't reject a secondary "Create Connection" request while another is still ongoing, they'll most likely serialize those requests in the firware. With commit 4c67bc74 ("[Bluetooth] Support concurrent connect requests") we started adding some serialization of our own in case the adapter returns "Command Disallowed" HCI error. This commit was using the BT_CONNECT2 state for the serialization, this state is also used for a few more things (most notably to indicate we're waiting for an inquiry to cancel) and therefore a bit unreliable. Also not all BT firwares would respond with "Command Disallowed" on too many connection requests, some will also respond with "Hardware Failure" (BCM4378), and others will error out later and send a "Connect Complete" event with error "Rejected Limited Resources" (Marvell 88W8897). We can clean things up a bit and also make the serialization more reliable by using our hci_sync machinery to always do "Create Connection" requests in a sequential manner. This is very similar to what we're already doing for establishing LE connections, and it works well there. Note that this causes a test failure in mgmt-tester (test "Pair Device - Power off 1") because the hci_abort_conn_sync() changes the error we return on timeout of the "Create Connection". We'll fix this on the mgmt-tester side by adjusting the expected error for the test. Signed-off-by:
-
Luiz Augusto von Dentz authored
BIG Sync (aka. Broadcast sink) requires to inform that the device is connected when a data path is active otherwise userspace could attempt to free resources allocated to the device object while scanning. Fixes: 1d11d70d ("Bluetooth: ISO: Pass BIG encryption info through QoS") Signed-off-by:
-
Luiz Augusto von Dentz authored
High Speed, Alternate MAC and PHY (AMP) extension, has been removed from Bluetooth Core specification on 5.3: https://www.bluetooth.com/blog/new-core-specification-v5-3-feature-enhancements/ Fixes: 244bc377 ("Bluetooth: Add BT_HS config option") Signed-off-by:
-
Edward Adam Davis authored
If hci_cmd_sync_complete() is triggered and skb is NULL, then hdev->req_skb is NULL, which will cause this issue. Reported-and-tested-by: syzbot+830d9e3fa61968246abd@syzkaller.appspotmail.com Signed-off-by:
Edward Adam Davis <eadavis@qq.com> Signed-off-by:
-
Christophe JAILLET authored
ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). Note that the upper limit of ida_simple_get() is exclusive, but the one of ida_alloc_max() is inclusive. So a -1 has been added when needed. Signed-off-by:
-
Ulrik Strid authored
Add VID 13d3 & PID 3602 for MediaTek MT7925 USB Bluetooth chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=07 Lev=01 Prnt=01 Port=10 Cnt=02 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=3602 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:
Ulrik Strid <ulrik@strid.tech> Signed-off-by:
Deren Wu <deren.wu@mediatek.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
If command has timed out call __hci_cmd_sync_cancel to notify the hci_req since it will inevitably cause a timeout. This also rework the code around __hci_cmd_sync_cancel since it was wrongly assuming it needs to cancel timer as well, but sometimes the timers have not been started or in fact they already had timed out in which case they don't need to be cancel yet again. Signed-off-by: -
Jonas Dreßler authored
We have error defines already, so let's use them. Signed-off-by:
-
Jonas Dreßler authored
The "pending connections" feature was originally introduced with commit 4c67bc74 ("[Bluetooth] Support concurrent connect requests") and 6bd57416 ("[Bluetooth] Handling pending connect attempts after inquiry") to handle controllers supporting only a single connection request at a time. Later things were extended to also cancel ongoing inquiries on connect() with commit 89e65975 ("Bluetooth: Cancel Inquiry before Create Connection"). With commit a9de9248 ("[Bluetooth] Switch from OGF+OCF to using only opcodes"), hci_conn_check_pending() was introduced as a helper to consolidate a few places where we check for pending connections (indicated by the BT_CONNECT2 flag) and then try to connect. This refactoring commit also snuck in two more calls to hci_conn_check_pending(): - One is in the failure callback of hci_cs_inquiry(), this one probably makes sense: If we send an "HCI Inquiry" command and then immediately after a "Create Connection" command, the "Create Connection" command might fail before the "HCI Inquiry" command, and then we want to retry the "Create Connection" on failure of the "HCI Inquiry". - The other added call to hci_conn_check_pending() is in the event handler for the "Remote Name" event, this seems unrelated and is possibly a copy-paste error, so remove that one. Fixes: a9de9248 ("[Bluetooth] Switch from OGF+OCF to using only opcodes") Signed-off-by:
-
Jonas Dreßler authored
On a lot of platforms (at least the MS Surface devices, M1 macbooks, and a few ThinkPads) firmware doesn't do its job when rfkilling a device and the bluetooth adapter is not actually shut down properly on rfkill. This leads to connected devices remaining in connected state and the bluetooth connection eventually timing out after rfkilling an adapter. Use the rfkill hook in the HCI driver to go through the full power-off sequence (including stopping scans and disconnecting devices) before rfkilling it, just like MGMT_OP_SET_POWERED would do. In case anything during the larger power-off sequence fails, make sure the device is still closed and the rfkill ends up being effective in the end. Signed-off-by:
-
Jonas Dreßler authored
Add a new state HCI_POWERING_DOWN that indicates that the device is currently powering down, this will be useful for the next commit. Signed-off-by:
-
Jonas Dreßler authored
Queuing of power_off work was introduced in these functions with commits 8b064a3a ("Bluetooth: Clean up HCI state when doing power off") and c9910d0f ("Bluetooth: Fix disconnecting connections in non-connected states") in an effort to clean up state and do things like disconnecting devices before actually powering off the device. After that, commit a3172b7e ("Bluetooth: Add timer to force power off") introduced a timeout to ensure that the device actually got powered off, even if some of the cleanup work would never complete. This code later got refactored with commit cf75ad8b ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED"), which made powering off the device synchronous and removed the need for initiating the power_off work from other places. The timeout mentioned above got removed too, because we now also made use of the command timeout during power on/off. These days the power_off work still exists, but it only seems to only be used for HCI_AUTO_OFF functionality, which is why we never noticed those two leftover places where we queue power_off work. So let's remove that code. Fixes: cf75ad8b ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Signed-off-by:
-
Jonas Dreßler authored
With commit cf75ad8b ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED"), the power off sequence got refactored so that this timeout was no longer necessary, let's remove the leftover define from the header too. Fixes: cf75ad8b ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Signed-off-by:
-
Neeraj Sanjay Kale authored
This fixes the tx timeout issue seen while running a stress test on btnxpuart for couple of hours, such that the interval between two HCI commands coincide with the power save timeout value of 2 seconds. Test procedure using bash script: <load btnxpuart.ko> hciconfig hci0 up //Enable Power Save feature hcitool -i hci0 cmd 3f 23 02 00 00 while (true) do hciconfig hci0 leadv sleep 2 hciconfig hci0 noleadv sleep 2 done Error log, after adding few more debug prints: Bluetooth: btnxpuart_queue_skb(): 01 0A 20 01 00 Bluetooth: hci0: Set UART break: on, status=0 Bluetooth: hci0: btnxpuart_tx_wakeup() tx_work scheduled Bluetooth: hci0: btnxpuart_tx_work() dequeue: 01 0A 20 01 00 Can't set advertise mode on hci0: Connection timed out (110) Bluetooth: hci0: command 0x200a tx timeout When the power save mechanism turns on UART break, and btnxpuart_tx_work() is scheduled simultaneously, psdata->ps_state is read as PS_STATE_AWAKE, which prevents the psdata->work from being scheduled, which is responsible to turn OFF UART break. This issue is fixed by adding a ps_lock mutex around UART break on/off as well as around ps_state read/write. btnxpuart_tx_wakeup() will now read updated ps_state value. If ps_state is PS_STATE_SLEEP, it will first schedule psdata->work, and then it will reschedule itself once UART break has been turned off and ps_state is PS_STATE_AWAKE. Tested above script for 50,000 iterations and TX timeout error was not observed anymore. Signed-off-by:Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Signed-off-by:
-
Max Chou authored
Add the support for RTL8852BT/RTL8852BE-VT BT controller on USB interface. The necessary firmware will be submitted to linux-firmware project. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 8 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=8520 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> Signed-off-by:
-
Juntong Deng authored
Currently getsockopt does not support IP_ROUTER_ALERT and IPV6_ROUTER_ALERT, and we are unable to get the values of these two socket options through getsockopt. This patch adds getsockopt support for IP_ROUTER_ALERT and IPV6_ROUTER_ALERT. Signed-off-by:
Juntong Deng <juntong.deng@outlook.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== tools: ynl: add --dbg-small-recv for easier kernel testing When testing netlink dumps I usually hack some user space up to constrain its user space buffer size (iproute2, ethtool or ynl). Netlink will try to fill the messages up, so since these apps use large buffers by default, the dumps are rarely fragmented. I was hoping to figure out a way to create a selftest for dump testing, but so far I have no idea how to do that in a useful and generic way. Until someone does that, make manual dump testing easier with YNL. Create a special option for limiting the buffer size, so I don't have to make the same edits each time, and maybe others will benefit, too :) Example: $ ./cli.py [...] --dbg-small-recv >/dev/null Recv: read 3712 bytes, 29 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 3968 bytes, 31 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 532 bytes, 5 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 nl_len = 20 (4) nl_flags = 0x2 nl_type = 3 Now let's make the DONE not fit in the last message: $ ./cli.py [...] --dbg-small-recv 4499 >/dev/null Recv: read 3712 bytes, 29 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 4480 bytes, 35 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 20 bytes, 1 messages nl_len = 20 (4) nl_flags = 0x2 nl_type = 3 A real test would also have to check the messages are complete and not duplicated. That part has to be done manually right now. Note that the first message is always conservatively sized by the kernel. Still, I think this is good enough to be useful. v2: - patch 2: - move the recv_size setting up - change the default to 0 so that cli.py doesn't have to worry what the "unset" value is v1: https://lore.kernel.org/all/20240301230542.116823-1-kuba@kernel.org/ ==================== Signed-off-by: -
Jakub Kicinski authored
Most "production" netlink clients use large buffers to make dump efficient, which means that handling of dump continuation in the kernel is not very well tested. Add an option for debugging / testing handling of dumps. It enables printing of extra netlink-level debug and lowers the recv() buffer size in one go. When used without any argument (--dbg-small-recv) it picks a very small default (4000), explicit size can be set, too (--dbg-small-recv 5000). Example: $ ./cli.py [...] --dbg-small-recv Recv: read 3712 bytes, 29 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 3968 bytes, 31 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 532 bytes, 5 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 nl_len = 20 (4) nl_flags = 0x2 nl_type = 3 (the [...] are edits to shorten the commit message). Note that the first message of the dump is sized conservatively by the kernel. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Donald Hunter <donald.hunter@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
For manual debug, allow printing the netlink level messages to stderr. Reviewed-by:
-
