27 Mar, 2019
3 commits
-
commit 56897b217a1d0a91c9920cb418d6b3fe922f590a upstream.
task A: task B:
hci_uart_set_proto flush_to_ldisc
- p->open(hu) -> h5_open //alloc h5 - receive_buf
- set_bit HCI_UART_PROTO_READY - tty_port_default_receive_buf
- hci_uart_register_dev - tty_ldisc_receive_buf
- hci_uart_tty_receive
- test_bit HCI_UART_PROTO_READY
- h5_recv
- clear_bit HCI_UART_PROTO_READY while() {
- p->open(hu) -> h5_close //free h5
- h5_rx_3wire_hdr
- h5_reset() //use-after-free
}It could use ioctl to set hci uart proto, but there is
a use-after-free issue when hci_uart_register_dev() fail in
hci_uart_set_proto(), see stack above, fix this by setting
HCI_UART_PROTO_READY bit only when hci_uart_register_dev()
return success.Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com
Signed-off-by: Kefeng Wang
Reviewed-by: Jeremy Cline
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 32a7b4cbe93b0a0ef7e63d31ca69ce54736c4412 upstream.
The hci_dev struct hdev is referenced in work queues and timers started
by open() in some protocols. This creates a race between the
initialization function and the work or timer which can result hdev
being dereferenced while it is still null.The syzbot report contains a reliable reproducer which causes a null
pointer dereference of hdev in hci_uart_write_work() by making the
memory allocation for hdev fail.To fix this, ensure hdev is valid from before calling a protocol's
open() until after calling a protocol's close().Reported-by: syzbot+257790c15bcdef6fe00c@syzkaller.appspotmail.com
Signed-off-by: Jeremy Cline
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 1dc2d785156cbdc80806c32e8d2c7c735d0b4721 upstream.
h4_recv_buf() callers store the return value to socket buffer and
recursively pass the buffer to h4_recv_buf() without protection. So,
ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again
before setting the socket buffer to NULL from previous error. Check if
skb is ERR_PTR in h4_recv_buf().Reported-by: syzbot+017a32f149406df32703@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman
10 Mar, 2019
1 commit
-
commit 00df214b1faae520880cc5c57e206f21239ef741 upstream.
Realtek bluetooth may not work after reboot:
[ 12.446130] Bluetooth: hci0: RTL: rtl: unknown IC info, lmp subver a99e, hci rev 826c, hci ver 0008This is a regression introduced by commit 26503ad25de8 ("Bluetooth:
btrtl: split the device initialization into smaller parts"). The new
logic errors out early when no matching IC info can be found, in this
case it means the firmware is already loaded.So let's assume the firmware is already loaded when we can't find
matching IC info, like the old logic did.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201921
Fixes: 26503ad25de8 ("Bluetooth: btrtl: split the device initialization into smaller parts")
Cc: stable@vger.kernel.org # 4.19+
Signed-off-by: Kai-Heng Feng
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman
13 Feb, 2019
1 commit
-
[ Upstream commit 28ac03b9ac3f784c2f048a910c8d0a7a87483b66 ]
On some systems that actually have the bluetooth controller wired up
with an extra clock signal, it's possible the bluetooth controller
probes before the clock provider. clk_get would return a defer probe
error, which was not handled by this driver.Handle this properly, so that these systems can work reliably.
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
26 Jan, 2019
1 commit
-
[ Upstream commit 2da711bcebe81209a9f2f90e145600eb1bae2b71 ]
Include the new USB product ID for Intel Bluetooth device 22260
family(CcPeak)The /sys/kernel/debug/usb/devices portion for this device is:
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=8087 ProdID=0029 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 64 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
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1msSigned-off-by: Raghuram Hegde
Signed-off-by: Chethan T N
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
14 Nov, 2018
2 commits
-
[ Upstream commit c2d7827338618a9e73a3f892ca63d9082bb7a94d ]
When flag KASAN is set, we are seeing an following crash while removing
hci_uart module.[ 50.589909] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b73
[ 50.597902] Mem abort info:
[ 50.600846] Exception class = DABT (current EL), IL = 32 bits
[ 50.606959] SET = 0, FnV = 0
[ 50.610142] EA = 0, S1PTW = 0
[ 50.613396] Data abort info:
[ 50.616401] ISV = 0, ISS = 0x00000004
[ 50.620373] CM = 0, WnR = 0
[ 50.623466] [006b6b6b6b6b6b73] address between user and kernel address ranges
[ 50.630818] Internal error: Oops: 96000004 [#1] PREEMPT SMP[ 50.671670] PC is at qca_power_shutdown+0x28/0x100 [hci_uart]
[ 50.677593] LR is at qca_close+0x74/0xb0 [hci_uart]
[ 50.775689] Process rmmod (pid: 2144, stack limit = 0xffffff801ba90000)
[ 50.782493] Call trace:[ 50.872150] [] qca_power_shutdown+0x28/0x100 [hci_uart]
[ 50.879138] [] qca_close+0x74/0xb0 [hci_uart]
[ 50.885238] [] hci_uart_unregister_device+0x44/0x50 [hci_uart]
[ 50.892846] [] qca_serdev_remove+0x50/0x5c [hci_uart]
[ 50.899654] [] serdev_drv_remove+0x28/0x38
[ 50.905489] [] device_release_driver_internal+0x140/0x1e4
[ 50.912653] [] driver_detach+0x78/0x84
[ 50.918121] [] bus_remove_driver+0x80/0xa8
[ 50.923942] [] driver_unregister+0x4c/0x58
[ 50.929768] [] qca_deinit+0x24/0x598 [hci_uart]
[ 50.936045] [] hci_uart_exit+0x10/0x48 [hci_uart]
[ 50.942495] [] SyS_delete_module+0x17c/0x224This crash is due to dereference of hdev, after freeing it.
Signed-off-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a357ea098c9605f60d92a66a9073f56ce25726da ]
This patch adds the device ID for the AMPAK AP6335 combo module used
in the 1st generation WeTek Hub Android/LibreELEC HTPC box. The WiFI
chip identifies itself as BCM4339, while Bluetooth identifies itself
as BCM4335 (rev C0):```
[ 4.864248] Bluetooth: hci0: BCM: chip id 86
[ 4.866388] Bluetooth: hci0: BCM: features 0x2f
[ 4.889317] Bluetooth: hci0: BCM4335C0
[ 4.889332] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0000
[ 9.778383] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0268
```Output from hciconfig:
```
hci0: Type: Primary Bus: UART
BD Address: 43:39:00:00:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:7567 acl:234 sco:0 events:386 errors:0
TX bytes:53844 acl:77 sco:0 commands:304 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HUB'
Class: 0x0c0000
Service Classes: Rendering, Capturing
Device Class: Miscellaneous,
HCI Version: 4.0 (0x6) Revision: 0x10c
LMP Version: 4.0 (0x6) Subversion: 0x6109
Manufacturer: Broadcom Corporation (15)
```Signed-off-by: Christian Hewitt
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
12 Oct, 2018
1 commit
-
Kees writes:
"Fix open-coded multiplication arguments to allocators- Fixes several new open-coded multiplications added in the 4.19
merge window."* tag 'alloc-args-v4.19-rc8' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
treewide: Replace more open-coded allocation size multiplications
06 Oct, 2018
1 commit
-
As done treewide earlier, this catches several more open-coded
allocation size calculations that were added to the kernel during the
merge window. This performs the following mechanical transformations
using Coccinelle:kvmalloc(a * b, ...) -> kvmalloc_array(a, b, ...)
kvzalloc(a * b, ...) -> kvcalloc(a, b, ...)
devm_kzalloc(..., a * b, ...) -> devm_kcalloc(..., a, b, ...)Signed-off-by: Kees Cook
11 Sep, 2018
1 commit
-
The percpu_rw_semaphore is not currently freed, and this leads to
a crash when the stale rcu callback is invoked. DEBUG_OBJECTS
detects this.ODEBUG: free active (active state 1) object type: rcu_head hint: (null)
------------[ cut here ]------------
WARNING: CPU: 1 PID: 2024 at debug_print_object+0xac/0xc8
PC is at debug_print_object+0xac/0xc8
LR is at debug_print_object+0xac/0xc8
Call trace:
[] debug_print_object+0xac/0xc8
[] debug_check_no_obj_freed+0x1e8/0x228
[] kfree+0x1cc/0x250
[] hci_uart_tty_close+0x54/0x108
[] tty_ldisc_close.isra.1+0x40/0x58
[] tty_ldisc_kill+0x1c/0x40
[] tty_ldisc_release+0x94/0x170
[] tty_release_struct+0x1c/0x58
[] tty_release+0x3b0/0x490
[] __fput+0x88/0x1d0
[] ____fput+0xc/0x18
[] task_work_run+0x9c/0xc0
[] do_exit+0x24c/0x8a0
[] do_group_exit+0x38/0xa0
[] __wake_up_parent+0x0/0x28
[] el0_svc_naked+0x34/0x38
---[ end trace bfe08cbd89098cdf ]---Signed-off-by: Hermes Zhang
Signed-off-by: Marcel Holtmann
21 Aug, 2018
2 commits
-
In case memory resources for *fw* were allocated, release them before
return.Addresses-Coverity-ID: 1472611 ("Resource leak")
Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
Signed-off-by: Gustavo A. R. Silva
Acked-by: Sean Wang
Signed-off-by: Marcel Holtmann -
At the moment we only support ACPI enumeration for serial port attached
RTL bluetooth controllers.This commit adds a dependency on ACPI to the BT_HCIUART_RTL configuration
option, fixing the following warning when ACPI is not enabled:drivers/bluetooth/hci_h5.c:920:22: warning: 'rtl_vnd' defined but not used
Cc: Arnd Bergmann
Reported-by: Arnd Bergmann
Signed-off-by: Hans de Goede
Acked-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Signed-off-by: Marcel Holtmann
13 Aug, 2018
1 commit
-
We're supposed to pass the number of elements in the mtk_recv_pkts, not
the number of bytes.Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
Signed-off-by: Dan Carpenter
Signed-off-by: Marcel Holtmann
10 Aug, 2018
1 commit
-
Like all the other UART protocols, introduce a configuration option for
Realtek based serial devices.Signed-off-by: Marcel Holtmann
Signed-off-by: Hans de Goede
Signed-off-by: Johan Hedberg
08 Aug, 2018
1 commit
-
This adds a driver based on serdev driver for the MediaTek serial protocol
based on running H:4, which can enable the built-in Bluetooth device inside
MT7622 SoC.Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann
07 Aug, 2018
1 commit
-
Using HCI_VENDOR_PKT for vendor specific events does work since it has
also the value 0xff, but it is actually the packet type indicator
constant and not the event constant. So introduce HCI_EV_VENDOR and
use it.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
05 Aug, 2018
1 commit
-
This driver was recently updated to use serdev, so add the appropriate
dependency. Without this one can get compiler warnings like this if
CONFIG_SERIAL_DEV_BUS is not enabled:CC [M] drivers/bluetooth/hci_h5.o
drivers/bluetooth/hci_h5.c:934:36: warning: ‘h5_serdev_driver’ defined but not used [-Wunused-variable]
static struct serdev_device_driver h5_serdev_driver = {
^~~~~~~~~~~~~~~~Signed-off-by: Johan Hedberg
Signed-off-by: Marcel Holtmann
03 Aug, 2018
18 commits
-
Add support to set voltage/current of various regulators
to power up/down Bluetooth chip wcn3990.Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
This patch enables the RAM and NV patch download for wcn3990.
Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
Enable Qualcomm chips to operate at 3.2Mbps.
Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
In function qca_setup, we set initial and operating speeds for Qualcomm
Bluetooth SoC's. This block of code is common across different
Qualcomm Bluetooth SoC's. Instead of duplicating the code, created
a wrapper function to set the speeds. So that future coming SoC's
can use these wrapper functions to set speeds.Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
Redefinition of qca_uart_setup will help future Qualcomm Bluetooth
SoC, to use the same function instead of duplicating the function.
Added new arguments soc_type and soc_ver to the functions.These arguments will help to decide type of firmware files
to be loaded into Bluetooth chip.
soc_type holds the Bluetooth chip connected to APPS processor.
soc_ver holds the Bluetooth chip version.Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
Some of the QCA BTSoC ROME functions, are used for different versions
or different make of BTSoC's. Instead of duplicating the same functions
for new chip, update names of the functions that are used for both
chips to keep this generic and would help in future when we would have
new BT SoC. To have generic text in logs updated from ROME to QCA where
ever possible. This avoids confusion to user, when using the future
Qualcomm Bluetooth SoC's. Updated BT_DBG, BT_ERR and BT_INFO with
bt_dev_dbg, bt_dev_err and bt_dev_info where ever applicable.Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
Add support for the enable and device-wake GPIOs used on ACPI enumerated
RTL8723BS devices.Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
Implement support for the RTL8723BS chip.
Signed-off-by: Jeremy Cline
[hdegoede@redhat.com: Port from bt3wire.c to hci_h5.c, drop broken GPIO code]
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
Allow vendor-specific setup, open, and close functions to be defined.
Signed-off-by: Jeremy Cline
[hdegoede@redhat.com: Port from bt3wire.c to hci_h5.c, drop dt support]
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
Add basic support for serdev enumerated devices, note sine this does
not (yet) declare any of / ACPI ids to bind to atm this is a nop.Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
The contents of the rtl_bt/rtlXXXX_config.bin file may be board specific
allow the caller of btrtl_initialize to specify a postfix identifying
the board, which if specified will make btrtl_initialize look for
rtl_bt/rtlXXXX_config-.bin instead.Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
The Realtek RTL8723BS and RTL8723DS chipsets are SDIO wifi chips. They
also contain a Bluetooth module which is connected via UART to the host.Realtek's userspace initialization tool (rtk_hciattach) differentiates
these two via the HCI version and revision returned by the
HCI_OP_READ_LOCAL_VERSION command.
Additionally we apply these checks only the for UART devices. Everything
else is assumed to be a "RTL8723B" which was originally supported by the
driver (communicating via USB).Signed-off-by: Martin Blumenstingl
Signed-off-by: Jeremy Cline
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
The UART settings are embedded in the config blob. This has to be parsed
to successfully initialize the Bluetooth part of the RTL8723BS (which is
an SDIO chip, but the Bluetooth part is connected via UART).The Realtek "rtl8723bs_bt" and "rtl8723ds_bt" userspace Bluetooth UART
initialization tools (rtk_hciattach) use the following sequence:
- send H5 sync pattern (already supported by hci_h5)
- get LMP version (already supported by btrtl)
- get ROM version (already supported by btrtl)
- load the firmware and config for the current chipset (already
supported by btrtl)
- read UART settings from the config blob (part of this patch)
- send UART settings via a vendor command to the device (which changes
the baudrate of the device and enables or disables flow control
depending on the config)
- change the baudrate and flow control settings on the host
- send the firmware and config blob to the device (already supported by
btrtl)Sending the last firmware and config blob download command
(rtl_download_cmd) fails if the UART settings are not updated
beforehand. This is presumably because the device applies the config
right after the firmware and config blob download - which means that at
this point the host is using different UART settings than the device
(which will obviously result in non-working communication).Signed-off-by: Martin Blumenstingl
Signed-off-by: Jeremy Cline
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
Consistently use rtl_dev_err and rtl_dev_info everywhere for messages.
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
This prepares the btrtl code so it can be used to initialize Bluetooth
modules connected via UART (these are found for example on the RTL8723BS
and RTL8723DS SDIO chips, which come with an embedded UART Bluetooth
module).The Realtek "rtl8723bs_bt" and "rtl8723ds_bt" userspace Bluetooth UART
initialization tools (rtk_hciattach) use the following sequence:
1) send H5 sync pattern (already supported by hci_h5)
2) get LMP version (already supported by btrtl)
3) get ROM version (already supported by btrtl)
4) load the firmware and config for the current chipset (already
supported by btrtl)
5) read UART settings from the config blob (currently not supported)
6) send UART settings via a vendor command to the device (which changes
the baudrate of the device and enables or disables flow control
depending on the config)
7) change the baudrate and flow control settings on the host
8) send the firmware and config blob to the device (already supported by
btrtl)The main reason why the initialization has to be split is step #7. This
requires changes to the underlying "bus", which should be kept outside
of the "generic" btrtl driver.
The idea for this split is borrowed from the btbcm driver but adjusted
where needed (the btrtl driver for example needs two blobs: firmware and
config, while the btbcm only needs one).This also prepares the code for step #5 (parsing the config blob) by
centralizing the code which loads the firmware and config blobs and
storing the result in the new struct btrtl_device_info.Signed-off-by: Martin Blumenstingl
Signed-off-by: Jeremy Cline
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
This makes the firmware names show up in modinfo.
Signed-off-by: Martin Blumenstingl
Signed-off-by: Jeremy Cline
Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
Replace the BT_ERR functions with bt_dev_err to get a consistent error
printout that always prefixes the HCI device identifier.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg -
Issue description: Intel 7265 shares the same RF with Wifi and BT.
In the shutdown scenario turn off BT, followed by turn WiFi off
and on causing error in RF calibration in WiFi ModuleSolution: before shutdown BT ensure any RF activity to clear by
HCI reset command.Reference Logs:
ERR kernel: [ 386.193284] iwlwifi 0000:01:00.0: Failed to run INIT calibrations: -5
ERR kernel: [ 386.193298] iwlwifi 0000:01:00.0: Failed to run INIT ucode: -5
ERR kernel: [ 386.193309] iwlwifi 0000:01:00.0: Failed to start RT ucode: -5Signed-off-by: Amit K Bag
Singed-off-by: Chethan T N
Signed-off-by: Marcel Holtmann
24 Jul, 2018
4 commits
-
qca_open() and qca_set_baudrate() are never called in atomic context.
They call kzalloc() and bt_skb_alloc() with GFP_ATOMIC,
which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.Signed-off-by: Jia-Ju Bai
Signed-off-by: Marcel Holtmann -
inject_cmd_complete() is only called by intel_dequeue(),
which is never called in atomic context.inject_cmd_complete() calls bt_skb_alloc() with GFP_ATOMIC,
which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.Signed-off-by: Jia-Ju Bai
Signed-off-by: Marcel Holtmann -
inject_cmd_complete() is only called by btusb_send_frame_intel(),
which is set to hdev->send, and hdev->send() is never
called in atomic context.inject_cmd_complete() calls bt_skb_alloc() with GFP_ATOMIC,
which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.Signed-off-by: Jia-Ju Bai
Signed-off-by: Marcel Holtmann -
btmrvl_sdio_card_to_host() is never called in atomic context.
It calls bt_skb_alloc() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replaced with GFP_KERNEL.This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.Signed-off-by: Jia-Ju Bai
Signed-off-by: Marcel Holtmann
