[PATCH v2 0/2] Bluetooth: hci_bcm: Autobaud mode support

Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading.
Autobaud mode can also be required on some boards where the controller
device is using a non-standard baud rate when first powered on.

Only a limited subset of HCI commands are supported in autobaud mode.

These patches add a DT property, "brcm,uses-autobaud-mode", to control
autobaud mode selection.

Changes v1 -> v2:
- Modify description in binding document

Hakan Jansson (2):
  dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode
  Bluetooth: hci_bcm: Add support for FW loading in autobaud mode

 .../bindings/net/broadcom-bluetooth.yaml      |  9 ++++++
 drivers/bluetooth/btbcm.c                     | 31 ++++++++++++++-----
 drivers/bluetooth/btbcm.h                     |  8 ++---
 drivers/bluetooth/hci_bcm.c                   | 15 +++++++--
 4 files changed, 48 insertions(+), 15 deletions(-)


base-commit: 48b57999e38745b707abe233019786cc097df3c9
-- 
2.25.1

Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading.
Autobaud mode can also be required on some boards where the controller
device is using a non-standard baud rate when first powered on.

This patch adds a property, "brcm,uses-autobaud-mode", to enable autobaud
mode selection.

Signed-off-by: Hakan Jansson <redacted>
---
V1 -> V2: Modify property description

 .../devicetree/bindings/net/broadcom-bluetooth.yaml      | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
index 5aac094fd217..a29f059c21cc 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml

@@ -92,6 +92,15 @@ properties:
        pcm-sync-mode: slave, master
        pcm-clock-mode: slave, master
 
+  brcm,uses-autobaud-mode:
+    type: boolean
+    description: >
+      Setting this property will make the host (driver) assert the controller
+      chip's BT_UART_CTS_N prior to asserting BT_REG_ON. This will make the
+      controller start up in autobaud mode. The controller will then detect the
+      baud rate of the first incoming (HCI Reset) command from the host and
+      subsequently use that baud rate.
+
   interrupts:
     items:
       - description: Handle to the line HOST_WAKE used to wake

-- 
2.25.1

On 20/05/2022 17:07, Hakan Jansson wrote:

Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading.

Which devices support this? You probably need allOf:if:then.

Autobaud mode can also be required on some boards where the controller
device is using a non-standard baud rate when first powered on.

This patch adds a property, "brcm,uses-autobaud-mode", to enable autobaud
mode selection.

Don't use "This patch":
https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95

Based on description, I understand the host triggers using autobaud.
However here you word it as "uses", so it is independent of host, it
looks like property of a device. The commit msg describes it even
different - "require autobaud".

This leads to second issue - it looks like there is some hardware
property (requiring to use autobaud) which should be described by
bindings. But instead you describe desired operational feature.

+    type: boolean
+    description: >

No need for '>'.

+      Setting this property will make the host (driver) assert the controller
+      chip's BT_UART_CTS_N prior to asserting BT_REG_ON. This will make the
+      controller start up in autobaud mode. The controller will then detect the
+      baud rate of the first incoming (HCI Reset) command from the host and
+      subsequently use that baud rate.
+
   interrupts:
     items:
       - description: Handle to the line HOST_WAKE used to wake

Best regards,
Krzysztof

Hi Krzysztof,

Thanks for responding.

On 5/22/2022 10:14 AM, Krzysztof Kozlowski wrote:

quoted

Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading.

Which devices support this? You probably need allOf:if:then.

Most devices _support_ autobaud mode but I don't have a definitive list. 
The CYW5557x is the first device family to _require_ autobaud mode for 
FW loading as far as I know.

quoted

Autobaud mode can also be required on some boards where the controller
device is using a non-standard baud rate when first powered on.

This patch adds a property, "brcm,uses-autobaud-mode", to enable autobaud
mode selection.

Don't use "This patch":
https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95

Sorry, will change in next rev.

quoted

Signed-off-by: Hakan Jansson <redacted>
---
V1 -> V2: Modify property description

  .../devicetree/bindings/net/broadcom-bluetooth.yaml      | 9 +++++++++
  1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
index 5aac094fd217..a29f059c21cc 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml

@@ -92,6 +92,15 @@ properties:
         pcm-sync-mode: slave, master
         pcm-clock-mode: slave, master

+  brcm,uses-autobaud-mode:

Based on description, I understand the host triggers using autobaud.

Correct, the host triggers using autobaud.

However here you word it as "uses", so it is independent of host, it
looks like property of a device.

I've been thinking of it as a a property of a specific board HW, 
inherited either from a property of the device being used or from a 
property of the HW design (e.g. a PCB using an alternate crystal 
frequency yielding a non-standard baud rate).

  The commit msg describes it even
different - "require autobaud".

Yes, the commit message describes two separate reasons why autobaud mode 
would be required:

1. Requirement coming from Device: "Some devices (e.g. CYW5557x) require 
autobaud mode to enable FW loading."

2. Requirement coming from HW design: "Autobaud mode can also be 
required on some boards where the controller device is using a 
non-standard baud rate when first powered on."

This leads to second issue - it looks like there is some hardware
property (requiring to use autobaud) which should be described by
bindings. But instead you describe desired operational feature.

Sorry about that. I've really been struggling with what should go into 
the description. Any suggestions or hints would be much appreciated.

How about, changing the property name to "brcm,requires-autobaud-mode" 
and the description to:
"Set this property if autobaud mode is required. Autobaud mode is 
required if the device's baud rate in normal mode is not supported by 
the host or if the device requires autobaud mode startup before loading FW."

Would that be an appropriate name and description?

quoted

+    type: boolean
+    description: >

No need for '>'.

Ok, will remove in next rev.

quoted

+      Setting this property will make the host (driver) assert the controller
+      chip's BT_UART_CTS_N prior to asserting BT_REG_ON. This will make the
+      controller start up in autobaud mode. The controller will then detect the
+      baud rate of the first incoming (HCI Reset) command from the host and
+      subsequently use that baud rate.
+
    interrupts:
      items:
        - description: Handle to the line HOST_WAKE used to wake

Thanks,
Håkan

On 23/05/2022 11:21, Hakan Jansson wrote:

Hi Krzysztof,

Thanks for responding.

On 5/22/2022 10:14 AM, Krzysztof Kozlowski wrote:

quoted

quoted

Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading.

Which devices support this? You probably need allOf:if:then.

Most devices _support_ autobaud mode but I don't have a definitive list. 
The CYW5557x is the first device family to _require_ autobaud mode for 
FW loading as far as I know.

quoted

quoted

Autobaud mode can also be required on some boards where the controller
device is using a non-standard baud rate when first powered on.

This patch adds a property, "brcm,uses-autobaud-mode", to enable autobaud
mode selection.

Don't use "This patch":
https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95

Sorry, will change in next rev.

quoted

quoted

Signed-off-by: Hakan Jansson <redacted>
---
V1 -> V2: Modify property description

  .../devicetree/bindings/net/broadcom-bluetooth.yaml      | 9 +++++++++
  1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
index 5aac094fd217..a29f059c21cc 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
+++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml

@@ -92,6 +92,15 @@ properties:
         pcm-sync-mode: slave, master
         pcm-clock-mode: slave, master

+  brcm,uses-autobaud-mode:

Based on description, I understand the host triggers using autobaud.

Correct, the host triggers using autobaud.

quoted

However here you word it as "uses", so it is independent of host, it
looks like property of a device.

I've been thinking of it as a a property of a specific board HW, 
inherited either from a property of the device being used or from a 
property of the HW design (e.g. a PCB using an alternate crystal 
frequency yielding a non-standard baud rate).

quoted

  The commit msg describes it even
different - "require autobaud".

Yes, the commit message describes two separate reasons why autobaud mode 
would be required:

1. Requirement coming from Device: "Some devices (e.g. CYW5557x) require 
autobaud mode to enable FW loading."

2. Requirement coming from HW design: "Autobaud mode can also be 
required on some boards where the controller device is using a 
non-standard baud rate when first powered on."

quoted

This leads to second issue - it looks like there is some hardware
property (requiring to use autobaud) which should be described by
bindings. But instead you describe desired operational feature.

Sorry about that. I've really been struggling with what should go into 
the description. Any suggestions or hints would be much appreciated.

How about, changing the property name to "brcm,requires-autobaud-mode" 
and the description to:
"Set this property if autobaud mode is required. Autobaud mode is 
required if the device's baud rate in normal mode is not supported by 
the host or if the device requires autobaud mode startup before loading FW."

Would that be an appropriate name and description?

Yes, sounds good. I also have trouble to name it nicely.

Sorry for late reply.

Best regards,
Krzysztof

Some devices (e.g. CYW5557x) require autobaud mode to enable FW loading.
Autobaud mode can also be required on some boards where the controller
device is using a non-standard baud rate when first powered on.

Only a limited subset of HCI commands are supported in autobaud mode.

This patch looks for a DT property, "brcm,uses-autobaud-mode", to enable
autobaud mode selection. If the property is present, the device is started
in autobaud mode by keeping RTS asserted while powering on the device. The
patch also prevents the use of unsupported commands for devices started in
autobaud mode.

Signed-off-by: Hakan Jansson <redacted>
---
V1 -> V2: No changes, submitted as part of updated patch series

 drivers/bluetooth/btbcm.c   | 31 +++++++++++++++++++++++--------
 drivers/bluetooth/btbcm.h   |  8 ++++----
 drivers/bluetooth/hci_bcm.c | 15 ++++++++++++---
 3 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index 92a2b7e81757..0c0958030c0a 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c

@@ -403,6 +403,13 @@ static int btbcm_read_info(struct hci_dev *hdev)
 	bt_dev_info(hdev, "BCM: chip id %u", skb->data[1]);
 	kfree_skb(skb);
 
+	return 0;
+}
+
+static int btbcm_print_controller_features(struct hci_dev *hdev)
+{
+	struct sk_buff *skb;
+
 	/* Read Controller Features */
 	skb = btbcm_read_controller_features(hdev);
 	if (IS_ERR(skb))

@@ -513,7 +520,7 @@ static const char *btbcm_get_board_name(struct device *dev)
 #endif
 }
 
-int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done)
+int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode)
 {
 	u16 subver, rev, pid, vid;
 	struct sk_buff *skb;

@@ -550,9 +557,16 @@ int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done)
 		if (err)
 			return err;
 	}
-	err = btbcm_print_local_name(hdev);
-	if (err)
-		return err;
+
+	if (!use_autobaud_mode) {
+		err = btbcm_print_controller_features(hdev);
+		if (err)
+			return err;
+
+		err = btbcm_print_local_name(hdev);
+		if (err)
+			return err;
+	}
 
 	bcm_subver_table = (hdev->bus == HCI_USB) ? bcm_usb_subver_table :
 						    bcm_uart_subver_table;

@@ -635,13 +649,13 @@ int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done)
 }
 EXPORT_SYMBOL_GPL(btbcm_initialize);
 
-int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done)
+int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode)
 {
 	int err;
 
 	/* Re-initialize if necessary */
 	if (*fw_load_done) {
-		err = btbcm_initialize(hdev, fw_load_done);
+		err = btbcm_initialize(hdev, fw_load_done, use_autobaud_mode);
 		if (err)
 			return err;
 	}

@@ -657,15 +671,16 @@ EXPORT_SYMBOL_GPL(btbcm_finalize);
 int btbcm_setup_patchram(struct hci_dev *hdev)
 {
 	bool fw_load_done = false;
+	bool use_autobaud_mode = false;
 	int err;
 
 	/* Initialize */
-	err = btbcm_initialize(hdev, &fw_load_done);
+	err = btbcm_initialize(hdev, &fw_load_done, use_autobaud_mode);
 	if (err)
 		return err;
 
 	/* Re-initialize after loading Patch */
-	return btbcm_finalize(hdev, &fw_load_done);
+	return btbcm_finalize(hdev, &fw_load_done, use_autobaud_mode);
 }
 EXPORT_SYMBOL_GPL(btbcm_setup_patchram);
 

diff --git a/drivers/bluetooth/btbcm.h b/drivers/bluetooth/btbcm.h
index 8bf01565fdfc..b4cb24231a20 100644
--- a/drivers/bluetooth/btbcm.h
+++ b/drivers/bluetooth/btbcm.h

@@ -62,8 +62,8 @@ int btbcm_write_pcm_int_params(struct hci_dev *hdev,
 int btbcm_setup_patchram(struct hci_dev *hdev);
 int btbcm_setup_apple(struct hci_dev *hdev);
 
-int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done);
-int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done);
+int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode);
+int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode);
 
 #else
 

@@ -104,12 +104,12 @@ static inline int btbcm_setup_apple(struct hci_dev *hdev)
 	return 0;
 }
 
-static inline int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done)
+static inline int btbcm_initialize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode)
 {
 	return 0;
 }
 
-static inline int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done)
+static inline int btbcm_finalize(struct hci_dev *hdev, bool *fw_load_done, bool use_autobaud_mode)
 {
 	return 0;
 }

diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 785f445dd60d..0230cfcc8e3e 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c

@@ -99,6 +99,7 @@ struct bcm_device_data {
  * @no_early_set_baudrate: don't set_baudrate before setup()
  * @drive_rts_on_open: drive RTS signal on ->open() when platform requires it
  * @pcm_int_params: keep the initial PCM configuration
+ * @use_autobaud_mode: start Bluetooth device in autobaud mode
  */
 struct bcm_device {
 	/* Must be the first member, hci_serdev.c expects this. */

@@ -136,6 +137,7 @@ struct bcm_device {
 #endif
 	bool			no_early_set_baudrate;
 	bool			drive_rts_on_open;
+	bool			use_autobaud_mode;
 	u8			pcm_int_params[5];
 };
 

@@ -472,7 +474,9 @@ static int bcm_open(struct hci_uart *hu)
 
 out:
 	if (bcm->dev) {
-		if (bcm->dev->drive_rts_on_open)
+		if (bcm->dev->use_autobaud_mode)
+			hci_uart_set_flow_control(hu, false);	/* Assert BT_UART_CTS_N */
+		else if (bcm->dev->drive_rts_on_open)
 			hci_uart_set_flow_control(hu, true);
 
 		hu->init_speed = bcm->dev->init_speed;

@@ -564,6 +568,7 @@ static int bcm_setup(struct hci_uart *hu)
 {
 	struct bcm_data *bcm = hu->priv;
 	bool fw_load_done = false;
+	bool use_autobaud_mode = (bcm->dev ? bcm->dev->use_autobaud_mode : 0);
 	unsigned int speed;
 	int err;
 

@@ -572,7 +577,7 @@ static int bcm_setup(struct hci_uart *hu)
 	hu->hdev->set_diag = bcm_set_diag;
 	hu->hdev->set_bdaddr = btbcm_set_bdaddr;
 
-	err = btbcm_initialize(hu->hdev, &fw_load_done);
+	err = btbcm_initialize(hu->hdev, &fw_load_done, use_autobaud_mode);
 	if (err)
 		return err;
 

@@ -616,7 +621,7 @@ static int bcm_setup(struct hci_uart *hu)
 		btbcm_write_pcm_int_params(hu->hdev, &params);
 	}
 
-	err = btbcm_finalize(hu->hdev, &fw_load_done);
+	err = btbcm_finalize(hu->hdev, &fw_load_done, use_autobaud_mode);
 	if (err)
 		return err;
 

@@ -1197,6 +1202,10 @@ static int bcm_acpi_probe(struct bcm_device *dev)
 
 static int bcm_of_probe(struct bcm_device *bdev)
 {
+	bdev->use_autobaud_mode = device_property_read_bool(bdev->dev, "brcm,uses-autobaud-mode");
+	if (bdev->use_autobaud_mode)
+		bdev->no_early_set_baudrate = true;
+
 	device_property_read_u32(bdev->dev, "max-speed", &bdev->oper_speed);
 	device_property_read_u8_array(bdev->dev, "brcm,bt-pcm-int-params",
 				      bdev->pcm_int_params, 5);

-- 
2.25.1