FROMLIST: Bluetooth: qca: add QCC2072 support#1279
Conversation
…ersion matches Since USB can disconnect at any time, if it disconnects during the BT firmware download, the BT controller firmware version may still be updated even without completing the download. When USB reconnects, the BT host detects the same version as in the firmware file, which prevents the firmware from being downloaded again. Therefore, remove the equality check to ensure that after USB reconnection, the BT host can still download the firmware. Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/
Since the timer uses jiffies as its unit rather than ms, the timeout value must be converted from ms to jiffies when configuring the timer. Otherwise, the intended 8s timeout is incorrectly set to approximately 33s. To improve readability, embed msecs_to_jiffies() directly in the macro definitions and drop the _MS suffix from macros that now yield jiffies values: MEMDUMP_TIMEOUT, FW_DOWNLOAD_TIMEOUT, IBS_DISABLE_SSR_TIMEOUT, CMD_TRANS_TIMEOUT, and IBS_BTSOC_TX_IDLE_TIMEOUT. IBS_WAKE_RETRANS_TIMEOUT_MS and IBS_HOST_TX_IDLE_TIMEOUT_MS are intentionally left unchanged. Their values are stored in the struct fields wake_retrans and tx_idle_delay, which hold ms values at runtime and can be modified via debugfs. The msecs_to_jiffies() conversion happens at each call site against the field value, so it cannot be embedded in the macro. Depends on commit c347ca1 ("Bluetooth: hci_qca: Fix missing wakeup during SSR memdump handling"). Cc: stable@vger.kernel.org Fixes: d841502 ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
…VM loading When bt_en is pulled high by hardware, the host does not re-download the firmware after SSR. The controller loads the rampatch and NVM internally. On WCN7850 chip, the rampatch is ~264 KB and the NVM is ~9.4 KB. The loading process takes approximately 70 ms. The previous 50 ms delay is too short, causing the controller to not respond to the reset command sent by the host, which leads to BT initialization failure: Bluetooth: hci0: QCA memdump Done, received 458752, total 458752 Bluetooth: hci0: mem_dump_status: 2 Bluetooth: hci0: Opcode 0x0c03 failed: -110 Increase the delay to 100 ms, which was confirmed as a safe value by the controller, to ensure the controller has finished loading the firmware before the host sends commands. Steps to reproduce: 1. Trigger SSR and wait for SSR to complete: hcitool cmd 0x3f 0c 26 2. Run "bluetoothctl power on" and observe that BT fails to start. Fixes: fce1a92 ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw") Cc: stable@vger.kernel.org Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260525065156.2213123-1-shuai.zhang@oss.qualcomm.com Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
QCC2072 is a BT/WiFi combo SoC that uses different firmware
filenames and requires no external voltage regulators, so add
it as a new SoC type.
The chip supports the wideband speech and valid LE states
capabilities. Its firmware is named using the "orn" prefix and
follows the standard rom-version-based scheme:
- qca/ornbtfw<ver>.tlv
- qca/ornnv<ver>.bin
These firmware files are already present in the linux-firmware
repository.
Signed-off-by: Rahul Samana <rahul.samana@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260529175822.3366535-1-yepuri.siddu@oss.qualcomm.com/
QCC2072 requires the NVM and calibration data to be delivered to the controller bundled together in an outer TLV of type 4. After loading the NVM file, load the calibration file (qca/ornbcscal<ver>.bin) and combine both into a single buffer with the outer TLV header before passing it to qca_tlv_check_data(). The outer TLV header encodes the combined payload length in the high 24 bits and type 4 in the low 8 bits of the type_len field. If the calibration file is unavailable, fall back to downloading the NVM alone. Signed-off-by: Rahul Samana <rahul.samana@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260529180431.3373856-1-yepuri.siddu@oss.qualcomm.com/
PR #1279 — validate-patchPR: #1279
Final Summary
|
PR #1279 — checker-log-analyzerPR: #1279
Detailed report: Full report
|
cab8484 to
e43ffb6
Compare
|
Will raise these changes in tech/all/workaround. These changes will be maintained until M.2 Power Sequencing is upstreamed. |
This series adds QCC2072 support to hci_qca.
QCC2072 uses orn-prefixed firmware filenames and does not require external voltage regulators, so the first patch adds it as a new SoC type and enables the appropriate capabilities.
It also requires NVM and calibration data to be sent together in an outer TLV of type 4. The second patch loads qca/ornbcscal.bin in addition to the NVM file, combines both blobs into the required TLV container, and passes the result to qca_tlv_check_data(). If the calibration file is missing, the existing NVM-only path is retained as fallback.
The required firmware files are already available in linux-firmware.