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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <AS4PR04MB9692790DAB0B376EA0F6B279E773A@AS4PR04MB9692.eurprd04.prod.outlook.com>
Date: Tue, 17 Jun 2025 09:52:43 +0000
From: Neeraj Sanjay Kale <neeraj.sanjaykale@....com>
To: Krzysztof Kozlowski <krzk@...nel.org>, "marcel@...tmann.org"
	<marcel@...tmann.org>, "luiz.dentz@...il.com" <luiz.dentz@...il.com>,
	"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>
CC: "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Amitkumar Karwar
	<amitkumar.karwar@....com>, Sherry Sun <sherry.sun@....com>, Manjeet Gupta
	<manjeet.gupta@....com>
Subject: Re: [PATCH v1 1/2] dt-bindings: net: bluetooth: nxp: Add support for
 4M baudrate

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@....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