- 23 Jan, 2022 1 commit
-
-
Soenke Huster authored
msft_find_handle_data returns NULL if it can't find the handle. Therefore, handle_data must be checked, otherwise a null pointer is dereferenced. Signed-off-by:
Soenke Huster <soenke.huster@eknoes.de> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- 21 Jan, 2022 12 commits
-
-
Sean Wang authored
Currently, there is a loop in btmtksdio_txrx_work() which iteratively executes until the variable int_status is zero. But the variable int_status should be masked out with the actual interrupt sources (MTK_REG_CHISR bit 0-15) before we check the loop condition. Otherwise, RX_PKT_LEN (MTK_REG_CHISR bit 16-31) which is read-only and unclearable would cause the loop to get stuck on some chipsets like MT7663s. Fixes: 26270bc1 ("Bluetooth: btmtksdio: move interrupt service to work") Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Sean Wang authored
Apply sleep mode by default and a smaller idle time to reduce power consumption further. Signed-off-by:
-
Sean Wang authored
Lower its log level from INFO to DEBUG prior to we enable runtime pm for mt7921s with the smaller idle time as default. Signed-off-by:
-
Mark Chen authored
According to the firmware behavior (even the oldest one in linux-firmware) If the firmware is downloaded, MT7921S must rely on the additional mailbox mechanism that resides in firmware to check if the device is the right state for btmtksdio_mcu_[drv|fw]_pmctrl(). Otherwise, we still apply the old way for that. That is a necessary patch before we enable runtime pm for mt7921s as default. Fixes: c603bf1f ("Bluetooth: btmtksdio: add MT7921s Bluetooth support") Co-developed-by:
Mark Chen <mark-yw.chen@mediatek.com> Signed-off-by:
-
Mark Chen authored
According to chip hw flow, mt7921s need to re-acquire privilege again before normal running. Otherwise, the bus may be stuck in an abnormal status. Fixes: c603bf1f ("Bluetooth: btmtksdio: add MT7921s Bluetooth support") Co-developed-by:
-
Mark Chen authored
Refactor btmtksdio_runtime_[suspend|resume]() to create the common funcitons btmtksdio_[fw|drv]_pmctrl() shared with btmtksdio_[open|close]() to avoid the redundant code as well. This is also a prerequisite patch for the incoming patches. Co-developed-by:
-
Mark Chen authored
According to the MCU firmware behavior, as the driver is aware of the notification of the interrupt source FW_MAILBOX_INT that shows the MCU completed delivered a core dump piece to the host, the driver must acknowledge the MCU with the register PH2DSM0R bit PH2DSM0R_DRIVER_OWN to notify the MCU to handle the next core dump piece. Fixes: db57b625 ("Bluetooth: btmtksdio: add support of processing firmware coredump and log") Co-developed-by:
-
Pavel Skripkin authored
kvartet reported, that hci_uart_tx_wakeup() uses uninitialized rwsem. The problem was in wrong place for percpu_init_rwsem() call. hci_uart_proto::open() may register a timer whose callback may call hci_uart_tx_wakeup(). There is a chance, that hci_uart_register_device() thread won't be fast enough to call percpu_init_rwsem(). Fix it my moving percpu_init_rwsem() call before p->open(). INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 2 PID: 18524 Comm: syz-executor.5 Not tainted 5.16.0-rc6 #9 ... Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 assign_lock_key kernel/locking/lockdep.c:951 [inline] register_lock_class+0x148d/0x1950 kernel/locking/lockdep.c:1263 __lock_acquire+0x106/0x57e0 kernel/locking/lockdep.c:4906 lock_acquire kernel/locking/lockdep.c:5637 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5602 percpu_down_read_trylock include/linux/percpu-rwsem.h:92 [inline] hci_uart_tx_wakeup+0x12e/0x490 drivers/bluetooth/hci_ldisc.c:124 h5_timed_event+0x32f/0x6a0 drivers/bluetooth/hci_h5.c:188 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 Fixes: d73e1728 ("Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops") Reported-by:
Yiru Xu <xyru1999@gmail.com> Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch changes the kernel-doc style comment block to common comment block. These files don't support kernel-doc style so no need to use the kernel-doc style. Also, they cause the warning when W=1 option is used as below. drivers/bluetooth/hci_ll.c:518: warning: Function parameter or member 'lldev' not described in 'download_firmware' drivers/bluetooth/btmrvl_debugfs.c:29: warning: cannot understand function prototype: 'struct btmrvl_debugfs_data ' drivers/bluetooth/btmrvl_sdio.c:36: warning: expecting prototype for Marvell BT-over-SDIO driver(). Prototype was for VERSION() instead Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
-
Ismael Ferreras Morezuelas authored
Properly align the list items of the quirk for readability. No functional changes intended. Trivial stuff. Fixes: 0671c066 ("Bluetooth: btusb: Add workaround for remote-wakeup issues with Barrot 8041a02 fake CSR controllers") Signed-off-by:
Ismael Ferreras Morezuelas <swyterzone@gmail.com> Signed-off-by:
-
Larry Finger authored
This Realtek device has both wifi and BT components. The latter reports a USB ID of 0bda:2852, which is not in the table. BT device description in /sys/kernel/debug/usb/devices contains the following entries: T: Bus=01 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=2852 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 The missing USB_ID was reported by user trius65 at https://github.com/lwfinger/rtw89/issues/122Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: stable@vger.kernel.org Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch adds the flag to identify the Intel legacy ROM products that don't support WBS like WP and StP. Fixes: 3df4dfbe ("Bluetooth: btintel: Move hci quirks to setup routine") Signed-off-by:
-
- 20 Jan, 2022 2 commits
-
-
Manish Mandlik authored
This patch introduces two new MGMT events for notifying the bluetoothd whenever the controller starts/stops monitoring a device. Test performed: - Verified by logs that the MSFT Monitor Device is received from the controller and the bluetoothd is notified whenever the controller starts/stops monitoring a device. Signed-off-by:
Manish Mandlik <mmandlik@google.com> Reviewed-by:
Miao-chen Chou <mcchou@google.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Manish Mandlik authored
Whenever the controller starts/stops monitoring a bt device, it sends MSFT Monitor Device event. Add handler to read this vendor event. Test performed: - Verified by logs that the MSFT Monitor Device event is received from the controller whenever it starts/stops monitoring a device. Signed-off-by:
-
- 14 Jan, 2022 1 commit
-
-
Soenke Huster authored
This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL. Signed-off-by:
-
- 11 Jan, 2022 1 commit
-
-
Dan Carpenter authored
Add unlocks to two error paths in hci_inquiry_result_with_rssi_evt(). Fixes: fee64503 ("Bluetooth: hci_event: Use skb_pull_data when processing inquiry results") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 10 Jan, 2022 23 commits
-
-
Sean Wang authored
Have "..reg (%d)" to be consistent with the other similar error messages. Signed-off-by:
-
Sean Wang authored
move struct reg_read_cmd to btmtk.h to allow other mtk drivers refer to. Signed-off-by:
-
Mark Chen authored
The driver has to issue the specific command to enable Bluetooth SCO over the I2S/PCM interface on mt7921s, that is supported since the firmware with version 20211222191101 was added, and the patch would not cause any harm even when the old firmware is applied. The SCO profile with the patch was tested by setting up a VOIP application, connected to HFP device, checked telephony function can work normally. Co-developed-by:
-
Mark Chen authored
Enable wake on bluetooth on mt7921s that can be supported since the firmware with version 20211129211059 was added, and the patch would not cause any harm even when the old firmware is applied. The patch was tested by setting up an HID or HOGP profile to connect a Bluetooth keyboard and mouse, then putting the system to suspend, then trying to wake up the system by moving the Bluetooth keyboard or mouse, and then checking if the system can wake up and be brought back to the normal state. Co-developed-by:
-
Sean Wang authored
Using "btmtksdio" as the prefix instead of "btsdio" Signed-off-by:
-
Luiz Augusto von Dentz authored
This fixes the following warning: net/bluetooth/hci_sync.c:5143:5: warning: no previous prototype for ‘hci_le_ext_create_conn_sync’ [-Wmissing-prototypes] Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Merge in fixes directly in prep for the 5.17 merge window. No conflicts. Signed-off-by:Jakub Kicinski <kuba@kernel.org>
-
Benjamin Yim authored
After this parameter is passed in, there is no usage, and deleting it will not bring any impact. Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Benjamin Yim <yan2228598786@gmail.com> Link: https://lore.kernel.org/r/20220109130824.2776-1-yan2228598786@gmail.comSigned-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/3011689e8c77d49d7e44509d5a8241320ec408c5.1641754134.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'highdma' is known to be true. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'pci_using_dac' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Moreover, dma_set_mask_and_coherent() returns 0 or -EIO, so the return code of the function can be used directly. Finally, inline bnx2x_set_coherency_mask() because it is now only a wrapper for a single dma_set_mask_and_coherent() call. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. Moreover, dma_set_mask_and_coherent() returns 0 or -EIO, so the return code of the function can be used directly. There is no need to 'rc = -EIO' explicitly. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So if dma_set_mask_and_coherent() succeeds, 'netdev->features' will have NETIF_F_HIGHDMA in all cases. Move the assignment of this feature in be_netdev_init() instead be_probe() which is a much logical place. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask never fails if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So if dma_set_mask_and_coherent() succeeds, 'dma64' is know to be 'true'. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. So, if dma_set_mask_and_coherent() succeeds, 'using_dac' is known to be 'true'. This variable can be removed. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. If dma_set_mask_and_coherent() succeeds, 'ap->pci_using_dac' is known to be 1. So 'pci_using_dac' can be removed from the 'struct ace_private'. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
Christophe JAILLET authored
As stated in [1], dma_set_mask() with a 64-bit mask will never fail if dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also fail for the same reason. If dma_set_mask_and_coherent() succeeds, 'dac_enabled' is known to be 1. Simplify code and remove some dead code accordingly. [1]: https://lkml.org/lkml/2021/6/7/398Signed-off-by:
-
