summaryrefslogtreecommitdiff
path: root/drivers/bluetooth/btnxpuart.c
AgeCommit message (Collapse)AuthorFilesLines
2023-05-20Bluetooth: btnxpuart: Fix compiler warningsNeeraj Sanjay Kale1-3/+3
This fixes the follwing compiler warning reported by kernel test robot: drivers/bluetooth/btnxpuart.c:1332:34: warning: unused variable 'nxpuart_of_match_table' [-Wunused-const-variable] Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202305161345.eClvTYQ9-lkp@intel.com/ Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-04-24Bluetooth: btnxpuart: Enable flow control before checking boot signatureNeeraj Sanjay Kale1-7/+6
This enables flow control before checking for bootloader signature and deciding whether FW download is needed or not. In case of V1 bootloader chips w8987 and w8997, it is observed that if WLAN FW is downloaded first and power save is enabled in wlan core, bootloader signatures are not emitted by the BT core when the chip is put to sleep. As a result, the driver skips FW download and subsequent HCI commands get timeout errors in dmesg as shown below: [ 112.898867] Bluetooth: hci0: Opcode 0x c03 failed: -110 [ 114.914865] Bluetooth: hci0: Setting baudrate failed (-110) [ 116.930856] Bluetooth: hci0: Setting wake-up method failed (-110) By enabling the flow control, the host enables its RTS pin, and an interrupt in chip's UART peripheral causes the bootloader to wake up, enabling the bootloader signatures, which then helps in downloading the bluetooth FW file. This changes all instances of 0/1 for serdev_device_set_flow_control() to false/true. Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-04-24Bluetooth: btnxpuart: Fix sparse warningsLuiz Augusto von Dentz1-34/+51
This fixes the following sparse warnings: drivers/bluetooth/btnxpuart.c:681:23: sparse: sparse: restricted __le16 degrades to integer drivers/bluetooth/btnxpuart.c:690:82: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned short [usertype] req_len @@ got restricted __le16 [usertype] len @@ drivers/bluetooth/btnxpuart.c:690:82: sparse: expected unsigned short [usertype] req_len drivers/bluetooth/btnxpuart.c:690:82: sparse: got restricted __le16 [usertype] len drivers/bluetooth/btnxpuart.c:694:84: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned short [usertype] req_len @@ got restricted __le16 [usertype] len @@ drivers/bluetooth/btnxpuart.c:694:84: sparse: expected unsigned short [usertype] req_len drivers/bluetooth/btnxpuart.c:694:84: sparse: got restricted __le16 [usertype] len drivers/bluetooth/btnxpuart.c:708:23: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] requested_len @@ got restricted __le16 [usertype] len @@ drivers/bluetooth/btnxpuart.c:708:23: sparse: expected unsigned int [usertype] requested_len drivers/bluetooth/btnxpuart.c:708:23: sparse: got restricted __le16 [usertype] len drivers/bluetooth/btnxpuart.c:787:78: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned short [usertype] chipid @@ got restricted __le16 [usertype] chip_id @@ drivers/bluetooth/btnxpuart.c:787:78: sparse: expected unsigned short [usertype] chipid drivers/bluetooth/btnxpuart.c:787:78: sparse: got restricted __le16 [usertype] chip_id drivers/bluetooth/btnxpuart.c:810:74: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned short [usertype] req_len @@ got restricted __le16 [usertype] len @@ drivers/bluetooth/btnxpuart.c:810:74: sparse: expected unsigned short [usertype] req_len drivers/bluetooth/btnxpuart.c:810:74: sparse: got restricted __le16 [usertype] len drivers/bluetooth/btnxpuart.c:815:76: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned short [usertype] req_len @@ got restricted __le16 [usertype] len @@ drivers/bluetooth/btnxpuart.c:815:76: sparse: expected unsigned short [usertype] req_len drivers/bluetooth/btnxpuart.c:815:76: sparse: got restricted __le16 [usertype] len drivers/bluetooth/btnxpuart.c:834:16: sparse: sparse: restricted __le32 degrades to integer drivers/bluetooth/btnxpuart.c:843:55: sparse: sparse: restricted __le32 degrades to integer drivers/bluetooth/btnxpuart.c:844:36: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected unsigned long [usertype] @@ got restricted __le16 [usertype] len @@ drivers/bluetooth/btnxpuart.c:844:36: sparse: expected unsigned long [usertype] drivers/bluetooth/btnxpuart.c:844:36: sparse: got restricted __le16 [usertype] len Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202304160736.Tsa0zTBU-lkp@intel.com/ Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-04-24Bluetooth: btnxpuart: No need to check the received bootloader signatureNeeraj Sanjay Kale1-16/+3
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>
2023-04-24Bluetooth: btnxpuart: Disable Power Save feature on startupNeeraj Sanjay Kale1-1/+1
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>
2023-04-24Bluetooth: btnxpuart: Deasset UART break before closing serdev deviceNeeraj Sanjay Kale1-0/+1
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>
2023-04-24Bluetooth: btnxpuart: Add support to download helper FW file for w8997Neeraj Sanjay Kale1-8/+59
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>
2023-04-24Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsetsNeeraj Sanjay Kale1-0/+1297
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>