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

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

[tjiang]

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 | 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

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

[tjiang]

Hi Marcel:
   could you help review this patch as I resolved all comments from 
Matthias , thank you for the help.

regards.
tim


On 2021-10-22 13:35, 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 | 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) {

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

[Matthias Kaehlcke]

On Fri, Oct 22, 2021 at 01:35:38PM +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 | 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;

This assignement was introduced in v3, it isn't really useful since the
variable is always assigned to a value in the switch statement below.

btw, why did you reset the patch version numbers, earlier they went up
to v11? This is confusing, e.g. when someone mentions v3 of this patch,
are they referring to this version or to
https://patchwork.kernel.org/project/bluetooth/patch/1628758216-3201-1-git-send-email-zijuhu@codeaurora.org/?

> +
> +		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

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

[tjiang]

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.
tim

On 2021-10-27 00:24, Matthias Kaehlcke wrote:
> On Fri, Oct 22, 2021 at 01:35:38PM +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 | 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;
> 
> This assignement was introduced in v3, it isn't really useful since the
> variable is always assigned to a value in the switch statement below.
> 
> btw, why did you reset the patch version numbers, earlier they went up
> to v11? This is confusing, e.g. when someone mentions v3 of this patch,
> are they referring to this version or to
> https://patchwork.kernel.org/project/bluetooth/patch/1628758216-3201-1-git-send-email-zijuhu@codeaurora.org/?
> 
>> +
>> +		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

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

[Matthias Kaehlcke]

On Wed, Oct 27, 2021 at 02:12:07PM +0800, tjiang@codeaurora.org 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.

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

[tjiang]

Thanks Matthias for the comments.

the conclusion is that I can continue to use this patch , right ? thank 
you.

regards.
tim


On 2021-10-27 23:59, Matthias Kaehlcke wrote:
> On Wed, Oct 27, 2021 at 02:12:07PM +0800, tjiang@codeaurora.org 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.

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

[Marcel Holtmann]

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.

I really don’t care much since that is for them and their company policy to figure out.

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

It is a total mess already for a dead simple patch like this. And they keep messing it up differently every time.

I provided a btusb_generate_qca_nvm_name() in one of my replies, where the variant variable was declared without NULL assignment and the ram_version was converted from little endian in place. That was 28th of September and 4 patches later the patch is still not ready to be merged. The maintainer hands you the recipe and you still screw up the cake multiple times; I am just done with this.

The next version would be a v16 btw. So seriously, how can we have 15 revisions so far and still not have this in a mergable state?

Regards

Marcel

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

[tjiang]

Thanks Marcel for the reply, I will do as what you said , thank you.

regards.
tim


On 2021-10-28 22:00, Marcel Holtmann 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.
> 
> I really don’t care much since that is for them and their company
> policy to figure out.
> 
>> 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.
> 
> It is a total mess already for a dead simple patch like this. And they
> keep messing it up differently every time.
> 
> I provided a btusb_generate_qca_nvm_name() in one of my replies, where
> the variant variable was declared without NULL assignment and the
> ram_version was converted from little endian in place. That was 28th
> of September and 4 patches later the patch is still not ready to be
> merged. The maintainer hands you the recipe and you still screw up the
> cake multiple times; I am just done with this.
> 
> The next version would be a v16 btw. So seriously, how can we have 15
> revisions so far and still not have this in a mergable state?
> 
> Regards
> 
> Marcel