- 08 Mar, 2020 1 commit
-
-
Luiz Augusto von Dentz authored
This uses skb_pull when parsing signalling PDUs so skb->data for pointing to the current PDU and skb->len as the remaining bytes to be processed. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- 07 Mar, 2020 1 commit
-
-
Marcel Holtmann authored
When processing SCO packets, the handle is wrongly assumed as 16-bit value. The actual size is 12-bits and the other 4-bits are used for packet flags. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
- 04 Mar, 2020 4 commits
-
-
Rocky Liao authored
This patch replaces devm_gpiod_get() with devm_gpiod_get_optional() to get bt_en and replaces devm_clk_get() with devm_clk_get_optional() to get susclk. It also uses NULL check to determine whether the resource is available or not. Fixes: 8a208b24 ("Bluetooth: hci_qca: Make bt_en and susclk not mandatory for QCA Rome") Signed-off-by:
Rocky Liao <rjliao@codeaurora.org> Signed-off-by:
-
Lukas Bulwahn authored
Commit 107db7ec ("docs: networking: convert 6lowpan.txt to ReST") renamed 6lowpan.txt to 6lowpan.rst for the ReST conversion. Since then, ./scripts/get_maintainer.pl --self-test complains: warning: no file matches F: Documentation/networking/6lowpan.txt Adjust 6LOWPAN GENERIC (BTLE/IEEE 802.15.4) entry in MAINTAINERS. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Alain Michaud authored
Some controllers have been observed to send zero'd events under some conditions. This change guards against this condition as well as adding a trace to facilitate diagnosability of this condition. Signed-off-by:
Alain Michaud <alainm@chromium.org> Signed-off-by:
-
Rocky Liao authored
On some platforms the bt_en pin and susclk are default on and there is no exposed resource to control them. This patch makes the bt_en and susclk not mandatory to have BT work. It also will not set the HCI_QUIRK_NON_PERSISTENT_SETUP and shutdown() callback if bt_en is not available. Signed-off-by:
-
- 01 Mar, 2020 1 commit
-
-
Rocky Liao authored
The baudrate set byte of wcn3991 in the NVM tag is byte 1, not byte 2. This patch will set correct byte for wcn3991. Signed-off-by:
-
- 28 Feb, 2020 13 commits
-
-
Rocky Liao authored
QCA Rome doesn't support the pre-shutdown vendor hci command, this patch will check the soc type in qca_power_off() and only send this command for wcn399x. Fixes: ae563183 ("Bluetooth: hci_qca: Enable power off/on support during hci down/up for QCA Rome") Signed-off-by:
-
Mauro Carvalho Chehab authored
- add SPDX header; - use document title markup; - mark code blocks and literals as such; - adjust identation, whitespaces and blank lines; - add to networking/index.rst. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Alain Michaud authored
This patch provides a mechanism for MGMT interface client to query the capability of the controller to support WBS. Signed-off-by:
-
Alain Michaud authored
This change adds a new flag to define a controller's wideband speech capability. This is required since no reliable over HCI mechanism exists to query the controller and driver's compatibility with wideband speech. Signed-off-by:
-
Alain Michaud authored
This change simply fixes a few typos in the quirk definitions. Signed-off-by:
-
Christophe JAILLET authored
'hu->priv' is set twice to NULL in this function. Axe one of these assignments. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
'transmittion' should be 'transmission' Signed-off-by:
-
Sathish Narsimman authored
Disabling LE_LEGACY_ADV when LE_EXT_ADV is enabled causes 'command disallowed . This patch fixes that issue and disables EXT_ADV if enabled. Signed-off-by:
Sathish Narsimman <sathish.narasimman@intel.com> Signed-off-by:
-
Sathish Narsimman authored
Extended advertising Data is set during bluetooth initialization by default which causes InvalidHCICommandParameters when setting Extended advertising parameters. As per Core Spec 5.2 Vol 2, PART E, Sec 7.8.53, for advertising_event_property LE_LEGACY_ADV_DIRECT_IND does not supports advertising data when the advertising set already contains some, the controller shall return erroc code 'InvalidHCICommandParameters(0x12). So it is required to remove adv set for handle 0x00. since we use instance 0 for directed adv. Signed-off-by:
-
Madhuparna Bhowmik authored
In function hci_is_blocked_key() RCU list is traversed with list_for_each_entry() in RCU read-side CS. Use list_for_each_entry_rcu() instead. Signed-off-by:
Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Signed-off-by:
-
Madhuparna Bhowmik authored
The following functions in hci_core are always called with hdev->lock held. No need to use list_for_each_entry_rcu(), therefore change the usage of list_for_each_entry_rcu() in these functions to list_for_each_entry(). hci_link_keys_clear() hci_smp_ltks_clear() hci_smp_irks_clear() hci_blocked_keys_clear() Warning encountered with CONFIG_PROVE_RCU_LIST: [ 72.213184] ============================= [ 72.213188] WARNING: suspicious RCU usage [ 72.213192] 5.6.0-rc1+ #5 Not tainted [ 72.213195] ----------------------------- [ 72.213198] net/bluetooth/hci_core.c:2288 RCU-list traversed in non-reader section!! [ 72.213676] ============================= [ 72.213679] WARNING: suspicious RCU usage [ 72.213683] 5.6.0-rc1+ #5 Not tainted [ 72.213685] ----------------------------- [ 72.213689] net/bluetooth/hci_core.c:2298 RCU-list traversed in non-reader section!! [ 72.214195] ============================= [ 72.214198] WARNING: suspicious RCU usage [ 72.214201] 5.6.0-rc1+ #5 Not tainted [ 72.214204] ----------------------------- [ 72.214208] net/bluetooth/hci_core.c:2308 RCU-list traversed in non-reader section!! [ 333.456972] ============================= [ 333.456979] WARNING: suspicious RCU usage [ 333.457001] 5.6.0-rc1+ #5 Not tainted [ 333.457007] ----------------------------- [ 333.457014] net/bluetooth/hci_core.c:2318 RCU-list traversed in non-reader section!! Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
-
- 19 Feb, 2020 2 commits
-
-
Howard Chung authored
This patch fix the issue: warning:variable 'passkey' is uninitialized when used here Link: https://groups.google.com/forum/#!topic/clang-built-linux/kyRKCjRsGoU Fixes: cee5f20f ("Bluetooth: secure bluetooth stack from bluedump attack") Reported-by:
kbuild test robot <lkp@intel.com> Suggested-by:
Howard Chung <howardchung@google.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
This reuse the L2CAP MTU auto logic to select the MTU used for RFCOMM channels, this should increase the maximum from 1013 to 1021 when 3-DH5 is supported. Since it does not set an L2CAP MTU we no longer need a debugfs so that is removed. Signed-off-by:
-
- 18 Feb, 2020 5 commits
-
-
Luiz Augusto von Dentz authored
This fixes the invalid check for connected socket which causes the following trace due to sco_pi(sk)->conn being NULL: RIP: 0010:sco_sock_getsockopt+0x2ff/0x800 net/bluetooth/sco.c:966 L2CAP has also been fixed since it has the same problem. Signed-off-by:
-
Marcel Holtmann authored
The variable was declared in an unnecessarily broad scope. Signed-off-by:
-
Venkata Lakshmi Narayana Gubba authored
This patch will fix the below issues 1. Discarding memory dump events if memdump state is moved to MEMDUMP_TIMEOUT. 2. Fixed race conditions between qca_hw_error() and qca_controller_memdump while free memory dump buffers using mutex lock 3. Moved timeout timer to delayed work queue 4. Injecting HW error event in a case when dumps failed to receive and HW error event is not yet received. 5. Clearing hw error and command timeout function callbacks before sending pre shutdown command. Collecting memory dump will follow any of the below sequence. Sequence 1: Receiving Memory dump events from the controller Received entire dump in stipulated time Received HW error event from the controller Controller Reset from HOST Sequence 2: Receiving Memory dump events from the controller Failed to Receive entire dump in stipulated time A Timeout schedules and if no HW error event received a fake HW error event will be injected. Controller Reset from HOST. Sequence 3: Received HW error event HOST trigger SSR by sending crash packet to controller. Received entire dump in stipulated time Controller Reset from HOST Fixes: d841502c ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Reported-by:Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by:
Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Reviewed-by:
-
Sathish Narsimman authored
Disabling LEGACY_ADV when EXT_ADV is enabled causes 'command disallowed' during DIRECTED_ADV. This Patch fixes this issue. Signed-off-by:
-
Max Chou authored
Add new compatible and FW loading support for RTL8822C. Signed-off-by:
Max Chou <max.chou@realtek.com> Signed-off-by:
-
- 16 Feb, 2020 1 commit
-
-
Christophe JAILLET authored
'internface' has an extra 'n'. Signed-off-by:
-
- 14 Feb, 2020 2 commits
-
-
Luiz Augusto von Dentz authored
This adds BT_PHY socket option (read-only) which can be used to read the PHYs in use by the underline connection. Signed-off-by:
-
Howard Chung authored
Attack scenario: 1. A Chromebook (let's call this device A) is paired to a legitimate Bluetooth classic device (e.g. a speaker) (let's call this device B). 2. A malicious device (let's call this device C) pretends to be the Bluetooth speaker by using the same BT address. 3. If device A is not currently connected to device B, device A will be ready to accept connection from device B in the background (technically, doing Page Scan). 4. Therefore, device C can initiate connection to device A (because device A is doing Page Scan) and device A will accept the connection because device A trusts device C's address which is the same as device B's address. 5. Device C won't be able to communicate at any high level Bluetooth profile with device A because device A enforces that device C is encrypted with their common Link Key, which device C doesn't have. But device C can initiate pairing with device A with just-works model without requiring user interaction (there is only pairing notification). After pairing, device A now trusts device C with a new different link key, common between device A and C. 6. From now on, device A trusts device C, so device C can at anytime connect to device A to do any kind of high-level hijacking, e.g. speaker hijack or mouse/keyboard hijack. Since we don't know whether the repairing is legitimate or not, leave the decision to user space if all the conditions below are met. - the pairing is initialized by peer - the authorization method is just-work - host already had the link key to the peer Signed-off-by:
-
- 13 Feb, 2020 3 commits
-
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
-
- 08 Feb, 2020 1 commit
-
-
Sergey Shatunov authored
The ASUS FX505DV laptop contains RTL8822CE device with an associated BT chip using a USB ID of 13d3:3548. This patch add fw download support for it. T: Bus=03 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3548 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Sergey Shatunov <me@prok.pw> Signed-off-by:
-
- 05 Feb, 2020 3 commits
-
-
Venkata Lakshmi Narayana Gubba authored
* Directly passing clock pointer to clock code without checking for NULL as clock code takes care of it * Removed the comment which was not necessary * Updated code for return in qca_regulator_enable() Signed-off-by:
-
Alex Shi authored
These 3 macros are never used from first git commit Linux-2.6.12-rc2. let's remove them. Signed-off-by:
Alex Shi <alex.shi@linux.alibaba.com> Signed-off-by:
-
Hillf Danton authored
Prefetch channel before killing sock in order to fix UAF like BUG: KASAN: use-after-free in l2cap_sock_release+0x24c/0x290 net/bluetooth/l2cap_sock.c:1212 Read of size 8 at addr ffff8880944904a0 by task syz-fuzzer/9751 Reported-by: syzbot+c3c5bdea7863886115dc@syzkaller.appspotmail.com Fixes: 6c08fc89 ("Bluetooth: Fix refcount use-after-free issue") Cc: Manish Mandlik <mmandlik@google.com> Signed-off-by:
Hillf Danton <hdanton@sina.com> Signed-off-by:
-
- 03 Feb, 2020 2 commits
-
-
Venkata Lakshmi Narayana Gubba authored
Add compatible string for the Qualcomm WCN3991 Bluetooth controller Signed-off-by:
-
Venkata Lakshmi Narayana Gubba authored
Instead of relying on other subsytem to turn ON clocks required for BT SoC to operate, voting them from the driver. Signed-off-by:
-
- 29 Jan, 2020 1 commit
-
-
Davidlohr Bueso authored
Use smp_mb__before_atomic() instead of smp_mb() and avoid the unnecessary barrier for non LL/SC architectures, such as x86. Signed-off-by:
Davidlohr Bueso <dbueso@suse.de> Signed-off-by:
-
