[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AM9PR04MB8603920AC4B83DB6D7CEAB71E7BC9@AM9PR04MB8603.eurprd04.prod.outlook.com>
Date: Thu, 16 Mar 2023 07:06:41 +0000
From: Neeraj sanjay kale <neeraj.sanjaykale@....com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"marcel@...tmann.org" <marcel@...tmann.org>,
"johan.hedberg@...il.com" <johan.hedberg@...il.com>,
"luiz.dentz@...il.com" <luiz.dentz@...il.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"jirislaby@...nel.org" <jirislaby@...nel.org>,
"alok.a.tiwari@...cle.com" <alok.a.tiwari@...cle.com>,
"hdanton@...a.com" <hdanton@...a.com>,
"ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
"leon@...nel.org" <leon@...nel.org>,
"simon.horman@...igine.com" <simon.horman@...igine.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
Amitkumar Karwar <amitkumar.karwar@....com>,
Rohit Fule <rohit.fule@....com>,
Sherry Sun <sherry.sun@....com>
Subject: RE: [EXT] Re: [PATCH v12 4/4] Bluetooth: NXP: Add protocol support
for NXP Bluetooth chipsets
Hi Paul,
Thank you for reviewing the patch.
> >
> > This driver has Power Save feature that will put the chip into sleep
> > state whenever there is no activity for 2000ms, and will be woken up
> > when any
>
> Interesting. Are two seconds recommended in some specification?
This 2 seconds is a default timeout value in this design, which is enough to decide if the communication between chip is going to be idle, in order to prevent more frequent sleep-wakeup cycles, and to not keep the power consumption high for too long in idle scenarios.
We however intend to make this timeout configurable (default will still be 2000ms) in future patches, probably by coming up with a new hci vendor command.
> > +
> > +static u8 *nxp_get_fw_name_from_chipid(struct hci_dev *hdev, u16
> > +chipid)
>
> Any reason to limit the length of `chipid` instead of using `unsigned int`?
This 'chipid' is nothing but the one received from chip's bootloader signature, which is of 16 bits.
Please check 'struct v3_start_ind' definition and 'nxp_recv_chip_ver_v3()'.
To maintain consistency I have kept the datatype as u16. Please let me know if you think otherwise.
Thanks,
Neeraj
Powered by blists - more mailing lists