summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-07-21Bluetooth: hci_bcm: Add DT compatible for CYW55572Hakan Jansson
CYW55572 is a Wi-Fi + Bluetooth combo device from Infineon. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21dt-bindings: net: broadcom-bluetooth: Add conditional constraintsHakan Jansson
Add conditional constraint to make property "reset-gpios" available only for compatible devices acually having the reset pin. Make property "brcm,requires-autobaud-mode" depend on property "shutdown-gpios" as the shutdown pin is required to enter autobaud mode. I looked at all compatible devices and compiled the matrix below before formulating the conditional constraint. This was a pure paper exercise and no verification testing has been performed. d e v h i o c s s e t h - - u w w v t r a a v d d e k k b d o s e e a i w e u u t o n t p p - - - - - - s s g g g g u u p p p p t p p i i i i x l p p o o o o c p l l s s s s o o y y --------------------------------------- brcm,bcm20702a1 X X X X X X X X brcm,bcm4329-bt X X X X X X X X brcm,bcm4330-bt X X X X X X X X brcm,bcm4334-bt X - X X X X X X brcm,bcm43438-bt X - X X X X X X brcm,bcm4345c5 X - X X X X X X brcm,bcm43540-bt X - X X X X X X brcm,bcm4335a0 X - X X X X X X brcm,bcm4349-bt X - X X X X X X infineon,cyw55572-bt X - X X X X X X Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21dt-bindings: net: broadcom-bluetooth: Add CYW55572 DT bindingHakan Jansson
CYW55572 is a Wi-Fi + Bluetooth combo device from Infineon. Extend the binding with its DT compatible. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: clean up error pointer checkingDan Carpenter
The bt_skb_sendmsg() function can't return NULL so there is no need to check for that. Several of these checks were removed previously but this one was missed. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3586Hilda Wu
Add the support ID(0x13D3, 0x3586) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=03 Lev=01 Prnt=01 Port=02 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=13d3 ProdID=3586 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: Hilda Wu <hildawu@realtek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: btusb: Add Realtek RTL8852C support ID 0x13D3:0x3587Hilda Wu
Add the support ID(0x13D3, 0x3587) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=03 Lev=01 Prnt=01 Port=02 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=13d3 ProdID=3587 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: Hilda Wu <hildawu@realtek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0CB8:0xC558Hilda Wu
Add the support ID(0x0CB8, 0xC558) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=03 Lev=01 Prnt=01 Port=02 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=0cb8 ProdID=c558 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: Hilda Wu <hildawu@realtek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: btusb: Add Realtek RTL8852C support ID 0x04C5:0x1675Hilda Wu
Add the support ID(0x04c5, 0x1675) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=03 Lev=01 Prnt=01 Port=02 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=1675 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: Hilda Wu <hildawu@realtek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: btusb: Add Realtek RTL8852C support ID 0x04CA:0x4007Hilda Wu
Add the support ID(0x04CA, 0x4007) to usb_device_id table for Realtek RTL8852C. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=03 Lev=01 Prnt=01 Port=02 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=04ca ProdID=4007 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: Hilda Wu <hildawu@realtek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: Add default wakeup callback for HCI UART driverYing Hsu
Bluetooth HCI devices indicate if they are able to wakeup in the wakeup callback since 'commit 4539ca67fe8e ("Bluetooth: Rename driver .prevent_wake to .wakeup")'. This patch adds a default wakeup callback for Bluetooth HCI UAR devices. It assumes Bluetooth HCI UART devices are wakeable for backward compatibility. For those who need a customized behavior, one can override it before calling hci_uart_register_device(). Fixes: 4539ca67fe8e ("Bluetooth: Rename driver .prevent_wake to .wakeup") Signed-off-by: Ying Hsu <yinghsu@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: hci_sync: Don't remove connected devices from accept listLuiz Augusto von Dentz
These devices are likely going to be reprogrammed when disconnected so this avoid a whole bunch of commands attempt to remove and the add back to the list. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Tested-by: Zhengping Jiang <jiangzp@google.com>
2022-07-21Bluetooth: hci_sync: Fix not updating privacy_modeLuiz Augusto von Dentz
When programming a new entry into the resolving list it shall default to network mode since the params may contain the mode programmed when the device was last added to the resolving list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=209745 Fixes: 853b70b506a20 ("Bluetooth: hci_sync: Set Privacy Mode when updating the resolving list") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Tested-by: Zhengping Jiang <jiangzp@google.com>
2022-07-21Bluetooth: Collect kcov coverage from hci_rx_workTamas Koczka
Annotate hci_rx_work() with kcov_remote_start() and kcov_remote_stop() calls, so remote KCOV coverage is collected while processing the rx_q queue which is the main incoming Bluetooth packet queue. Coverage is associated with the thread which created the packet skb. The collected extra coverage helps kernel fuzzing efforts in finding vulnerabilities. This change only has effect if the kernel is compiled with CONFIG_KCOV, otherwise kcov_ functions don't do anything. Signed-off-by: Tamas Koczka <poprdi@google.com> Tested-by: Aleksandr Nogikh <nogikh@google.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: hci_sync: Fix resuming scan after suspend resumeZhengping Jiang
After resuming, remove setting scanning_paused to false, because it is checked and set to false in hci_resume_scan_sync. Also move setting the value to false before updating passive scan, because the value is used when resuming passive scan. Fixes: 3b42055388c30 (Bluetooth: hci_sync: Fix attempting to suspend with unfiltered passive scan) Signed-off-by: Zhengping Jiang <jiangzp@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: btmtksdio: Add in-band wakeup supportSean Wang
Commit ce64b3e94919 ("Bluetooth: mt7921s: Support wake on bluetooth") adds the wake on bluethooth via a dedicated GPIO. Extend the wake-on-bluetooth to use the SDIO DAT1 pin (in-band wakeup), when supported by the SDIO host driver. Co-developed-by: Yake Yang <yake.yang@mediatek.com> Signed-off-by: Yake Yang <yake.yang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: mgmt: Fix refresh cached connection infoZhengping Jiang
Set the connection data before calling get_conn_info_sync, so it can be verified the connection is still connected, before refreshing cached values. Fixes: 47db6b42991e6 ("Bluetooth: hci_sync: Convert MGMT_OP_GET_CONN_INFO") Signed-off-by: Zhengping Jiang <jiangzp@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: HCI: Fix not always setting Scan Response/Advertising DataLuiz Augusto von Dentz
The scan response and advertising data needs to be tracked on a per instance (adv_info) since when these instaces are removed so are their data, to fix that new flags are introduced which is used to mark when the data changes and then checked to confirm when the data needs to be synced with the controller. Tested-by: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: eir: Fix using strlen with hdev->{dev_name,short_name}Luiz Augusto von Dentz
Both dev_name and short_name are not guaranteed to be NULL terminated so this instead use strnlen and then attempt to determine if the resulting string needs to be truncated or not. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216018 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-07-21Bluetooth: use memset avoid memory leaksXiaohui Zhang
Similar to the handling of l2cap_ecred_connect in commit d3715b2333e9 ("Bluetooth: use memset avoid memory leaks"), we thought a patch might be needed here as well. Use memset to initialize structs to prevent memory leaks in l2cap_le_connect Signed-off-by: Xiaohui Zhang <xiaohuizhang@ruc.edu.cn> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: fix an error code in hci_register_dev()Dan Carpenter
Preserve the error code from hci_register_suspend_notifier(). Don't return success. Fixes: d6bb2a91f95b ("Bluetooth: Unregister suspend with userchannel") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: hci_bcm: Add BCM4349B1 variantAhmad Fatoum
The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth portion can be controlled over serial. Two subversions are added for the chip, because ROM firmware reports 002.002.013 (at least for the chips I have here), while depending on patchram firmware revision, either 002.002.013 or 002.002.014 is reported. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21dt-bindings: bluetooth: broadcom: Add BCM4349B1 DT bindingAhmad Fatoum
The BCM4349B1, aka CYW/BCM89359, is a WiFi+BT chip and its Bluetooth portion can be controlled over serial. Extend the binding with its DT compatible. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: Unregister suspend with userchannelAbhishek Pandit-Subedi
When HCI_USERCHANNEL is used, unregister the suspend notifier when binding and register when releasing. The userchannel socket should be left alone after open is completed. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: Fix index added after unregisterAbhishek Pandit-Subedi
When a userchannel socket is released, we should check whether the hdev is already unregistered before sending out an IndexAdded. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: When HCI work queue is drained, only queue chained workSchspa Shi
The HCI command, event, and data packet processing workqueue is drained to avoid deadlock in commit 76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state"). There is another delayed work, which will queue command to this drained workqueue. Which results in the following error report: Bluetooth: hci2: command 0x040f tx timeout WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140 Workqueue: events hci_cmd_timeout RIP: 0010:__queue_work+0xdad/0x1140 RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093 RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000 RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08 RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700 R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60 R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800 FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? queue_work_on+0xcb/0x110 ? lockdep_hardirqs_off+0x90/0xd0 queue_work_on+0xee/0x110 process_one_work+0x996/0x1610 ? pwq_dec_nr_in_flight+0x2a0/0x2a0 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_lock_irq+0x41/0x50 worker_thread+0x665/0x1080 ? process_one_work+0x1610/0x1610 kthread+0x2e9/0x3a0 ? kthread_complete_and_exit+0x40/0x40 ret_from_fork+0x1f/0x30 </TASK> To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue the timeout workqueue while command workqueue is draining. Fixes: 76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state") Reported-by: syzbot+63bed493aebbf6872647@syzkaller.appspotmail.com Signed-off-by: Schspa Shi <schspa@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: hci_intel: Add check for platform_driver_registerJiasheng Jiang
As platform_driver_register() could fail, it should be better to deal with the return value in order to maintain the code consisitency. Fixes: 1ab1f239bf17 ("Bluetooth: hci_intel: Add support for platform driver") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: clear the temporary linkkey in hci_conn_cleanupAlain Michaud
If a hardware error occurs and the connections are flushed without a disconnection_complete event being signaled, the temporary linkkeys are not flushed. This change ensures that any outstanding flushable linkkeys are flushed when the connection are flushed from the hash table. Additionally, this also makes use of test_and_clear_bit to avoid multiple attempts to delete the link key that's already been flushed. Signed-off-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: hci_bcm: Add support for FW loading in autobaud modeHakan Jansson
Use the presence of a DT property, "brcm,requires-autobaud-mode", to enable startup in autobaud mode. If the property is present, the device is started in autobaud mode by asserting RTS (BT_UART_CTS_N) prior to powering on the device. Also prevent the use of unsupported commands for devices started in autobaud mode. Only a limited subset of HCI commands are supported in autobaud mode. Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate in normal mode when first powered on. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21dt-bindings: net: broadcom-bluetooth: Add property for autobaud modeHakan Jansson
Add property, "brcm,requires-autobaud-mode", to enable autobaud mode selection. Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading. Autobaud mode can also be required on some boards where the controller device is using a non-standard baud rate when first powered on. Signed-off-by: Hakan Jansson <hakan.jansson@infineon.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: hci_qca: Return wakeup for qca_wakeupSai Teja Aluvala
This fixes the return value of qca_wakeup(), since .wakeup work inversely with original .prevent_wake. Fixes: 4539ca67fe8ed (Bluetooth: Rename driver .prevent_wake to .wakeup) Signed-off-by: Sai Teja Aluvala <quic_saluvala@quicinc.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21Bluetooth: btusb: Add support of IMC Networks PID 0x3568Aaron Ma
It is 13d3:3568 for MediaTek MT7922 USB Bluetooth chip. T: Bus=03 Lev=01 Prnt=01 Port=02 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=3568 Rev=01.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=... C: #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-07-21net: ipa: fix buildPaolo Abeni
After commit 2c7b9b936bdc ("net: ipa: move configuration data files into a subdirectory"), build of the ipa driver fails with the following error: drivers/net/ipa/data/ipa_data-v3.1.c:9:10: fatal error: gsi.h: No such file or directory After the mentioned commit, all the file included by the configuration are in the parent directory. Fix the issue updating the include path. Fixes: 2c7b9b936bdc ("net: ipa: move configuration data files into a subdirectory") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/7105112c38cfe0642a2d9e1779bf784a7aa63d16.1658411666.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-22bpf, docs: Use SPDX license identifier in bpf_doc.pyAlejandro Colomar
The Linux man-pages project now uses SPDX tags, instead of the full license text. Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://www.kernel.org/doc/man-pages/licenses.html Link: https://spdx.org/licenses/Linux-man-pages-copyleft.html Link: https://lore.kernel.org/bpf/20220721110821.8240-1-alx.manpages@gmail.com
2022-07-22bpf, arm64: Fix compile error in dummy_tramp()Xu Kuohai
dummy_tramp() uses "lr" to refer to the x30 register, but some assembler does not recognize "lr" and reports a build failure: /tmp/cc52xO0c.s: Assembler messages: /tmp/cc52xO0c.s:8: Error: operand 1 should be an integer register -- `mov lr,x9' /tmp/cc52xO0c.s:7: Error: undefined symbol lr used as an immediate value make[2]: *** [scripts/Makefile.build:250: arch/arm64/net/bpf_jit_comp.o] Error 1 make[1]: *** [scripts/Makefile.build:525: arch/arm64/net] Error 2 So replace "lr" with "x30" to fix it. Fixes: b2ad54e1533e ("bpf, arm64: Implement bpf_arch_text_poke() for arm64") Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Link: https://lore.kernel.org/bpf/20220721121319.2999259-1-xukuohai@huaweicloud.com
2022-07-21ice: add write functionality for GNSS TTYKarol Kolacinski
Add the possibility to write raw bytes to the GNSS module through the first TTY device. This allows user to configure the module. Create a second read-only TTY device. Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-07-21Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
No conflicts. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-21ublk_drv: fix lockdep warningMing Lei
ub->mutex is used to protecting reading and writing ub->mm, then the following lockdep warning is triggered. Fix it by using one dedicated spin lock for protecting ub->mm. [1] lockdep warning [ 25.046186] ====================================================== [ 25.048886] WARNING: possible circular locking dependency detected [ 25.051610] 5.19.0-rc4_for-v5.20+ #149 Not tainted [ 25.053665] ------------------------------------------------------ [ 25.056334] ublk/989 is trying to acquire lock: [ 25.058296] ffff975d0329a918 (&disk->open_mutex){+.+.}-{3:3}, at: bd_register_pending_holders+0x2a/0x110 [ 25.063678] [ 25.063678] but task is already holding lock: [ 25.066246] ffff975d1df59708 (&ub->mutex){+.+.}-{3:3}, at: ublk_ctrl_uring_cmd+0x2df/0x730 [ 25.069423] [ 25.069423] which lock already depends on the new lock. [ 25.069423] [ 25.072603] [ 25.072603] the existing dependency chain (in reverse order) is: [ 25.074908] [ 25.074908] -> #3 (&ub->mutex){+.+.}-{3:3}: [ 25.076386] __mutex_lock+0x93/0x870 [ 25.077470] ublk_ch_mmap+0x3a/0x140 [ 25.078494] mmap_region+0x375/0x5a0 [ 25.079386] do_mmap+0x33a/0x530 [ 25.080168] vm_mmap_pgoff+0xb9/0x150 [ 25.080979] ksys_mmap_pgoff+0x184/0x1f0 [ 25.081838] do_syscall_64+0x37/0x80 [ 25.082653] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 25.083730] [ 25.083730] -> #2 (&mm->mmap_lock#2){++++}-{3:3}: [ 25.084707] __might_fault+0x55/0x80 [ 25.085344] _copy_from_user+0x1e/0xa0 [ 25.086020] get_sg_io_hdr+0x26/0xb0 [ 25.086651] scsi_ioctl+0x42f/0x960 [ 25.087267] sr_block_ioctl+0xe8/0x100 [ 25.087734] blkdev_ioctl+0x134/0x2b0 [ 25.088196] __x64_sys_ioctl+0x8a/0xc0 [ 25.088677] do_syscall_64+0x37/0x80 [ 25.089044] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 25.089548] [ 25.089548] -> #1 (&cd->lock){+.+.}-{3:3}: [ 25.090072] __mutex_lock+0x93/0x870 [ 25.090452] sr_block_open+0x64/0xe0 [ 25.090837] blkdev_get_whole+0x26/0x90 [ 25.091445] blkdev_get_by_dev.part.0+0x1ce/0x2f0 [ 25.092203] blkdev_open+0x52/0x90 [ 25.092617] do_dentry_open+0x1ca/0x360 [ 25.093499] path_openat+0x78d/0xcb0 [ 25.094136] do_filp_open+0xa1/0x130 [ 25.094759] do_sys_openat2+0x76/0x130 [ 25.095454] __x64_sys_openat+0x5c/0x70 [ 25.096078] do_syscall_64+0x37/0x80 [ 25.096637] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 25.097304] [ 25.097304] -> #0 (&disk->open_mutex){+.+.}-{3:3}: [ 25.098229] __lock_acquire+0x12e2/0x1f90 [ 25.098789] lock_acquire+0xbf/0x2c0 [ 25.099256] __mutex_lock+0x93/0x870 [ 25.099706] bd_register_pending_holders+0x2a/0x110 [ 25.100246] device_add_disk+0x209/0x370 [ 25.100712] ublk_ctrl_uring_cmd+0x405/0x730 [ 25.101205] io_issue_sqe+0xfe/0x2ac0 [ 25.101665] io_submit_sqes+0x352/0x1820 [ 25.102131] __do_sys_io_uring_enter+0x848/0xdc0 [ 25.102646] do_syscall_64+0x37/0x80 [ 25.103087] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 25.103640] [ 25.103640] other info that might help us debug this: [ 25.103640] [ 25.104549] Chain exists of: [ 25.104549] &disk->open_mutex --> &mm->mmap_lock#2 --> &ub->mutex [ 25.104549] [ 25.105611] Possible unsafe locking scenario: [ 25.105611] [ 25.106258] CPU0 CPU1 [ 25.106677] ---- ---- [ 25.107100] lock(&ub->mutex); [ 25.107446] lock(&mm->mmap_lock#2); [ 25.108045] lock(&ub->mutex); [ 25.108802] lock(&disk->open_mutex); [ 25.109265] [ 25.109265] *** DEADLOCK *** [ 25.109265] [ 25.110117] 2 locks held by ublk/989: [ 25.110490] #0: ffff975d07bbf8a8 (&ctx->uring_lock){+.+.}-{3:3}, at: __do_sys_io_uring_enter+0x83e/0xdc0 [ 25.111249] #1: ffff975d1df59708 (&ub->mutex){+.+.}-{3:3}, at: ublk_ctrl_uring_cmd+0x2df/0x730 [ 25.111943] [ 25.111943] stack backtrace: [ 25.112557] CPU: 2 PID: 989 Comm: ublk Not tainted 5.19.0-rc4_for-v5.20+ #149 [ 25.113137] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-1.fc33 04/01/2014 [ 25.113792] Call Trace: [ 25.114130] <TASK> [ 25.114417] dump_stack_lvl+0x71/0xa0 [ 25.114771] check_noncircular+0xdf/0x100 [ 25.115137] ? register_lock_class+0x38/0x470 [ 25.115524] __lock_acquire+0x12e2/0x1f90 [ 25.115887] ? find_held_lock+0x2b/0x80 [ 25.116244] lock_acquire+0xbf/0x2c0 [ 25.116590] ? bd_register_pending_holders+0x2a/0x110 [ 25.117009] __mutex_lock+0x93/0x870 [ 25.117362] ? bd_register_pending_holders+0x2a/0x110 [ 25.117780] ? bd_register_pending_holders+0x2a/0x110 [ 25.118201] ? kobject_add+0x71/0x90 [ 25.118546] ? bd_register_pending_holders+0x2a/0x110 [ 25.118958] bd_register_pending_holders+0x2a/0x110 [ 25.119373] device_add_disk+0x209/0x370 [ 25.119732] ublk_ctrl_uring_cmd+0x405/0x730 [ 25.120109] ? rcu_read_lock_sched_held+0x3c/0x70 [ 25.120514] io_issue_sqe+0xfe/0x2ac0 [ 25.120863] io_submit_sqes+0x352/0x1820 [ 25.121228] ? rcu_read_lock_sched_held+0x3c/0x70 [ 25.121626] ? __do_sys_io_uring_enter+0x83e/0xdc0 [ 25.122028] ? find_held_lock+0x2b/0x80 [ 25.122390] ? __do_sys_io_uring_enter+0x848/0xdc0 [ 25.122791] __do_sys_io_uring_enter+0x848/0xdc0 [ 25.123190] ? syscall_enter_from_user_mode+0x20/0x70 [ 25.123606] ? syscall_enter_from_user_mode+0x20/0x70 [ 25.124024] do_syscall_64+0x37/0x80 [ 25.124383] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 25.124829] RIP: 0033:0x7f120a762af6 [ 25.125223] Code: 45 c1 41 89 c2 41 b9 08 00 00 00 41 83 ca 10 f6 87 d0 00 00 00 01 8b bf cc 00 00 00 44 0f 44 d0 45 31 c0c [ 25.126576] RSP: 002b:00007ffdcb3c5518 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa [ 25.127153] RAX: ffffffffffffffda RBX: 00000000013aef50 RCX: 00007f120a762af6 [ 25.127748] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000004 [ 25.128351] RBP: 000000000000000b R08: 0000000000000000 R09: 0000000000000008 [ 25.128956] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdcb3c74a6 [ 25.129524] R13: 00000000013aef50 R14: 0000000000000000 R15: 00000000000003df [ 25.130121] </TASK> Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20220721153117.591394-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-07-21riscv: add as-options for modules with assembly compontentsBen Dooks
When trying to load modules built for RISC-V which include assembly files the kernel loader errors with "unexpected relocation type 'R_RISCV_ALIGN'" due to R_RISCV_ALIGN relocations being generated by the assembler. The R_RISCV_ALIGN relocations can be removed at the expense of code space by adding -mno-relax to gcc and as. In commit 7a8e7da42250138 ("RISC-V: Fixes to module loading") -mno-relax is added to the build variable KBUILD_CFLAGS_MODULE. See [1] for more info. The issue is that when kbuild builds a .S file, it invokes gcc with the -mno-relax flag, but this is not being passed through to the assembler. Adding -Wa,-mno-relax to KBUILD_AFLAGS_MODULE ensures that the assembler is invoked correctly. This may have now been fixed in gcc[2] and this addition should not stop newer gcc and as from working. [1] https://github.com/riscv/riscv-elf-psabi-doc/issues/183 [2] https://github.com/gcc-mirror/gcc/commit/3b0a7d624e64eeb81e4d5e8c62c46d86ef521857 Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Link: https://lore.kernel.org/r/20220529152200.609809-1-ben.dooks@codethink.co.uk Fixes: ab1ef68e5401 ("RISC-V: Add sections of PLT and GOT for kernel module") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-07-21Merge tag 'mtd/fixes-for-5.19-final' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fix from Richard Weinberger: "A aingle NAND controller fix: - gpmi: Fix busy timeout setting (wrong calculation, yes again)" * tag 'mtd/fixes-for-5.19-final' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times
2022-07-21ice: add i2c write commandKarol Kolacinski
Add the possibility to write to connected i2c devices using the AQ command. FW may reject the write if the device is not on allowlist. Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-07-21Merge tag 'net-5.19-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from can. Still no major regressions, most of the changes are still due to data races fixes, plus the usual bunch of drivers fixes. Previous releases - regressions: - tcp/udp: make early_demux back namespacified. - dsa: fix issues with vlan_filtering_is_global Previous releases - always broken: - ip: fix data-races around ipv4_net_table (round 2, 3 & 4) - amt: fix validation and synchronization bugs - can: fix detection of mcp251863 - eth: iavf: fix handling of dummy receive descriptors - eth: lan966x: fix issues with MAC table - eth: stmmac: dwmac-mediatek: fix clock issue Misc: - dsa: update documentation" * tag 'net-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (107 commits) mlxsw: spectrum_router: Fix IPv4 nexthop gateway indication net/sched: cls_api: Fix flow action initialization tcp: Fix data-races around sysctl_tcp_max_reordering. tcp: Fix a data-race around sysctl_tcp_abort_on_overflow. tcp: Fix a data-race around sysctl_tcp_rfc1337. tcp: Fix a data-race around sysctl_tcp_stdurg. tcp: Fix a data-race around sysctl_tcp_retrans_collapse. tcp: Fix data-races around sysctl_tcp_slow_start_after_idle. tcp: Fix a data-race around sysctl_tcp_thin_linear_timeouts. tcp: Fix data-races around sysctl_tcp_recovery. tcp: Fix a data-race around sysctl_tcp_early_retrans. tcp: Fix data-races around sysctl knobs related to SYN option. udp: Fix a data-race around sysctl_udp_l3mdev_accept. ip: Fix data-races around sysctl_ip_prot_sock. ipv4: Fix data-races around sysctl_fib_multipath_hash_fields. ipv4: Fix data-races around sysctl_fib_multipath_hash_policy. ipv4: Fix a data-race around sysctl_fib_multipath_use_neigh. can: rcar_canfd: Add missing of_node_put() in rcar_canfd_probe() can: mcp251xfd: fix detection of mcp251863 Documentation: fix udp_wmem_min in ip-sysctl.rst ...
2022-07-21s390/archrandom: prevent CPACF trng invocations in interrupt contextHarald Freudenberger
This patch slightly reworks the s390 arch_get_random_seed_{int,long} implementation: Make sure the CPACF trng instruction is never called in any interrupt context. This is done by adding an additional condition in_task(). Justification: There are some constrains to satisfy for the invocation of the arch_get_random_seed_{int,long}() functions: - They should provide good random data during kernel initialization. - They should not be called in interrupt context as the TRNG instruction is relatively heavy weight and may for example make some network loads cause to timeout and buck. However, it was not clear what kind of interrupt context is exactly encountered during kernel init or network traffic eventually calling arch_get_random_seed_long(). After some days of investigations it is clear that the s390 start_kernel function is not running in any interrupt context and so the trng is called: Jul 11 18:33:39 t35lp54 kernel: [<00000001064e90ca>] arch_get_random_seed_long.part.0+0x32/0x70 Jul 11 18:33:39 t35lp54 kernel: [<000000010715f246>] random_init+0xf6/0x238 Jul 11 18:33:39 t35lp54 kernel: [<000000010712545c>] start_kernel+0x4a4/0x628 Jul 11 18:33:39 t35lp54 kernel: [<000000010590402a>] startup_continue+0x2a/0x40 The condition in_task() is true and the CPACF trng provides random data during kernel startup. The network traffic however, is more difficult. A typical call stack looks like this: Jul 06 17:37:07 t35lp54 kernel: [<000000008b5600fc>] extract_entropy.constprop.0+0x23c/0x240 Jul 06 17:37:07 t35lp54 kernel: [<000000008b560136>] crng_reseed+0x36/0xd8 Jul 06 17:37:07 t35lp54 kernel: [<000000008b5604b8>] crng_make_state+0x78/0x340 Jul 06 17:37:07 t35lp54 kernel: [<000000008b5607e0>] _get_random_bytes+0x60/0xf8 Jul 06 17:37:07 t35lp54 kernel: [<000000008b56108a>] get_random_u32+0xda/0x248 Jul 06 17:37:07 t35lp54 kernel: [<000000008aefe7a8>] kfence_guarded_alloc+0x48/0x4b8 Jul 06 17:37:07 t35lp54 kernel: [<000000008aeff35e>] __kfence_alloc+0x18e/0x1b8 Jul 06 17:37:07 t35lp54 kernel: [<000000008aef7f10>] __kmalloc_node_track_caller+0x368/0x4d8 Jul 06 17:37:07 t35lp54 kernel: [<000000008b611eac>] kmalloc_reserve+0x44/0xa0 Jul 06 17:37:07 t35lp54 kernel: [<000000008b611f98>] __alloc_skb+0x90/0x178 Jul 06 17:37:07 t35lp54 kernel: [<000000008b6120dc>] __napi_alloc_skb+0x5c/0x118 Jul 06 17:37:07 t35lp54 kernel: [<000000008b8f06b4>] qeth_extract_skb+0x13c/0x680 Jul 06 17:37:07 t35lp54 kernel: [<000000008b8f6526>] qeth_poll+0x256/0x3f8 Jul 06 17:37:07 t35lp54 kernel: [<000000008b63d76e>] __napi_poll.constprop.0+0x46/0x2f8 Jul 06 17:37:07 t35lp54 kernel: [<000000008b63dbec>] net_rx_action+0x1cc/0x408 Jul 06 17:37:07 t35lp54 kernel: [<000000008b937302>] __do_softirq+0x132/0x6b0 Jul 06 17:37:07 t35lp54 kernel: [<000000008abf46ce>] __irq_exit_rcu+0x13e/0x170 Jul 06 17:37:07 t35lp54 kernel: [<000000008abf531a>] irq_exit_rcu+0x22/0x50 Jul 06 17:37:07 t35lp54 kernel: [<000000008b922506>] do_io_irq+0xe6/0x198 Jul 06 17:37:07 t35lp54 kernel: [<000000008b935826>] io_int_handler+0xd6/0x110 Jul 06 17:37:07 t35lp54 kernel: [<000000008b9358a6>] psw_idle_exit+0x0/0xa Jul 06 17:37:07 t35lp54 kernel: ([<000000008ab9c59a>] arch_cpu_idle+0x52/0xe0) Jul 06 17:37:07 t35lp54 kernel: [<000000008b933cfe>] default_idle_call+0x6e/0xd0 Jul 06 17:37:07 t35lp54 kernel: [<000000008ac59f4e>] do_idle+0xf6/0x1b0 Jul 06 17:37:07 t35lp54 kernel: [<000000008ac5a28e>] cpu_startup_entry+0x36/0x40 Jul 06 17:37:07 t35lp54 kernel: [<000000008abb0d90>] smp_start_secondary+0x148/0x158 Jul 06 17:37:07 t35lp54 kernel: [<000000008b935b9e>] restart_int_handler+0x6e/0x90 which confirms that the call is in softirq context. So in_task() covers exactly the cases where we want to have CPACF trng called: not in nmi, not in hard irq, not in soft irq but in normal task context and during kernel init. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Link: https://lore.kernel.org/r/20220713131721.257907-1-freude@linux.ibm.com Fixes: e4f74400308c ("s390/archrandom: simplify back to earlier design and initialize earlier") [agordeev@linux.ibm.com changed desc, added Fixes and Link, removed -stable] Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2022-07-21mmu_gather: Force tlb-flush VM_PFNMAP vmasPeter Zijlstra
Jann reported a race between munmap() and unmap_mapping_range(), where unmap_mapping_range() will no-op once unmap_vmas() has unlinked the VMA; however munmap() will not yet have invalidated the TLBs. Therefore unmap_mapping_range() will complete while there are still (stale) TLB entries for the specified range. Mitigate this by force flushing TLBs for VM_PFNMAP ranges. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-07-21mmu_gather: Let there be one tlb_{start,end}_vma() implementationPeter Zijlstra
Now that architectures are no longer allowed to override tlb_{start,end}_vma() re-arrange code so that there is only one implementation for each of these functions. This much simplifies trying to figure out what they actually do. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-07-21csky/tlb: Remove tlb_flush() definePeter Zijlstra
The previous patch removed the tlb_flush_end() implementation which used tlb_flush_range(). This means: - csky did double invalidates, a range invalidate per vma and a full invalidate at the end - csky actually has range invalidates and as such the generic tlb_flush implementation is more efficient for it. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will@kernel.org> Tested-by: Guo Ren <guoren@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-07-21mmu_gather: Remove per arch tlb_{start,end}_vma()Peter Zijlstra
Scattered across the archs are 3 basic forms of tlb_{start,end}_vma(). Provide two new MMU_GATHER_knobs to enumerate them and remove the per arch tlb_{start,end}_vma() implementations. - MMU_GATHER_NO_FLUSH_CACHE indicates the arch has flush_cache_range() but does *NOT* want to call it for each VMA. - MMU_GATHER_MERGE_VMAS indicates the arch wants to merge the invalidate across multiple VMAs if possible. With these it is possible to capture the three forms: 1) empty stubs; select MMU_GATHER_NO_FLUSH_CACHE and MMU_GATHER_MERGE_VMAS 2) start: flush_cache_range(), end: empty; select MMU_GATHER_MERGE_VMAS 3) start: flush_cache_range(), end: flush_tlb_range(); default Obviously, if the architecture does not have flush_cache_range() then it also doesn't need to select MMU_GATHER_NO_FLUSH_CACHE. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will@kernel.org> Cc: David Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-07-21scripts/gdb: Fix gdb 'lx-symbols' commandKhalid Masum
Currently the command 'lx-symbols' in gdb exits with the error`Function "do_init_module" not defined in "kernel/module.c"`. This occurs because the file kernel/module.c was moved to kernel/module/main.c. Fix this breakage by changing the path to "kernel/module/main.c" in LoadModuleBreakpoint. Signed-off-by: Khalid Masum <khalid.masum.92@gmail.com> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Fixes: cfc1d277891e ("module: Move all into module/") Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-07-21watch-queue: remove spurious double semicolonLinus Torvalds
Sedat Dilek noticed that I had an extraneous semicolon at the end of a line in the previous patch. It's harmless, but unintentional, and while compilers just treat it as an extra empty statement, for all I know some other tooling might warn about it. So clean it up before other people notice too ;) Fixes: 353f7988dd84 ("watchqueue: make sure to serialize 'wqueue->defunct' properly") Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
2022-07-21block: remove __blk_get_queueChristoph Hellwig
__blk_get_queue is only called by blk_get_queue, so merge the two. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20220721063432.1714609-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-07-21block: call blk_mq_exit_queue from disk_release for never added disksChristoph Hellwig
To undo the all initialization from blk_mq_init_allocated_queue in case of a probe failure where add_disk is never called we have to call blk_mq_exit_queue from put_disk. This relies on the fact that drivers always call blk_mq_free_tag_set after calling put_disk in the probe error path if they have a gendisk at all. We should be doing this in general, but can't do it for the normal teardown case (yet) as the tagset can be gone by the time the disk is released once it was added. I hope to sort this out properly eventually but for now this isolated hack will do it. Fixes: 6f8191fdf41d ("block: simplify disk shutdown") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20220720130541.1323531-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
generated by cgit (git 2.34.1) at 2025-09-23 12:13:53 +0000