[PATCH v4 0/2] Cover letter QCC2072 enablement

[PATCH v4 0/2] Cover letter QCC2072 enablement

[Vivek Sahu]

The history of the patch set as follows.
v1: First commit to add support of QCC2072 chipset
v2: resolving review comments to sort the chipset in the switch case
    and other files whenever possible. "qca_btsoc_type" enum in 
    drivers/bluetooth/btqca.h contains all the soc type which need to be 
    enabled for BT enablement on the target device. There are few places 
    where logic of framing packets transferring between SoC  and Host 
    depends on the which generation of the chip it is, refer api 
    "qca_read_soc_version". So It is not sorted in btqca.h file.
v3: indentation fix and "qcom,wcn3950-bt" is deleted by mistake.
v4: made a separate change for sorting chip name. added new schema
    for qcc2072 dt-bindings

Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>

Vivek Sahu (2):
  dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema
  Bluetooth: qca: add QCC2072 support

 .../net/bluetooth/qcom,qcc2072-bt.yaml        | 48 +++++++++++++++++++
 drivers/bluetooth/btqca.c                     |  8 ++++
 drivers/bluetooth/btqca.h                     |  1 +
 drivers/bluetooth/hci_qca.c                   | 18 +++++++
 4 files changed, 75 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml

-- 
2.34.1

[PATCH v4 1/2] dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema

[Vivek Sahu]

One big Qualcomm Bluetooth schema is hardly manageable: it lists all
possible properties (19 supplies).  Split qcom,qcc2072-bt to separate
bindings, so device schema will be easier to read/maintain and list only
relevant properties.

Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
---
 .../net/bluetooth/qcom,qcc2072-bt.yaml        | 48 +++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml

diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
new file mode 100644
index 000000000000..48936bb8e91c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/bluetooth/qcom,qcc2072-bt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCC2072 Bluetooth
+
+maintainers:
+  - Balakrishna Godavarthi <quic_bgodavar@quicinc.com>
+  - Rocky Liao <quic_rjliao@quicinc.com>
+  - Vivek Sahu <vivek.sahu@oss.qualcomm.com>
+
+description:
+  Qualcomm QCC2072 is a UART-based Bluetooth controller.
+
+properties:
+  compatible:
+    enum:
+      - qcom,qcc2072-bt
+
+  enable-gpios:
+    maxItems: 1
+    description: GPIO specifier for the chip interrupt.
+
+required:
+  - compatible
+  - enable-gpios
+
+allOf:
+  - $ref: bluetooth-controller.yaml#
+  - $ref: qcom,bluetooth-common.yaml
+  - $ref: /schemas/serial/serial-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    serial {
+        bluetooth {
+            compatible = "qcom,qcc2072-bt";
+            enable-gpios = <&tlmm 19 IRQ_TYPE_EDGE_FALLING>;
+            max-speed = <3200000>;
+        };
+    };
-- 
2.34.1

Re: [PATCH v4 1/2] dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 11:17:30AM +0530, Vivek Sahu wrote:
> One big Qualcomm Bluetooth schema is hardly manageable: it lists all
> possible properties (19 supplies).  Split qcom,qcc2072-bt to separate
> bindings, so device schema will be easier to read/maintain and list only
> relevant properties.

How is it relevant to the commit? You are not splitting anything. You
are adding bindings for the new hardware.

> 
> Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
> ---
>  .../net/bluetooth/qcom,qcc2072-bt.yaml        | 48 +++++++++++++++++++
>  1 file changed, 48 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
> 

-- 
With best wishes
Dmitry

Re: [PATCH v4 1/2] dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema

[Vivek Sahu]

On 2/17/2026 12:04 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 17, 2026 at 11:17:30AM +0530, Vivek Sahu wrote:
>> One big Qualcomm Bluetooth schema is hardly manageable: it lists all
>> possible properties (19 supplies).  Split qcom,qcc2072-bt to separate
>> bindings, so device schema will be easier to read/maintain and list only
>> relevant properties.
> 
> How is it relevant to the commit? You are not splitting anything. You
> are adding bindings for the new hardware.
This commit is added on top of split schema where for each chip set 
there is separate binding yaml file instead of following up traditional
method of updating qualcomm-bluetooth.yaml
> 
>>
>> Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
>> ---
>>   .../net/bluetooth/qcom,qcc2072-bt.yaml        | 48 +++++++++++++++++++
>>   1 file changed, 48 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
>>
> 

Re: [PATCH v4 1/2] dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 01:11:05PM +0530, Vivek Sahu wrote:
> 
> 
> On 2/17/2026 12:04 PM, Dmitry Baryshkov wrote:
> > On Tue, Feb 17, 2026 at 11:17:30AM +0530, Vivek Sahu wrote:
> > > One big Qualcomm Bluetooth schema is hardly manageable: it lists all
> > > possible properties (19 supplies).  Split qcom,qcc2072-bt to separate
> > > bindings, so device schema will be easier to read/maintain and list only
> > > relevant properties.
> > 
> > How is it relevant to the commit? You are not splitting anything. You
> > are adding bindings for the new hardware.
> This commit is added on top of split schema where for each chip set there is
> separate binding yaml file instead of following up traditional
> method of updating qualcomm-bluetooth.yaml

What does your commit message describe? What are you splitting?

> > 
> > > 
> > > Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
> > > ---
> > >   .../net/bluetooth/qcom,qcc2072-bt.yaml        | 48 +++++++++++++++++++
> > >   1 file changed, 48 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
> > > 
> > 
> 

-- 
With best wishes
Dmitry

Re: [PATCH v4 1/2] dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema

[Vivek Sahu]

On 2/17/2026 1:43 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 17, 2026 at 01:11:05PM +0530, Vivek Sahu wrote:
>>
>>
>> On 2/17/2026 12:04 PM, Dmitry Baryshkov wrote:
>>> On Tue, Feb 17, 2026 at 11:17:30AM +0530, Vivek Sahu wrote:
>>>> One big Qualcomm Bluetooth schema is hardly manageable: it lists all
>>>> possible properties (19 supplies).  Split qcom,qcc2072-bt to separate
>>>> bindings, so device schema will be easier to read/maintain and list only
>>>> relevant properties.
>>>
>>> How is it relevant to the commit? You are not splitting anything. You
>>> are adding bindings for the new hardware.
>> This commit is added on top of split schema where for each chip set there is
>> separate binding yaml file instead of following up traditional
>> method of updating qualcomm-bluetooth.yaml
> 
> What does your commit message describe? What are you splitting?
> 
The commit is about adding a binding for new chipset QCC2072 which is a 
WiFi/BT connectivity chip. It requires different firmware, so document 
it as a new compatible string.
Seems like slit to separate schema is confusing sentence for this 
commit. I'll correct it in new patch set.

>>>
>>>>
>>>> Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
>>>> ---
>>>>    .../net/bluetooth/qcom,qcc2072-bt.yaml        | 48 +++++++++++++++++++
>>>>    1 file changed, 48 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
>>>>
>>>
>>
> 

Re: [PATCH v4 1/2] dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema

[Krzysztof Kozlowski]

On 17/02/2026 09:19, Vivek Sahu wrote:
> 
> 
> On 2/17/2026 1:43 PM, Dmitry Baryshkov wrote:
>> On Tue, Feb 17, 2026 at 01:11:05PM +0530, Vivek Sahu wrote:
>>>
>>>
>>> On 2/17/2026 12:04 PM, Dmitry Baryshkov wrote:
>>>> On Tue, Feb 17, 2026 at 11:17:30AM +0530, Vivek Sahu wrote:
>>>>> One big Qualcomm Bluetooth schema is hardly manageable: it lists all
>>>>> possible properties (19 supplies).  Split qcom,qcc2072-bt to separate
>>>>> bindings, so device schema will be easier to read/maintain and list only
>>>>> relevant properties.
>>>>
>>>> How is it relevant to the commit? You are not splitting anything. You
>>>> are adding bindings for the new hardware.
>>> This commit is added on top of split schema where for each chip set there is
>>> separate binding yaml file instead of following up traditional
>>> method of updating qualcomm-bluetooth.yaml
>>
>> What does your commit message describe? What are you splitting?
>>
> The commit is about adding a binding for new chipset QCC2072 which is a 
> WiFi/BT connectivity chip. It requires different firmware, so document 
> it as a new compatible string.
> Seems like slit to separate schema is confusing sentence for this 
> commit. I'll correct it in new patch set.

No, it is not confusing. It is just false, a lie. You are not doing what
your commit message said.

Best regards,
Krzysztof

Re: [PATCH v4 1/2] dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema

[Krzysztof Kozlowski]

On Tue, Feb 17, 2026 at 11:17:30AM +0530, Vivek Sahu wrote:
> One big Qualcomm Bluetooth schema is hardly manageable: it lists all
> possible properties (19 supplies).  Split qcom,qcc2072-bt to separate
> bindings, so device schema will be easier to read/maintain and list only
> relevant properties.

Huh? I do not see any split here and I do not see how this commit msg
relates anyhow to what the patch is doing.
> 
> Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
> ---
>  .../net/bluetooth/qcom,qcc2072-bt.yaml        | 48 +++++++++++++++++++


Best regards,
Krzysztof

Re: [PATCH v4 1/2] dt-bindings: bluetooth: qcom,qcc2072-bt: Split to separate schema

[Vivek Sahu]

On 2/17/2026 1:21 PM, Krzysztof Kozlowski wrote:
> On Tue, Feb 17, 2026 at 11:17:30AM +0530, Vivek Sahu wrote:
>> One big Qualcomm Bluetooth schema is hardly manageable: it lists all
>> possible properties (19 supplies).  Split qcom,qcc2072-bt to separate
>> bindings, so device schema will be easier to read/maintain and list only
>> relevant properties.
> 
> Huh? I do not see any split here and I do not see how this commit msg
> relates anyhow to what the patch is doing.

Let me re-write the commit message with more clear information about the 
patch.

>>
>> Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
>> ---
>>   .../net/bluetooth/qcom,qcc2072-bt.yaml        | 48 +++++++++++++++++++
> 
> 
> Best regards,
> Krzysztof
> 

[PATCH v4 2/2] Bluetooth: qca: add QCC2072 support

[Vivek Sahu]

QCC2072 is a family of WiFi/BT connectivity chip.
It requires different firmware files and has different
configurations , so add it as a separate SoC type.

The firmware for these chips has been recently added to the
linux-firmware repository and will be a part of the upcoming
release.

Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
---
 drivers/bluetooth/btqca.c   |  8 ++++++++
 drivers/bluetooth/btqca.h   |  1 +
 drivers/bluetooth/hci_qca.c | 18 ++++++++++++++++++
 3 files changed, 27 insertions(+)

diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index 9f7e13fcb20e..65c8d2978956 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -807,6 +807,10 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
 			snprintf(config.fwname, sizeof(config.fwname),
 				 "qca/htbtfw%02x.tlv", rom_ver);
 			break;
+		case QCA_QCC2072:
+			snprintf(config.fwname, sizeof(config.fwname),
+				 "qca/ornbtfw%02x.tlv", rom_ver);
+			break;
 		case QCA_WCN3950:
 			snprintf(config.fwname, sizeof(config.fwname),
 				 "qca/cmbtfw%02x.tlv", rom_ver);
@@ -900,6 +904,10 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
 			snprintf(config.fwname, sizeof(config.fwname),
 				 "qca/htnv%02x.bin", rom_ver);
 			break;
+		case QCA_QCC2072:
+			snprintf(config.fwname, sizeof(config.fwname),
+				 "qca/ornnv%02x.bin", rom_ver);
+			break;
 		case QCA_WCN3950:
 			if (le32_to_cpu(ver.soc_id) == QCA_WCN3950_SOC_ID_T)
 				variant = "t";
diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
index 8f3c1b1c77b3..a175ac31e7b2 100644
--- a/drivers/bluetooth/btqca.h
+++ b/drivers/bluetooth/btqca.h
@@ -158,6 +158,7 @@ enum qca_btsoc_type {
 	QCA_WCN6750,
 	QCA_WCN6855,
 	QCA_WCN7850,
+	QCA_QCC2072,
 };
 
 #if IS_ENABLED(CONFIG_BT_QCA)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 8e035b7c6f3e..7786ced0bbbb 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -625,6 +625,7 @@ static int qca_open(struct hci_uart *hu)
 		qcadev = serdev_device_get_drvdata(hu->serdev);
 
 		switch (qcadev->btsoc_type) {
+		case QCA_QCC2072:
 		case QCA_WCN3950:
 		case QCA_WCN3988:
 		case QCA_WCN3990:
@@ -1500,6 +1501,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 		 * changing the baudrate of chip and host.
 		 */
 		switch (soc_type) {
+		case QCA_QCC2072:
 		case QCA_WCN3950:
 		case QCA_WCN3988:
 		case QCA_WCN3990:
@@ -1516,6 +1518,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 		}
 
 		switch (soc_type) {
+		case QCA_QCC2072:
 		case QCA_WCN3990:
 			reinit_completion(&qca->drop_ev_comp);
 			set_bit(QCA_DROP_VENDOR_EVENT, &qca->flags);
@@ -1535,6 +1538,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 
 error:
 		switch (soc_type) {
+		case QCA_QCC2072:
 		case QCA_WCN3950:
 		case QCA_WCN3988:
 		case QCA_WCN3990:
@@ -1551,6 +1555,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 		}
 
 		switch (soc_type) {
+		case QCA_QCC2072:
 		case QCA_WCN3990:
 			/* Wait for the controller to send the vendor event
 			 * for the baudrate change command.
@@ -1935,6 +1940,10 @@ static int qca_setup(struct hci_uart *hu)
 		soc_name = "qca2066";
 		break;
 
+	case QCA_QCC2072:
+		soc_name = "qcc2072";
+		break;
+
 	case QCA_WCN3950:
 	case QCA_WCN3988:
 	case QCA_WCN3990:
@@ -1970,6 +1979,7 @@ static int qca_setup(struct hci_uart *hu)
 	clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
 
 	switch (soc_type) {
+	case QCA_QCC2072:
 	case QCA_WCN3950:
 	case QCA_WCN3988:
 	case QCA_WCN3990:
@@ -2003,6 +2013,7 @@ static int qca_setup(struct hci_uart *hu)
 	}
 
 	switch (soc_type) {
+	case QCA_QCC2072:
 	case QCA_WCN3950:
 	case QCA_WCN3988:
 	case QCA_WCN3990:
@@ -2108,6 +2119,12 @@ static const struct qca_device_data qca_soc_data_qca6390 __maybe_unused = {
 	.num_vregs = 0,
 };
 
+static const struct qca_device_data qca_soc_data_qcc2072 __maybe_unused = {
+	.soc_type = QCA_QCC2072,
+	.num_vregs = 0,
+	.capabilities = QCA_CAP_WIDEBAND_SPEECH | QCA_CAP_VALID_LE_STATES,
+};
+
 static const struct qca_device_data qca_soc_data_wcn3950 __maybe_unused = {
 	.soc_type = QCA_WCN3950,
 	.vregs = (struct qca_vreg []) {
@@ -2758,6 +2775,7 @@ static const struct of_device_id qca_bluetooth_of_match[] = {
 	{ .compatible = "qcom,qca6174-bt" },
 	{ .compatible = "qcom,qca6390-bt", .data = &qca_soc_data_qca6390},
 	{ .compatible = "qcom,qca9377-bt" },
+	{ .compatible = "qcom,qcc2072-bt", .data = &qca_soc_data_qcc2072},
 	{ .compatible = "qcom,wcn3950-bt", .data = &qca_soc_data_wcn3950},
 	{ .compatible = "qcom,wcn3988-bt", .data = &qca_soc_data_wcn3988},
 	{ .compatible = "qcom,wcn3990-bt", .data = &qca_soc_data_wcn3990},
-- 
2.34.1

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

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 11:17:31AM +0530, Vivek Sahu wrote:
> QCC2072 is a family of WiFi/BT connectivity chip.
> It requires different firmware files and has different
> configurations , so add it as a separate SoC type.
> 
> The firmware for these chips has been recently added to the
> linux-firmware repository and will be a part of the upcoming
> release.
> 
> Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
> ---
>  drivers/bluetooth/btqca.c   |  8 ++++++++
>  drivers/bluetooth/btqca.h   |  1 +
>  drivers/bluetooth/hci_qca.c | 18 ++++++++++++++++++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index 9f7e13fcb20e..65c8d2978956 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -807,6 +807,10 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
>  			snprintf(config.fwname, sizeof(config.fwname),
>  				 "qca/htbtfw%02x.tlv", rom_ver);
>  			break;
> +		case QCA_QCC2072:
> +			snprintf(config.fwname, sizeof(config.fwname),
> +				 "qca/ornbtfw%02x.tlv", rom_ver);
> +			break;
>  		case QCA_WCN3950:
>  			snprintf(config.fwname, sizeof(config.fwname),
>  				 "qca/cmbtfw%02x.tlv", rom_ver);
> @@ -900,6 +904,10 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
>  			snprintf(config.fwname, sizeof(config.fwname),
>  				 "qca/htnv%02x.bin", rom_ver);
>  			break;
> +		case QCA_QCC2072:
> +			snprintf(config.fwname, sizeof(config.fwname),
> +				 "qca/ornnv%02x.bin", rom_ver);
> +			break;
>  		case QCA_WCN3950:
>  			if (le32_to_cpu(ver.soc_id) == QCA_WCN3950_SOC_ID_T)
>  				variant = "t";
> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
> index 8f3c1b1c77b3..a175ac31e7b2 100644
> --- a/drivers/bluetooth/btqca.h
> +++ b/drivers/bluetooth/btqca.h
> @@ -158,6 +158,7 @@ enum qca_btsoc_type {
>  	QCA_WCN6750,
>  	QCA_WCN6855,
>  	QCA_WCN7850,
> +	QCA_QCC2072,

Why not keep it sorted?

>  };
>  
>  #if IS_ENABLED(CONFIG_BT_QCA)
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 8e035b7c6f3e..7786ced0bbbb 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -625,6 +625,7 @@ static int qca_open(struct hci_uart *hu)
>  		qcadev = serdev_device_get_drvdata(hu->serdev);
>  
>  		switch (qcadev->btsoc_type) {
> +		case QCA_QCC2072:
>  		case QCA_WCN3950:
>  		case QCA_WCN3988:
>  		case QCA_WCN3990:
> @@ -1500,6 +1501,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>  		 * changing the baudrate of chip and host.
>  		 */
>  		switch (soc_type) {
> +		case QCA_QCC2072:
>  		case QCA_WCN3950:
>  		case QCA_WCN3988:
>  		case QCA_WCN3990:
> @@ -1516,6 +1518,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>  		}
>  
>  		switch (soc_type) {
> +		case QCA_QCC2072:
>  		case QCA_WCN3990:
>  			reinit_completion(&qca->drop_ev_comp);
>  			set_bit(QCA_DROP_VENDOR_EVENT, &qca->flags);
> @@ -1535,6 +1538,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>  
>  error:
>  		switch (soc_type) {
> +		case QCA_QCC2072:
>  		case QCA_WCN3950:
>  		case QCA_WCN3988:
>  		case QCA_WCN3990:
> @@ -1551,6 +1555,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>  		}
>  
>  		switch (soc_type) {
> +		case QCA_QCC2072:
>  		case QCA_WCN3990:
>  			/* Wait for the controller to send the vendor event
>  			 * for the baudrate change command.
> @@ -1935,6 +1940,10 @@ static int qca_setup(struct hci_uart *hu)
>  		soc_name = "qca2066";
>  		break;
>  
> +	case QCA_QCC2072:
> +		soc_name = "qcc2072";
> +		break;
> +
>  	case QCA_WCN3950:
>  	case QCA_WCN3988:
>  	case QCA_WCN3990:
> @@ -1970,6 +1979,7 @@ static int qca_setup(struct hci_uart *hu)
>  	clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
>  
>  	switch (soc_type) {
> +	case QCA_QCC2072:
>  	case QCA_WCN3950:
>  	case QCA_WCN3988:
>  	case QCA_WCN3990:
> @@ -2003,6 +2013,7 @@ static int qca_setup(struct hci_uart *hu)
>  	}
>  
>  	switch (soc_type) {
> +	case QCA_QCC2072:
>  	case QCA_WCN3950:
>  	case QCA_WCN3988:
>  	case QCA_WCN3990:
> @@ -2108,6 +2119,12 @@ static const struct qca_device_data qca_soc_data_qca6390 __maybe_unused = {
>  	.num_vregs = 0,
>  };
>  
> +static const struct qca_device_data qca_soc_data_qcc2072 __maybe_unused = {
> +	.soc_type = QCA_QCC2072,
> +	.num_vregs = 0,
> +	.capabilities = QCA_CAP_WIDEBAND_SPEECH | QCA_CAP_VALID_LE_STATES,

No regulators? How is it powered on?

> +};
> +
>  static const struct qca_device_data qca_soc_data_wcn3950 __maybe_unused = {
>  	.soc_type = QCA_WCN3950,
>  	.vregs = (struct qca_vreg []) {
> @@ -2758,6 +2775,7 @@ static const struct of_device_id qca_bluetooth_of_match[] = {
>  	{ .compatible = "qcom,qca6174-bt" },
>  	{ .compatible = "qcom,qca6390-bt", .data = &qca_soc_data_qca6390},
>  	{ .compatible = "qcom,qca9377-bt" },
> +	{ .compatible = "qcom,qcc2072-bt", .data = &qca_soc_data_qcc2072},
>  	{ .compatible = "qcom,wcn3950-bt", .data = &qca_soc_data_wcn3950},
>  	{ .compatible = "qcom,wcn3988-bt", .data = &qca_soc_data_wcn3988},
>  	{ .compatible = "qcom,wcn3990-bt", .data = &qca_soc_data_wcn3990},
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

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

[Vivek Sahu]

On 2/17/2026 12:06 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 17, 2026 at 11:17:31AM +0530, Vivek Sahu wrote:
>> QCC2072 is a family of WiFi/BT connectivity chip.
>> It requires different firmware files and has different
>> configurations , so add it as a separate SoC type.
>>
>> The firmware for these chips has been recently added to the
>> linux-firmware repository and will be a part of the upcoming
>> release.
>>
>> Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com>
>> ---
>>   drivers/bluetooth/btqca.c   |  8 ++++++++
>>   drivers/bluetooth/btqca.h   |  1 +
>>   drivers/bluetooth/hci_qca.c | 18 ++++++++++++++++++
>>   3 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
>> index 9f7e13fcb20e..65c8d2978956 100644
>> --- a/drivers/bluetooth/btqca.c
>> +++ b/drivers/bluetooth/btqca.c
>> @@ -807,6 +807,10 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
>>   			snprintf(config.fwname, sizeof(config.fwname),
>>   				 "qca/htbtfw%02x.tlv", rom_ver);
>>   			break;
>> +		case QCA_QCC2072:
>> +			snprintf(config.fwname, sizeof(config.fwname),
>> +				 "qca/ornbtfw%02x.tlv", rom_ver);
>> +			break;
>>   		case QCA_WCN3950:
>>   			snprintf(config.fwname, sizeof(config.fwname),
>>   				 "qca/cmbtfw%02x.tlv", rom_ver);
>> @@ -900,6 +904,10 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
>>   			snprintf(config.fwname, sizeof(config.fwname),
>>   				 "qca/htnv%02x.bin", rom_ver);
>>   			break;
>> +		case QCA_QCC2072:
>> +			snprintf(config.fwname, sizeof(config.fwname),
>> +				 "qca/ornnv%02x.bin", rom_ver);
>> +			break;
>>   		case QCA_WCN3950:
>>   			if (le32_to_cpu(ver.soc_id) == QCA_WCN3950_SOC_ID_T)
>>   				variant = "t";
>> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
>> index 8f3c1b1c77b3..a175ac31e7b2 100644
>> --- a/drivers/bluetooth/btqca.h
>> +++ b/drivers/bluetooth/btqca.h
>> @@ -158,6 +158,7 @@ enum qca_btsoc_type {
>>   	QCA_WCN6750,
>>   	QCA_WCN6855,
>>   	QCA_WCN7850,
>> +	QCA_QCC2072,
> 
> Why not keep it sorted?
> 
As mentioned in the cover letter "qca_btsoc_type" enum in 
drivers/bluetooth/btqca.h contains all the soc type which need to be 
enabled for BT enablement on the target device. There are few places 
where logic of framing packets transferring between SoC  and Host 
depends on the which generation of the chip it is, refer api 
"qca_read_soc_version". So It is not sorted in btqca.h file.

>>   };
>>   
>>   #if IS_ENABLED(CONFIG_BT_QCA)
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index 8e035b7c6f3e..7786ced0bbbb 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -625,6 +625,7 @@ static int qca_open(struct hci_uart *hu)
>>   		qcadev = serdev_device_get_drvdata(hu->serdev);
>>   
>>   		switch (qcadev->btsoc_type) {
>> +		case QCA_QCC2072:
>>   		case QCA_WCN3950:
>>   		case QCA_WCN3988:
>>   		case QCA_WCN3990:
>> @@ -1500,6 +1501,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>>   		 * changing the baudrate of chip and host.
>>   		 */
>>   		switch (soc_type) {
>> +		case QCA_QCC2072:
>>   		case QCA_WCN3950:
>>   		case QCA_WCN3988:
>>   		case QCA_WCN3990:
>> @@ -1516,6 +1518,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>>   		}
>>   
>>   		switch (soc_type) {
>> +		case QCA_QCC2072:
>>   		case QCA_WCN3990:
>>   			reinit_completion(&qca->drop_ev_comp);
>>   			set_bit(QCA_DROP_VENDOR_EVENT, &qca->flags);
>> @@ -1535,6 +1538,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>>   
>>   error:
>>   		switch (soc_type) {
>> +		case QCA_QCC2072:
>>   		case QCA_WCN3950:
>>   		case QCA_WCN3988:
>>   		case QCA_WCN3990:
>> @@ -1551,6 +1555,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
>>   		}
>>   
>>   		switch (soc_type) {
>> +		case QCA_QCC2072:
>>   		case QCA_WCN3990:
>>   			/* Wait for the controller to send the vendor event
>>   			 * for the baudrate change command.
>> @@ -1935,6 +1940,10 @@ static int qca_setup(struct hci_uart *hu)
>>   		soc_name = "qca2066";
>>   		break;
>>   
>> +	case QCA_QCC2072:
>> +		soc_name = "qcc2072";
>> +		break;
>> +
>>   	case QCA_WCN3950:
>>   	case QCA_WCN3988:
>>   	case QCA_WCN3990:
>> @@ -1970,6 +1979,7 @@ static int qca_setup(struct hci_uart *hu)
>>   	clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
>>   
>>   	switch (soc_type) {
>> +	case QCA_QCC2072:
>>   	case QCA_WCN3950:
>>   	case QCA_WCN3988:
>>   	case QCA_WCN3990:
>> @@ -2003,6 +2013,7 @@ static int qca_setup(struct hci_uart *hu)
>>   	}
>>   
>>   	switch (soc_type) {
>> +	case QCA_QCC2072:
>>   	case QCA_WCN3950:
>>   	case QCA_WCN3988:
>>   	case QCA_WCN3990:
>> @@ -2108,6 +2119,12 @@ static const struct qca_device_data qca_soc_data_qca6390 __maybe_unused = {
>>   	.num_vregs = 0,
>>   };
>>   
>> +static const struct qca_device_data qca_soc_data_qcc2072 __maybe_unused = {
>> +	.soc_type = QCA_QCC2072,
>> +	.num_vregs = 0,
>> +	.capabilities = QCA_CAP_WIDEBAND_SPEECH | QCA_CAP_VALID_LE_STATES,
> 
> No regulators? How is it powered on?
> 
Host to controller communication is over M.2 UART, so no regulators are 
required to power on chip.

>> +};
>> +
>>   static const struct qca_device_data qca_soc_data_wcn3950 __maybe_unused = {
>>   	.soc_type = QCA_WCN3950,
>>   	.vregs = (struct qca_vreg []) {
>> @@ -2758,6 +2775,7 @@ static const struct of_device_id qca_bluetooth_of_match[] = {
>>   	{ .compatible = "qcom,qca6174-bt" },
>>   	{ .compatible = "qcom,qca6390-bt", .data = &qca_soc_data_qca6390},
>>   	{ .compatible = "qcom,qca9377-bt" },
>> +	{ .compatible = "qcom,qcc2072-bt", .data = &qca_soc_data_qcc2072},
>>   	{ .compatible = "qcom,wcn3950-bt", .data = &qca_soc_data_wcn3950},
>>   	{ .compatible = "qcom,wcn3988-bt", .data = &qca_soc_data_wcn3988},
>>   	{ .compatible = "qcom,wcn3990-bt", .data = &qca_soc_data_wcn3990},
>> -- 
>> 2.34.1
>>
> 

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

[Krzysztof Kozlowski]

On Tue, Feb 17, 2026 at 01:17:29PM +0530, Vivek Sahu wrote:
> > > +		case QCA_QCC2072:
> > > +			snprintf(config.fwname, sizeof(config.fwname),
> > > +				 "qca/ornnv%02x.bin", rom_ver);
> > > +			break;
> > >   		case QCA_WCN3950:
> > >   			if (le32_to_cpu(ver.soc_id) == QCA_WCN3950_SOC_ID_T)
> > >   				variant = "t";
> > > diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
> > > index 8f3c1b1c77b3..a175ac31e7b2 100644
> > > --- a/drivers/bluetooth/btqca.h
> > > +++ b/drivers/bluetooth/btqca.h
> > > @@ -158,6 +158,7 @@ enum qca_btsoc_type {
> > >   	QCA_WCN6750,
> > >   	QCA_WCN6855,
> > >   	QCA_WCN7850,
> > > +	QCA_QCC2072,
> > 
> > Why not keep it sorted?
> > 
> As mentioned in the cover letter "qca_btsoc_type" enum in
> drivers/bluetooth/btqca.h contains all the soc type which need to be enabled
> for BT enablement on the target device. There are few places where logic of
> framing packets transferring between SoC  and Host depends on the which
> generation of the chip it is, refer api "qca_read_soc_version". So It is not
> sorted in btqca.h file.

Neither in previous patch comments nor here you respond to actual
comment. You just write something completely irrelevant.

I don't think any of this should be considered if you are not
responding to actual comments.


Best regards,
Krzysztof

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

[Vivek Sahu]

On 2/17/2026 1:23 PM, Krzysztof Kozlowski wrote:
> On Tue, Feb 17, 2026 at 01:17:29PM +0530, Vivek Sahu wrote:
>>>> +		case QCA_QCC2072:
>>>> +			snprintf(config.fwname, sizeof(config.fwname),
>>>> +				 "qca/ornnv%02x.bin", rom_ver);
>>>> +			break;
>>>>    		case QCA_WCN3950:
>>>>    			if (le32_to_cpu(ver.soc_id) == QCA_WCN3950_SOC_ID_T)
>>>>    				variant = "t";
>>>> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
>>>> index 8f3c1b1c77b3..a175ac31e7b2 100644
>>>> --- a/drivers/bluetooth/btqca.h
>>>> +++ b/drivers/bluetooth/btqca.h
>>>> @@ -158,6 +158,7 @@ enum qca_btsoc_type {
>>>>    	QCA_WCN6750,
>>>>    	QCA_WCN6855,
>>>>    	QCA_WCN7850,
>>>> +	QCA_QCC2072,
>>>
>>> Why not keep it sorted?
>>>
>> As mentioned in the cover letter "qca_btsoc_type" enum in
>> drivers/bluetooth/btqca.h contains all the soc type which need to be enabled
>> for BT enablement on the target device. There are few places where logic of
>> framing packets transferring between SoC  and Host depends on the which
>> generation of the chip it is, refer api "qca_read_soc_version". So It is not
>> sorted in btqca.h file.
> 
> Neither in previous patch comments nor here you respond to actual
> comment. You just write something completely irrelevant.
> 
> I don't think any of this should be considered if you are not
> responding to actual comments.
> 
> 
> Best regards,
> Krzysztof
> 
There is high impact on the existing design if i make this enum sorted. 
We are considering your comments regarding sorting for next commit not 
for this commit. Can we have approval for this commit if all other 
changes looks fine.

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

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 06:21:19PM +0530, Vivek Sahu wrote:
> 
> 
> On 2/17/2026 1:23 PM, Krzysztof Kozlowski wrote:
> > On Tue, Feb 17, 2026 at 01:17:29PM +0530, Vivek Sahu wrote:
> > > > > +		case QCA_QCC2072:
> > > > > +			snprintf(config.fwname, sizeof(config.fwname),
> > > > > +				 "qca/ornnv%02x.bin", rom_ver);
> > > > > +			break;
> > > > >    		case QCA_WCN3950:
> > > > >    			if (le32_to_cpu(ver.soc_id) == QCA_WCN3950_SOC_ID_T)
> > > > >    				variant = "t";
> > > > > diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
> > > > > index 8f3c1b1c77b3..a175ac31e7b2 100644
> > > > > --- a/drivers/bluetooth/btqca.h
> > > > > +++ b/drivers/bluetooth/btqca.h
> > > > > @@ -158,6 +158,7 @@ enum qca_btsoc_type {
> > > > >    	QCA_WCN6750,
> > > > >    	QCA_WCN6855,
> > > > >    	QCA_WCN7850,
> > > > > +	QCA_QCC2072,
> > > > 
> > > > Why not keep it sorted?
> > > > 
> > > As mentioned in the cover letter "qca_btsoc_type" enum in
> > > drivers/bluetooth/btqca.h contains all the soc type which need to be enabled
> > > for BT enablement on the target device. There are few places where logic of
> > > framing packets transferring between SoC  and Host depends on the which
> > > generation of the chip it is, refer api "qca_read_soc_version". So It is not
> > > sorted in btqca.h file.
> > 
> > Neither in previous patch comments nor here you respond to actual
> > comment. You just write something completely irrelevant.
> > 
> > I don't think any of this should be considered if you are not
> > responding to actual comments.
> > 
> > 
> > Best regards,
> > Krzysztof
> > 
> There is high impact on the existing design if i make this enum sorted. We

What kind of "high impact"?

> are considering your comments regarding sorting for next commit not for this
> commit. Can we have approval for this commit if all other changes looks
> fine.


No.

-- 
With best wishes
Dmitry

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

[Vivek Sahu]

On 2/17/2026 6:31 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 17, 2026 at 06:21:19PM +0530, Vivek Sahu wrote:
>>
>>
>> On 2/17/2026 1:23 PM, Krzysztof Kozlowski wrote:
>>> On Tue, Feb 17, 2026 at 01:17:29PM +0530, Vivek Sahu wrote:
>>>>>> +		case QCA_QCC2072:
>>>>>> +			snprintf(config.fwname, sizeof(config.fwname),
>>>>>> +				 "qca/ornnv%02x.bin", rom_ver);
>>>>>> +			break;
>>>>>>     		case QCA_WCN3950:
>>>>>>     			if (le32_to_cpu(ver.soc_id) == QCA_WCN3950_SOC_ID_T)
>>>>>>     				variant = "t";
>>>>>> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
>>>>>> index 8f3c1b1c77b3..a175ac31e7b2 100644
>>>>>> --- a/drivers/bluetooth/btqca.h
>>>>>> +++ b/drivers/bluetooth/btqca.h
>>>>>> @@ -158,6 +158,7 @@ enum qca_btsoc_type {
>>>>>>     	QCA_WCN6750,
>>>>>>     	QCA_WCN6855,
>>>>>>     	QCA_WCN7850,
>>>>>> +	QCA_QCC2072,
>>>>>
>>>>> Why not keep it sorted?
>>>>>
>>>> As mentioned in the cover letter "qca_btsoc_type" enum in
>>>> drivers/bluetooth/btqca.h contains all the soc type which need to be enabled
>>>> for BT enablement on the target device. There are few places where logic of
>>>> framing packets transferring between SoC  and Host depends on the which
>>>> generation of the chip it is, refer api "qca_read_soc_version". So It is not
>>>> sorted in btqca.h file.
>>>
>>> Neither in previous patch comments nor here you respond to actual
>>> comment. You just write something completely irrelevant.
>>>
>>> I don't think any of this should be considered if you are not
>>> responding to actual comments.
>>>
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> There is high impact on the existing design if i make this enum sorted. We
> 
> What kind of "high impact"?
> 
We identified a better way of handling it. I'll move it to the correct 
place.
>> are considering your comments regarding sorting for next commit not for this
>> commit. Can we have approval for this commit if all other changes looks
>> fine.
> 
> 
> No.
> 

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

[Vivek Sahu]

On 2/17/2026 1:23 PM, Krzysztof Kozlowski wrote:
> On Tue, Feb 17, 2026 at 01:17:29PM +0530, Vivek Sahu wrote:
>>>> +		case QCA_QCC2072:
>>>> +			snprintf(config.fwname, sizeof(config.fwname),
>>>> +				 "qca/ornnv%02x.bin", rom_ver);
>>>> +			break;
>>>>    		case QCA_WCN3950:
>>>>    			if (le32_to_cpu(ver.soc_id) == QCA_WCN3950_SOC_ID_T)
>>>>    				variant = "t";
>>>> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
>>>> index 8f3c1b1c77b3..a175ac31e7b2 100644
>>>> --- a/drivers/bluetooth/btqca.h
>>>> +++ b/drivers/bluetooth/btqca.h
>>>> @@ -158,6 +158,7 @@ enum qca_btsoc_type {
>>>>    	QCA_WCN6750,
>>>>    	QCA_WCN6855,
>>>>    	QCA_WCN7850,
>>>> +	QCA_QCC2072,
>>>
>>> Why not keep it sorted?
>>>
>> As mentioned in the cover letter "qca_btsoc_type" enum in
>> drivers/bluetooth/btqca.h contains all the soc type which need to be enabled
>> for BT enablement on the target device. There are few places where logic of
>> framing packets transferring between SoC  and Host depends on the which
>> generation of the chip it is, refer api "qca_read_soc_version". So It is not
>> sorted in btqca.h file.
> 
> Neither in previous patch comments nor here you respond to actual
> comment. You just write something completely irrelevant.
> 
> I don't think any of this should be considered if you are not
> responding to actual comments.
> 
> 
> Best regards,
> Krzysztof
> 
I've addressed it in patch set 5 of this commit