archive mirror
 help / color / mirror / Atom feed
From: Hakan Jansson <>
To: Krzysztof Kozlowski <>
Cc: "David S. Miller" <>,
	Jakub Kicinski <>, Paolo Abeni <>,
	Rob Herring <>,
	"Krzysztof Kozlowski" <>,
	Linus Walleij <>,
	<>, <>,
	Marcel Holtmann <>,
	Johan Hedberg <>,
	"Luiz Augusto von Dentz" <>,
Subject: Re: [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode
Date: Mon, 23 May 2022 11:21:54 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Krzysztof,

Thanks for responding.

On 5/22/2022 10:14 AM, Krzysztof Kozlowski wrote:
>> 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.

>> 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":

Sorry, will change in next rev.

>> Signed-off-by: Hakan Jansson <>
>> ---
>> 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?

>> +    type: boolean
>> +    description: >
> No need for '>'.

Ok, will remove in next rev.

>> +      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


  reply	other threads:[~2022-05-23  9:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-20 15:07 [PATCH v2 0/2] Bluetooth: hci_bcm: Autobaud mode support Hakan Jansson
2022-05-20 15:07 ` [PATCH v2 1/2] dt-bindings: net: broadcom-bluetooth: Add property for autobaud mode Hakan Jansson
2022-05-22  8:14   ` Krzysztof Kozlowski
2022-05-23  9:21     ` Hakan Jansson [this message]
2022-05-30  7:44       ` Krzysztof Kozlowski
2022-05-20 15:07 ` [PATCH v2 2/2] Bluetooth: hci_bcm: Add support for FW loading in " Hakan Jansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).