| Age | Commit message (Collapse) | Author |
|---|
|
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Add support to set voltage/current of various regulators
to power up/down Bluetooth chip wcn3990.
Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch enables the RAM and NV patch download for wcn3990.
Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Enable Qualcomm chips to operate at 3.2Mbps.
Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <bgodavar@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <bgodavar@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <bgodavar@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch enables regulators for the Qualcomm Bluetooth wcn3990
controller.
Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Add support for the enable and device-wake GPIOs used on ACPI enumerated
RTL8723BS devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Implement support for the RTL8723BS chip.
Signed-off-by: Jeremy Cline <jeremy@jcline.org>
[hdegoede@redhat.com: Port from bt3wire.c to hci_h5.c, drop broken GPIO code]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Allow vendor-specific setup, open, and close functions to be defined.
Signed-off-by: Jeremy Cline <jeremy@jcline.org>
[hdegoede@redhat.com: Port from bt3wire.c to hci_h5.c, drop dt support]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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-<postfix>.bin instead.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <martin.blumenstingl@googlemail.com>
Signed-off-by: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <martin.blumenstingl@googlemail.com>
Signed-off-by: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Consistently use rtl_dev_err and rtl_dev_info everywhere for messages.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <martin.blumenstingl@googlemail.com>
Signed-off-by: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This makes the firmware names show up in modinfo.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
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 Module
Solution: 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: -5
Signed-off-by: Amit K Bag <amit.k.bag@intel.com>
Singed-off-by: Chethan T N <chethan.tumkur.narayan@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
CVE-2018-9363
The buffer length is unsigned at all layers, but gets cast to int and
checked in hidp_process_report and can lead to a buffer overflow.
Switch len parameter to unsigned int to resolve issue.
This affects 3.18 and newer kernels.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough")
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-bluetooth@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: security@kernel.org
Cc: kernel-team@android.com
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This fixes two issues with setting hid->name information.
CC net/bluetooth/hidp/core.o
In function ‘hidp_setup_hid’,
inlined from ‘hidp_session_dev_init’ at net/bluetooth/hidp/core.c:815:9,
inlined from ‘hidp_session_new’ at net/bluetooth/hidp/core.c:953:8,
inlined from ‘hidp_connection_add’ at net/bluetooth/hidp/core.c:1366:8:
net/bluetooth/hidp/core.c:778:2: warning: ‘strncpy’ output may be truncated copying 127 bytes from a string of length 127 [-Wstringop-truncation]
strncpy(hid->name, req->name, sizeof(req->name) - 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC net/bluetooth/hidp/core.o
net/bluetooth/hidp/core.c: In function ‘hidp_setup_hid’:
net/bluetooth/hidp/core.c:778:38: warning: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Wsizeof-pointer-memaccess]
strncpy(hid->name, req->name, sizeof(req->name));
^
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that
runs setup() after every open() and not just after the first open().
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch adds support for advertising in primary and secondary
channel on different PHYs. User can add the phy preference in
the flag based on which phy type will be added in extended
advertising parameter would be set.
@ MGMT Command: Add Advertising (0x003e) plen 11
Instance: 1
Flags: 0x00000200
Advertise in CODED on Secondary channel
Duration: 0
Timeout: 0
Advertising data length: 0
Scan response length: 0
< HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 2
Extended advertising: Disabled (0x00)
Number of sets: Disable all sets (0x00)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Success (0x00)
< HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25
Handle: 0x00
Properties: 0x0000
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Channel map: 37, 38, 39 (0x07)
Own address type: Random (0x01)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
TX power: 127 dbm (0x7f)
Primary PHY: LE Coded (0x03)
Secondary max skip: 0x00
Secondary PHY: LE Coded (0x03)
SID: 0x00
Scan request notifications: Disabled (0x00)
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This event comes after connection complete event for incoming
connections. Since we now have different random address for
each instance, conn resp address is assigned from this event.
As of now only connection part is handled as we are not
enabling duration or max num of events while starting ext adv.
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This basically sets the random address for the adv instance
Random address can be set only if the instance is created which
is done in Set ext adv param.
Random address and rpa expire timer and flags have been added
to adv instance which will be used when the respective
instance is scheduled.
This introduces a hci_get_random_address() which returns the
own address type and random address (rpa or nrpa) based
on the instance flags and hdev flags. New function is required
since own address type should be known before setting adv params
but address can be set only after setting params.
< HCI Command: LE Set Advertising Set Random Address (0x08|0x0035) plen 7
Advertising handle: 0x00
Advertising random address: 3C:8E:56:9B:77:84 (OUI 3C-8E-56)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertising Set Random Address (0x08|0x0035) ncmd 1
Status: Success (0x00)
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch does extended advertising for directed advertising
if the controller supportes. Instance 0 is used for directed
advertising.
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
If ext adv is enabled then use ext adv to disable as well.
Also remove the adv set during LE disable.
< HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 2
Extended advertising: Disabled (0x00)
Number of sets: Disable all sets (0x00)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Success (0x00)
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch implements Set Ext Adv data and Set Ext Scan rsp data
if controller support extended advertising.
Currently the operation is set as Complete data and fragment
preference is set as no fragment
< HCI Command: LE Set Extended Advertising Data (0x08|0x0037) plen 35
Handle: 0x00
Operation: Complete extended advertising data (0x03)
Fragment preference: Minimize fragmentation (0x01)
Data length: 0x15
16-bit Service UUIDs (complete): 2 entries
Heart Rate (0x180d)
Battery Service (0x180f)
Name (complete): Test LE
Company: Google (224)
Data: 0102
> HCI Event: Command Complete (0x0e) plen 4
LE Set Extended Advertising Data (0x08|0x0037) ncmd 1
Status: Success (0x00)
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch basically replaces legacy adv with extended adv
based on the controller support. Currently there is no
design change. ie only one adv set will be enabled at a time.
This also adds tx_power in instance and store whatever returns
from Set_ext_parameter, use the same in adv data as well.
For instance 0 tx_power is stored in hdev only.
< HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25
Handle: 0x00
Properties: 0x0010
Use legacy advertising PDUs: ADV_NONCONN_IND
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Channel map: 37, 38, 39 (0x07)
Own address type: Random (0x01)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
TX power: 127 dbm (0x7f)
Primary PHY: LE 1M (0x01)
Secondary max skip: 0x00
Secondary PHY: LE 1M (0x01)
SID: 0x00
Scan request notifications: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 5
LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
Status: Success (0x00)
TX power (selected): 7 dbm (0x07)
< HCI Command: LE Set Extended Advertising Enable (0x08|0x0039) plen 6
Extended advertising: Enabled (0x01)
Number of sets: 1 (0x01)
Entry 0
Handle: 0x00
Duration: 0 ms (0x00)
Max ext adv events: 0
> HCI Event: Command Complete (0x0e) plen 4
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Success (0x00)
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch reads the number of advertising sets in the controller
during init and save it in hdev.
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Use the selected PHYs by Set PHY Configuration management command
in extended create connection.
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch defines the extended ADV types and handle it in ADV report.
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Use the PHYs selected in Set Phy Configuration management command
while scanning.
< HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 13
Own address type: Random (0x01)
Filter policy: Accept all advertisement (0x00)
PHYs: 0x05
Entry 0: LE 1M
Type: Active (0x01)
Interval: 11.250 msec (0x0012)
Window: 11.250 msec (0x0012)
Entry 1: LE Coded
Type: Active (0x01)
Interval: 11.250 msec (0x0012)
Window: 11.250 msec (0x0012)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Extended Scan Enable (0x08|0x0042) plen 6
Extended scan: Enabled (0x01)
Filter duplicates: Enabled (0x01)
Duration: 0 msec (0x0000)
Period: 0.00 sec (0x0000)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
Status: Success (0x00)
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This defines and implement phy changed event and send it to user
whenever selected PHYs changes using SET_PHY_CONFIGURATION.
This will be also trigerred when BREDR pkt_type is changed using
the legacy ioctl HCISETPTYPE.
@ MGMT Command: Set PHY Configuration (0x0045) plen 4
Selected PHYs: 0x7fff
BR 1M 1SLOT
BR 1M 3SLOT
BR 1M 5SLOT
EDR 2M 1SLOT
EDR 2M 3SLOT
EDR 2M 5SLOT
EDR 3M 1SLOT
EDR 3M 3SLOT
EDR 3M 5SLOT
LE 1M TX
LE 1M RX
LE 2M TX
LE 2M RX
LE CODED TX
LE CODED RX
< HCI Command: LE Set Default PHY (0x08|0x0031) plen 3
All PHYs preference: 0x00
TX PHYs preference: 0x07
LE 1M
LE 2M
LE Coded
RX PHYs preference: 0x07
LE 1M
LE 2M
LE Coded
> HCI Event: Command Complete (0x0e) plen 4
LE Set Default PHY (0x08|0x0031) ncmd 1
Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 3
Set PHY Configuration (0x0045) plen 0
Status: Success (0x00)
@ MGMT Event: PHY Configuration Changed (0x0026) plen 4
Selected PHYs: 0x7fff
BR 1M 1SLOT
BR 1M 3SLOT
BR 1M 5SLOT
EDR 2M 1SLOT
EDR 2M 3SLOT
EDR 2M 5SLOT
EDR 3M 1SLOT
EDR 3M 3SLOT
EDR 3M 5SLOT
LE 1M TX
LE 1M RX
LE 2M TX
LE 2M RX
LE CODED TX
LE CODED RX
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This enables user to set phys which will be used in all subsequent
connections. Also host will use the same in LE scanning as well.
@ MGMT Command: Set PHY Configuration (0x0045) plen 4
Selected PHYs: 0x7fff
BR 1M 1SLOT
BR 1M 3SLOT
BR 1M 5SLOT
EDR 2M 1SLOT
EDR 2M 3SLOT
EDR 2M 5SLOT
EDR 3M 1SLOT
EDR 3M 3SLOT
EDR 3M 5SLOT
LE 1M TX
LE 1M RX
LE 2M TX
LE 2M RX
LE CODED TX
LE CODED RX
< HCI Command: LE Set Default PHY (0x08|0x0031) plen 3
All PHYs preference: 0x00
TX PHYs preference: 0x07
LE 1M
LE 2M
LE Coded
RX PHYs preference: 0x07
LE 1M
LE 2M
LE Coded
> HCI Event: Command Complete (0x0e) plen 4
LE Set Default PHY (0x08|0x0031) ncmd 1
Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 3
Set PHY Configuration (0x0045) plen 0
Status: Success (0x00)
@ MGMT Event: PHY Configuration Changed (0x0026) plen 4
Selected PHYs: 0x7fff
BR 1M 1SLOT
BR 1M 3SLOT
BR 1M 5SLOT
EDR 2M 1SLOT
EDR 2M 3SLOT
EDR 2M 5SLOT
EDR 3M 1SLOT
EDR 3M 3SLOT
EDR 3M 5SLOT
LE 1M TX
LE 1M RX
LE 2M TX
LE 2M RX
LE CODED TX
LE CODED RX
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This commands basically retrieve the supported packet types of
BREDR and supported PHYs of the controller.
BR_1M_1SLOT, LE_1M_TX and LE_1M_RX would be supported by default.
Other PHYs are supported based on the local features.
Also this sets PHY_CONFIGURATION bit in supported settings.
@ MGMT Command: Get PHY Configuration (0x0044) plen 0
@ MGMT Event: Command Complete (0x0001) plen 15
Get PHY Configuration (0x0044) plen 12
Status: Success (0x00)
Supported PHYs: 0x7fff
BR 1M 1SLOT
BR 1M 3SLOT
BR 1M 5SLOT
EDR 2M 1SLOT
EDR 2M 3SLOT
EDR 2M 5SLOT
EDR 3M 1SLOT
EDR 3M 3SLOT
EDR 3M 5SLOT
LE 1M TX
LE 1M RX
LE 2M TX
LE 2M RX
LE CODED TX
LE CODED RX
Configurable PHYs: 0x79fe
BR 1M 3SLOT
BR 1M 5SLOT
EDR 2M 1SLOT
EDR 2M 3SLOT
EDR 2M 5SLOT
EDR 3M 1SLOT
EDR 3M 3SLOT
EDR 3M 5SLOT
LE 2M TX
LE 2M RX
LE CODED TX
LE CODED RX
Selected PHYs: 0x07ff
BR 1M 1SLOT
BR 1M 3SLOT
BR 1M 5SLOT
EDR 2M 1SLOT
EDR 2M 3SLOT
EDR 2M 5SLOT
EDR 3M 1SLOT
EDR 3M 3SLOT
EDR 3M 5SLOT
LE 1M TX
LE 1M RX
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This also add macros for checking LMP support for different
pkt_types
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
1M is mandatory to be supported by LE controllers and the same
would be set in power on. This patch defines hdev flags for
LE PHYs and set 1M to default.
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <baijiaju1990@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
inject_cmd_complete()
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 <baijiaju1990@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
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 <baijiaju1990@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
btmrvl_sdio_card_to_host()
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 <baijiaju1990@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
bpa10x_send_frame() is only set to hdev->send, and hdev->send() is never
called in atomic context.
bpa10x_send_frame() calls usb_alloc_urb(), kmalloc() and usb_submit_urb()
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 <baijiaju1990@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
bluecard_hci_set_baud_rate()
bluecard_hci_set_baud_rate() is never called in atomic context.
bluecard_hci_set_baud_rate() is only by bluecard_hci_open(), which is
set to hdev->open, and hdev->open() is never called in atomic context.
bluecard_hci_set_baud_rate() 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 <baijiaju1990@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
bfusb_send_frame() is only set to hdev->send, and hdev->send() is never
called in atomic context.
bfusb_send_frame() 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 <baijiaju1990@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Fixes this warning that was provoked by a pairing:
[60258.016221] WARNING: possible recursive locking detected
[60258.021558] 4.15.0-RD1812-BSP #1 Tainted: G O
[60258.027146] --------------------------------------------
[60258.032464] kworker/u5:0/70 is trying to acquire lock:
[60258.037609] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<87759073>] bt_accept_enqueue+0x3c/0x74
[60258.046863]
[60258.046863] but task is already holding lock:
[60258.052704] (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<d22d7106>] l2cap_sock_new_connection_cb+0x1c/0x88
[60258.062905]
[60258.062905] other info that might help us debug this:
[60258.069441] Possible unsafe locking scenario:
[60258.069441]
[60258.075368] CPU0
[60258.077821] ----
[60258.080272] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
[60258.085510] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
[60258.090748]
[60258.090748] *** DEADLOCK ***
[60258.090748]
[60258.096676] May be due to missing lock nesting notation
[60258.096676]
[60258.103472] 5 locks held by kworker/u5:0/70:
[60258.107747] #0: ((wq_completion)%shdev->name#2){+.+.}, at: [<9460d092>] process_one_work+0x130/0x4fc
[60258.117263] #1: ((work_completion)(&hdev->rx_work)){+.+.}, at: [<9460d092>] process_one_work+0x130/0x4fc
[60258.126942] #2: (&conn->chan_lock){+.+.}, at: [<7877c8c3>] l2cap_connect+0x80/0x4f8
[60258.134806] #3: (&chan->lock/2){+.+.}, at: [<2e16c724>] l2cap_connect+0x8c/0x4f8
[60258.142410] #4: (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: [<d22d7106>] l2cap_sock_new_connection_cb+0x1c/0x88
[60258.153043]
[60258.153043] stack backtrace:
[60258.157413] CPU: 1 PID: 70 Comm: kworker/u5:0 Tainted: G O 4.15.0-RD1812-BSP #1
[60258.165945] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[60258.172485] Workqueue: hci0 hci_rx_work
[60258.176331] Backtrace:
[60258.178797] [<8010c9fc>] (dump_backtrace) from [<8010ccbc>] (show_stack+0x18/0x1c)
[60258.186379] r7:80e55fe4 r6:80e55fe4 r5:20050093 r4:00000000
[60258.192058] [<8010cca4>] (show_stack) from [<809864e8>] (dump_stack+0xb0/0xdc)
[60258.199301] [<80986438>] (dump_stack) from [<8016ecc8>] (__lock_acquire+0xffc/0x11d4)
[60258.207144] r9:5e2bb019 r8:630f974c r7:ba8a5940 r6:ba8a5ed8 r5:815b5220 r4:80fa081c
[60258.214901] [<8016dccc>] (__lock_acquire) from [<8016f620>] (lock_acquire+0x78/0x98)
[60258.222655] r10:00000040 r9:00000040 r8:808729f0 r7:00000001 r6:00000000 r5:60050013
[60258.230491] r4:00000000
[60258.233045] [<8016f5a8>] (lock_acquire) from [<806ee974>] (lock_sock_nested+0x64/0x88)
[60258.240970] r7:00000000 r6:b796e870 r5:00000001 r4:b796e800
[60258.246643] [<806ee910>] (lock_sock_nested) from [<808729f0>] (bt_accept_enqueue+0x3c/0x74)
[60258.255004] r8:00000001 r7:ba7d3c00 r6:ba7d3ea4 r5:ba7d2000 r4:b796e800
[60258.261717] [<808729b4>] (bt_accept_enqueue) from [<808aa39c>] (l2cap_sock_new_connection_cb+0x68/0x88)
[60258.271117] r5:b796e800 r4:ba7d2000
[60258.274708] [<808aa334>] (l2cap_sock_new_connection_cb) from [<808a294c>] (l2cap_connect+0x190/0x4f8)
[60258.283933] r5:00000001 r4:ba6dce00
[60258.287524] [<808a27bc>] (l2cap_connect) from [<808a4a14>] (l2cap_recv_frame+0x744/0x2cf8)
[60258.295800] r10:ba6dcf24 r9:00000004 r8:b78d8014 r7:00000004 r6:bb05d000 r5:00000004
[60258.303635] r4:bb05d008
[60258.306183] [<808a42d0>] (l2cap_recv_frame) from [<808a7808>] (l2cap_recv_acldata+0x210/0x214)
[60258.314805] r10:b78e7800 r9:bb05d960 r8:00000001 r7:bb05d000 r6:0000000c r5:b7957a80
[60258.322641] r4:ba6dce00
[60258.325188] [<808a75f8>] (l2cap_recv_acldata) from [<8087630c>] (hci_rx_work+0x35c/0x4e8)
[60258.333374] r6:80e5743c r5:bb05d7c8 r4:b7957a80
[60258.338004] [<80875fb0>] (hci_rx_work) from [<8013dc7c>] (process_one_work+0x1a4/0x4fc)
[60258.346018] r10:00000001 r9:00000000 r8:baabfef8 r7:ba997500 r6:baaba800 r5:baaa5d00
[60258.353853] r4:bb05d7c8
[60258.356401] [<8013dad8>] (process_one_work) from [<8013e028>] (worker_thread+0x54/0x5cc)
[60258.364503] r10:baabe038 r9:baaba834 r8:80e05900 r7:00000088 r6:baaa5d18 r5:baaba800
[60258.372338] r4:baaa5d00
[60258.374888] [<8013dfd4>] (worker_thread) from [<801448f8>] (kthread+0x134/0x160)
[60258.382295] r10:ba8310b8 r9:bb07dbfc r8:8013dfd4 r7:baaa5d00 r6:00000000 r5:baaa8ac0
[60258.390130] r4:ba831080
[60258.392682] [<801447c4>] (kthread) from [<801080b4>] (ret_from_fork+0x14/0x20)
[60258.399915] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801447c4
[60258.407751] r4:baaa8ac0 r3:baabe000
Signed-off-by: Philipp Puschmann <pp@emlix.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
slub debug reported:
[ 440.648642] =============================================================================
[ 440.648649] BUG kmalloc-1024 (Tainted: G BU O ): Poison overwritten
[ 440.648651] -----------------------------------------------------------------------------
[ 440.648655] INFO: 0xe70f4bec-0xe70f4bec. First byte 0x6a instead of 0x6b
[ 440.648665] INFO: Allocated in sk_prot_alloc+0x6b/0xc6 age=33155 cpu=1 pid=1047
[ 440.648671] ___slab_alloc.constprop.24+0x1fc/0x292
[ 440.648675] __slab_alloc.isra.18.constprop.23+0x1c/0x25
[ 440.648677] __kmalloc+0xb6/0x17f
[ 440.648680] sk_prot_alloc+0x6b/0xc6
[ 440.648683] sk_alloc+0x1e/0xa1
[ 440.648700] sco_sock_alloc.constprop.6+0x26/0xaf [bluetooth]
[ 440.648716] sco_connect_cfm+0x166/0x281 [bluetooth]
[ 440.648731] hci_conn_request_evt.isra.53+0x258/0x281 [bluetooth]
[ 440.648746] hci_event_packet+0x28b/0x2326 [bluetooth]
[ 440.648759] hci_rx_work+0x161/0x291 [bluetooth]
[ 440.648764] process_one_work+0x163/0x2b2
[ 440.648767] worker_thread+0x1a9/0x25c
[ 440.648770] kthread+0xf8/0xfd
[ 440.648774] ret_from_fork+0x2e/0x38
[ 440.648779] INFO: Freed in __sk_destruct+0xd3/0xdf age=3815 cpu=1 pid=1047
[ 440.648782] __slab_free+0x4b/0x27a
[ 440.648784] kfree+0x12e/0x155
[ 440.648787] __sk_destruct+0xd3/0xdf
[ 440.648790] sk_destruct+0x27/0x29
[ 440.648793] __sk_free+0x75/0x91
[ 440.648795] sk_free+0x1c/0x1e
[ 440.648810] sco_sock_kill+0x5a/0x5f [bluetooth]
[ 440.648825] sco_conn_del+0x8e/0xba [bluetooth]
[ 440.648840] sco_disconn_cfm+0x3a/0x41 [bluetooth]
[ 440.648855] hci_event_packet+0x45e/0x2326 [bluetooth]
[ 440.648868] hci_rx_work+0x161/0x291 [bluetooth]
[ 440.648872] process_one_work+0x163/0x2b2
[ 440.648875] worker_thread+0x1a9/0x25c
[ 440.648877] kthread+0xf8/0xfd
[ 440.648880] ret_from_fork+0x2e/0x38
[ 440.648884] INFO: Slab 0xf4718580 objects=27 used=27 fp=0x (null) flags=0x40008100
[ 440.648886] INFO: Object 0xe70f4b88 @offset=19336 fp=0xe70f54f8
When KASAN was enabled, it reported:
[ 210.096613] ==================================================================
[ 210.096634] BUG: KASAN: use-after-free in ex_handler_refcount+0x5b/0x127
[ 210.096641] Write of size 4 at addr ffff880107e17160 by task kworker/u9:1/2040
[ 210.096651] CPU: 1 PID: 2040 Comm: kworker/u9:1 Tainted: G U O 4.14.47-20180606+ #2
[ 210.096654] Hardware name: , BIOS 2017.01-00087-g43e04de 08/30/2017
[ 210.096693] Workqueue: hci0 hci_rx_work [bluetooth]
[ 210.096698] Call Trace:
[ 210.096711] dump_stack+0x46/0x59
[ 210.096722] print_address_description+0x6b/0x23b
[ 210.096729] ? ex_handler_refcount+0x5b/0x127
[ 210.096736] kasan_report+0x220/0x246
[ 210.096744] ex_handler_refcount+0x5b/0x127
[ 210.096751] ? ex_handler_clear_fs+0x85/0x85
[ 210.096757] fixup_exception+0x8c/0x96
[ 210.096766] do_trap+0x66/0x2c1
[ 210.096773] do_error_trap+0x152/0x180
[ 210.096781] ? fixup_bug+0x78/0x78
[ 210.096817] ? hci_debugfs_create_conn+0x244/0x26a [bluetooth]
[ 210.096824] ? __schedule+0x113b/0x1453
[ 210.096830] ? sysctl_net_exit+0xe/0xe
[ 210.096837] ? __wake_up_common+0x343/0x343
[ 210.096843] ? insert_work+0x107/0x163
[ 210.096850] invalid_op+0x1b/0x40
[ 210.096888] RIP: 0010:hci_debugfs_create_conn+0x244/0x26a [bluetooth]
[ 210.096892] RSP: 0018:ffff880094a0f970 EFLAGS: 00010296
[ 210.096898] RAX: 0000000000000000 RBX: ffff880107e170e8 RCX: ffff880107e17160
[ 210.096902] RDX: 000000000000002f RSI: ffff88013b80ed40 RDI: ffffffffa058b940
[ 210.096906] RBP: ffff88011b2b0578 R08: 00000000852f0ec9 R09: ffffffff81cfcf9b
[ 210.096909] R10: 00000000d21bdad7 R11: 0000000000000001 R12: ffff8800967b0488
[ 210.096913] R13: ffff880107e17168 R14: 0000000000000068 R15: ffff8800949c0008
[ 210.096920] ? __sk_destruct+0x2c6/0x2d4
[ 210.096959] hci_event_packet+0xff5/0x7de2 [bluetooth]
[ 210.096969] ? __local_bh_enable_ip+0x43/0x5b
[ 210.097004] ? l2cap_sock_recv_cb+0x158/0x166 [bluetooth]
[ 210.097039] ? hci_le_meta_evt+0x2bb3/0x2bb3 [bluetooth]
[ 210.097075] ? l2cap_ertm_init+0x94e/0x94e [bluetooth]
[ 210.097093] ? xhci_urb_enqueue+0xbd8/0xcf5 [xhci_hcd]
[ 210.097102] ? __accumulate_pelt_segments+0x24/0x33
[ 210.097109] ? __accumulate_pelt_segments+0x24/0x33
[ 210.097115] ? __update_load_avg_se.isra.2+0x217/0x3a4
[ 210.097122] ? set_next_entity+0x7c3/0x12cd
[ 210.097128] ? pick_next_entity+0x25e/0x26c
[ 210.097135] ? pick_next_task_fair+0x2ca/0xc1a
[ 210.097141] ? switch_mm_irqs_off+0x346/0xb4f
[ 210.097147] ? __switch_to+0x769/0xbc4
[ 210.097153] ? compat_start_thread+0x66/0x66
[ 210.097188] ? hci_conn_check_link_mode+0x1cd/0x1cd [bluetooth]
[ 210.097195] ? finish_task_switch+0x392/0x431
[ 210.097228] ? hci_rx_work+0x154/0x487 [bluetooth]
[ 210.097260] hci_rx_work+0x154/0x487 [bluetooth]
[ 210.097269] process_one_work+0x579/0x9e9
[ 210.097277] worker_thread+0x68f/0x804
[ 210.097285] kthread+0x31c/0x32b
[ 210.097292] ? rescuer_thread+0x70c/0x70c
[ 210.097299] ? kthread_create_on_node+0xa3/0xa3
[ 210.097306] ret_from_fork+0x35/0x40
[ 210.097314] Allocated by task 2040:
[ 210.097323] kasan_kmalloc.part.1+0x51/0xc7
[ 210.097328] __kmalloc+0x17f/0x1b6
[ 210.097335] sk_prot_alloc+0xf2/0x1a3
[ 210.097340] sk_alloc+0x22/0x297
[ 210.097375] sco_sock_alloc.constprop.7+0x23/0x202 [bluetooth]
[ 210.097410] sco_connect_cfm+0x2d0/0x566 [bluetooth]
[ 210.097443] hci_conn_request_evt.isra.53+0x6d3/0x762 [bluetooth]
[ 210.097476] hci_event_packet+0x85e/0x7de2 [bluetooth]
[ 210.097507] hci_rx_work+0x154/0x487 [bluetooth]
[ 210.097512] process_one_work+0x579/0x9e9
[ 210.097517] worker_thread+0x68f/0x804
[ 210.097523] kthread+0x31c/0x32b
[ 210.097529] ret_from_fork+0x35/0x40
[ 210.097533] Freed by task 2040:
[ 210.097539] kasan_slab_free+0xb3/0x15e
[ 210.097544] kfree+0x103/0x1a9
[ 210.097549] __sk_destruct+0x2c6/0x2d4
[ 210.097584] sco_conn_del.isra.1+0xba/0x10e [bluetooth]
[ 210.097617] hci_event_packet+0xff5/0x7de2 [bluetooth]
[ 210.097648] hci_rx_work+0x154/0x487 [bluetooth]
[ 210.097653] process_one_work+0x579/0x9e9
[ 210.097658] worker_thread+0x68f/0x804
[ 210.097663] kthread+0x31c/0x32b
[ 210.097670] ret_from_fork+0x35/0x40
[ 210.097676] The buggy address belongs to the object at ffff880107e170e8
which belongs to the cache kmalloc-1024 of size 1024
[ 210.097681] The buggy address is located 120 bytes inside of
1024-byte region [ffff880107e170e8, ffff880107e174e8)
[ 210.097683] The buggy address belongs to the page:
[ 210.097689] page:ffffea00041f8400 count:1 mapcount:0 mapping: (null) index:0xffff880107e15b68 compound_mapcount: 0
[ 210.110194] flags: 0x8000000000008100(slab|head)
[ 210.115441] raw: 8000000000008100 0000000000000000 ffff880107e15b68 0000000100170016
[ 210.115448] raw: ffffea0004a47620 ffffea0004b48e20 ffff88013b80ed40 0000000000000000
[ 210.115451] page dumped because: kasan: bad access detected
[ 210.115454] Memory state around the buggy address:
[ 210.115460] ffff880107e17000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 210.115465] ffff880107e17080: fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb
[ 210.115469] >ffff880107e17100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 210.115472] ^
[ 210.115477] ffff880107e17180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 210.115481] ffff880107e17200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 210.115483] ==================================================================
And finally when BT_DBG() and ftrace was enabled it showed:
<...>-14979 [001] .... 186.104191: sco_sock_kill <-sco_sock_close
<...>-14979 [001] .... 186.104191: sco_sock_kill <-sco_sock_release
<...>-14979 [001] .... 186.104192: sco_sock_kill: sk ef0497a0 state 9
<...>-14979 [001] .... 186.104193: bt_sock_unlink <-sco_sock_kill
kworker/u9:2-792 [001] .... 186.104246: sco_sock_kill <-sco_conn_del
kworker/u9:2-792 [001] .... 186.104248: sco_sock_kill: sk ef0497a0 state 9
kworker/u9:2-792 [001] .... 186.104249: bt_sock_unlink <-sco_sock_kill
kworker/u9:2-792 [001] .... 186.104250: sco_sock_destruct <-__sk_destruct
kworker/u9:2-792 [001] .... 186.104250: sco_sock_destruct: sk ef0497a0
kworker/u9:2-792 [001] .... 186.104860: hci_conn_del <-hci_event_packet
kworker/u9:2-792 [001] .... 186.104864: hci_conn_del: hci0 hcon ef0484c0 handle 266
Only in the failed case, sco_sock_kill() gets called with the same sock
pointer two times. Add a check for SOCK_DEAD to avoid continue killing
a socket which has already been killed.
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This implements extended LE craete connection and enhanced
LE conn complete event if the controller supports.
For now it is as good as legacy LE connection and event as
no new features in the extended connection is handled.
< HCI Command: LE Extended Create Connection (0x08|0x0043) plen 26
Filter policy: White list is not used (0x00)
Own address type: Public (0x00)
Peer address type: Random (0x01)
Peer address: DB:7E:2E:1D:85:E8 (Static)
Initiating PHYs: 0x01
Entry 0: LE 1M
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Min connection interval: 50.00 msec (0x0028)
Max connection interval: 70.00 msec (0x0038)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4
LE Extended Create Connection (0x08|0x0043) ncmd 2
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 31
LE Enhanced Connection Complete (0x0a)
Status: Success (0x00)
Handle: 3585
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: DB:7E:2E:1D:85:E8 (Static)
Local resolvable private address: 00:00:00:00:00:00 (Non-Resolvable)
Peer resolvable private address: 00:00:00:00:00:00 (Non-Resolvable)
Connection interval: 67.50 msec (0x0036)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
@ MGMT Event: Device Connected (0x000b) plen 40
LE Address: DB:7E:2E:1D:85:E8 (Static)
Flags: 0x00000000
Data length: 27
Name (complete): Designer Mouse
Appearance: Mouse (0x03c2)
Flags: 0x05
LE Limited Discoverable Mode
BR/EDR Not Supported
16-bit Service UUIDs (complete): 1 entry
Human Interface Device (0x1812)
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This is done so that the helpers can be used for extended conn
implementation which will be done in subsequent patch.
Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
