From: Matthias Kaehlcke <mka@chromium.org>
To: Zijun Hu <zijuhu@codeaurora.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,
tjiang@codeaurora.org
Subject: Re: [PATCH v5] Bluetooth: btusb: Add support using different nvm for variant WCN6855 controller
Date: Tue, 24 Aug 2021 02:12:00 -0700 [thread overview]
Message-ID: <YSS34JcZcoZwWg5D@google.com> (raw)
In-Reply-To: <1629793683-28770-1-git-send-email-zijuhu@codeaurora.org>
On Tue, Aug 24, 2021 at 04:28:03PM +0800, Zijun Hu wrote:
> From: Tim Jiang <tjiang@codeaurora.org>
>
> we have variant wcn6855 soc chip from different foundries, so we should
> use different nvm file with suffix to distinguish them.
Similar question as on v4: why is it necessary to know where a chip was
manufactured? Is the hardware different? Should the FW behave differently
for some reason (e.g. regulatory differences)?
>
> Signed-off-by: Tim Jiang <tjiang@codeaurora.org>
> ---
> drivers/bluetooth/btusb.c | 57 +++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 45 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 60d2fce59a71..ad7734f8917c 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3141,6 +3141,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;
> @@ -3172,6 +3175,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,
> @@ -3326,27 +3330,56 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev,
> return err;
> }
>
> -static int btusb_setup_qca_load_nvm(struct hci_dev *hdev,
> - struct qca_version *ver,
> - const struct qca_device_info *info)
> +static void btusb_generate_qca_nvm_name(char **fwname,
> + int max_size,
> + struct qca_version *ver,
> + char *foundry)
> {
> - const struct firmware *fw;
> - char fwname[64];
> - int err;
> + char *separator;
> + u16 board_id;
> + u32 rom_version;
> +
> + separator = (foundry == NULL) ? "" : "_";
> + board_id = le16_to_cpu(ver->board_id);
> + rom_version = le32_to_cpu(ver->rom_version);
Make the above assignments in the declaration.
>
> if (((ver->flag >> 8) & 0xff) == QCA_FLAG_MULTI_NVM) {
> /* if boardid equal 0, use default nvm without surfix */
> if (le16_to_cpu(ver->board_id) == 0x0) {
> - snprintf(fwname, sizeof(fwname), "qca/nvm_usb_%08x.bin",
> - le32_to_cpu(ver->rom_version));
> + snprintf(fwname, sizeof(fwname), "qca/nvm_usb_%08x%s%s.bin",
> + rom_version,
> + separator,
> + foundry);
the last three parameters could be in a single line.
> } else {
> - snprintf(fwname, sizeof(fwname), "qca/nvm_usb_%08x_%04x.bin",
> - le32_to_cpu(ver->rom_version),
> - le16_to_cpu(ver->board_id));
> + snprintf(fwname, sizeof(fwname), "qca/nvm_usb_%08x%s%s%04x.bin",
> + rom_version,
> + separator,
> + foundry,
> + board_id);
the last four parameters could be in a single line.
Besides the minor comments above this looks good to me in terms of code, but
I'd like to have a better understanding of why the origin of the chip is
important.
next prev parent reply other threads:[~2021-08-24 9:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-24 8:28 [PATCH v5] Bluetooth: btusb: Add support using different nvm for variant WCN6855 controller Zijun Hu
2021-08-24 9:12 ` Matthias Kaehlcke [this message]
2021-08-26 17:55 ` Matthias Kaehlcke
2021-08-24 13:26 ` kernel test robot
2021-08-24 21:06 ` kernel test robot
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=YSS34JcZcoZwWg5D@google.com \
--to=mka@chromium.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=rjliao@codeaurora.org \
--cc=tjiang@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