[PATCH v1 1/2] dt-bindings: net: bluetooth: nxp: Add support for 4M baudrate

[PATCH v1 1/2] dt-bindings: net: bluetooth: nxp: Add support for 4M baudrate

[Neeraj Sanjay Kale]

Add support for 4000000 as secondary baudrate for downloading FW chunks and
after HCI initialization is done at fw-init-baudrate.

Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
---
 .../bindings/net/bluetooth/nxp,88w8987-bt.yaml         | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
index 3ab60c70286f..f1c7f900001c 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
@@ -34,6 +34,16 @@ properties:
       This property depends on the module vendor's
       configuration.
 
+  secondary-baudrate:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum:
+      - 3000000
+      - 4000000
+    default: 3000000
+    description:
+      Operational baudrate after HCI initialization is done.
+      Also used by FW download mechanism while downloading FW chunks.
+
   firmware-name:
     maxItems: 1
 
-- 
2.34.1

[PATCH v1 2/2] Bluetooth: btnxpuart: Add support for 4M baudrate

[Neeraj Sanjay Kale]

This adds support for 4000000 as secondary baudrate.
This value is selected from device tree property "secondary-baudrate"
which is then used to download FW chunks, and as operational baudrate after
HCI initialization is done.

Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
---
 drivers/bluetooth/btnxpuart.c | 29 ++++++++++++++++++++---------
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
index 6b13feed06df..e2cd568bdffe 100644
--- a/drivers/bluetooth/btnxpuart.c
+++ b/drivers/bluetooth/btnxpuart.c
@@ -73,7 +73,8 @@
 #define FW_AUTH_ENC		0xc0
 
 #define HCI_NXP_PRI_BAUDRATE	115200
-#define HCI_NXP_SEC_BAUDRATE	3000000
+#define HCI_NXP_SEC_BAUDRATE_3M	3000000
+#define HCI_NXP_SEC_BAUDRATE_4M	4000000
 
 #define MAX_FW_FILE_NAME_LEN    50
 
@@ -201,6 +202,7 @@ struct btnxpuart_dev {
 	u32 new_baudrate;
 	u32 current_baudrate;
 	u32 fw_init_baudrate;
+	u32 secondary_baudrate;
 	enum bootloader_param_change timeout_changed;
 	enum bootloader_param_change baudrate_changed;
 	bool helper_downloaded;
@@ -802,7 +804,10 @@ static bool nxp_fw_change_baudrate(struct hci_dev *hdev, u16 req_len)
 		nxpdev->fw_v3_offset_correction += req_len;
 	} else if (req_len == sizeof(uart_config)) {
 		uart_config.clkdiv.address = __cpu_to_le32(clkdivaddr);
-		uart_config.clkdiv.value = __cpu_to_le32(0x00c00000);
+		if (nxpdev->new_baudrate == HCI_NXP_SEC_BAUDRATE_4M)
+			uart_config.clkdiv.value = __cpu_to_le32(0x01000000);
+		else
+			uart_config.clkdiv.value = __cpu_to_le32(0x00c00000);
 		uart_config.uartdiv.address = __cpu_to_le32(uartdivaddr);
 		uart_config.uartdiv.value = __cpu_to_le32(1);
 		uart_config.mcr.address = __cpu_to_le32(uartmcraddr);
@@ -969,9 +974,9 @@ static int nxp_recv_fw_req_v1(struct hci_dev *hdev, struct sk_buff *skb)
 			if (nxp_fw_change_baudrate(hdev, len)) {
 				nxpdev->baudrate_changed = changed;
 				serdev_device_set_baudrate(nxpdev->serdev,
-							   HCI_NXP_SEC_BAUDRATE);
+							   HCI_NXP_SEC_BAUDRATE_3M);
 				serdev_device_set_flow_control(nxpdev->serdev, true);
-				nxpdev->current_baudrate = HCI_NXP_SEC_BAUDRATE;
+				nxpdev->current_baudrate = HCI_NXP_SEC_BAUDRATE_3M;
 			}
 			goto free_skb;
 		}
@@ -992,7 +997,7 @@ static int nxp_recv_fw_req_v1(struct hci_dev *hdev, struct sk_buff *skb)
 			nxpdev->helper_downloaded = true;
 			serdev_device_wait_until_sent(nxpdev->serdev, 0);
 			serdev_device_set_baudrate(nxpdev->serdev,
-						   HCI_NXP_SEC_BAUDRATE);
+						   HCI_NXP_SEC_BAUDRATE_3M);
 			serdev_device_set_flow_control(nxpdev->serdev, true);
 		} else {
 			clear_bit(BTNXPUART_FW_DOWNLOADING, &nxpdev->tx_state);
@@ -1216,12 +1221,13 @@ static int nxp_recv_fw_req_v3(struct hci_dev *hdev, struct sk_buff *skb)
 	}
 
 	if (nxpdev->baudrate_changed != changed) {
+		nxpdev->new_baudrate = nxpdev->secondary_baudrate;
 		if (nxp_fw_change_baudrate(hdev, len)) {
 			nxpdev->baudrate_changed = cmd_sent;
 			serdev_device_set_baudrate(nxpdev->serdev,
-						   HCI_NXP_SEC_BAUDRATE);
+						   nxpdev->secondary_baudrate);
 			serdev_device_set_flow_control(nxpdev->serdev, true);
-			nxpdev->current_baudrate = HCI_NXP_SEC_BAUDRATE;
+			nxpdev->current_baudrate = nxpdev->secondary_baudrate;
 		}
 		goto free_skb;
 	}
@@ -1447,8 +1453,8 @@ static int nxp_post_init(struct hci_dev *hdev)
 	struct btnxpuart_dev *nxpdev = hci_get_drvdata(hdev);
 	struct ps_data *psdata = &nxpdev->psdata;
 
-	if (nxpdev->current_baudrate != HCI_NXP_SEC_BAUDRATE) {
-		nxpdev->new_baudrate = HCI_NXP_SEC_BAUDRATE;
+	if (nxpdev->current_baudrate != nxpdev->secondary_baudrate) {
+		nxpdev->new_baudrate = nxpdev->secondary_baudrate;
 		nxp_set_baudrate_cmd(hdev, NULL);
 	}
 	if (psdata->cur_h2c_wakeupmode != psdata->h2c_wakeupmode)
@@ -1773,6 +1779,11 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
 	if (!nxpdev->fw_init_baudrate)
 		nxpdev->fw_init_baudrate = FW_INIT_BAUDRATE;
 
+	device_property_read_u32(&nxpdev->serdev->dev, "secondary-baudrate",
+				 &nxpdev->secondary_baudrate);
+	if (!nxpdev->secondary_baudrate)
+		nxpdev->secondary_baudrate = HCI_NXP_SEC_BAUDRATE_3M;
+
 	set_bit(BTNXPUART_FW_DOWNLOADING, &nxpdev->tx_state);
 
 	crc8_populate_msb(crc8_table, POLYNOMIAL8);
-- 
2.34.1

RE: [PATCH v1 2/2] Bluetooth: btnxpuart: Add support for 4M baudrate

[Sherry Sun]

> -----Original Message-----
> From: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
> Sent: Monday, June 16, 2025 11:09 PM
> To: marcel@holtmann.org; luiz.dentz@gmail.com; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org
> Cc: linux-bluetooth@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; Amitkumar Karwar
> <amitkumar.karwar@nxp.com>; Neeraj Sanjay Kale
> <neeraj.sanjaykale@nxp.com>; Sherry Sun <sherry.sun@nxp.com>; Manjeet
> Gupta <manjeet.gupta@nxp.com>
> Subject: [PATCH v1 2/2] Bluetooth: btnxpuart: Add support for 4M baudrate
> 
> This adds support for 4000000 as secondary baudrate.
> This value is selected from device tree property "secondary-baudrate"
> which is then used to download FW chunks, and as operational baudrate
> after HCI initialization is done.
> 
> Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
> ---
>  drivers/bluetooth/btnxpuart.c | 29 ++++++++++++++++++++---------
>  1 file changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> index 6b13feed06df..e2cd568bdffe 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c
> @@ -73,7 +73,8 @@
>  #define FW_AUTH_ENC		0xc0
> 
>  #define HCI_NXP_PRI_BAUDRATE	115200
> -#define HCI_NXP_SEC_BAUDRATE	3000000
> +#define HCI_NXP_SEC_BAUDRATE_3M	3000000
> +#define HCI_NXP_SEC_BAUDRATE_4M	4000000
> 
>  #define MAX_FW_FILE_NAME_LEN    50
> 
> @@ -201,6 +202,7 @@ struct btnxpuart_dev {
>  	u32 new_baudrate;
>  	u32 current_baudrate;
>  	u32 fw_init_baudrate;
> +	u32 secondary_baudrate;
>  	enum bootloader_param_change timeout_changed;
>  	enum bootloader_param_change baudrate_changed;
>  	bool helper_downloaded;
> @@ -802,7 +804,10 @@ static bool nxp_fw_change_baudrate(struct hci_dev
> *hdev, u16 req_len)
>  		nxpdev->fw_v3_offset_correction += req_len;
>  	} else if (req_len == sizeof(uart_config)) {
>  		uart_config.clkdiv.address = __cpu_to_le32(clkdivaddr);
> -		uart_config.clkdiv.value = __cpu_to_le32(0x00c00000);
> +		if (nxpdev->new_baudrate == HCI_NXP_SEC_BAUDRATE_4M)
> +			uart_config.clkdiv.value =
> __cpu_to_le32(0x01000000);
> +		else
> +			uart_config.clkdiv.value =
> __cpu_to_le32(0x00c00000);
>  		uart_config.uartdiv.address = __cpu_to_le32(uartdivaddr);
>  		uart_config.uartdiv.value = __cpu_to_le32(1);
>  		uart_config.mcr.address = __cpu_to_le32(uartmcraddr); @@
> -969,9 +974,9 @@ static int nxp_recv_fw_req_v1(struct hci_dev *hdev, struct
> sk_buff *skb)
>  			if (nxp_fw_change_baudrate(hdev, len)) {
>  				nxpdev->baudrate_changed = changed;
>  				serdev_device_set_baudrate(nxpdev->serdev,
> -
> HCI_NXP_SEC_BAUDRATE);
> +
> HCI_NXP_SEC_BAUDRATE_3M);
>  				serdev_device_set_flow_control(nxpdev-
> >serdev, true);
> -				nxpdev->current_baudrate =
> HCI_NXP_SEC_BAUDRATE;
> +				nxpdev->current_baudrate =
> HCI_NXP_SEC_BAUDRATE_3M;
>  			}
>  			goto free_skb;
>  		}
> @@ -992,7 +997,7 @@ static int nxp_recv_fw_req_v1(struct hci_dev *hdev,
> struct sk_buff *skb)
>  			nxpdev->helper_downloaded = true;
>  			serdev_device_wait_until_sent(nxpdev->serdev, 0);
>  			serdev_device_set_baudrate(nxpdev->serdev,
> -						   HCI_NXP_SEC_BAUDRATE);
> +
> HCI_NXP_SEC_BAUDRATE_3M);

Hi Neeraj,

Does this mean that some legacy BT chips using nxp_recv_fw_req_v1() don't support 4Mbps?
If so, please add comments in the commit message.

>  			serdev_device_set_flow_control(nxpdev->serdev,
> true);
>  		} else {
>  			clear_bit(BTNXPUART_FW_DOWNLOADING,
> &nxpdev->tx_state); @@ -1216,12 +1221,13 @@ static int
> nxp_recv_fw_req_v3(struct hci_dev *hdev, struct sk_buff *skb)
>  	}
> 
>  	if (nxpdev->baudrate_changed != changed) {
> +		nxpdev->new_baudrate = nxpdev->secondary_baudrate;
>  		if (nxp_fw_change_baudrate(hdev, len)) {
>  			nxpdev->baudrate_changed = cmd_sent;
>  			serdev_device_set_baudrate(nxpdev->serdev,
> -						   HCI_NXP_SEC_BAUDRATE);
> +						   nxpdev-
> >secondary_baudrate);
>  			serdev_device_set_flow_control(nxpdev->serdev,
> true);
> -			nxpdev->current_baudrate =
> HCI_NXP_SEC_BAUDRATE;
> +			nxpdev->current_baudrate = nxpdev-
> >secondary_baudrate;
>  		}
>  		goto free_skb;
>  	}
> @@ -1447,8 +1453,8 @@ static int nxp_post_init(struct hci_dev *hdev)
>  	struct btnxpuart_dev *nxpdev = hci_get_drvdata(hdev);
>  	struct ps_data *psdata = &nxpdev->psdata;
> 
> -	if (nxpdev->current_baudrate != HCI_NXP_SEC_BAUDRATE) {
> -		nxpdev->new_baudrate = HCI_NXP_SEC_BAUDRATE;
> +	if (nxpdev->current_baudrate != nxpdev->secondary_baudrate) {
> +		nxpdev->new_baudrate = nxpdev->secondary_baudrate;
>  		nxp_set_baudrate_cmd(hdev, NULL);
>  	}
>  	if (psdata->cur_h2c_wakeupmode != psdata->h2c_wakeupmode) @@
> -1773,6 +1779,11 @@ static int nxp_serdev_probe(struct serdev_device
> *serdev)
>  	if (!nxpdev->fw_init_baudrate)
>  		nxpdev->fw_init_baudrate = FW_INIT_BAUDRATE;
> 
> +	device_property_read_u32(&nxpdev->serdev->dev, "secondary-
> baudrate",
> +				 &nxpdev->secondary_baudrate);
> +	if (!nxpdev->secondary_baudrate)
> +		nxpdev->secondary_baudrate =
> HCI_NXP_SEC_BAUDRATE_3M;
> +

What if the user sets the wrong secondary_baudrate in dts (not 3M or 4M)?
Need to add the corresponding error handling here. Make sure the value is 3M or 4M, otherwise report an error log.

Best Regards
Sherry

>  	set_bit(BTNXPUART_FW_DOWNLOADING, &nxpdev->tx_state);
> 
>  	crc8_populate_msb(crc8_table, POLYNOMIAL8);
> --
> 2.34.1

Re: [PATCH v1 2/2] Bluetooth: btnxpuart: Add support for 4M baudrate

[Krzysztof Kozlowski]

On 17/06/2025 04:53, Sherry Sun wrote:
>> @@ -992,7 +997,7 @@ static int nxp_recv_fw_req_v1(struct hci_dev *hdev,
>> struct sk_buff *skb)
>>  			nxpdev->helper_downloaded = true;
>>  			serdev_device_wait_until_sent(nxpdev->serdev, 0);
>>  			serdev_device_set_baudrate(nxpdev->serdev,
>> -						   HCI_NXP_SEC_BAUDRATE);
>> +
>> HCI_NXP_SEC_BAUDRATE_3M);
> 
> Hi Neeraj,
> 
> Does this mean that some legacy BT chips using nxp_recv_fw_req_v1() don't support 4Mbps?
> If so, please add comments in the commit message.

If that's true this is implied by compatible and entire property should
be dropped.

Best regards,
Krzysztof

Re: [PATCH v1 2/2] Bluetooth: btnxpuart: Add support for 4M baudrate

[Neeraj Sanjay Kale]

Hi Sherry, Krzysztof,

Thank you for reviewing the patch.

I did not add 4M baudrate support in nxp_recv_fw_req_v1() as V1 bootloader are Legacy chipsets, and 4M baudrate was never tested or used by any customer so far. This feature is more actively used with newer V3 bootloaders. But in my testing w8987 (v1 bootloader) on iMX8M mini works fine at 4M baudrate. I can add it here.

> On 17/06/2025 04:53, Sherry Sun wrote:
> >> @@ -992,7 +997,7 @@ static int nxp_recv_fw_req_v1(struct hci_dev
> >> *hdev, struct sk_buff *skb)
> >>                      nxpdev->helper_downloaded = true;
> >>                      serdev_device_wait_until_sent(nxpdev->serdev, 0);
> >>                      serdev_device_set_baudrate(nxpdev->serdev,
> >> -                                               HCI_NXP_SEC_BAUDRATE);
> >> +
> >> HCI_NXP_SEC_BAUDRATE_3M);
> >
> > Hi Neeraj,
> >
> > Does this mean that some legacy BT chips using nxp_recv_fw_req_v1() don't
> support 4Mbps?
> > If so, please add comments in the commit message.
> 
> If that's true this is implied by compatible and entire property should be
> dropped.
 
As for the code snippet above, it comes into picture for w8997, which needs a helper.bin file to be downloaded before the actual FW file.
The helper.bin sets the chip's baudrate to 3M only, hence I have kept HCI_NXP_SEC_BAUDRATE_3M.

Thanks,
Neeraj

Re: [PATCH v1 1/2] dt-bindings: net: bluetooth: nxp: Add support for 4M baudrate

[Krzysztof Kozlowski]

On 16/06/2025 17:09, Neeraj Sanjay Kale wrote:
> Add support for 4000000 as secondary baudrate for downloading FW chunks and
> after HCI initialization is done at fw-init-baudrate.
> 
> Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
> ---
>  .../bindings/net/bluetooth/nxp,88w8987-bt.yaml         | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
> index 3ab60c70286f..f1c7f900001c 100644
> --- a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
> +++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
> @@ -34,6 +34,16 @@ properties:
>        This property depends on the module vendor's
>        configuration.
>  
> +  secondary-baudrate:
> +    $ref: /schemas/types.yaml#/definitions/uint32

baudrate is in some value, so use unit suffix from property-units and
drop the ref.

And then you will see that it could be actually an array, so why not
using existing properties? Otherwise you will add soon "tertiary" etc?
This does not scale.

Best regards,
Krzysztof

Re: [PATCH v1 1/2] dt-bindings: net: bluetooth: nxp: Add support for 4M baudrate

[Neeraj Sanjay Kale]

Hi Krzysztof,

Thank you for reviewing the patch.

> 
> On 16/06/2025 17:09, Neeraj Sanjay Kale wrote:
> > Add support for 4000000 as secondary baudrate for downloading FW
> > chunks and after HCI initialization is done at fw-init-baudrate.
> >
> > Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
> > ---
> >  .../bindings/net/bluetooth/nxp,88w8987-bt.yaml         | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
> > b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
> > index 3ab60c70286f..f1c7f900001c 100644
> > ---
> > a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml
> > +++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.y
> > +++ aml
> > @@ -34,6 +34,16 @@ properties:
> >        This property depends on the module vendor's
> >        configuration.
> >
> > +  secondary-baudrate:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> 
> baudrate is in some value, so use unit suffix from property-units and drop the
> ref.
In property-units.yaml, I can see "-bps" with ref type uint32.
I will change this property to "secondary-baudrate-bps" and drop ref in v2 patch.

> 
> And then you will see that it could be actually an array, so why not using
> existing properties? Otherwise you will add soon "tertiary" etc?
> This does not scale.
> 

There won't be a tertiary baudrate as far as I know. 
Also, if we remove the existing fw-init-baudrate property to combine fw-init-baudrate and secondary baudrate in an array, it would cause backward compatibility issues for existing customers.

Let me explain the objective here.
The NXP BT chip will power-on and bootloader will always configure it at 115200 baudrate, even for the planned future chipsets.
The driver will read chip signature and flags to select the chip specific FW file and set the chip baudrate to a higher/secondary baudrate for the actual FW download.

Once FW download is complete, FW will initialize and based on module vendor's OTP setting set the chip's UART baudrate to "fw-init-baudrate".
HCI initialization will happen at this fw-init-baudrate, and post-init, driver will set chip baudrate to higher/secondary baudrate for normal operation.

Currently, this higher/secondary baudrate is hardcoded to 3000000 in driver. But if BT chip and host processor are close-by, or mounted on the same PCB, UART communication at 4000000 is possible.

This can be achieved by adding the new device tree property "secondary-baudrate-bps = <4000000>".

Connections with FRC cables or fly-wires show command timeout errors at 4000000 baudrate.
Hence, we keep default secondary baudrate as 3000000.

Please let me know, based on above explanation if we should change the baudrate parameter to array in DT and Driver.

Thanks,
Neeraj

RE: [PATCH v1 1/2] dt-bindings: net: bluetooth: nxp: Add support for 4M baudrate

[Neeraj Sanjay Kale]

> Hi Krzysztof,
> 
> Thank you for reviewing the patch.
> 
> >
> > On 16/06/2025 17:09, Neeraj Sanjay Kale wrote:
> > > Add support for 4000000 as secondary baudrate for downloading FW
> > > chunks and after HCI initialization is done at fw-init-baudrate.
> > >
> > > Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
> > > ---
> > >  .../bindings/net/bluetooth/nxp,88w8987-bt.yaml         | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-
> bt.yam
> > > l
> > > b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-
> bt.yam
> > > l index 3ab60c70286f..f1c7f900001c 100644
> > > ---
> > > a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-
> bt.yam
> > > l
> > > +++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-
> bt
> > > +++ .y
> > > +++ aml
> > > @@ -34,6 +34,16 @@ properties:
> > >        This property depends on the module vendor's
> > >        configuration.
> > >
> > > +  secondary-baudrate:
> > > +    $ref: /schemas/types.yaml#/definitions/uint32
> >
> > baudrate is in some value, so use unit suffix from property-units and
> > drop the ref.
> In property-units.yaml, I can see "-bps" with ref type uint32.
> I will change this property to "secondary-baudrate-bps" and drop ref in v2
> patch.
> 
> >
> > And then you will see that it could be actually an array, so why not
> > using existing properties? Otherwise you will add soon "tertiary" etc?
> > This does not scale.
> >
> 
> There won't be a tertiary baudrate as far as I know.
> Also, if we remove the existing fw-init-baudrate property to combine fw-init-
> baudrate and secondary baudrate in an array, it would cause backward
> compatibility issues for existing customers.
> 
> Let me explain the objective here.
> The NXP BT chip will power-on and bootloader will always configure it at
> 115200 baudrate, even for the planned future chipsets.
> The driver will read chip signature and flags to select the chip specific FW file
> and set the chip baudrate to a higher/secondary baudrate for the actual FW
> download.
> 
> Once FW download is complete, FW will initialize and based on module
> vendor's OTP setting set the chip's UART baudrate to "fw-init-baudrate".
> HCI initialization will happen at this fw-init-baudrate, and post-init, driver will
> set chip baudrate to higher/secondary baudrate for normal operation.
> 
> Currently, this higher/secondary baudrate is hardcoded to 3000000 in driver.
> But if BT chip and host processor are close-by, or mounted on the same PCB,
> UART communication at 4000000 is possible.
> 
> This can be achieved by adding the new device tree property "secondary-
> baudrate-bps = <4000000>".
> 
> Connections with FRC cables or fly-wires show command timeout errors at
> 4000000 baudrate.
> Hence, we keep default secondary baudrate as 3000000.
> 
> Please let me know, based on above explanation if we should change the
> baudrate parameter to array in DT and Driver.
> 

Can the existing "max-speed" property be used in this context as an enum?
max-speed: true
  enum:
    - 3000000
    - 4000000

Thanks,
 Neeraj