2021-10-22 05:38:54

by tjiang

[permalink] [raw]
Subject: [PATCH v3] Bluetooth: btusb: Add support for variant WCN6855 by using different nvm

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 <[email protected]>
---
drivers/bluetooth/btusb.c | 55
+++++++++++++++++++++++++++++++++++------------
1 file changed, 41 insertions(+), 14 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 87b71740fad8..a5fe57e7cd7e 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3195,6 +3195,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;
@@ -3226,6 +3229,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,
@@ -3380,6 +3384,42 @@ 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,
+ const struct qca_version *ver)
+{
+ 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 = NULL;
+
+ switch (ram_version) {
+ case WCN6855_2_0_RAM_VERSION_GF:
+ case WCN6855_2_1_RAM_VERSION_GF:
+ variant = "_gf";
+ break;
+ default:
+ variant = "";
+ break;
+ }
+
+ if (board_id == 0) {
+ snprintf(fwname, max_size, "qca/nvm_usb_%08x%s.bin",
+ rom_version, variant);
+ } else {
+ snprintf(fwname, max_size, "qca/nvm_usb_%08x%s_%04x.bin",
+ rom_version, variant, board_id);
+ }
+ } else {
+ snprintf(fwname, max_size, "qca/nvm_usb_%08x.bin",
+ rom_version);
+ }
+
+}
+
static int btusb_setup_qca_load_nvm(struct hci_dev *hdev,
struct qca_version *ver,
const struct qca_device_info *info)
@@ -3388,20 +3428,7 @@ static int btusb_setup_qca_load_nvm(struct
hci_dev *hdev,
char fwname[64];
int err;

- 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));
- } else {
- snprintf(fwname, sizeof(fwname), "qca/nvm_usb_%08x_%04x.bin",
- le32_to_cpu(ver->rom_version),
- le16_to_cpu(ver->board_id));
- }
- } else {
- snprintf(fwname, sizeof(fwname), "qca/nvm_usb_%08x.bin",
- le32_to_cpu(ver->rom_version));
- }
+ btusb_generate_qca_nvm_name(fwname, sizeof(fwname), ver);

err = request_firmware(&fw, fwname, &hdev->dev);
if (err) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project


2021-10-27 21:29:00

by Matthias Kaehlcke

[permalink] [raw]
Subject: Re: [PATCH v3] Bluetooth: btusb: Add support for variant WCN6855 by using different nvm

On Wed, Oct 27, 2021 at 02:12:07PM +0800, [email protected] wrote:
> Hi Matthias:
> the previous patch is submitted by zijun , as he is not working on this
> project, I take over his job, so can we assume abandon the previous patch,
> using my new patch ? thank you.
> regards.

Your patch is clearly based on zijun's one, it even has the same subject. A
change of authorship shouldn't result in resetting the version number, it's
still the same patch/series. You can always add a 'Co-developed-by:' tag to
indicate that someone else contributed to a patch, or use a 'From:' tag if
you only made minor changes on top of someone else's work.

Not sure how to proceed best with the version number, especially since there
are already 3 versions of the 'new' patch. Either option can create confusion,
I guess you can continue with the new scheme, it seems the patch is almost
ready to land anyway.