- 06 Jul, 2019 33 commits
-
-
Sean Wang authored
This adds the support of enabling MT7668U Bluetooth function running on the top of btusb driver. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=0e8d ProdID=7668 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 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=125us E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Josua Mayer authored
BLE based 6LoWPAN networks are highly constrained in bandwidth. Do not take a short-cut, always check if the destination address is known to belong to a peer. As a side-effect this also removes any behavioral differences between one, and two or more connected peers. Acked-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Tested-by:
Michael Scott <mike@foundries.io> Signed-off-by:
Josua Mayer <josua.mayer@jm0.eu> Signed-off-by:
-
Josua Mayer authored
Like any IPv6 capable device, 6LNs can have multiple addresses assigned using SLAAC and made known through neighbour advertisements. After checking the destination address against all peers link-local addresses, consult the neighbour cache for additional known addresses. RFC7668 defines the scope of Neighbor Advertisements in Section 3.2.3: 1. "A Bluetooth LE 6LN MUST NOT register its link-local address" 2. "A Bluetooth LE 6LN MUST register its non-link-local addresses with the 6LBR by sending Neighbor Solicitation (NS) messages ..." Due to these constranits both the link-local addresses tracked in the list of 6lowpan peers, and the neighbour cache have to be used when identifying the 6lowpan peer for a destination address. Acked-by:
-
Josua Mayer authored
Handle overlooked case where the target address is assigned to a peer and neither route nor gateway exist. For one peer, no checks are performed to see if it is meant to receive packets for a given address. As soon as there is a second peer however, checks are performed to deal with routes and gateways for handling complex setups with multiple hops to a target address. This logic assumed that no route and no gateway imply that the destination address can not be reached, which is false in case of a direct peer. Acked-by:
-
Szymon Janc authored
Microsoft Surface Precision Mouse provides bogus identity address when pairing. It connects with Static Random address but provides Public Address in SMP Identity Address Information PDU. Address has same value but type is different. Workaround this by dropping IRK if ID address discrepancy is detected. > HCI Event: LE Meta Event (0x3e) plen 19 LE Connection Complete (0x01) Status: Success (0x00) Handle: 75 Role: Master (0x00) Peer address type: Random (0x01) Peer address: E0:52:33:93:3B:21 (Static) Connection interval: 50.00 msec (0x0028) Connection latency: 0 (0x0000) Supervision timeout: 420 msec (0x002a) Master clock accuracy: 0x00 .... > ACL Data RX: Handle 75 flags 0x02 dlen 12 SMP: Identity Address Information (0x09) len 7 Address type: Public (0x00) Address: E0:52:33:93:3B:21 Signed-off-by:Szymon Janc <szymon.janc@codecoup.pl> Tested-by:
Maarten Fonville <maarten.fonville@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199461 Cc: stable@vger.kernel.org Signed-off-by:
-
Luiz Augusto von Dentz authored
The spec defines PSM and LE_PSM as different domains so a listen on the same PSM is valid if the address type points to a different bearer. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Luiz Augusto von Dentz authored
This makes use of controller sets when using Extended Advertising feature thus offloading the scheduling to the controller. Signed-off-by:
-
csonsino authored
Problem: The Linux Bluetooth stack yields complete control over the BLE connection interval to the remote device. The Linux Bluetooth stack provides access to the BLE connection interval min and max values through /sys/kernel/debug/bluetooth/hci0/ conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval. These values are used for initial BLE connections, but the remote device has the ability to request a connection parameter update. In the event that the remote side requests to change the connection interval, the Linux kernel currently only validates that the desired value is within the acceptable range in the Bluetooth specification (6 - 3200, corresponding to 7.5ms - 4000ms). There is currently no validation that the desired value requested by the remote device is within the min/max limits specified in the conn_min_interval/conn_max_interval configurations. This essentially leads to Linux yielding complete control over the connection interval to the remote device. The proposed patch adds a verification step to the connection parameter update mechanism, ensuring that the desired value is within the min/max bounds of the current connection. If the desired value is outside of the current connection min/max values, then the connection parameter update request is rejected and the negative response is returned to the remote device. Recall that the initial connection is established using the local conn_min_interval/conn_max_interval values, so this allows the Linux administrator to retain control over the BLE connection interval. The one downside that I see is that the current default Linux values for conn_min_interval and conn_max_interval typically correspond to 30ms and 50ms respectively. If this change were accepted, then it is feasible that some devices would no longer be able to negotiate to their desired connection interval values. This might be remedied by setting the default Linux conn_min_interval and conn_max_interval values to the widest supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same behavior as the current implementation, where the remote device could request to change the connection interval value to any value that is permitted by the Bluetooth specification, and Linux would accept the desired value. Signed-off-by:
Carey Sonsino <csonsino@gmail.com> Signed-off-by:
-
Spoorthi Ravishankar Koppad authored
Changes made to add HCI Write Authenticated Payload timeout command for LE Ping feature. As per the Core Specification 5.0 Volume 2 Part E Section 7.3.94, the following code changes implements HCI Write Authenticated Payload timeout command for LE Ping feature. Signed-off-by:
Spoorthi Ravishankar Koppad <spoorthix.k@intel.com> Signed-off-by:
-
Matias Karhumaa authored
Because of both sides doing L2CAP disconnection at the same time, it was possible to receive L2CAP Disconnection Response with CID that was already freed. That caused problems if CID was already reused and L2CAP Connection Request with same CID was sent out. Before this patch kernel deleted channel context regardless of the state of the channel. Example where leftover Disconnection Response (frame #402) causes local device to delete L2CAP channel which was not yet connected. This in turn confuses remote device's stack because same CID is re-used without properly disconnecting. Btmon capture before patch: ** snip ** > ACL Data RX: Handle 43 flags 0x02 dlen 8 #394 [hci1] 10.748949 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #395 [hci1] 10.749062 Channel: 65 len 4 [PSM 3 mode 0] {chan 2} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #396 [hci1] 10.749073 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Packets (0x13) plen 5 #397 [hci1] 10.752391 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 #398 [hci1] 10.753394 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #399 [hci1] 10.756499 L2CAP: Disconnection Request (0x06) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #400 [hci1] 10.756548 L2CAP: Disconnection Response (0x07) ident 26 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #401 [hci1] 10.757459 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #402 [hci1] 10.759148 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o.. 10.759447 > HCI Event: Number of Completed Packets (0x13) plen 5 #403 [hci1] 10.759386 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #404 [hci1] 10.760397 L2CAP: Connection Request (0x02) ident 27 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #405 [hci1] 10.760441 L2CAP: Connection Response (0x03) ident 27 len 8 Destination CID: 65 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #406 [hci1] 10.760449 L2CAP: Configure Request (0x04) ident 19 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > HCI Event: Number of Completed Packets (0x13) plen 5 #407 [hci1] 10.761399 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #408 [hci1] 10.762942 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Similar case after the patch: *snip* > ACL Data RX: Handle 43 flags 0x02 dlen 8 #22702 [hci0] 1664.411056 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Disconnect (DISC) (0x43) Address: 0x03 cr 1 dlci 0x00 Control: 0x53 poll/final 1 Length: 0 FCS: 0xfd < ACL Data TX: Handle 43 flags 0x00 dlen 8 #22703 [hci0] 1664.411136 Channel: 65 len 4 [PSM 3 mode 0] {chan 3} RFCOMM: Unnumbered Ack (UA) (0x63) Address: 0x03 cr 1 dlci 0x00 Control: 0x73 poll/final 1 Length: 0 FCS: 0xd7 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22704 [hci0] 1664.411143 L2CAP: Disconnection Request (0x06) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22705 [hci0] 1664.414009 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22706 [hci0] 1664.415007 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22707 [hci0] 1664.418674 L2CAP: Disconnection Request (0x06) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22708 [hci0] 1664.418762 L2CAP: Disconnection Response (0x07) ident 17 len 4 Destination CID: 65 Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 12 #22709 [hci0] 1664.421073 L2CAP: Connection Request (0x02) ident 12 len 4 PSM: 1 (0x0001) Source CID: 65 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22710 [hci0] 1664.421371 L2CAP: Disconnection Response (0x07) ident 11 len 4 Destination CID: 65 Source CID: 65 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22711 [hci0] 1664.424082 Num handles: 1 Handle: 43 Count: 1 > HCI Event: Number of Completed Pac.. (0x13) plen 5 #22712 [hci0] 1664.425040 Num handles: 1 Handle: 43 Count: 1 > ACL Data RX: Handle 43 flags 0x02 dlen 12 #22713 [hci0] 1664.426103 L2CAP: Connection Request (0x02) ident 18 len 4 PSM: 3 (0x0003) Source CID: 65 < ACL Data TX: Handle 43 flags 0x00 dlen 16 #22714 [hci0] 1664.426186 L2CAP: Connection Response (0x03) ident 18 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) < ACL Data TX: Handle 43 flags 0x00 dlen 27 #22715 [hci0] 1664.426196 L2CAP: Configure Request (0x04) ident 13 len 19 Destination CID: 65 Flags: 0x0000 Option: Maximum Transmission Unit (0x01) [mandatory] MTU: 1013 Option: Retransmission and Flow Control (0x04) [mandatory] Mode: Basic (0x00) TX window size: 0 Max transmit: 0 Retransmission timeout: 0 Monitor timeout: 0 Maximum PDU size: 0 > ACL Data RX: Handle 43 flags 0x02 dlen 16 #22716 [hci0] 1664.428804 L2CAP: Connection Response (0x03) ident 12 len 8 Destination CID: 66 Source CID: 65 Result: Connection successful (0x0000) Status: No further information available (0x0000) *snip* Fix is to check that channel is in state BT_DISCONN before deleting the channel. This bug was found while fuzzing Bluez's OBEX implementation using Synopsys Defensics. Reported-by:Matti Kamunen <matti.kamunen@synopsys.com> Reported-by:
Ari Timonen <ari.timonen@synopsys.com> Signed-off-by:
Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by:
-
Dan Carpenter authored
This change is similar to commit a1616a5a ("Bluetooth: hidp: fix buffer overflow") but for the compat ioctl. We take a string from the user and forgot to ensure that it's NUL terminated. I have also changed the strncpy() in to strscpy() in hidp_setup_hid(). The difference is the strncpy() doesn't necessarily NUL terminate the destination string. Either change would fix the problem but it's nice to take a belt and suspenders approach and do both. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
João Paulo Rechi Vita authored
Without the QCA ROME setup routine this adapter fails to establish a SCO connection. T: Bus=01 Lev=01 Prnt=01 Port=08 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3491 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by:
-
João Paulo Rechi Vita authored
Without the QCA ROME setup routine this adapter fails to establish a SCO connection. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3501 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
-
Tomas Bortoli authored
Syzkaller found that it is possible to provoke a memory leak by never freeing rx_skb in struct bcsp_struct. Fix by freeing in bcsp_close() Signed-off-by:
Tomas Bortoli <tomasbortoli@gmail.com> Reported-by: syzbot+98162c885993b72f19c4@syzkaller.appspotmail.com Signed-off-by:
-
Larry Finger authored
This device is functionally equivalent to the BT part of the RTL8723DE, uses the same firmware, but the LMP subversion and HCI revision are unique. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Sean Wang authored
Some board requires explicitily control external osscilator via GPIO. So, add an implementation of a clock property for an external oscillator to the device. Signed-off-by:
-
Sean Wang authored
Not every platform has the pinctrl device integrates the GPIO the function such as MT7621 whose pinctrl and GPIO are separate hardware so the driver adds additional boot-gpios to let the MT766[3,8]U can enter the proper boot mode by gpiod for such platform. Signed-off-by:
-
Sean Wang authored
Some board requires explicitily control external osscilator via GPIO. So, add a clock property for an external oscillator for the device. Signed-off-by:
-
Sean Wang authored
Not every platform has the pinctrl device integrates the GPIO the function such as MT7621 whose pinctrl and GPIO are separate hardware so adding an additional boot-gpios property for such platform allows them to bring up the device. Signed-off-by:
-
Neil Armstrong authored
The BCM4359C0 BT/Wi-Fi compo chip needs an entry to be discovered by the btbcm driver. Tested using an AP6398S module from Ampak. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Rocky Liao authored
This patch adds an optional device property "firmware-name" to allow the driver to load customized nvm firmware file based on this property. Signed-off-by:
Rocky Liao <rjliao@codeaurora.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rocky Liao authored
QCA BTSOC NVM is a customized firmware file and different vendors may want to have different BTSOC configuration (e.g. Configure SCO over PCM or I2S, Setting Tx power, etc.) via this file. This patch will allow vendors to download different NVM firmware file by reading a device property "firmware-name". Signed-off-by:
Harish Bandi <c-hbandi@codeaurora.org> Signed-off-by:
-
Sascha Hauer authored
This adds serdev support to the Marvell hci uart driver. Only basic serdev support, none of the fancier features like regulator or enable GPIO support is added for now. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Sascha Hauer authored
For the Marvell HCI UART we have to upload two firmware files. The first one is only for switching the baudrate of the device to a higher baudrate. After the baudrate switching firmware has been uploaded the device waits for a final ack (0x5a) before actually switching the baudrate. To send this final ack with the old baudrate give the hci ldisc workqueue a chance to run before switching the baudrate. Without this the final ack will never be received by the device and firmware upload fails. Signed-off-by:
-
Sascha Hauer authored
The hci UART line discipline sends its characters in a workqueue. Some devices like the Marvell Bluetooth chips need to make sure that all queued characters are sent before switching the baudrate. This adds a function to synchronize with the workqueue. Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Because we don't care if debugfs works or not, this trickles back a bit so we can clean things up by making some functions return void instead of an error value that is never going to fail. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
-
Matthias Kaehlcke authored
Firmware download to the WCN3990 often fails with a 'TLV response size mismatch' error: [ 133.064659] Bluetooth: hci0: setting up wcn3990 [ 133.489150] Bluetooth: hci0: QCA controller version 0x02140201 [ 133.495245] Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv [ 133.507214] Bluetooth: hci0: QCA TLV response size mismatch [ 133.513265] Bluetooth: hci0: QCA Failed to download patch (-84) This is caused by a vendor event that corresponds to an earlier command to change the baudrate. The event is not processed in the context of the baudrate change and is later interpreted as response to the firmware download command (which is also a vendor command), but the driver detects that the event doesn't have the expected amount of associated data. More details: For the WCN3990 the vendor command for a baudrate change isn't sent as synchronous HCI command, because the controller sends the corresponding vendor event with the new baudrate. The event is received and decoded after the baudrate change of the host port. Identify the 'unused' event when it is received and don't add it to the queue of RX frames. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
Balakrishna Godavarthi authored
Latest qualcomm chips are not sending an command complete event for every firmware packet sent to chip. They only respond with a vendor specific event for the last firmware packet. This optimization will decrease the BT ON time. Due to this we are seeing a timeout error message logs on the console during firmware download. Now we are injecting a command complete event once we receive an vendor specific event for the last RAM firmware packet. Signed-off-by:
Balakrishna Godavarthi <bgodavar@codeaurora.org> Tested-by:
-
Fabian Schindlatz authored
Fix some warnings and one error reported by checkpatch.pl: - lines longer than 80 characters are wrapped - empty lines inserted to separate variable declarations from the actual code - line break inserted after if (...) Co-developed-by:
Thomas Röthenbacher <thomas.roethenbacher@fau.de> Signed-off-by:
Fabian Schindlatz <fabian.schindlatz@fau.de> Cc: linux-kernel@i4.cs.fau.de Signed-off-by:
-
Jian-Hong Pan authored
Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly after on-off several times. Bluetooth daemon sets BT mode failed when this issue happens. Scanning must be active while turning off for this bug to be hit. bluetoothd[1576]: Failed to set mode: Failed (0x03) If BT is turned off, then turned on again, it works correctly again. According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set during probing. So, this patch makes Realtek's BT reset on close to fix this issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429Signed-off-by:
Jian-Hong Pan <jian-hong@endlessm.com> Reviewed-by:
Daniel Drake <drake@endlessm.com> Signed-off-by:
-
Fabian Schindlatz authored
Extract the new function send_command_from_firmware from download_firmware, which helps with the readability of the switch statement. This way the code is less deeply nested and also no longer exceeds the 80 character limit. Co-developed-by:
-
Philipp Puschmann authored
Uploading the firmware needs quite a few seconds if done at 115200 kbps. So set the operational frequency, usually 3 MHz, before uploading the firmware. I have successfully tested this with a wl1837mod. Signed-off-by:
Philipp Puschmann <philipp.puschmann@emlix.com> Signed-off-by:
-
Peter Robinson authored
BCM4356 devices soldered onto the PCB (non-removable) use an UART connection for bluetooth, such as the Rock960, but it also advertise btsdio support as a sdio function. Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> CC: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
- 05 Jul, 2019 7 commits
-
-
David S. Miller authored
Tariq Toukan says: ==================== mlx5 TLS TX HW offload support This series from Eran and me, adds TLS TX HW offload support to the mlx5 driver. This offloads the kTLS encryption process from kernel to the Mellanox NIC, saving CPU cycles and improving utilization. Upon a new TLS connection request, driver is responsible to create a dedicated HW context and configure it according to the crypto info, so HW can do the encryption itself. When the HW context gets out-of-sync (i.e. due to packets retransmission), driver is responsible for the re-sync process. This is done by posting special resync descriptors to the HW. Feature is supported on Mellanox Connect-X 6DX, and newer. Series was tested on SimX simulator. Series generated against net-next commit [1], with Saeed's request pulled [2]: [1] c4cde580 Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next [2] git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2019-07-04-v2 Changes from last pull request: Fixed comments from Jakub: Patch 4: - Replace zero memset with a call to memzero_explicit(). Patch 11: - Fix stats counters names. - Drop TLS SKB with non-matching netdev. ==================== Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Tariq Toukan authored
Add support for transmit side kernel-TLS acceleration. Offload the crypto encryption to HW. Per TLS connection: - Use a separate TIS to maintain the HW context. - Use a separate encryption key. - Maintain static and progress HW contexts by posting the proper WQEs at creation time, or upon resync. - Use a special DUMP opcode to replay the previous frags and sync the HW context. To make sure the SQ is able to serve an xmit request, increase SQ stop room to cover: - static params WQE, - progress params WQE, and - resync DUMP per frag. Currently supporting TLS 1.2, and key size 128bit. Tested over SimX simulator. Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Tariq Toukan authored
Similar to the existing mlx5e_post_nop(), but marks a fence in the WQE control segment. Added as a separate new function to not hurt the performance of the common case. To be used in a downstream patch of the series. Signed-off-by:
Boris Pismenny <borisp@mellanox.com> Signed-off-by:
-
Tariq Toukan authored
Let the EN TIS creation function (mlx5e_create_tis) be responsible for applying common mdev related fields. Other specific fields must be set by the caller and passed within the inbox. Signed-off-by:
-
Tariq Toukan authored
Use an SQ field for stop_room, and use the larger value only if TLS is supported. Signed-off-by:
-
Eran Ben Elisha authored
When polling a CQE of an SKB-less WQE, don't assume it consumed only one WQEBB. Use wi->num_wqebbs directly instead. In the downstream patch, SKB-less WQEs might have more the one WQEBB, thus this change is needed. Signed-off-by:
-
Tariq Toukan authored
Change mlx5e_sq_fetch_wqe to be agnostic to the Work Queue Element (WQE) type. Before this patch, it was specific for struct mlx5e_tx_wqe. In order to allow the change, the function now returns the generic void pointer, and gets the WQE size to do the zero memset. Signed-off-by:
-
