linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tjiang@codeaurora.org
To: Matthias Kaehlcke <mka@chromium.org>
Cc: marcel@holtmann.org, johan.hedberg@gmail.com,
	luiz.dentz@gmail.com, linux-kernel@vger.kernel.org,
	linux-bluetooth@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	bgodavar@codeaurora.org, c-hbandi@codeaurora.org,
	hemantg@codeaurora.org, rjliao@codeaurora.org,
	zijuhu@codeaurora.org
Subject: Re: [PATCH v2] Bluetooth: btusb: Add support for variant WCN6855 by using different nvm
Date: Thu, 21 Oct 2021 12:07:54 +0800	[thread overview]
Message-ID: <f42cb074563111526e0e5e419a540419@codeaurora.org> (raw)
In-Reply-To: <YXA1+tEiCoY8yPRR@google.com>

thanks Matthias for the new comments.

marcel :
   do you agree with my comments which response to Matthias , if is OK, I 
will make the final version for the next patch, thank you for the help.

regards.
tim

On 2021-10-20 23:30, Matthias Kaehlcke wrote:
> On Wed, Oct 20, 2021 at 12:00:52PM +0800, tjiang@codeaurora.org wrote:
>> Thanks Matthias for the comments. please see my comments inline .
>> 
>> BTW: marcel , do you agree with Matthias comments ? if fine , I will 
>> align
>> Matthias comments and make the final version.
>> 
>> regards.
>> tim
>> On 2021-10-20 03:29, Matthias Kaehlcke wrote:
>> > On Tue, Oct 12, 2021 at 03:55:56PM +0800, tjiang@codeaurora.org wrote:
>> > > the RF performance of wcn6855 soc chip from different foundries will
>> > > be
>> > > difference, so we should use different nvm to configure them.
>> > >
>> > > Signed-off-by: Tim Jiang <tjiang@codeaurora.org>
>> > > ---
>> > >  drivers/bluetooth/btusb.c | 56
>> > > +++++++++++++++++++++++++++++++++++------------
>> > >  1 file changed, 42 insertions(+), 14 deletions(-)
>> > >
>> > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> > > index 75c83768c257..f352ff351b61 100644
>> > > --- a/drivers/bluetooth/btusb.c
>> > > +++ b/drivers/bluetooth/btusb.c
>> > > @@ -3190,6 +3190,9 @@ static int btusb_set_bdaddr_wcn6855(struct
>> > > hci_dev
>> > > *hdev,
>> > >  #define QCA_DFU_TIMEOUT		3000
>> > >  #define QCA_FLAG_MULTI_NVM      0x80
>> > >
>> > > +#define WCN6855_2_0_RAM_VERSION_GF 0x400c1200
>> > > +#define WCN6855_2_1_RAM_VERSION_GF 0x400c1211
>> > > +
>> > >  struct qca_version {
>> > >  	__le32	rom_version;
>> > >  	__le32	patch_version;
>> > > @@ -3221,6 +3224,7 @@ static const struct qca_device_info
>> > > qca_devices_table[] = {
>> > >  	{ 0x00000302, 28, 4, 16 }, /* Rome 3.2 */
>> > >  	{ 0x00130100, 40, 4, 16 }, /* WCN6855 1.0 */
>> > >  	{ 0x00130200, 40, 4, 16 }, /* WCN6855 2.0 */
>> > > +	{ 0x00130201, 40, 4, 16 }, /* WCN6855 2.1 */
>> > >  };
>> > >
>> > >  static int btusb_qca_send_vendor_req(struct usb_device *udev, u8
>> > > request,
>> > > @@ -3375,6 +3379,43 @@ static int btusb_setup_qca_load_rampatch(struct
>> > > hci_dev *hdev,
>> > >  	return err;
>> > >  }
>> > >
>> > > +static void btusb_generate_qca_nvm_name(char *fwname,
>> > > +					size_t max_size,
>> > > +					struct qca_version *ver)
>> >
>> > => const struct qca_version *ver
[Tim] fine ,will modify it in next version.
>> >
>> > > +{
>> > > +	u32 rom_version = le32_to_cpu(ver->rom_version);
>> > > +	u16 flag = le16_to_cpu(ver->flag);
>> > > +
>> > > +	if (((flag >> 8) & 0xff) == QCA_FLAG_MULTI_NVM) {
>> > > +		u16 board_id = le16_to_cpu(ver->board_id);
>> > > +		u32 ram_version = le32_to_cpu(ver->ram_version);
>> > > +		const char *variant;
>> > > +
>> > > +		switch (ram_version) {
>> > > +		case WCN6855_2_0_RAM_VERSION_GF:
>> > > +		case WCN6855_2_1_RAM_VERSION_GF:
>> > > +			variant = "_gf";
>> > > +			break;
>> > > +		default:
>> > > +			variant = "";
>> >
>> > instead of the default branch you could assign a default to 'variant' at
>> > declaration time, but it's fine either way.
>> 
>> [Tim] this code style is recommend by marcel.
> 
> Both are ok, if Marcel prefers the default branch let's keep it that 
> way.
> 
>> >
>> > > +			break;
>> > > +		}
>> > > +
>> > > +		/* if boardid equal 0, use default nvm without suffix */
>> >
>> > delete the comment, it just states the obvious
[Tim] fine, will modify it in next version.
>> >
>> > > +		if (board_id == 0x0) {
>> >
>> > nit: is there really any value in using a hex number here instead of a
>> > plain decimal 0?
>> 
>> [Tim] this line is inherit from last change , if you think I should 
>> change
>> 0x0 to 0 , I am fine.
> 
> Since this patch touches/moves this code it seems a good opportunity to 
> clean
> things up a bit. It's also true that there are quite a few instances of 
> this
> and comparisons with '0x00' in other parts of the kernel, so I guess 
> it's
> also fine to leave it as is.
[Tim] I am OK to change from 0x0 to 0 in next version.

      reply	other threads:[~2021-10-21  4:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12  7:55 [PATCH v2] Bluetooth: btusb: Add support for variant WCN6855 by using different nvm tjiang
2021-10-18  7:49 ` tjiang
2021-10-19 19:29 ` Matthias Kaehlcke
2021-10-20  4:00   ` tjiang
2021-10-20 15:30     ` Matthias Kaehlcke
2021-10-21  4:07       ` tjiang [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=f42cb074563111526e0e5e419a540419@codeaurora.org \
    --to=tjiang@codeaurora.org \
    --cc=bgodavar@codeaurora.org \
    --cc=c-hbandi@codeaurora.org \
    --cc=hemantg@codeaurora.org \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=mka@chromium.org \
    --cc=rjliao@codeaurora.org \
    --cc=zijuhu@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).