edl->data is an array of __u8 so the null check is unneccessary,
so remove it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The workqueue "workqueue" queues multiple work items viz &qca->ws_awake_rx
&qca->ws_rx_vote_off, &qca->ws_awake_device, &qca->ws_tx_vote_off which
require strict execution ordering. Hence, an ordered dedicated workqueue
has been used to replace the deprecated create_singlethread_workqueue
instance.
WQ_MEM_RECLAIM has not been set since the driver is not being used on a
memory reclaim path.
Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The newly added bluetooth driver is based on the soc-specific support,
but lacks the obvious compile-time dependency on that:
drivers/bluetooth/btqcomsmd.o: In function `btqcomsmd_probe':
btqcomsmd.c:(.text.btqcomsmd_probe+0x40): undefined reference to `qcom_wcnss_open_channel'
btqcomsmd.c:(.text.btqcomsmd_probe+0x5c): undefined reference to `qcom_wcnss_open_channel'
Makefile:969: recipe for target 'vmlinux' failed
Fixes: 90c107dc8b2c ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang <wsa-dev@sang-engineering.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
wait_on_bit_timeout() returns one of the following three values:
* 0 to indicate success.
* -EINTR to indicate that a signal has been received;
* -EAGAIN to indicate timeout;
Make the wait_on_bit_timeout() callers check for these values.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Qualcomm WCNSS chip provides two SMD channels to the BT core; one
for command and one for event packets. This driver exposes the two
channels as a hci device.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
is_suspending flag remains on when host sleep fails to enable. Data
path is unnecessarily blocked after this. This patch ensures to
reset the flag in failure path.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Digianswer sniffer devices allow for reading a firmware specific
information string. If it is available, then inform the Bluetooth core
about it via hci_set_fw_info. That exposes it via debugfs like this:
# cat /sys/kernel/debug/bluetooth/hci0/firmware_info
SNIF_102,BB930,02/01/18,10:37:56
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
On mips and parisc:
drivers/bluetooth/btwilink.c: In function 'ti_st_open':
drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit constant conversion [-Woverflow]
hst->reg_status = -EINPROGRESS;
drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant conversion [-Woverflow]
drv->st_register_cb_status = -EINPROGRESS;
There are actually two issues:
1. Whether "char" is signed or unsigned depends on the architecture.
As the completion callback data is used to pass a (negative) error
code, it should always be signed.
2. EINPROGRESS is 150 on mips, 245 on parisc.
Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
Change the callback status from "char" to "int" to fix these.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
LPM can be enabled via a DDC write command at specific DDC ID.
As any other DDC value, this is up to the DDC config file to
include (or not) the low power mode configuration.
Signed-off-by: Loic Poulain <loic.poulain@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The HCI_BREDR naming is confusing since it actually stands for Primary
Bluetooth Controller. Which is a term that has been used in the latest
standard. However from a legacy point of view there only really have
been Basic Rate (BR) and Enhanced Data Rate (EDR). Recent versions of
Bluetooth introduced Low Energy (LE) and made this terminology a little
bit confused since Dual Mode Controllers include BR/EDR and LE. To
simplify this the name HCI_PRIMARY stands for the Primary Controller
which can be a single mode or dual mode controller.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With current btusb.ko kernel module, Bluetooth pretends to be active
but there is no real activity.
I'm using an Acer Aspire VN7-791.
Output of lsusb:
Bus 003 Device 007: ID 0489:e092 Foxconn / Hon Hai
On my laptop, this device is actually used as a combo with wifi chipset
Atheros Qualcomm Killer N1525 Wireless-AC [168c:003e],
* Fix by adding a declaration in kernel sources drivers/bluetooth/btusb.c
{ USB_DEVICE(0x0489, 0xe092), .driver_info = BTUSB_QCA_ROME },
* Compiled extra module /lib/modules/4.4.0-22-generic/extra/btusb.ko
* Successfully tested against my phone (obex file transfer)
Signed-off-by: Yvain THONNART <yvain.thonnart@m4x.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Kasan reported slab-out-of-bounds access in btmrvl_sdio:
[ 33.055400] ==================================================================
[ 33.062585] BUG: KASAN: slab-out-of-bounds in memcpy+0x24/0x50 at addr ffffffc0d89b4a00
[ 33.070529] Read of size 256 by task btmrvl_main_ser/3576
[ 33.075885] =============================================================================
[ 33.084002] BUG kmalloc-256 (Tainted: G B ): kasan: bad access detected
[ 33.091511] -----------------------------------------------------------------------------
<snip...>
[ 33.413498] Call trace:
[ 33.415928] [<ffffffc00020a440>] dump_backtrace+0x0/0x190
[ 33.421288] [<ffffffc00020a5ec>] show_stack+0x1c/0x28
[ 33.426305] [<ffffffc000b3288c>] dump_stack+0xa0/0xf8
[ 33.431320] [<ffffffc000396130>] print_trailer+0x158/0x16c
[ 33.436765] [<ffffffc0003962cc>] object_err+0x48/0x5c
[ 33.441780] [<ffffffc00039be24>] kasan_report+0x344/0x510
[ 33.447141] [<ffffffc00039afd8>] __asan_loadN+0x20/0x150
[ 33.452413] [<ffffffc00039b60c>] memcpy+0x20/0x50
[ 33.457084] [<ffffffc000595fcc>] swiotlb_tbl_map_single+0x2ec/0x310
[ 33.463305] [<ffffffc000596b54>] map_single+0x24/0x30
[ 33.468320] [<ffffffc0005970c8>] swiotlb_map_sg_attrs+0xec/0x21c
[ 33.474286] [<ffffffc000219d4c>] __swiotlb_map_sg_attrs+0x48/0xec
[ 33.480339] [<ffffffc0008ea610>] msdc_prepare_data.isra.11+0xf0/0x11c
[ 33.486733] [<ffffffc0008ecbd0>] msdc_ops_request+0x74/0xf0
[ 33.492266] [<ffffffc0008c6b38>] __mmc_start_request+0x78/0x8c
[ 33.498057] [<ffffffc0008c6d6c>] mmc_start_request+0x220/0x240
[ 33.503848] [<ffffffc0008c6e04>] mmc_wait_for_req+0x78/0x250
[ 33.509468] [<ffffffc0008d70fc>] mmc_io_rw_extended+0x2ec/0x388
[ 33.515347] [<ffffffc0008d8fc0>] sdio_io_rw_ext_helper+0x160/0x268
[ 33.521483] [<ffffffc0008d93fc>] sdio_writesb+0x40/0x50
[ 33.526677] [<ffffffbffc338b38>] btmrvl_sdio_host_to_card+0x124/0x1bc [btmrvl_sdio]
[ 33.534283] [<ffffffbffc3290a0>] btmrvl_service_main_thread+0x384/0x428 [btmrvl]
[ 33.541626] [<ffffffc0002518e8>] kthread+0x140/0x158
[ 33.546550] Memory state around the buggy address:
[ 33.551305] ffffffc0d89b4980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 33.558474] ffffffc0d89b4a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.565643] >ffffffc0d89b4a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
[ 33.572809] ^
[ 33.579889] ffffffc0d89b4b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 33.587055] ffffffc0d89b4b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 33.594221] ==================================================================
The cause of this is that btmrvl_sdio_host_to_card can access memory region
out of its allocated space due to:
1. the requested block size is smaller than SDIO_BLOCK_SIZE, and/or
2. the allocated memory is not BTSDIO_DMA_ALIGN-aligned.
This patch fixes the issue by allocating a buffer which is big enough for
SDIO_BLOCK_SIZE transfer and/or BTSDIO_DMA_ALIGN address relocation.
Signed-off-by: Ricky Liang <jcliang@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The format of Intel Bluetooth firmware filename for bootloader product
is ibt-<hw_variant>-<device_revision_id>.sfi
Currently the driver uses a constant value 11 (0x0b) for hw_variant
to support LnP/SfP product. But new product like WsP product has
a different value such as 12 (0x0c).
To support the multiple products, this patch replaces the constant
value of hw_variant to the actual hw_variant value read from
the device.
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
gpiod_get_optional can return either ERR_PTR or NULL pointer.
NULL case is not tested and then dereferenced later in desc_to_gpio.
Fix this by using non optional version which returns ERR_PTR in any
error case (this is not an optional gpio).
Use the same non optional version for the host-wake gpio.
Fixes: 765ea3abd1 ("Bluetooth: hci_intel: Retrieve host-wake IRQ")
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
On some arm-based platforms, we need to configure platform specific
parameters by device tree node and also define our node as a child
node of parent SDIO host controller.
This patch parses these parameters from device tree. It includes
calibration data download to firmware, wakeup pin configured to firmware,
and soc specific wake up gpio, which will be set as wakeup interrupt pin.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We could print an uninitialized value in the error message.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
hci_vhci driver creates a hci device object dynamically upon each
HCI_VENDOR_PKT write. Although it checks the already created object
and returns an error, it's still racy and may build multiple hci_dev
objects concurrently when parallel writes are performed, as the device
tracks only a single hci_dev object.
This patch introduces a mutex to protect against the concurrent device
creations.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Both vhci_get_user and vhci_release race with open_timeout work. They
both contain cancel_delayed_work_sync, but do not test whether the
work actually created hdev or not. Since the work can be in progress
and _sync will wait for finishing it, we can have data->hdev allocated
when cancel_delayed_work_sync returns. But the call sites do 'if
(data->hdev)' *before* cancel_delayed_work_sync.
As a result:
* vhci_get_user allocates a second hdev and puts it into
data->hdev. The former is leaked.
* vhci_release does not release data->hdev properly as it thinks there
is none.
Fix both cases by moving the actual test *after* the call to
cancel_delayed_work_sync.
This can be hit by this program:
#include <err.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
int main(int argc, char **argv)
{
int fd;
srand(time(NULL));
while (1) {
const int delta = (rand() % 200 - 100) * 100;
fd = open("/dev/vhci", O_RDWR);
if (fd < 0)
err(1, "open");
usleep(1000000 + delta);
close(fd);
}
return 0;
}
And the result is:
BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228
Read of size 8 by task kworker/u13:1/32068
=============================================================================
BUG kmalloc-192 (Tainted: G E ): kasan: bad access detected
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040
...
kmem_cache_alloc_trace+0x150/0x190
vhci_open+0x50/0x330 [hci_vhci]
misc_open+0x35b/0x4e0
chrdev_open+0x23b/0x510
...
INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040
...
__slab_free+0x204/0x310
vhci_release+0xa4/0xd0 [hci_vhci]
...
INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080
INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600
Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00 ...k............
Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff ...k.......k....
Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff .F.k.....F.k....
Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00 ................
Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff @..k....@..k....
Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de P.n.............
Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00 .........b......
Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff ........8..k....
Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00 .. .............
Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff ...........=....
Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . ..............
Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb ........
Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00 ........
CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G B E 4.4.6-0-default #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
Workqueue: hci0 hci_cmd_work [bluetooth]
00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180
ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320
ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80
Call Trace:
...
[<ffffffff81ec8ebe>] ? skb_queue_tail+0x13e/0x150
[<ffffffffa06e027c>] ? vhci_send_frame+0xac/0x100 [hci_vhci]
[<ffffffffa0c61268>] ? hci_send_frame+0x188/0x320 [bluetooth]
[<ffffffffa0c61515>] ? hci_cmd_work+0x115/0x310 [bluetooth]
[<ffffffff811a1375>] ? process_one_work+0x815/0x1340
[<ffffffff811a1f85>] ? worker_thread+0xe5/0x11f0
[<ffffffff811a1ea0>] ? process_one_work+0x1340/0x1340
[<ffffffff811b3c68>] ? kthread+0x1c8/0x230
...
Memory state around the buggy address:
ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers)
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: stable 3.13+ <stable@vger.kernel.org>
HCI_UART_PROTO_SET flag is set before hci_uart_set_proto call. If we
receive data from tty layer during this procedure, proto pointer may
not be assigned yet, leading to null pointer dereference in rx method
hci_uart_tty_receive.
This patch fixes this issue by introducing HCI_UART_PROTO_READY flag in
order to avoid any proto operation before proto opening and assignment.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In some case, the btmrvl_sdio firmware would fail to active within the
polling time. Increase the polling interval to 100 msec to fix the
issue.
Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org>
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Lenovo ThinkPad Tablet 8 with BCM43241 rev B5 chipset uses the BCM2E55
ACPI ID for Bluetooth. Add it to the list of supported devices.
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The AG6xx devices behave similar to Wilkens Peak and Stone Peak and with
that it is needed to check for Intel default address. In addition it is
possible to enable vendor events and diag support.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This driver implements support for iBT2.1 Bluetooth controller embedded
in the AG620 communication combo. The controller needs to be configured
with bddata and can be patched with a binary patch file (pbn).
These operations are performed in manufacturing mode.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the call to request_firmware() fails in btbcm_setup_patchram(),
the BCM chip will be operating with its default firmware.
In this case, btbcm_setup_patchram() should not return immediately
but instead should skip to btbcm_check_bdaddr() and quirk setup.
Signed-off-by: Petri Gynther <pgynther@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Recent macbooks (early 2015) with BCM43241 use this ACPI ID. Add it to the
list of supported devices.
Reported-by: Leif Liddy <leif.liddy@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This ACPI ID is used at least by HP for their Omni 10 5600eg tablet.
Signed-off-by: J.J. Meijer <jjmeijer88@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
A return value of the intel_wait_booting() function compared with
a constant ETIMEDOUT instead of -ETIMEDOUT.
Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Fixed a coding style issue. Added a blank link after declaration.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Usually when driver sends data to firmware it receives TX_DONE
(DN_LD_HOST_INT_STATUS) interrupt from firmware right away.
It's also observed that some times the fireware could delay
sending DN_LD_HOST_INT_STATUS interrupt. If driver sends data to
firmware during suspend processing and the TX_DONE interrupt is
delayed, it may come back at wrong time when SDIO host driver is
in the middle of suspending.
Block any data from stack while suspending. Also skip sending
data that are already in driver tx_queue.
Don't purge the skb queue on suspend to avoid intermittent music
after system resumes from S3.
Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For gpio=0xff (wake up host through SDIO interface) case,
gap=0xff means no delay (same as gap=0) for incoming data packet
to be sent to host after host sleep is activated.
Change it to the maximum delay to reduce the chance that RX
interrupt could be delivered while host controller suspends.
Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
These are used at least by Acer with BCM43241.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The IDs should all be for Broadcom BCM43241 module, and
hci_bcm is now the proper driver for them. This removes one
of two different ways of handling PM with the module.
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
devm_kzalloc prints its own OOM message upon failure.
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
devm_kzalloc prints its own OOM message upon failure.
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
