Re: [PATCH v2 2/6] Bluetooth: qca: add QCC2072 support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditional prepending of a Type 4 TLV header leads to nested Type 4 headers if the NVM file already has one, silently breaking NVM parsing.
--

--- Patch [2]: [PATCH v2 2/6] Bluetooth: qca: add QCC2072 support ---
commit 6bcb3bc10729db904fa228c76a2bef00327ec17a
Author: Vivek Sahu <vivek.sahu@oss.qualcomm.com>

Bluetooth: qca: add QCC2072 support

Adds support for the QCC2072 Bluetooth controller, which uses ORN firmware
naming. It introduces a helper to combine BCS calibration TLV data with NVM
downloads and registers the compatible hardware.

> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index 10c496eaea2c1..34bc0684cf1b6 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
[ ... ]
> @@ -569,6 +569,54 @@ static int qca_inject_cmd_complete_event(struct hci_dev *hdev)
>  	return hci_recv_frame(hdev, skb);
>  }
>  
> +static void qca_combine_nvm_calib(struct hci_dev *hdev, u8 **data,
> +				  int *size, char *calib_name,
> +				  size_t max_size)
> +{
[ ... ]
> +	outer_hdr = (struct tlv_type_hdr *)combined_data;
> +	/* high 24 bits = payload length, low 8 bits = type */
> +	outer_hdr->type_len = cpu_to_le32((inner_len << 8) | 4);
> +	memcpy(combined_data + sizeof(*outer_hdr), *data, *size);
> +	memcpy(combined_data + sizeof(*outer_hdr) + *size,
> +	       calib_fw->data, calib_fw->size);
> +	release_firmware(calib_fw);

[Severity: High]
If the original NVM file already contains an enclosing Type 4 header, will
this unconditionally prepend a second Type 4 header?

Looking at qca_tlv_check_data(), it expects to peel off at most one Type 4
header before strictly requiring a Type 2 header:

    if (type == 4) {
        ...
        tlv++;
        type_len = le32_to_cpu(tlv->type_len);
        length = type_len >> 8;
        type = type_len & 0xff;
    }
    
    ...
    
    if (type != 2)
        break;

If there are nested Type 4 headers, the second header will cause type to
equal 4 again, which triggers the early break out of the parser.

Could this cause the driver to silently skip parsing the NVM data, leaving
critical settings like the MAC address, deep sleep masks, and UART baud rates
unpatched? If the baud rate is not updated to match the host, this might
cause all HCI communication to drop after the controller applies the NVM.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727-rb3-industrial-bt-uart-v2-0-2d100f30e202@oss.qualcomm.com?part=2