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:
 <AS4PR04MB96929C2A48B10D8C7FAF282BE773A@AS4PR04MB9692.eurprd04.prod.outlook.com>
Date: Tue, 17 Jun 2025 09:56:02 +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.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