- 24 Apr, 2023 40 commits
-
-
Max Chou authored
Realtek changed the format of the firmware file as v2. The driver should implement the patch to extract the firmware data from the firmware file. The future chips must apply this patch for firmware loading. This patch is compatible with the both previous format and v2 as well. Signed-off-by: Allen Chen <allen_chen@realsil.com.cn> Signed-off-by: Alex Lu <alex_lu@realsil.com.cn> Tested-by: Hilda Wu <hildawu@realtek.com> Signed-off-by: Max Chou <max.chou@realtek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Zijun Hu authored
API hci_devcd_init() stores its u32 type parameter @dump_size into skb, but it does not specify which byte order is used to store the integer, let us take little endian to store and parse the integer. Fixes: f5cc609d09d4 ("Bluetooth: Add support for hci devcoredump") Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Ruihan Li authored
Previously, capability was checked using capable(), which verified that the caller of the ioctl system call had the required capability. In addition, the result of the check would be stored in the HCI_SOCK_TRUSTED flag, making it persistent for the socket. However, malicious programs can abuse this approach by deliberately sharing an HCI socket with a privileged task. The HCI socket will be marked as trusted when the privileged task occasionally makes an ioctl call. This problem can be solved by using sk_capable() to check capability, which ensures that not only the current task but also the socket opener has the specified capability, thus reducing the risk of privilege escalation through the previously identified vulnerability. Cc: stable@vger.kernel.org Fixes: f81f5b2d ("Bluetooth: Send control open and close messages for HCI raw sockets") Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Min Li authored
conn->chan_lock isn't acquired before l2cap_get_chan_by_scid, if l2cap_get_chan_by_scid returns NULL, then 'bad unlock balance' is triggered. Reported-by: syzbot+9519d6b5b79cf7787cf3@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/000000000000894f5f05f95e9f4d@google.com/Signed-off-by: Min Li <lm0963hack@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Ruihan Li authored
Previously, channel open messages were always sent to monitors on the first ioctl() call for unbound HCI sockets, even if the command and arguments were completely invalid. This can leave an exploitable hole with the abuse of invalid ioctl calls. This commit hardens the ioctl processing logic by first checking if the command is valid, and immediately returning with an ENOIOCTLCMD error code if it is not. This ensures that ioctl calls with invalid commands are free of side effects, and increases the difficulty of further exploitation by forcing exploitation to find a way to pass a valid command first. Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn> Co-developed-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Liu Jian authored
This reverts commit 1e9ac114. This patch introduces a possible null-ptr-def problem. Revert it. And the fixed bug by this patch have resolved by commit 73f7b171 ("Bluetooth: btsdio: fix use after free bug in btsdio_remove due to race condition"). Fixes: 1e9ac114 ("Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work") Signed-off-by: Liu Jian <liujian56@huawei.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Raul Cheleguini authored
The ATS2851 based controller advertises support for command "LE Set Random Private Address Timeout" but does not actually implement it, impeding the controller initialization. Add the quirk HCI_QUIRK_BROKEN_SET_RPA_TIMEOUT to unblock the controller initialization. < HCI Command: LE Set Resolvable Private... (0x08|0x002e) plen 2 Timeout: 900 seconds > HCI Event: Command Status (0x0f) plen 4 LE Set Resolvable Private Address Timeout (0x08|0x002e) ncmd 1 Status: Unknown HCI Command (0x01) Co-developed-by: imoc <wzj9912@gmail.com> Signed-off-by: imoc <wzj9912@gmail.com> Signed-off-by: Raul Cheleguini <raul.cheleguini@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Luiz Augusto von Dentz authored
When submitting HCI_OP_LE_CREATE_CIS the code shall wait for HCI_EVT_LE_CIS_ESTABLISHED thus enforcing the serialization of HCI_OP_LE_CREATE_CIS as the Core spec does not allow to send them in parallel: BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E page 2566: If the Host issues this command before all the HCI_LE_CIS_Established events from the previous use of the command have been generated, the Controller shall return the error code Command Disallowed (0x0C). Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Luiz Augusto von Dentz authored
This fixes only matching CIS by address which prevents creating new hcon if upper layer is requesting a specific CIS ID. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Luiz Augusto von Dentz authored
Since it is required for some configurations to have multiple CIS with the same peer which is now covered by iso-tester in the following test cases: ISO AC 6(i) - Success ISO AC 7(i) - Success ISO AC 8(i) - Success ISO AC 9(i) - Success ISO AC 11(i) - Success Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Dan Carpenter authored
There are a number of bugs here: 1) If "count" is less than sizeof(dump_data.data) then it copies uninitialized data. 2) If simple_write_to_buffer() returns -EFAULT then we run into a problem "ret < count" comparison. "count" is an unsigned long so the comparison is type promoted to unsigned long and the negative returns become high positive values. That also results in copying uninitialized data. 3) If "*ppos" is non-zero then the first part of the dump_data buffer is uninitialized. Using copy_from_user() instead of simple_write_to_buffer() is more appropriate here. Fixes: d5d5df6da0aa ("Bluetooth: Add vhci devcoredump support") Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Steev Klimaszewski authored
The driver can be compile tested with !CONFIG_OF making certain data unused. Signed-off-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Iulia Tanasescu authored
Remove extra line setting the broadcast code parameter of the hci_cp_le_create_big struct to 0. The broadcast code is copied from the QoS struct. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Lanzhe Li authored
Fixed a wrong indentation before "return".This line uses a 7 space indent instead of a tab. Signed-off-by: Lanzhe Li <u202212060@hust.edu.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Neeraj Sanjay Kale authored
We can never assume the uart will deliver a complete packet to the BT layer at once, the expected packet may be divided into several parts by uart as uart doesn't know the received packet size, the received data count may mismatch with the expected packet size, so here is_valid_bootloader_signature() check may always return false. Even we remove the count check in is_valid_bootloader_signature(), then the first part of the data which includes the packet type can pass the is_valid_bootloader_signature() check, but the remaining parts don't have the packet type data still cannot pass the check, here return directly will cause the data loss. So need to remove the received bootloader signature check here, the h4_recv_buf() can help us combine the different data received into one packet. If any out-of-sync or incomplete bootloader signature is received, it is safe to ignore and discard it, and process the next bootloader signature. Co-developed-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Neeraj Sanjay Kale authored
This sets the default power save mode setting to disabled. With this setting, this driver will behave like a normal h4 driver. If user needs to use the power save feature, it can be enabled using the following vendor command: hcitool cmd 3f 23 02 00 00 (HCI_NXP_AUTO_SLEEP_MODE) Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Neeraj Sanjay Kale authored
This adds a call to ps_wakeup() before closing the serdev device, to de-assert UART break. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Neeraj Sanjay Kale authored
This adds support to download helper FW file for the legacy NXP chipset 88w8997 for the btnxpuart driver. This helper FW file is necessary to set the bootloader baudrate to 3000000 after which the actual BT FW file can be downloaded. This change helps bring the FW download time from around 10 sec to less than 2 sec for 88w8997 chip. For newer chipsets, both V1 and V3 bootloader, driver sends the cmd5 and cmd7 to the chip bootloader, and does not need a helper FW file. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Hans de Goede authored
The DSDT for the Acer Iconia One 7 B1-750 models (which share the same mainboard) specifies a IOAPIC IRQ for the HCI -> host IRQ but this is not correct. Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO controller for the IRQ and this pin is _not_ configured in direct IRQ mode by the firmware. Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table, to fix bluetooth not working on these tablets. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Hans de Goede authored
The DSDT for the Lenovo Yoga Tablet 2 830 / 1050 models (which share the same mainboard) specifies a IOAPIC IRQ for the HCI -> host IRQ but this is not correct. Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO controller for the IRQ and this pin is _not_ configured in direct IRQ mode by the firmware. Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table, to fix bluetooth not working on these tablets. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Hans de Goede authored
The bcm43430a0 and bcm43430a1 BT does not support the 0xfc45 command to set the UART clock to 48 MHz and it also does not work at 4000000 baud without this command as some newer models do. These chips are found on ACPI/x86 devices where the operating baudrate does not come from the firmware but is hardcoded at 4000000, which does not work. Add a max_baudrate value to struct bcm_device_data and set this to 2000000 on all known ACPI hardware-ids for the bcm43430a0 and the bcm43430a1. Note this also adds the BCM2E9F ACPI HID which was missing until now. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Hans de Goede authored
On some devices the BCM Bluetooth adapter does not have a valid bdaddr set. btbcm.c currently sets HCI_QUIRK_INVALID_BDADDR to indicate when this is the case. But this requires users to manual setup a btaddr, by doing e.g.: btmgmt -i hci0 public-addr 'B0:F1:EC:82:1D:B3' Which means that Bluetooth will not work out of the box on such devices. To avoid this (where possible) hci_bcm sets: HCI_QUIRK_USE_BDADDR_PROPERTY which tries to get the bdaddr from devicetree. But this only works on devicetree platforms. On UEFI based platforms there is a special Broadcom UEFI variable which when present contains the devices bdaddr, just like how there is another UEFI variable which contains wifi nvram contents including the wifi MAC address. Add support for getting the bdaddr from this Broadcom UEFI variable, so that Bluetooth will work OOTB for users on devices where this UEFI variable is present. This fixes Bluetooth not working on for example Asus T100HA 2-in-1s. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Qiqi Zhang authored
As shown in the schematic diagram below.There may be a critical scenario in the current code. If the device does not receive an pure ack sent by the host due to insufficient receive buffer or other reasons and triggers a retransmission, the host will always be in an 'out-of-order' state.The state machine will get stuck. host device SEQ3,ACK4 ---------> <--------- SEQ4,ACK4 pure ACK ---------> (not received) (out-of-order) <--------- SEQ4,ACK4(retransmission) ........ (out-of-order) <--------- SEQ4,ACK4(retransmission) According to the description in the core specification: "whenever a reliable packet is received, an acknowledgment shall be generated." So set H5_TX_ACK_REQ bit to trigger retransmission of pure ack packet when "out-of-order" occurs. Signed-off-by: Qiqi Zhang <eddy.zhang@rock-chips.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Luiz Augusto von Dentz authored
This enables 2M and Coded PHY by default if they are marked as supported in the LE features bits. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Iulia Tanasescu authored
Split bt_iso_qos into dedicated unicast and broadcast structures and add additional broadcast parameters. Fixes: eca0ae4a ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Abhishek Pandit-Subedi authored
Intercept debug exception events from the controller and put them into a devcoredump using hci devcoredump APIs. The debug exception contains data in a TLV format and it will be parsed in userspace. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Manish Mandlik <mmandlik@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Chethan Tumkur Narayan <chethan.tumkur.narayan@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Manish Mandlik authored
This patch implements the btusb driver side .coredump() callback to trigger a devcoredump via sysfs. Signed-off-by: Manish Mandlik <mmandlik@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Manish Mandlik authored
Add devcoredump support for vhci that creates forcce_devcoredump debugfs entry. This is used for mgmt-tester tests. Signed-off-by: Manish Mandlik <mmandlik@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Abhishek Pandit-Subedi authored
Add devcoredump APIs to hci core so that drivers only have to provide the dump skbs instead of managing the synchronization and timeouts. The devcoredump APIs should be used in the following manner: - hci_devcoredump_init is called to allocate the dump. - hci_devcoredump_append is called to append any skbs with dump data OR hci_devcoredump_append_pattern is called to insert a pattern. - hci_devcoredump_complete is called when all dump packets have been sent OR hci_devcoredump_abort is called to indicate an error and cancel an ongoing dump collection. The high level APIs just prepare some skbs with the appropriate data and queue it for the dump to process. Packets part of the crashdump can be intercepted in the driver in interrupt context and forwarded directly to the devcoredump APIs. Internally, there are 5 states for the dump: idle, active, complete, abort and timeout. A devcoredump will only be in active state after it has been initialized. Once active, it accepts data to be appended, patterns to be inserted (i.e. memset) and a completion event or an abort event to generate a devcoredump. The timeout is initialized at the same time the dump is initialized (defaulting to 10s) and will be cleared either when the timeout occurs or the dump is complete or aborted. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Manish Mandlik <mmandlik@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Chethan T N authored
Basically all Intel controllers support both Central/Peripheral LE states. This patch enables the LE States quirk by default on all Solar and Magnertor Intel controllers. Signed-off-by: Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Steev Klimaszewski authored
Add regulators, GPIOs and changes required to power on/off wcn6855. Add support for firmware download for wcn6855 which is in the linux-firmware repository as hpbtfw21.tlv and hpnv21.bin. Based on the assumption that this is similar to the wcn6750 Tested-on: BTFW.HSP.2.1.0-00538-VER_PATCHZ-1 Signed-off-by: Steev Klimaszewski <steev@kali.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Tested-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Steev Klimaszewski authored
Add bindings for the QTI WCN6855 chipset. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Max Chou authored
The btrtl_set_quirks() has accessed btrtl_dev->ic_info->lmp_subver since b8e482d02513. However, if installing a Realtek Bluetooth controller without the driver supported, it will hit the NULL point accessed. Add a check for NULL to avoid the Kernel Oops. Signed-off-by: Max Chou <max.chou@realtek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Larry Finger authored
This device is part of a Realtek RTW8852BE chip. The device table is as follows: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3571 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 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: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Larry Finger authored
This device is part of a Realtek RTW8852BE chip. The device table entry is as follows: T: Bus=03 Lev=01 Prnt=01 Port=12 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=887b Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 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: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Arnd Bergmann authored
The driver needs both CRC32 and CRC8 to link correctly: ld: drivers/bluetooth/btnxpuart.o: in function `nxp_serdev_probe': drivers/bluetooth/btnxpuart.c:1214: undefined reference to `crc8_populate_msb' ld: drivers/bluetooth/btnxpuart.o: in function `nxp_send_ack': drivers/bluetooth/btnxpuart.c:559: undefined reference to `crc8' ld: drivers/bluetooth/btnxpuart.c:559: undefined reference to `crc8' Fixes: 3e662aa4453a ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Neeraj Sanjay Kale authored
This adds a driver based on serdev driver for the NXP BT serial protocol based on running H:4, which can enable the built-in Bluetooth device inside an NXP BT chip. This driver has Power Save feature that will put the chip into sleep state whenever there is no activity for 2000ms, and will be woken up when any activity is to be initiated over UART. This driver enables the power save feature by default by sending the vendor specific commands to the chip during setup. During setup, the driver checks if a FW is already running on the chip by waiting for the bootloader signature, and downloads device specific FW file into the chip over UART if bootloader signature is received.. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Neeraj Sanjay Kale authored
Add binding document for NXP bluetooth chipsets attached over UART. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Neeraj Sanjay Kale authored
Adds serdev_device_break_ctl() and an implementation for ttyport. This function simply calls the break_ctl in tty layer, which can assert a break signal over UART-TX line, if the tty and the underlying platform and UART peripheral supports this operation. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Neeraj Sanjay Kale authored
This replaces all instances of ENOTSUPP with EOPNOTSUPP since ENOTSUPP is not a standard error code. This will help maintain consistency in error codes when new serdev API's are added. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-