[PATCH v2 0/2] wifi: ath11k: support board-specific firmware overrides

[PATCH v2 0/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
IPA, thermal, RAM size and etc, so new firmware files used. This change
allows board DT files to override the subdir of the firmware directory
used to lookup the amss.bin and m3.bin.

For example:

- ath11k/WCN6855/hw2.1/amss.bin,
  ath11k/WCN6855/hw2.1/m3.bin: main firmware files, used by default

- ath11k/WCN6855/hw2.1/qca6698aq/amss.bin,
  ath11k/WCN6855/hw2.1/qca6698aq/m3.bin

Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com>
---
v2: follow the approach that has been defined in the commit
5abf259772df ("wifi: ath10k: support board-specific firmware
overrides").
---

Miaoqing Pan (2):
  dt-bindings: net: wireless: ath11k-pci: add firmware-name property
  wifi: ath11k: support board-specific firmware overrides

 .../bindings/net/wireless/qcom,ath11k-pci.yaml   |  7 +++++++
 drivers/net/wireless/ath/ath11k/core.c           | 16 ++++++++++++++++
 drivers/net/wireless/ath/ath11k/core.h           | 11 +++--------
 3 files changed, 26 insertions(+), 8 deletions(-)


base-commit: cd8aa3af7491a1f7a5b81e53dbe62a38433c2d4b
-- 
2.25.1

[PATCH v2 1/2] dt-bindings: net: wireless: ath11k-pci: add firmware-name property

[Miaoqing Pan]

This is the same optional property that defined in qcom,ath10k.yaml. It's
useful for the platform / board to specify firmware through device-tree.

Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com>
---
 .../devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml  | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
index a71fdf05bc1e..2aa81690f7d5 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
 # Copyright (c) 2023 Linaro Limited
+# Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
 %YAML 1.2
 ---
 $id: http://devicetree.org/schemas/net/wireless/qcom,ath11k-pci.yaml#
@@ -29,6 +30,12 @@ properties:
       string to uniquely identify variant of the calibration data for designs
       with colliding bus and device ids
 
+  firmware-name:
+    maxItems: 1
+    description:
+      If present, a board or platform specific string used to lookup firmware
+      files for the device.
+
   vddrfacmn-supply:
     description: VDD_RFA_CMN supply regulator handle
 
-- 
2.25.1

Re: [PATCH v2 1/2] dt-bindings: net: wireless: ath11k-pci: add firmware-name property

[Krzysztof Kozlowski]

On 24/10/2024 02:25, Miaoqing Pan wrote:
> This is the same optional property that defined in qcom,ath10k.yaml. It's
> useful for the platform / board to specify firmware through device-tree.

Wasn't this rejected already?

Anyway NAK for the reasons below.
> 
> Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com>
> ---
>  .../devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml  | 7 +++++++
>  1 file changed, 7 insertions(+)
> 

<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.

Please kindly resend and include all necessary To/Cc entries.
</form letter>

Best regards,
Krzysztof

[PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
IPA, thermal, RAM size and etc, so new firmware files used. This change
allows board DT files to override the subdir of the firmware directory
used to lookup the amss.bin and m3.bin.

For example:

- ath11k/WCN6855/hw2.1/amss.bin,
  ath11k/WCN6855/hw2.1/m3.bin: main firmware files, used by default

- ath11k/WCN6855/hw2.1/qca6698aq/amss.bin,
  ath11k/WCN6855/hw2.1/qca6698aq/m3.bin

Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04402-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com>
---
 drivers/net/wireless/ath/ath11k/core.c | 16 ++++++++++++++++
 drivers/net/wireless/ath/ath11k/core.h | 11 +++--------
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
index be67382c00f6..775e48551522 100644
--- a/drivers/net/wireless/ath/ath11k/core.c
+++ b/drivers/net/wireless/ath/ath11k/core.c
@@ -1178,6 +1178,22 @@ static int ath11k_core_create_chip_id_board_name(struct ath11k_base *ab, char *n
 					       ATH11K_BDF_NAME_CHIP_ID);
 }
 
+void ath11k_core_create_firmware_path(struct ath11k_base *ab,
+				      const char *filename,
+				      void *buf, size_t buf_len)
+{	const char *board_name = NULL;
+
+	of_property_read_string(ab->dev->of_node, "firmware-name", &board_name);
+
+	if (board_name)
+		snprintf(buf, buf_len, "%s/%s/%s/%s", ATH11K_FW_DIR,
+			 ab->hw_params.fw.dir, board_name, filename);
+	else
+		snprintf(buf, buf_len, "%s/%s/%s", ATH11K_FW_DIR,
+			 ab->hw_params.fw.dir, filename);
+}
+EXPORT_SYMBOL(ath11k_core_create_firmware_path);
+
 const struct firmware *ath11k_core_firmware_request(struct ath11k_base *ab,
 						    const char *file)
 {
diff --git a/drivers/net/wireless/ath/ath11k/core.h b/drivers/net/wireless/ath/ath11k/core.h
index 09c37e19a168..ce4102cfed4d 100644
--- a/drivers/net/wireless/ath/ath11k/core.h
+++ b/drivers/net/wireless/ath/ath11k/core.h
@@ -1249,6 +1249,9 @@ bool ath11k_core_coldboot_cal_support(struct ath11k_base *ab);
 
 const struct firmware *ath11k_core_firmware_request(struct ath11k_base *ab,
 						    const char *filename);
+void ath11k_core_create_firmware_path(struct ath11k_base *ab,
+				      const char *filename,
+				      void *buf, size_t buf_len);
 
 static inline const char *ath11k_scan_state_str(enum ath11k_scan_state state)
 {
@@ -1295,14 +1298,6 @@ static inline struct ath11k *ath11k_ab_to_ar(struct ath11k_base *ab,
 	return ab->pdevs[ath11k_hw_mac_id_to_pdev_id(&ab->hw_params, mac_id)].ar;
 }
 
-static inline void ath11k_core_create_firmware_path(struct ath11k_base *ab,
-						    const char *filename,
-						    void *buf, size_t buf_len)
-{
-	snprintf(buf, buf_len, "%s/%s/%s", ATH11K_FW_DIR,
-		 ab->hw_params.fw.dir, filename);
-}
-
 static inline const char *ath11k_bus_str(enum ath11k_bus bus)
 {
 	switch (bus) {
-- 
2.25.1

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Dmitry Baryshkov]

On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
> IPA, thermal, RAM size and etc, so new firmware files used. This change
> allows board DT files to override the subdir of the firmware directory
> used to lookup the amss.bin and m3.bin.

I have slight concerns regarding the _board_ DT files overriding the
subdir. This opens a can of worms, allowing per-board firmware sets,
which (as far as I understand) is far from being what driver maintainers
would like to see. This was required for ath10k-snoc devices, since
firmware for those platforms is signed by the vendor keys and it is
limited to a particular SoC or SoC family. For ath11k-pci there is no
such limitation.

Would it be possible to use PCI subvendor / subdev to identify affected
cards? PCI Revision? Any other way to identify the device?  Please
provide lspci -nnvv for the affected device kind. Is there a way to
identify the RF part somehow?

Could you possibly clarify, how this situation is handled in Windows
world?

> 
> For example:
> 
> - ath11k/WCN6855/hw2.1/amss.bin,
>   ath11k/WCN6855/hw2.1/m3.bin: main firmware files, used by default
> 
> - ath11k/WCN6855/hw2.1/qca6698aq/amss.bin,
>   ath11k/WCN6855/hw2.1/qca6698aq/m3.bin

This approach looks good to me, thank you.

> 
> Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04402-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
> 
> Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com>
> ---
>  drivers/net/wireless/ath/ath11k/core.c | 16 ++++++++++++++++
>  drivers/net/wireless/ath/ath11k/core.h | 11 +++--------
>  2 files changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> index be67382c00f6..775e48551522 100644
> --- a/drivers/net/wireless/ath/ath11k/core.c
> +++ b/drivers/net/wireless/ath/ath11k/core.c
> @@ -1178,6 +1178,22 @@ static int ath11k_core_create_chip_id_board_name(struct ath11k_base *ab, char *n
>  					       ATH11K_BDF_NAME_CHIP_ID);
>  }
>  
> +void ath11k_core_create_firmware_path(struct ath11k_base *ab,
> +				      const char *filename,
> +				      void *buf, size_t buf_len)
> +{	const char *board_name = NULL;
> +
> +	of_property_read_string(ab->dev->of_node, "firmware-name", &board_name);

soc_name rather than board_name, please. Or just fw_name.

> +
> +	if (board_name)
> +		snprintf(buf, buf_len, "%s/%s/%s/%s", ATH11K_FW_DIR,
> +			 ab->hw_params.fw.dir, board_name, filename);
> +	else
> +		snprintf(buf, buf_len, "%s/%s/%s", ATH11K_FW_DIR,
> +			 ab->hw_params.fw.dir, filename);
> +}
> +EXPORT_SYMBOL(ath11k_core_create_firmware_path);
> +
>  const struct firmware *ath11k_core_firmware_request(struct ath11k_base *ab,
>  						    const char *file)
>  {
> diff --git a/drivers/net/wireless/ath/ath11k/core.h b/drivers/net/wireless/ath/ath11k/core.h
> index 09c37e19a168..ce4102cfed4d 100644
> --- a/drivers/net/wireless/ath/ath11k/core.h
> +++ b/drivers/net/wireless/ath/ath11k/core.h
> @@ -1249,6 +1249,9 @@ bool ath11k_core_coldboot_cal_support(struct ath11k_base *ab);
>  
>  const struct firmware *ath11k_core_firmware_request(struct ath11k_base *ab,
>  						    const char *filename);
> +void ath11k_core_create_firmware_path(struct ath11k_base *ab,
> +				      const char *filename,
> +				      void *buf, size_t buf_len);
>  
>  static inline const char *ath11k_scan_state_str(enum ath11k_scan_state state)
>  {
> @@ -1295,14 +1298,6 @@ static inline struct ath11k *ath11k_ab_to_ar(struct ath11k_base *ab,
>  	return ab->pdevs[ath11k_hw_mac_id_to_pdev_id(&ab->hw_params, mac_id)].ar;
>  }
>  
> -static inline void ath11k_core_create_firmware_path(struct ath11k_base *ab,
> -						    const char *filename,
> -						    void *buf, size_t buf_len)
> -{
> -	snprintf(buf, buf_len, "%s/%s/%s", ATH11K_FW_DIR,
> -		 ab->hw_params.fw.dir, filename);

It could have perfectly lived here. Is there any reason to move the
function?

> -}
> -
>  static inline const char *ath11k_bus_str(enum ath11k_bus bus)
>  {
>  	switch (bus) {
> -- 
> 2.25.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
>> IPA, thermal, RAM size and etc, so new firmware files used. This change
>> allows board DT files to override the subdir of the firmware directory
>> used to lookup the amss.bin and m3.bin.
> 
> I have slight concerns regarding the _board_ DT files overriding the
> subdir. This opens a can of worms, allowing per-board firmware sets,
> which (as far as I understand) is far from being what driver maintainers
> would like to see. This was required for ath10k-snoc devices, since
> firmware for those platforms is signed by the vendor keys and it is
> limited to a particular SoC or SoC family. For ath11k-pci there is no
> such limitation.
> 
> Would it be possible to use PCI subvendor / subdev to identify affected
> cards? PCI Revision? Any other way to identify the device?  Please
> provide lspci -nnvv for the affected device kind. Is there a way to
> identify the RF part somehow?

It's rather difficult, for WCN685x, there are multiple evolved subseries 
for customized products. e.g.

QCA6698AQ/hw2.1
QCA2066/hw2.1
WCN6855/hw2.0/hw2.1
WCN6856/hw2.1

They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi: 
ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate 
all QCA2066 cards, it lacks of flexibility, as the list will become 
longer and longer. But it's the only choice for QCA2066, as it's 
customized for X86 platform which without DT files.

So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE 
both attached to QCA6698AQ, we can specify the correct firmware to 
'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it 
depends on the type of the products(x86 windows, IoT products or AUTO).


0000:01:00.0 Network controller [0280]: Qualcomm QCNFA765 Wireless 
Network Adapter [17cb:1103] (rev 01)
	Subsystem: Qualcomm QCNFA765 Wireless Network Adapter [17cb:0108]
	Device tree node: /sys/firmware/devicetree/base/pci@1c00000/pcie@0/wifi@0


> 
> Could you possibly clarify, how this situation is handled in Windows
> world?

X86 platforms use standard m.2 PCIe card, and it will only use the 
default main firmware files, as they without DT files.

> 
>>
>> For example:
>>
>> - ath11k/WCN6855/hw2.1/amss.bin,
>>    ath11k/WCN6855/hw2.1/m3.bin: main firmware files, used by default
>>
>> - ath11k/WCN6855/hw2.1/qca6698aq/amss.bin,
>>    ath11k/WCN6855/hw2.1/qca6698aq/m3.bin
> 
> This approach looks good to me, thank you.
> 
>>
>> Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04402-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
>>
>> Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com>
>> ---
>>   drivers/net/wireless/ath/ath11k/core.c | 16 ++++++++++++++++
>>   drivers/net/wireless/ath/ath11k/core.h | 11 +++--------
>>   2 files changed, 19 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
>> index be67382c00f6..775e48551522 100644
>> --- a/drivers/net/wireless/ath/ath11k/core.c
>> +++ b/drivers/net/wireless/ath/ath11k/core.c
>> @@ -1178,6 +1178,22 @@ static int ath11k_core_create_chip_id_board_name(struct ath11k_base *ab, char *n
>>   					       ATH11K_BDF_NAME_CHIP_ID);
>>   }
>>   
>> +void ath11k_core_create_firmware_path(struct ath11k_base *ab,
>> +				      const char *filename,
>> +				      void *buf, size_t buf_len)
>> +{	const char *board_name = NULL;
>> +
>> +	of_property_read_string(ab->dev->of_node, "firmware-name", &board_name);
> 
> soc_name rather than board_name, please. Or just fw_name.

Will update to 'fw_name'.

> 
>> +
>> +	if (board_name)
>> +		snprintf(buf, buf_len, "%s/%s/%s/%s", ATH11K_FW_DIR,
>> +			 ab->hw_params.fw.dir, board_name, filename);
>> +	else
>> +		snprintf(buf, buf_len, "%s/%s/%s", ATH11K_FW_DIR,
>> +			 ab->hw_params.fw.dir, filename);
>> +}
>> +EXPORT_SYMBOL(ath11k_core_create_firmware_path);
>> +
>>   const struct firmware *ath11k_core_firmware_request(struct ath11k_base *ab,
>>   						    const char *file)
>>   {
>> diff --git a/drivers/net/wireless/ath/ath11k/core.h b/drivers/net/wireless/ath/ath11k/core.h
>> index 09c37e19a168..ce4102cfed4d 100644
>> --- a/drivers/net/wireless/ath/ath11k/core.h
>> +++ b/drivers/net/wireless/ath/ath11k/core.h
>> @@ -1249,6 +1249,9 @@ bool ath11k_core_coldboot_cal_support(struct ath11k_base *ab);
>>   
>>   const struct firmware *ath11k_core_firmware_request(struct ath11k_base *ab,
>>   						    const char *filename);
>> +void ath11k_core_create_firmware_path(struct ath11k_base *ab,
>> +				      const char *filename,
>> +				      void *buf, size_t buf_len);
>>   
>>   static inline const char *ath11k_scan_state_str(enum ath11k_scan_state state)
>>   {
>> @@ -1295,14 +1298,6 @@ static inline struct ath11k *ath11k_ab_to_ar(struct ath11k_base *ab,
>>   	return ab->pdevs[ath11k_hw_mac_id_to_pdev_id(&ab->hw_params, mac_id)].ar;
>>   }
>>   
>> -static inline void ath11k_core_create_firmware_path(struct ath11k_base *ab,
>> -						    const char *filename,
>> -						    void *buf, size_t buf_len)
>> -{
>> -	snprintf(buf, buf_len, "%s/%s/%s", ATH11K_FW_DIR,
>> -		 ab->hw_params.fw.dir, filename);
> 
> It could have perfectly lived here. Is there any reason to move the
> function?

Will update.

> 
>> -}
>> -
>>   static inline const char *ath11k_bus_str(enum ath11k_bus bus)
>>   {
>>   	switch (bus) {
>> -- 
>> 2.25.1
>>
> 

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Dmitry Baryshkov]

On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
> 
> 
> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
> > On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
> > > QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
> > > IPA, thermal, RAM size and etc, so new firmware files used. This change
> > > allows board DT files to override the subdir of the firmware directory
> > > used to lookup the amss.bin and m3.bin.
> > 
> > I have slight concerns regarding the _board_ DT files overriding the
> > subdir. This opens a can of worms, allowing per-board firmware sets,
> > which (as far as I understand) is far from being what driver maintainers
> > would like to see. This was required for ath10k-snoc devices, since
> > firmware for those platforms is signed by the vendor keys and it is
> > limited to a particular SoC or SoC family. For ath11k-pci there is no
> > such limitation.
> > 
> > Would it be possible to use PCI subvendor / subdev to identify affected
> > cards? PCI Revision? Any other way to identify the device?  Please
> > provide lspci -nnvv for the affected device kind. Is there a way to
> > identify the RF part somehow?
> 
> It's rather difficult, for WCN685x, there are multiple evolved subseries for
> customized products. e.g.
> 
> QCA6698AQ/hw2.1
> QCA2066/hw2.1
> WCN6855/hw2.0/hw2.1
> WCN6856/hw2.1
> 
> They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
> QCA2066 cards, it lacks of flexibility, as the list will become longer and
> longer. But it's the only choice for QCA2066, as it's customized for X86
> platform which without DT files.

I guess, this is closer to Kalle's expectations: being able to detect
the hardware instead of adding DT properties.

> So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
> attached to QCA6698AQ, we can specify the correct firmware to
> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
> on the type of the products(x86 windows, IoT products or AUTO).

No-no-no and no. The firmware used must not be specific to the product
type.  This is what everybody here is trying to avoid. Please try
following the QCA2066 approach instead. And note that it could use new
TLD as it perfectly shows itself as a different hardware kind.

> 0000:01:00.0 Network controller [0280]: Qualcomm QCNFA765 Wireless Network
> Adapter [17cb:1103] (rev 01)
> 	Subsystem: Qualcomm QCNFA765 Wireless Network Adapter [17cb:0108]
> 	Device tree node: /sys/firmware/devicetree/base/pci@1c00000/pcie@0/wifi@0
> 
> 
> > 
> > Could you possibly clarify, how this situation is handled in Windows
> > world?
> 
> X86 platforms use standard m.2 PCIe card, and it will only use the default
> main firmware files, as they without DT files.

So QCA6698AQ cannot appear on an M.2 PCIe card?

> 
> > 
> > > 
> > > For example:
> > > 
> > > - ath11k/WCN6855/hw2.1/amss.bin,
> > >    ath11k/WCN6855/hw2.1/m3.bin: main firmware files, used by default
> > > 
> > > - ath11k/WCN6855/hw2.1/qca6698aq/amss.bin,
> > >    ath11k/WCN6855/hw2.1/qca6698aq/m3.bin
> > 

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
> On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
>>
>>
>> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
>>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
>>>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
>>>> IPA, thermal, RAM size and etc, so new firmware files used. This change
>>>> allows board DT files to override the subdir of the firmware directory
>>>> used to lookup the amss.bin and m3.bin.
>>>
>>> I have slight concerns regarding the _board_ DT files overriding the
>>> subdir. This opens a can of worms, allowing per-board firmware sets,
>>> which (as far as I understand) is far from being what driver maintainers
>>> would like to see. This was required for ath10k-snoc devices, since
>>> firmware for those platforms is signed by the vendor keys and it is
>>> limited to a particular SoC or SoC family. For ath11k-pci there is no
>>> such limitation.
>>>
>>> Would it be possible to use PCI subvendor / subdev to identify affected
>>> cards? PCI Revision? Any other way to identify the device?  Please
>>> provide lspci -nnvv for the affected device kind. Is there a way to
>>> identify the RF part somehow?
>>
>> It's rather difficult, for WCN685x, there are multiple evolved subseries for
>> customized products. e.g.
>>
>> QCA6698AQ/hw2.1
>> QCA2066/hw2.1
>> WCN6855/hw2.0/hw2.1
>> WCN6856/hw2.1
>>
>> They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
>> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
>> QCA2066 cards, it lacks of flexibility, as the list will become longer and
>> longer. But it's the only choice for QCA2066, as it's customized for X86
>> platform which without DT files.
> 
> I guess, this is closer to Kalle's expectations: being able to detect
> the hardware instead of adding DT properties.
> 
>> So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
>> attached to QCA6698AQ, we can specify the correct firmware to
>> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
>> on the type of the products(x86 windows, IoT products or AUTO).
> 
> No-no-no and no. The firmware used must not be specific to the product
> type.  This is what everybody here is trying to avoid. Please try
> following the QCA2066 approach instead. And note that it could use new
> TLD as it perfectly shows itself as a different hardware kind.

Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw 
revision register in BAR0 space, it's hard to maintain the list.

We're going to have another problem to enable NFA765 m.2 card for IoT 
platforms, which has different feature sets with X86 platform, so also 
new firmware should be used. In this case, QCA2066 approach not works. 
Seems DT approach is only choice.

Could you advice ?


> 
>> 0000:01:00.0 Network controller [0280]: Qualcomm QCNFA765 Wireless Network
>> Adapter [17cb:1103] (rev 01)
>> 	Subsystem: Qualcomm QCNFA765 Wireless Network Adapter [17cb:0108]
>> 	Device tree node: /sys/firmware/devicetree/base/pci@1c00000/pcie@0/wifi@0
>>
>>
>>>
>>> Could you possibly clarify, how this situation is handled in Windows
>>> world?
>>
>> X86 platforms use standard m.2 PCIe card, and it will only use the default
>> main firmware files, as they without DT files.
> 
> So QCA6698AQ cannot appear on an M.2 PCIe card?

No, but no m.2 PCIe card so far. It depends on power sequencing module 
to do power up.

> 
>>
>>>
>>>>
>>>> For example:
>>>>
>>>> - ath11k/WCN6855/hw2.1/amss.bin,
>>>>     ath11k/WCN6855/hw2.1/m3.bin: main firmware files, used by default
>>>>
>>>> - ath11k/WCN6855/hw2.1/qca6698aq/amss.bin,
>>>>     ath11k/WCN6855/hw2.1/qca6698aq/m3.bin
>>>
> 

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Dmitry Baryshkov]

On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>
>
>
> On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
> > On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
> >>
> >>
> >> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
> >>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
> >>>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
> >>>> IPA, thermal, RAM size and etc, so new firmware files used. This change
> >>>> allows board DT files to override the subdir of the firmware directory
> >>>> used to lookup the amss.bin and m3.bin.
> >>>
> >>> I have slight concerns regarding the _board_ DT files overriding the
> >>> subdir. This opens a can of worms, allowing per-board firmware sets,
> >>> which (as far as I understand) is far from being what driver maintainers
> >>> would like to see. This was required for ath10k-snoc devices, since
> >>> firmware for those platforms is signed by the vendor keys and it is
> >>> limited to a particular SoC or SoC family. For ath11k-pci there is no
> >>> such limitation.
> >>>
> >>> Would it be possible to use PCI subvendor / subdev to identify affected
> >>> cards? PCI Revision? Any other way to identify the device?  Please
> >>> provide lspci -nnvv for the affected device kind. Is there a way to
> >>> identify the RF part somehow?
> >>
> >> It's rather difficult, for WCN685x, there are multiple evolved subseries for
> >> customized products. e.g.
> >>
> >> QCA6698AQ/hw2.1
> >> QCA2066/hw2.1
> >> WCN6855/hw2.0/hw2.1
> >> WCN6856/hw2.1
> >>
> >> They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
> >> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
> >> QCA2066 cards, it lacks of flexibility, as the list will become longer and
> >> longer. But it's the only choice for QCA2066, as it's customized for X86
> >> platform which without DT files.
> >
> > I guess, this is closer to Kalle's expectations: being able to detect
> > the hardware instead of adding DT properties.
> >
> >> So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
> >> attached to QCA6698AQ, we can specify the correct firmware to
> >> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
> >> on the type of the products(x86 windows, IoT products or AUTO).
> >
> > No-no-no and no. The firmware used must not be specific to the product
> > type.  This is what everybody here is trying to avoid. Please try
> > following the QCA2066 approach instead. And note that it could use new
> > TLD as it perfectly shows itself as a different hardware kind.
>
> Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
> revision register in BAR0 space, it's hard to maintain the list.

How is it so?

And if it is hard, can we please get to the _normal_ way how vendors
handle PCI hardware differences: the subvendor and subdevice? This is
a usual way to describe that the PCIe device is the same, but the
analog / tuner / RF / etc parts are different.

> We're going to have another problem to enable NFA765 m.2 card for IoT
> platforms, which has different feature sets with X86 platform, so also
> new firmware should be used. In this case, QCA2066 approach not works.
> Seems DT approach is only choice.
>
> Could you advice ?

Hmm, The first question is _why_ does it have different feature sets?
What exactly is different? What if the user plugs a normal (laptop)
M.2 card into their IoT device?

> >
> >> 0000:01:00.0 Network controller [0280]: Qualcomm QCNFA765 Wireless Network
> >> Adapter [17cb:1103] (rev 01)
> >>      Subsystem: Qualcomm QCNFA765 Wireless Network Adapter [17cb:0108]
> >>      Device tree node: /sys/firmware/devicetree/base/pci@1c00000/pcie@0/wifi@0
> >>
> >>
> >>>
> >>> Could you possibly clarify, how this situation is handled in Windows
> >>> world?
> >>
> >> X86 platforms use standard m.2 PCIe card, and it will only use the default
> >> main firmware files, as they without DT files.
> >
> > So QCA6698AQ cannot appear on an M.2 PCIe card?
>
> No, but no m.2 PCIe card so far. It depends on power sequencing module
> to do power up.

You are describing software (power sequencing module), while I was
talking about the hardware. Nothing prevents OEM from adding fixed
regulators to drive necessary voltages from the PCIe slot.

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
> On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>>
>>
>>
>> On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
>>> On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
>>>>
>>>>
>>>> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
>>>>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
>>>>>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
>>>>>> IPA, thermal, RAM size and etc, so new firmware files used. This change
>>>>>> allows board DT files to override the subdir of the firmware directory
>>>>>> used to lookup the amss.bin and m3.bin.
>>>>>
>>>>> I have slight concerns regarding the _board_ DT files overriding the
>>>>> subdir. This opens a can of worms, allowing per-board firmware sets,
>>>>> which (as far as I understand) is far from being what driver maintainers
>>>>> would like to see. This was required for ath10k-snoc devices, since
>>>>> firmware for those platforms is signed by the vendor keys and it is
>>>>> limited to a particular SoC or SoC family. For ath11k-pci there is no
>>>>> such limitation.
>>>>>
>>>>> Would it be possible to use PCI subvendor / subdev to identify affected
>>>>> cards? PCI Revision? Any other way to identify the device?  Please
>>>>> provide lspci -nnvv for the affected device kind. Is there a way to
>>>>> identify the RF part somehow?
>>>>
>>>> It's rather difficult, for WCN685x, there are multiple evolved subseries for
>>>> customized products. e.g.
>>>>
>>>> QCA6698AQ/hw2.1
>>>> QCA2066/hw2.1
>>>> WCN6855/hw2.0/hw2.1
>>>> WCN6856/hw2.1
>>>>
>>>> They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
>>>> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
>>>> QCA2066 cards, it lacks of flexibility, as the list will become longer and
>>>> longer. But it's the only choice for QCA2066, as it's customized for X86
>>>> platform which without DT files.
>>>
>>> I guess, this is closer to Kalle's expectations: being able to detect
>>> the hardware instead of adding DT properties.
>>>
>>>> So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
>>>> attached to QCA6698AQ, we can specify the correct firmware to
>>>> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
>>>> on the type of the products(x86 windows, IoT products or AUTO).
>>>
>>> No-no-no and no. The firmware used must not be specific to the product
>>> type.  This is what everybody here is trying to avoid. Please try
>>> following the QCA2066 approach instead. And note that it could use new
>>> TLD as it perfectly shows itself as a different hardware kind.
>>
>> Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
>> revision register in BAR0 space, it's hard to maintain the list.
> 
> How is it so?

I think QCA2066 approach is just a workaround. Different batches of chip 
manufacture has different value in TCSR_SOC_HW_SUB_VER.

> 
> And if it is hard, can we please get to the _normal_ way how vendors
> handle PCI hardware differences: the subvendor and subdevice? This is
> a usual way to describe that the PCIe device is the same, but the
> analog / tuner / RF / etc parts are different.


> 
>> We're going to have another problem to enable NFA765 m.2 card for IoT
>> platforms, which has different feature sets with X86 platform, so also
>> new firmware should be used. In this case, QCA2066 approach not works.
>> Seems DT approach is only choice.
>>
>> Could you advice ?
> 
> Hmm, The first question is _why_ does it have different feature sets?
> What exactly is different? 

Yeah, for IoT device will support SAP/TWT/UL-OFDMA/BSS color and etc new 
features, and the existing x86 firmware mainly for STA mode.

What if the user plugs a normal (laptop)
> M.2 card into their IoT device?

If there is no DT file to specify the firmware, IoT device will load the 
default firmware, it will affect SAP and WiFi-6 advanced features.


> 
>>>
>>>> 0000:01:00.0 Network controller [0280]: Qualcomm QCNFA765 Wireless Network
>>>> Adapter [17cb:1103] (rev 01)
>>>>       Subsystem: Qualcomm QCNFA765 Wireless Network Adapter [17cb:0108]
>>>>       Device tree node: /sys/firmware/devicetree/base/pci@1c00000/pcie@0/wifi@0
>>>>
>>>>
>>>>>
>>>>> Could you possibly clarify, how this situation is handled in Windows
>>>>> world?
>>>>
>>>> X86 platforms use standard m.2 PCIe card, and it will only use the default
>>>> main firmware files, as they without DT files.
>>>
>>> So QCA6698AQ cannot appear on an M.2 PCIe card?
>>
>> No, but no m.2 PCIe card so far. It depends on power sequencing module
>> to do power up.
> 
> You are describing software (power sequencing module), while I was
> talking about the hardware. Nothing prevents OEM from adding fixed
> regulators to drive necessary voltages from the PCIe slot.
> 

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Dmitry Baryshkov]

On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>
>
>
> On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
> > On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
> >>
> >>
> >>
> >> On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
> >>> On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
> >>>>
> >>>>
> >>>> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
> >>>>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
> >>>>>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
> >>>>>> IPA, thermal, RAM size and etc, so new firmware files used. This change
> >>>>>> allows board DT files to override the subdir of the firmware directory
> >>>>>> used to lookup the amss.bin and m3.bin.
> >>>>>
> >>>>> I have slight concerns regarding the _board_ DT files overriding the
> >>>>> subdir. This opens a can of worms, allowing per-board firmware sets,
> >>>>> which (as far as I understand) is far from being what driver maintainers
> >>>>> would like to see. This was required for ath10k-snoc devices, since
> >>>>> firmware for those platforms is signed by the vendor keys and it is
> >>>>> limited to a particular SoC or SoC family. For ath11k-pci there is no
> >>>>> such limitation.
> >>>>>
> >>>>> Would it be possible to use PCI subvendor / subdev to identify affected
> >>>>> cards? PCI Revision? Any other way to identify the device?  Please
> >>>>> provide lspci -nnvv for the affected device kind. Is there a way to
> >>>>> identify the RF part somehow?
> >>>>
> >>>> It's rather difficult, for WCN685x, there are multiple evolved subseries for
> >>>> customized products. e.g.
> >>>>
> >>>> QCA6698AQ/hw2.1
> >>>> QCA2066/hw2.1
> >>>> WCN6855/hw2.0/hw2.1
> >>>> WCN6856/hw2.1
> >>>>
> >>>> They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
> >>>> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
> >>>> QCA2066 cards, it lacks of flexibility, as the list will become longer and
> >>>> longer. But it's the only choice for QCA2066, as it's customized for X86
> >>>> platform which without DT files.
> >>>
> >>> I guess, this is closer to Kalle's expectations: being able to detect
> >>> the hardware instead of adding DT properties.
> >>>
> >>>> So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
> >>>> attached to QCA6698AQ, we can specify the correct firmware to
> >>>> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
> >>>> on the type of the products(x86 windows, IoT products or AUTO).
> >>>
> >>> No-no-no and no. The firmware used must not be specific to the product
> >>> type.  This is what everybody here is trying to avoid. Please try
> >>> following the QCA2066 approach instead. And note that it could use new
> >>> TLD as it perfectly shows itself as a different hardware kind.
> >>
> >> Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
> >> revision register in BAR0 space, it's hard to maintain the list.
> >
> > How is it so?
>
> I think QCA2066 approach is just a workaround. Different batches of chip
> manufacture has different value in TCSR_SOC_HW_SUB_VER.

Ok. So, subvendor / subdevice?

>
> >
> > And if it is hard, can we please get to the _normal_ way how vendors
> > handle PCI hardware differences: the subvendor and subdevice? This is
> > a usual way to describe that the PCIe device is the same, but the
> > analog / tuner / RF / etc parts are different.
>
>
> >
> >> We're going to have another problem to enable NFA765 m.2 card for IoT
> >> platforms, which has different feature sets with X86 platform, so also
> >> new firmware should be used. In this case, QCA2066 approach not works.
> >> Seems DT approach is only choice.
> >>
> >> Could you advice ?
> >
> > Hmm, The first question is _why_ does it have different feature sets?
> > What exactly is different?
>
> Yeah, for IoT device will support SAP/TWT/UL-OFDMA/BSS color and etc new
> features, and the existing x86 firmware mainly for STA mode.
>
> What if the user plugs a normal (laptop)
> > M.2 card into their IoT device?
>
> If there is no DT file to specify the firmware, IoT device will load the
> default firmware, it will affect SAP and WiFi-6 advanced features.

Can we get all those nice features into x86 world instead?

>
>
> >
> >>>
> >>>> 0000:01:00.0 Network controller [0280]: Qualcomm QCNFA765 Wireless Network
> >>>> Adapter [17cb:1103] (rev 01)
> >>>>       Subsystem: Qualcomm QCNFA765 Wireless Network Adapter [17cb:0108]
> >>>>       Device tree node: /sys/firmware/devicetree/base/pci@1c00000/pcie@0/wifi@0
> >>>>
> >>>>
> >>>>>
> >>>>> Could you possibly clarify, how this situation is handled in Windows
> >>>>> world?
> >>>>
> >>>> X86 platforms use standard m.2 PCIe card, and it will only use the default
> >>>> main firmware files, as they without DT files.
> >>>
> >>> So QCA6698AQ cannot appear on an M.2 PCIe card?
> >>
> >> No, but no m.2 PCIe card so far. It depends on power sequencing module
> >> to do power up.
> >
> > You are describing software (power sequencing module), while I was
> > talking about the hardware. Nothing prevents OEM from adding fixed
> > regulators to drive necessary voltages from the PCIe slot.
> >
>


-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

On 10/25/2024 8:21 PM, Dmitry Baryshkov wrote:
> On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>>
>>
>>
>> On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
>>> On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
>>>>>>
>>>>>>
>>>>>> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
>>>>>>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
>>>>>>>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
>>>>>>>> IPA, thermal, RAM size and etc, so new firmware files used. This change
>>>>>>>> allows board DT files to override the subdir of the firmware directory
>>>>>>>> used to lookup the amss.bin and m3.bin.
>>>>>>>
>>>>>>> I have slight concerns regarding the _board_ DT files overriding the
>>>>>>> subdir. This opens a can of worms, allowing per-board firmware sets,
>>>>>>> which (as far as I understand) is far from being what driver maintainers
>>>>>>> would like to see. This was required for ath10k-snoc devices, since
>>>>>>> firmware for those platforms is signed by the vendor keys and it is
>>>>>>> limited to a particular SoC or SoC family. For ath11k-pci there is no
>>>>>>> such limitation.
>>>>>>>
>>>>>>> Would it be possible to use PCI subvendor / subdev to identify affected
>>>>>>> cards? PCI Revision? Any other way to identify the device?  Please
>>>>>>> provide lspci -nnvv for the affected device kind. Is there a way to
>>>>>>> identify the RF part somehow?
>>>>>>
>>>>>> It's rather difficult, for WCN685x, there are multiple evolved subseries for
>>>>>> customized products. e.g.
>>>>>>
>>>>>> QCA6698AQ/hw2.1
>>>>>> QCA2066/hw2.1
>>>>>> WCN6855/hw2.0/hw2.1
>>>>>> WCN6856/hw2.1
>>>>>>
>>>>>> They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
>>>>>> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
>>>>>> QCA2066 cards, it lacks of flexibility, as the list will become longer and
>>>>>> longer. But it's the only choice for QCA2066, as it's customized for X86
>>>>>> platform which without DT files.
>>>>>
>>>>> I guess, this is closer to Kalle's expectations: being able to detect
>>>>> the hardware instead of adding DT properties.
>>>>>
>>>>>> So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
>>>>>> attached to QCA6698AQ, we can specify the correct firmware to
>>>>>> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
>>>>>> on the type of the products(x86 windows, IoT products or AUTO).
>>>>>
>>>>> No-no-no and no. The firmware used must not be specific to the product
>>>>> type.  This is what everybody here is trying to avoid. Please try
>>>>> following the QCA2066 approach instead. And note that it could use new
>>>>> TLD as it perfectly shows itself as a different hardware kind.
>>>>
>>>> Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
>>>> revision register in BAR0 space, it's hard to maintain the list.
>>>
>>> How is it so?
>>
>> I think QCA2066 approach is just a workaround. Different batches of chip
>> manufacture has different value in TCSR_SOC_HW_SUB_VER.
> 
> Ok. So, subvendor / subdevice?

The 'subvendor' is fixed to 0x17cb, so it's useless. And I don't have 
enough samples to decide to use 'subdevice', it's a risk for existing 
devices.

> 
>>
>>>
>>> And if it is hard, can we please get to the _normal_ way how vendors
>>> handle PCI hardware differences: the subvendor and subdevice? This is
>>> a usual way to describe that the PCIe device is the same, but the
>>> analog / tuner / RF / etc parts are different.
>>
>>
>>>
>>>> We're going to have another problem to enable NFA765 m.2 card for IoT
>>>> platforms, which has different feature sets with X86 platform, so also
>>>> new firmware should be used. In this case, QCA2066 approach not works.
>>>> Seems DT approach is only choice.
>>>>
>>>> Could you advice ?
>>>
>>> Hmm, The first question is _why_ does it have different feature sets?
>>> What exactly is different?
>>
>> Yeah, for IoT device will support SAP/TWT/UL-OFDMA/BSS color and etc new
>> features, and the existing x86 firmware mainly for STA mode.
>>
>> What if the user plugs a normal (laptop)
>>> M.2 card into their IoT device?
>>
>> If there is no DT file to specify the firmware, IoT device will load the
>> default firmware, it will affect SAP and WiFi-6 advanced features.
> 
> Can we get all those nice features into x86 world instead?

It's out of our scope, we will not touch the existing stable firmware 
version, also it's not allowed.

> 
>>
>>
>>>
>>>>>
>>>>>> 0000:01:00.0 Network controller [0280]: Qualcomm QCNFA765 Wireless Network
>>>>>> Adapter [17cb:1103] (rev 01)
>>>>>>        Subsystem: Qualcomm QCNFA765 Wireless Network Adapter [17cb:0108]
>>>>>>        Device tree node: /sys/firmware/devicetree/base/pci@1c00000/pcie@0/wifi@0
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Could you possibly clarify, how this situation is handled in Windows
>>>>>>> world?
>>>>>>
>>>>>> X86 platforms use standard m.2 PCIe card, and it will only use the default
>>>>>> main firmware files, as they without DT files.
>>>>>
>>>>> So QCA6698AQ cannot appear on an M.2 PCIe card?
>>>>
>>>> No, but no m.2 PCIe card so far. It depends on power sequencing module
>>>> to do power up.
>>>
>>> You are describing software (power sequencing module), while I was
>>> talking about the hardware. Nothing prevents OEM from adding fixed
>>> regulators to drive necessary voltages from the PCIe slot.
>>>
>>
> 
> 

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Dmitry Baryshkov]

On Fri, Oct 25, 2024 at 09:43:04PM +0800, Miaoqing Pan wrote:
> 
> 
> On 10/25/2024 8:21 PM, Dmitry Baryshkov wrote:
> > On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
> > > 
> > > 
> > > 
> > > On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
> > > > On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
> > > > > > On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
> > > > > > > > On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
> > > > > > > > > QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
> > > > > > > > > IPA, thermal, RAM size and etc, so new firmware files used. This change
> > > > > > > > > allows board DT files to override the subdir of the firmware directory
> > > > > > > > > used to lookup the amss.bin and m3.bin.
> > > > > > > > 
> > > > > > > > I have slight concerns regarding the _board_ DT files overriding the
> > > > > > > > subdir. This opens a can of worms, allowing per-board firmware sets,
> > > > > > > > which (as far as I understand) is far from being what driver maintainers
> > > > > > > > would like to see. This was required for ath10k-snoc devices, since
> > > > > > > > firmware for those platforms is signed by the vendor keys and it is
> > > > > > > > limited to a particular SoC or SoC family. For ath11k-pci there is no
> > > > > > > > such limitation.
> > > > > > > > 
> > > > > > > > Would it be possible to use PCI subvendor / subdev to identify affected
> > > > > > > > cards? PCI Revision? Any other way to identify the device?  Please
> > > > > > > > provide lspci -nnvv for the affected device kind. Is there a way to
> > > > > > > > identify the RF part somehow?
> > > > > > > 
> > > > > > > It's rather difficult, for WCN685x, there are multiple evolved subseries for
> > > > > > > customized products. e.g.
> > > > > > > 
> > > > > > > QCA6698AQ/hw2.1
> > > > > > > QCA2066/hw2.1
> > > > > > > WCN6855/hw2.0/hw2.1
> > > > > > > WCN6856/hw2.1
> > > > > > > 
> > > > > > > They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
> > > > > > > ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
> > > > > > > QCA2066 cards, it lacks of flexibility, as the list will become longer and
> > > > > > > longer. But it's the only choice for QCA2066, as it's customized for X86
> > > > > > > platform which without DT files.
> > > > > > 
> > > > > > I guess, this is closer to Kalle's expectations: being able to detect
> > > > > > the hardware instead of adding DT properties.
> > > > > > 
> > > > > > > So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
> > > > > > > attached to QCA6698AQ, we can specify the correct firmware to
> > > > > > > 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
> > > > > > > on the type of the products(x86 windows, IoT products or AUTO).
> > > > > > 
> > > > > > No-no-no and no. The firmware used must not be specific to the product
> > > > > > type.  This is what everybody here is trying to avoid. Please try
> > > > > > following the QCA2066 approach instead. And note that it could use new
> > > > > > TLD as it perfectly shows itself as a different hardware kind.
> > > > > 
> > > > > Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
> > > > > revision register in BAR0 space, it's hard to maintain the list.
> > > > 
> > > > How is it so?
> > > 
> > > I think QCA2066 approach is just a workaround. Different batches of chip
> > > manufacture has different value in TCSR_SOC_HW_SUB_VER.
> > 
> > Ok. So, subvendor / subdevice?
> 
> The 'subvendor' is fixed to 0x17cb, so it's useless. And I don't have enough
> samples to decide to use 'subdevice', it's a risk for existing devices.

What kind of risk? If subvendor is fixed, then it's Qualcomm who
enumerates subdevices.

I'm really reluctant to bringing more DT usage into the PCIe space.
Especially if the user is able to swap cards.

> > > > And if it is hard, can we please get to the _normal_ way how vendors
> > > > handle PCI hardware differences: the subvendor and subdevice? This is
> > > > a usual way to describe that the PCIe device is the same, but the
> > > > analog / tuner / RF / etc parts are different.
> > > 
> > > 
> > > > 
> > > > > We're going to have another problem to enable NFA765 m.2 card for IoT
> > > > > platforms, which has different feature sets with X86 platform, so also
> > > > > new firmware should be used. In this case, QCA2066 approach not works.
> > > > > Seems DT approach is only choice.
> > > > > 
> > > > > Could you advice ?
> > > > 
> > > > Hmm, The first question is _why_ does it have different feature sets?
> > > > What exactly is different?
> > > 
> > > Yeah, for IoT device will support SAP/TWT/UL-OFDMA/BSS color and etc new
> > > features, and the existing x86 firmware mainly for STA mode.
> > > 
> > > What if the user plugs a normal (laptop)
> > > > M.2 card into their IoT device?
> > > 
> > > If there is no DT file to specify the firmware, IoT device will load the
> > > default firmware, it will affect SAP and WiFi-6 advanced features.
> > 
> > Can we get all those nice features into x86 world instead?
> 
> It's out of our scope, we will not touch the existing stable firmware
> version, also it's not allowed.

If it's not allowed for laptop cards, why is it allowed for IoT M.2
cards (which then can be perfectly installed into the laptop)?

> > > > > > > 0000:01:00.0 Network controller [0280]: Qualcomm QCNFA765 Wireless Network
> > > > > > > Adapter [17cb:1103] (rev 01)
> > > > > > >        Subsystem: Qualcomm QCNFA765 Wireless Network Adapter [17cb:0108]
> > > > > > >        Device tree node: /sys/firmware/devicetree/base/pci@1c00000/pcie@0/wifi@0
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > Could you possibly clarify, how this situation is handled in Windows
> > > > > > > > world?
> > > > > > > 
> > > > > > > X86 platforms use standard m.2 PCIe card, and it will only use the default
> > > > > > > main firmware files, as they without DT files.
> > > > > > 
> > > > > > So QCA6698AQ cannot appear on an M.2 PCIe card?
> > > > > 
> > > > > No, but no m.2 PCIe card so far. It depends on power sequencing module
> > > > > to do power up.
> > > > 
> > > > You are describing software (power sequencing module), while I was
> > > > talking about the hardware. Nothing prevents OEM from adding fixed
> > > > regulators to drive necessary voltages from the PCIe slot.

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

On 10/25/2024 10:01 PM, Dmitry Baryshkov wrote:
> On Fri, Oct 25, 2024 at 09:43:04PM +0800, Miaoqing Pan wrote:
>>
>>
>> On 10/25/2024 8:21 PM, Dmitry Baryshkov wrote:
>>> On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
>>>>>>> On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
>>>>>>>>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
>>>>>>>>>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
>>>>>>>>>> IPA, thermal, RAM size and etc, so new firmware files used. This change
>>>>>>>>>> allows board DT files to override the subdir of the firmware directory
>>>>>>>>>> used to lookup the amss.bin and m3.bin.
>>>>>>>>>
>>>>>>>>> I have slight concerns regarding the _board_ DT files overriding the
>>>>>>>>> subdir. This opens a can of worms, allowing per-board firmware sets,
>>>>>>>>> which (as far as I understand) is far from being what driver maintainers
>>>>>>>>> would like to see. This was required for ath10k-snoc devices, since
>>>>>>>>> firmware for those platforms is signed by the vendor keys and it is
>>>>>>>>> limited to a particular SoC or SoC family. For ath11k-pci there is no
>>>>>>>>> such limitation.
>>>>>>>>>
>>>>>>>>> Would it be possible to use PCI subvendor / subdev to identify affected
>>>>>>>>> cards? PCI Revision? Any other way to identify the device?  Please
>>>>>>>>> provide lspci -nnvv for the affected device kind. Is there a way to
>>>>>>>>> identify the RF part somehow?
>>>>>>>>
>>>>>>>> It's rather difficult, for WCN685x, there are multiple evolved subseries for
>>>>>>>> customized products. e.g.
>>>>>>>>
>>>>>>>> QCA6698AQ/hw2.1
>>>>>>>> QCA2066/hw2.1
>>>>>>>> WCN6855/hw2.0/hw2.1
>>>>>>>> WCN6856/hw2.1
>>>>>>>>
>>>>>>>> They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
>>>>>>>> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
>>>>>>>> QCA2066 cards, it lacks of flexibility, as the list will become longer and
>>>>>>>> longer. But it's the only choice for QCA2066, as it's customized for X86
>>>>>>>> platform which without DT files.
>>>>>>>
>>>>>>> I guess, this is closer to Kalle's expectations: being able to detect
>>>>>>> the hardware instead of adding DT properties.
>>>>>>>
>>>>>>>> So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
>>>>>>>> attached to QCA6698AQ, we can specify the correct firmware to
>>>>>>>> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
>>>>>>>> on the type of the products(x86 windows, IoT products or AUTO).
>>>>>>>
>>>>>>> No-no-no and no. The firmware used must not be specific to the product
>>>>>>> type.  This is what everybody here is trying to avoid. Please try
>>>>>>> following the QCA2066 approach instead. And note that it could use new
>>>>>>> TLD as it perfectly shows itself as a different hardware kind.
>>>>>>
>>>>>> Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
>>>>>> revision register in BAR0 space, it's hard to maintain the list.
>>>>>
>>>>> How is it so?
>>>>
>>>> I think QCA2066 approach is just a workaround. Different batches of chip
>>>> manufacture has different value in TCSR_SOC_HW_SUB_VER.
>>>
>>> Ok. So, subvendor / subdevice?
>>
>> The 'subvendor' is fixed to 0x17cb, so it's useless. And I don't have enough
>> samples to decide to use 'subdevice', it's a risk for existing devices.
> 
> What kind of risk? If subvendor is fixed, then it's Qualcomm who
> enumerates subdevices.

It's risk for there is not enough sample card to verify. Subdevice is 
never used by ath1xk drivers.

> 
> I'm really reluctant to bringing more DT usage into the PCIe space.
> Especially if the user is able to swap cards.

Understand your concern, automatic adaptation is always the best choice. 
But it may not work for MSM boards, the PCIe card (non m.2) is 
customized, which has special PMU control. User can't swap cards. And 
that's why power sequencing module was introduced.

> 
>>>>> And if it is hard, can we please get to the _normal_ way how vendors
>>>>> handle PCI hardware differences: the subvendor and subdevice? This is
>>>>> a usual way to describe that the PCIe device is the same, but the
>>>>> analog / tuner / RF / etc parts are different.
>>>>
>>>>
>>>>>
>>>>>> We're going to have another problem to enable NFA765 m.2 card for IoT
>>>>>> platforms, which has different feature sets with X86 platform, so also
>>>>>> new firmware should be used. In this case, QCA2066 approach not works.
>>>>>> Seems DT approach is only choice.
>>>>>>
>>>>>> Could you advice ?
>>>>>
>>>>> Hmm, The first question is _why_ does it have different feature sets?
>>>>> What exactly is different?
>>>>
>>>> Yeah, for IoT device will support SAP/TWT/UL-OFDMA/BSS color and etc new
>>>> features, and the existing x86 firmware mainly for STA mode.
>>>>
>>>> What if the user plugs a normal (laptop)
>>>>> M.2 card into their IoT device?
>>>>
>>>> If there is no DT file to specify the firmware, IoT device will load the
>>>> default firmware, it will affect SAP and WiFi-6 advanced features.
>>>
>>> Can we get all those nice features into x86 world instead?
>>
>> It's out of our scope, we will not touch the existing stable firmware
>> version, also it's not allowed.
> 
> If it's not allowed for laptop cards, why is it allowed for IoT M.2
> cards (which then can be perfectly installed into the laptop)?
> 

Only specific IoT M.2 cards.

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Dmitry Baryshkov]

On Fri, Oct 25, 2024 at 10:23:45PM +0800, Miaoqing Pan wrote:
> 
> 
> On 10/25/2024 10:01 PM, Dmitry Baryshkov wrote:
> > On Fri, Oct 25, 2024 at 09:43:04PM +0800, Miaoqing Pan wrote:
> > > 
> > > 
> > > On 10/25/2024 8:21 PM, Dmitry Baryshkov wrote:
> > > > On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
> > > > > > On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
> > > > > > > > On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
> > > > > > > > > > On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
> > > > > > > > > > > QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
> > > > > > > > > > > IPA, thermal, RAM size and etc, so new firmware files used. This change
> > > > > > > > > > > allows board DT files to override the subdir of the firmware directory
> > > > > > > > > > > used to lookup the amss.bin and m3.bin.
> > > > > > > > > > 
> > > > > > > > > > I have slight concerns regarding the _board_ DT files overriding the
> > > > > > > > > > subdir. This opens a can of worms, allowing per-board firmware sets,
> > > > > > > > > > which (as far as I understand) is far from being what driver maintainers
> > > > > > > > > > would like to see. This was required for ath10k-snoc devices, since
> > > > > > > > > > firmware for those platforms is signed by the vendor keys and it is
> > > > > > > > > > limited to a particular SoC or SoC family. For ath11k-pci there is no
> > > > > > > > > > such limitation.
> > > > > > > > > > 
> > > > > > > > > > Would it be possible to use PCI subvendor / subdev to identify affected
> > > > > > > > > > cards? PCI Revision? Any other way to identify the device?  Please
> > > > > > > > > > provide lspci -nnvv for the affected device kind. Is there a way to
> > > > > > > > > > identify the RF part somehow?
> > > > > > > > > 
> > > > > > > > > It's rather difficult, for WCN685x, there are multiple evolved subseries for
> > > > > > > > > customized products. e.g.
> > > > > > > > > 
> > > > > > > > > QCA6698AQ/hw2.1
> > > > > > > > > QCA2066/hw2.1
> > > > > > > > > WCN6855/hw2.0/hw2.1
> > > > > > > > > WCN6856/hw2.1
> > > > > > > > > 
> > > > > > > > > They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
> > > > > > > > > ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
> > > > > > > > > QCA2066 cards, it lacks of flexibility, as the list will become longer and
> > > > > > > > > longer. But it's the only choice for QCA2066, as it's customized for X86
> > > > > > > > > platform which without DT files.
> > > > > > > > 
> > > > > > > > I guess, this is closer to Kalle's expectations: being able to detect
> > > > > > > > the hardware instead of adding DT properties.
> > > > > > > > 
> > > > > > > > > So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
> > > > > > > > > attached to QCA6698AQ, we can specify the correct firmware to
> > > > > > > > > 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
> > > > > > > > > on the type of the products(x86 windows, IoT products or AUTO).
> > > > > > > > 
> > > > > > > > No-no-no and no. The firmware used must not be specific to the product
> > > > > > > > type.  This is what everybody here is trying to avoid. Please try
> > > > > > > > following the QCA2066 approach instead. And note that it could use new
> > > > > > > > TLD as it perfectly shows itself as a different hardware kind.
> > > > > > > 
> > > > > > > Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
> > > > > > > revision register in BAR0 space, it's hard to maintain the list.
> > > > > > 
> > > > > > How is it so?
> > > > > 
> > > > > I think QCA2066 approach is just a workaround. Different batches of chip
> > > > > manufacture has different value in TCSR_SOC_HW_SUB_VER.
> > > > 
> > > > Ok. So, subvendor / subdevice?
> > > 
> > > The 'subvendor' is fixed to 0x17cb, so it's useless. And I don't have enough
> > > samples to decide to use 'subdevice', it's a risk for existing devices.
> > 
> > What kind of risk? If subvendor is fixed, then it's Qualcomm who
> > enumerates subdevices.
> 
> It's risk for there is not enough sample card to verify. Subdevice is never
> used by ath1xk drivers.

Oh, so it's just about development. I'd say, please discuss such risks
with your management, unless Kalle or Jeff disagree with using the
subdevice for identification.

> 
> > 
> > I'm really reluctant to bringing more DT usage into the PCIe space.
> > Especially if the user is able to swap cards.
> 
> Understand your concern, automatic adaptation is always the best choice. But
> it may not work for MSM boards, the PCIe card (non m.2) is customized, which
> has special PMU control. User can't swap cards. And that's why power
> sequencing module was introduced.

I know. Still, it's better to have less unnecessary data there for
autodiscoverable devices.

> 
> > 
> > > > > > And if it is hard, can we please get to the _normal_ way how vendors
> > > > > > handle PCI hardware differences: the subvendor and subdevice? This is
> > > > > > a usual way to describe that the PCIe device is the same, but the
> > > > > > analog / tuner / RF / etc parts are different.
> > > > > 
> > > > > 
> > > > > > 
> > > > > > > We're going to have another problem to enable NFA765 m.2 card for IoT
> > > > > > > platforms, which has different feature sets with X86 platform, so also
> > > > > > > new firmware should be used. In this case, QCA2066 approach not works.
> > > > > > > Seems DT approach is only choice.
> > > > > > > 
> > > > > > > Could you advice ?
> > > > > > 
> > > > > > Hmm, The first question is _why_ does it have different feature sets?
> > > > > > What exactly is different?
> > > > > 
> > > > > Yeah, for IoT device will support SAP/TWT/UL-OFDMA/BSS color and etc new
> > > > > features, and the existing x86 firmware mainly for STA mode.
> > > > > 
> > > > > What if the user plugs a normal (laptop)
> > > > > > M.2 card into their IoT device?
> > > > > 
> > > > > If there is no DT file to specify the firmware, IoT device will load the
> > > > > default firmware, it will affect SAP and WiFi-6 advanced features.
> > > > 
> > > > Can we get all those nice features into x86 world instead?
> > > 
> > > It's out of our scope, we will not touch the existing stable firmware
> > > version, also it's not allowed.
> > 
> > If it's not allowed for laptop cards, why is it allowed for IoT M.2
> > cards (which then can be perfectly installed into the laptop)?
> > 
> 
> Only specific IoT M.2 cards.

But they are (or are going to be available) for purchase? And more
importantly, what prevents the user of a normal card to use "featureful"
firmware with the laptop card?

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

On 10/25/2024 11:27 PM, Dmitry Baryshkov wrote:
> On Fri, Oct 25, 2024 at 10:23:45PM +0800, Miaoqing Pan wrote:
>>
>>
>> On 10/25/2024 10:01 PM, Dmitry Baryshkov wrote:
>>> On Fri, Oct 25, 2024 at 09:43:04PM +0800, Miaoqing Pan wrote:
>>>>
>>>>
>>>> On 10/25/2024 8:21 PM, Dmitry Baryshkov wrote:
>>>>> On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
>>>>>>> On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@quicinc.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
>>>>>>>>> On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
>>>>>>>>>>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
>>>>>>>>>>>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has different RF,
>>>>>>>>>>>> IPA, thermal, RAM size and etc, so new firmware files used. This change
>>>>>>>>>>>> allows board DT files to override the subdir of the firmware directory
>>>>>>>>>>>> used to lookup the amss.bin and m3.bin.
>>>>>>>>>>>
>>>>>>>>>>> I have slight concerns regarding the _board_ DT files overriding the
>>>>>>>>>>> subdir. This opens a can of worms, allowing per-board firmware sets,
>>>>>>>>>>> which (as far as I understand) is far from being what driver maintainers
>>>>>>>>>>> would like to see. This was required for ath10k-snoc devices, since
>>>>>>>>>>> firmware for those platforms is signed by the vendor keys and it is
>>>>>>>>>>> limited to a particular SoC or SoC family. For ath11k-pci there is no
>>>>>>>>>>> such limitation.
>>>>>>>>>>>
>>>>>>>>>>> Would it be possible to use PCI subvendor / subdev to identify affected
>>>>>>>>>>> cards? PCI Revision? Any other way to identify the device?  Please
>>>>>>>>>>> provide lspci -nnvv for the affected device kind. Is there a way to
>>>>>>>>>>> identify the RF part somehow?
>>>>>>>>>>
>>>>>>>>>> It's rather difficult, for WCN685x, there are multiple evolved subseries for
>>>>>>>>>> customized products. e.g.
>>>>>>>>>>
>>>>>>>>>> QCA6698AQ/hw2.1
>>>>>>>>>> QCA2066/hw2.1
>>>>>>>>>> WCN6855/hw2.0/hw2.1
>>>>>>>>>> WCN6856/hw2.1
>>>>>>>>>>
>>>>>>>>>> They have the same PCIe ID (17cb:1103), the commit 5dc9d1a55e95 ("wifi:
>>>>>>>>>> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER to enumerate all
>>>>>>>>>> QCA2066 cards, it lacks of flexibility, as the list will become longer and
>>>>>>>>>> longer. But it's the only choice for QCA2066, as it's customized for X86
>>>>>>>>>> platform which without DT files.
>>>>>>>>>
>>>>>>>>> I guess, this is closer to Kalle's expectations: being able to detect
>>>>>>>>> the hardware instead of adding DT properties.
>>>>>>>>>
>>>>>>>>>> So for MSM those have DT file platforms, like SA8775P-RIDE/QCS8300-RIDE both
>>>>>>>>>> attached to QCA6698AQ, we can specify the correct firmware to
>>>>>>>>>> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board firmware, it depends
>>>>>>>>>> on the type of the products(x86 windows, IoT products or AUTO).
>>>>>>>>>
>>>>>>>>> No-no-no and no. The firmware used must not be specific to the product
>>>>>>>>> type.  This is what everybody here is trying to avoid. Please try
>>>>>>>>> following the QCA2066 approach instead. And note that it could use new
>>>>>>>>> TLD as it perfectly shows itself as a different hardware kind.
>>>>>>>>
>>>>>>>> Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
>>>>>>>> revision register in BAR0 space, it's hard to maintain the list.
>>>>>>>
>>>>>>> How is it so?
>>>>>>
>>>>>> I think QCA2066 approach is just a workaround. Different batches of chip
>>>>>> manufacture has different value in TCSR_SOC_HW_SUB_VER.
>>>>>
>>>>> Ok. So, subvendor / subdevice?
>>>>
>>>> The 'subvendor' is fixed to 0x17cb, so it's useless. And I don't have enough
>>>> samples to decide to use 'subdevice', it's a risk for existing devices.
>>>
>>> What kind of risk? If subvendor is fixed, then it's Qualcomm who
>>> enumerates subdevices.
>>
>> It's risk for there is not enough sample card to verify. Subdevice is never
>> used by ath1xk drivers.
> 
> Oh, so it's just about development. I'd say, please discuss such risks
> with your management, unless Kalle or Jeff disagree with using the
> subdevice for identification.

Kalle & Jeff, any idea to introduce subdevice ?


> 
>>
>>>
>>> I'm really reluctant to bringing more DT usage into the PCIe space.
>>> Especially if the user is able to swap cards.
>>
>> Understand your concern, automatic adaptation is always the best choice. But
>> it may not work for MSM boards, the PCIe card (non m.2) is customized, which
>> has special PMU control. User can't swap cards. And that's why power
>> sequencing module was introduced.
> 
> I know. Still, it's better to have less unnecessary data there for
> autodiscoverable devices.


> 
>>
>>>
>>>>>>> And if it is hard, can we please get to the _normal_ way how vendors
>>>>>>> handle PCI hardware differences: the subvendor and subdevice? This is
>>>>>>> a usual way to describe that the PCIe device is the same, but the
>>>>>>> analog / tuner / RF / etc parts are different.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> We're going to have another problem to enable NFA765 m.2 card for IoT
>>>>>>>> platforms, which has different feature sets with X86 platform, so also
>>>>>>>> new firmware should be used. In this case, QCA2066 approach not works.
>>>>>>>> Seems DT approach is only choice.
>>>>>>>>
>>>>>>>> Could you advice ?
>>>>>>>
>>>>>>> Hmm, The first question is _why_ does it have different feature sets?
>>>>>>> What exactly is different?
>>>>>>
>>>>>> Yeah, for IoT device will support SAP/TWT/UL-OFDMA/BSS color and etc new
>>>>>> features, and the existing x86 firmware mainly for STA mode.
>>>>>>
>>>>>> What if the user plugs a normal (laptop)
>>>>>>> M.2 card into their IoT device?
>>>>>>
>>>>>> If there is no DT file to specify the firmware, IoT device will load the
>>>>>> default firmware, it will affect SAP and WiFi-6 advanced features.
>>>>>
>>>>> Can we get all those nice features into x86 world instead?
>>>>
>>>> It's out of our scope, we will not touch the existing stable firmware
>>>> version, also it's not allowed.
>>>
>>> If it's not allowed for laptop cards, why is it allowed for IoT M.2
>>> cards (which then can be perfectly installed into the laptop)?
>>>
>>
>> Only specific IoT M.2 cards.
> 
> But they are (or are going to be available) for purchase? And more
> importantly, what prevents the user of a normal card to use "featureful"
> firmware with the laptop card?
> 

We can't prevent the user to use 'featureful' firmware, but it's not 
fully tested on the x86 platform, they need to bear the risk of instability.

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

On 10/26/2024 10:31 AM, Miaoqing Pan wrote:
> 
> 
> On 10/25/2024 11:27 PM, Dmitry Baryshkov wrote:
>> On Fri, Oct 25, 2024 at 10:23:45PM +0800, Miaoqing Pan wrote:
>>>
>>>
>>> On 10/25/2024 10:01 PM, Dmitry Baryshkov wrote:
>>>> On Fri, Oct 25, 2024 at 09:43:04PM +0800, Miaoqing Pan wrote:
>>>>>
>>>>>
>>>>> On 10/25/2024 8:21 PM, Dmitry Baryshkov wrote:
>>>>>> On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan 
>>>>>> <quic_miaoqing@quicinc.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
>>>>>>>> On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan 
>>>>>>>> <quic_miaoqing@quicinc.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
>>>>>>>>>>>>> QCA6698AQ IP core is the same as WCN6855 hw2.1, but it has 
>>>>>>>>>>>>> different RF,
>>>>>>>>>>>>> IPA, thermal, RAM size and etc, so new firmware files used. 
>>>>>>>>>>>>> This change
>>>>>>>>>>>>> allows board DT files to override the subdir of the 
>>>>>>>>>>>>> firmware directory
>>>>>>>>>>>>> used to lookup the amss.bin and m3.bin.
>>>>>>>>>>>>
>>>>>>>>>>>> I have slight concerns regarding the _board_ DT files 
>>>>>>>>>>>> overriding the
>>>>>>>>>>>> subdir. This opens a can of worms, allowing per-board 
>>>>>>>>>>>> firmware sets,
>>>>>>>>>>>> which (as far as I understand) is far from being what driver 
>>>>>>>>>>>> maintainers
>>>>>>>>>>>> would like to see. This was required for ath10k-snoc 
>>>>>>>>>>>> devices, since
>>>>>>>>>>>> firmware for those platforms is signed by the vendor keys 
>>>>>>>>>>>> and it is
>>>>>>>>>>>> limited to a particular SoC or SoC family. For ath11k-pci 
>>>>>>>>>>>> there is no
>>>>>>>>>>>> such limitation.
>>>>>>>>>>>>
>>>>>>>>>>>> Would it be possible to use PCI subvendor / subdev to 
>>>>>>>>>>>> identify affected
>>>>>>>>>>>> cards? PCI Revision? Any other way to identify the device?  
>>>>>>>>>>>> Please
>>>>>>>>>>>> provide lspci -nnvv for the affected device kind. Is there a 
>>>>>>>>>>>> way to
>>>>>>>>>>>> identify the RF part somehow?
>>>>>>>>>>>
>>>>>>>>>>> It's rather difficult, for WCN685x, there are multiple 
>>>>>>>>>>> evolved subseries for
>>>>>>>>>>> customized products. e.g.
>>>>>>>>>>>
>>>>>>>>>>> QCA6698AQ/hw2.1
>>>>>>>>>>> QCA2066/hw2.1
>>>>>>>>>>> WCN6855/hw2.0/hw2.1
>>>>>>>>>>> WCN6856/hw2.1
>>>>>>>>>>>
>>>>>>>>>>> They have the same PCIe ID (17cb:1103), the commit 
>>>>>>>>>>> 5dc9d1a55e95 ("wifi:
>>>>>>>>>>> ath11k: add support for QCA2066") reads TCSR_SOC_HW_SUB_VER 
>>>>>>>>>>> to enumerate all
>>>>>>>>>>> QCA2066 cards, it lacks of flexibility, as the list will 
>>>>>>>>>>> become longer and
>>>>>>>>>>> longer. But it's the only choice for QCA2066, as it's 
>>>>>>>>>>> customized for X86
>>>>>>>>>>> platform which without DT files.
>>>>>>>>>>
>>>>>>>>>> I guess, this is closer to Kalle's expectations: being able to 
>>>>>>>>>> detect
>>>>>>>>>> the hardware instead of adding DT properties.
>>>>>>>>>>
>>>>>>>>>>> So for MSM those have DT file platforms, like SA8775P-RIDE/ 
>>>>>>>>>>> QCS8300-RIDE both
>>>>>>>>>>> attached to QCA6698AQ, we can specify the correct firmware to
>>>>>>>>>>> 'ath11k/WCN6855/hw2.1/qca6698aq', so it's not per-board 
>>>>>>>>>>> firmware, it depends
>>>>>>>>>>> on the type of the products(x86 windows, IoT products or AUTO).
>>>>>>>>>>
>>>>>>>>>> No-no-no and no. The firmware used must not be specific to the 
>>>>>>>>>> product
>>>>>>>>>> type.  This is what everybody here is trying to avoid. Please try
>>>>>>>>>> following the QCA2066 approach instead. And note that it could 
>>>>>>>>>> use new
>>>>>>>>>> TLD as it perfectly shows itself as a different hardware kind.
>>>>>>>>>
>>>>>>>>> Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
>>>>>>>>> revision register in BAR0 space, it's hard to maintain the list.
>>>>>>>>
>>>>>>>> How is it so?
>>>>>>>
>>>>>>> I think QCA2066 approach is just a workaround. Different batches 
>>>>>>> of chip
>>>>>>> manufacture has different value in TCSR_SOC_HW_SUB_VER.
>>>>>>
>>>>>> Ok. So, subvendor / subdevice?
>>>>>
>>>>> The 'subvendor' is fixed to 0x17cb, so it's useless. And I don't 
>>>>> have enough
>>>>> samples to decide to use 'subdevice', it's a risk for existing 
>>>>> devices.
>>>>
>>>> What kind of risk? If subvendor is fixed, then it's Qualcomm who
>>>> enumerates subdevices.
>>>
>>> It's risk for there is not enough sample card to verify. Subdevice is 
>>> never
>>> used by ath1xk drivers.
>>
>> Oh, so it's just about development. I'd say, please discuss such risks
>> with your management, unless Kalle or Jeff disagree with using the
>> subdevice for identification.
> 
> Kalle & Jeff, any idea to introduce subdevice ?
> 
> 

Whether 'QCA2066 approach' or 'subdevice approach', all need to 
introduce lots of redundant code, as they share the same IP code.

'DT approach' only needs minor change, brings great flexibility. It's 
only for Snapdragon boards, will not affect default firmware for X86 
platforms.

>>
>>>
>>>>
>>>> I'm really reluctant to bringing more DT usage into the PCIe space.
>>>> Especially if the user is able to swap cards.
>>>
>>> Understand your concern, automatic adaptation is always the best 
>>> choice. But
>>> it may not work for MSM boards, the PCIe card (non m.2) is 
>>> customized, which
>>> has special PMU control. User can't swap cards. And that's why power
>>> sequencing module was introduced.
>>
>> I know. Still, it's better to have less unnecessary data there for
>> autodiscoverable devices.
> 

We discussed internally, we have no other choice to enable NFA765 for 
non X86 boards. Could you please approve this 'DT' approach ?


> 
>>
>>>
>>>>
>>>>>>>> And if it is hard, can we please get to the _normal_ way how 
>>>>>>>> vendors
>>>>>>>> handle PCI hardware differences: the subvendor and subdevice? 
>>>>>>>> This is
>>>>>>>> a usual way to describe that the PCIe device is the same, but the
>>>>>>>> analog / tuner / RF / etc parts are different.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> We're going to have another problem to enable NFA765 m.2 card 
>>>>>>>>> for IoT
>>>>>>>>> platforms, which has different feature sets with X86 platform, 
>>>>>>>>> so also
>>>>>>>>> new firmware should be used. In this case, QCA2066 approach not 
>>>>>>>>> works.
>>>>>>>>> Seems DT approach is only choice.
>>>>>>>>>
>>>>>>>>> Could you advice ?
>>>>>>>>
>>>>>>>> Hmm, The first question is _why_ does it have different feature 
>>>>>>>> sets?
>>>>>>>> What exactly is different?
>>>>>>>
>>>>>>> Yeah, for IoT device will support SAP/TWT/UL-OFDMA/BSS color and 
>>>>>>> etc new
>>>>>>> features, and the existing x86 firmware mainly for STA mode.
>>>>>>>
>>>>>>> What if the user plugs a normal (laptop)
>>>>>>>> M.2 card into their IoT device?
>>>>>>>
>>>>>>> If there is no DT file to specify the firmware, IoT device will 
>>>>>>> load the
>>>>>>> default firmware, it will affect SAP and WiFi-6 advanced features.
>>>>>>
>>>>>> Can we get all those nice features into x86 world instead?
>>>>>
>>>>> It's out of our scope, we will not touch the existing stable firmware
>>>>> version, also it's not allowed.
>>>>
>>>> If it's not allowed for laptop cards, why is it allowed for IoT M.2
>>>> cards (which then can be perfectly installed into the laptop)?
>>>>
>>>
>>> Only specific IoT M.2 cards.
>>
>> But they are (or are going to be available) for purchase? And more
>> importantly, what prevents the user of a normal card to use "featureful"
>> firmware with the laptop card?
>>
> 
> We can't prevent the user to use 'featureful' firmware, but it's not 
> fully tested on the x86 platform, they need to bear the risk of 
> instability.
> 
> 
> 

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Dmitry Baryshkov]

On Mon, Oct 28, 2024 at 06:32:58PM +0800, Miaoqing Pan wrote:
> 
> 
> On 10/26/2024 10:31 AM, Miaoqing Pan wrote:
> > 
> > 
> > On 10/25/2024 11:27 PM, Dmitry Baryshkov wrote:
> > > On Fri, Oct 25, 2024 at 10:23:45PM +0800, Miaoqing Pan wrote:
> > > > 
> > > > 
> > > > On 10/25/2024 10:01 PM, Dmitry Baryshkov wrote:
> > > > > On Fri, Oct 25, 2024 at 09:43:04PM +0800, Miaoqing Pan wrote:
> > > > > > 
> > > > > > 
> > > > > > On 10/25/2024 8:21 PM, Dmitry Baryshkov wrote:
> > > > > > > On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan
> > > > > > > <quic_miaoqing@quicinc.com> wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
> > > > > > > > > On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan
> > > > > > > > > <quic_miaoqing@quicinc.com> wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
> > > > > > > > > > > On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
> > > > > > > > > > > > > On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
> > > > > > > > > > > > > > QCA6698AQ IP core is the
> > > > > > > > > > > > > > same as WCN6855 hw2.1,
> > > > > > > > > > > > > > but it has different RF,
> > > > > > > > > > > > > > IPA, thermal, RAM size
> > > > > > > > > > > > > > and etc, so new firmware
> > > > > > > > > > > > > > files used. This change
> > > > > > > > > > > > > > allows board DT files to
> > > > > > > > > > > > > > override the subdir of
> > > > > > > > > > > > > > the firmware directory
> > > > > > > > > > > > > > used to lookup the amss.bin and m3.bin.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I have slight concerns
> > > > > > > > > > > > > regarding the _board_ DT
> > > > > > > > > > > > > files overriding the
> > > > > > > > > > > > > subdir. This opens a can of
> > > > > > > > > > > > > worms, allowing per-board
> > > > > > > > > > > > > firmware sets,
> > > > > > > > > > > > > which (as far as I
> > > > > > > > > > > > > understand) is far from
> > > > > > > > > > > > > being what driver
> > > > > > > > > > > > > maintainers
> > > > > > > > > > > > > would like to see. This was
> > > > > > > > > > > > > required for ath10k-snoc
> > > > > > > > > > > > > devices, since
> > > > > > > > > > > > > firmware for those platforms
> > > > > > > > > > > > > is signed by the vendor keys
> > > > > > > > > > > > > and it is
> > > > > > > > > > > > > limited to a particular SoC
> > > > > > > > > > > > > or SoC family. For
> > > > > > > > > > > > > ath11k-pci there is no
> > > > > > > > > > > > > such limitation.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Would it be possible to use
> > > > > > > > > > > > > PCI subvendor / subdev to
> > > > > > > > > > > > > identify affected
> > > > > > > > > > > > > cards? PCI Revision? Any
> > > > > > > > > > > > > other way to identify the
> > > > > > > > > > > > > device?  Please
> > > > > > > > > > > > > provide lspci -nnvv for the
> > > > > > > > > > > > > affected device kind. Is
> > > > > > > > > > > > > there a way to
> > > > > > > > > > > > > identify the RF part somehow?
> > > > > > > > > > > > 
> > > > > > > > > > > > It's rather difficult, for
> > > > > > > > > > > > WCN685x, there are multiple
> > > > > > > > > > > > evolved subseries for
> > > > > > > > > > > > customized products. e.g.
> > > > > > > > > > > > 
> > > > > > > > > > > > QCA6698AQ/hw2.1
> > > > > > > > > > > > QCA2066/hw2.1
> > > > > > > > > > > > WCN6855/hw2.0/hw2.1
> > > > > > > > > > > > WCN6856/hw2.1
> > > > > > > > > > > > 
> > > > > > > > > > > > They have the same PCIe ID
> > > > > > > > > > > > (17cb:1103), the commit
> > > > > > > > > > > > 5dc9d1a55e95 ("wifi:
> > > > > > > > > > > > ath11k: add support for
> > > > > > > > > > > > QCA2066") reads
> > > > > > > > > > > > TCSR_SOC_HW_SUB_VER to enumerate
> > > > > > > > > > > > all
> > > > > > > > > > > > QCA2066 cards, it lacks of
> > > > > > > > > > > > flexibility, as the list will
> > > > > > > > > > > > become longer and
> > > > > > > > > > > > longer. But it's the only choice
> > > > > > > > > > > > for QCA2066, as it's customized
> > > > > > > > > > > > for X86
> > > > > > > > > > > > platform which without DT files.
> > > > > > > > > > > 
> > > > > > > > > > > I guess, this is closer to Kalle's
> > > > > > > > > > > expectations: being able to detect
> > > > > > > > > > > the hardware instead of adding DT properties.
> > > > > > > > > > > 
> > > > > > > > > > > > So for MSM those have DT file
> > > > > > > > > > > > platforms, like SA8775P-RIDE/
> > > > > > > > > > > > QCS8300-RIDE both
> > > > > > > > > > > > attached to QCA6698AQ, we can specify the correct firmware to
> > > > > > > > > > > > 'ath11k/WCN6855/hw2.1/qca6698aq',
> > > > > > > > > > > > so it's not per-board firmware,
> > > > > > > > > > > > it depends
> > > > > > > > > > > > on the type of the products(x86 windows, IoT products or AUTO).
> > > > > > > > > > > 
> > > > > > > > > > > No-no-no and no. The firmware used
> > > > > > > > > > > must not be specific to the product
> > > > > > > > > > > type.  This is what everybody here is trying to avoid. Please try
> > > > > > > > > > > following the QCA2066 approach
> > > > > > > > > > > instead. And note that it could use
> > > > > > > > > > > new
> > > > > > > > > > > TLD as it perfectly shows itself as a different hardware kind.
> > > > > > > > > > 
> > > > > > > > > > Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
> > > > > > > > > > revision register in BAR0 space, it's hard to maintain the list.
> > > > > > > > > 
> > > > > > > > > How is it so?
> > > > > > > > 
> > > > > > > > I think QCA2066 approach is just a workaround.
> > > > > > > > Different batches of chip
> > > > > > > > manufacture has different value in TCSR_SOC_HW_SUB_VER.
> > > > > > > 
> > > > > > > Ok. So, subvendor / subdevice?
> > > > > > 
> > > > > > The 'subvendor' is fixed to 0x17cb, so it's useless. And
> > > > > > I don't have enough
> > > > > > samples to decide to use 'subdevice', it's a risk for
> > > > > > existing devices.
> > > > > 
> > > > > What kind of risk? If subvendor is fixed, then it's Qualcomm who
> > > > > enumerates subdevices.
> > > > 
> > > > It's risk for there is not enough sample card to verify.
> > > > Subdevice is never
> > > > used by ath1xk drivers.
> > > 
> > > Oh, so it's just about development. I'd say, please discuss such risks
> > > with your management, unless Kalle or Jeff disagree with using the
> > > subdevice for identification.
> > 
> > Kalle & Jeff, any idea to introduce subdevice ?
> > 
> > 
> 
> Whether 'QCA2066 approach' or 'subdevice approach', all need to introduce
> lots of redundant code, as they share the same IP code.
> 
> 'DT approach' only needs minor change, brings great flexibility. It's only
> for Snapdragon boards, will not affect default firmware for X86 platforms.
> 
> > > 
> > > > 
> > > > > 
> > > > > I'm really reluctant to bringing more DT usage into the PCIe space.
> > > > > Especially if the user is able to swap cards.
> > > > 
> > > > Understand your concern, automatic adaptation is always the best
> > > > choice. But
> > > > it may not work for MSM boards, the PCIe card (non m.2) is
> > > > customized, which
> > > > has special PMU control. User can't swap cards. And that's why power
> > > > sequencing module was introduced.
> > > 
> > > I know. Still, it's better to have less unnecessary data there for
> > > autodiscoverable devices.
> > 
> 
> We discussed internally, we have no other choice to enable NFA765 for non
> X86 boards. Could you please approve this 'DT' approach ?

If you can't use subdevice approach for some reason, then we have no
other choice that I can imagine.

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Miaoqing Pan]

On 10/28/2024 9:45 PM, Dmitry Baryshkov wrote:
> On Mon, Oct 28, 2024 at 06:32:58PM +0800, Miaoqing Pan wrote:
>>
>>
>> On 10/26/2024 10:31 AM, Miaoqing Pan wrote:
>>>
>>>
>>> On 10/25/2024 11:27 PM, Dmitry Baryshkov wrote:
>>>> On Fri, Oct 25, 2024 at 10:23:45PM +0800, Miaoqing Pan wrote:
>>>>>
>>>>>
>>>>> On 10/25/2024 10:01 PM, Dmitry Baryshkov wrote:
>>>>>> On Fri, Oct 25, 2024 at 09:43:04PM +0800, Miaoqing Pan wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 10/25/2024 8:21 PM, Dmitry Baryshkov wrote:
>>>>>>>> On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan
>>>>>>>> <quic_miaoqing@quicinc.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan
>>>>>>>>>> <quic_miaoqing@quicinc.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/25/2024 2:01 PM, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Fri, Oct 25, 2024 at 10:56:02AM +0800, Miaoqing Pan wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/25/2024 3:39 AM, Dmitry Baryshkov wrote:
>>>>>>>>>>>>>> On Thu, Oct 24, 2024 at 08:25:14AM +0800, Miaoqing Pan wrote:
>>>>>>>>>>>>>>> QCA6698AQ IP core is the
>>>>>>>>>>>>>>> same as WCN6855 hw2.1,
>>>>>>>>>>>>>>> but it has different RF,
>>>>>>>>>>>>>>> IPA, thermal, RAM size
>>>>>>>>>>>>>>> and etc, so new firmware
>>>>>>>>>>>>>>> files used. This change
>>>>>>>>>>>>>>> allows board DT files to
>>>>>>>>>>>>>>> override the subdir of
>>>>>>>>>>>>>>> the firmware directory
>>>>>>>>>>>>>>> used to lookup the amss.bin and m3.bin.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have slight concerns
>>>>>>>>>>>>>> regarding the _board_ DT
>>>>>>>>>>>>>> files overriding the
>>>>>>>>>>>>>> subdir. This opens a can of
>>>>>>>>>>>>>> worms, allowing per-board
>>>>>>>>>>>>>> firmware sets,
>>>>>>>>>>>>>> which (as far as I
>>>>>>>>>>>>>> understand) is far from
>>>>>>>>>>>>>> being what driver
>>>>>>>>>>>>>> maintainers
>>>>>>>>>>>>>> would like to see. This was
>>>>>>>>>>>>>> required for ath10k-snoc
>>>>>>>>>>>>>> devices, since
>>>>>>>>>>>>>> firmware for those platforms
>>>>>>>>>>>>>> is signed by the vendor keys
>>>>>>>>>>>>>> and it is
>>>>>>>>>>>>>> limited to a particular SoC
>>>>>>>>>>>>>> or SoC family. For
>>>>>>>>>>>>>> ath11k-pci there is no
>>>>>>>>>>>>>> such limitation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would it be possible to use
>>>>>>>>>>>>>> PCI subvendor / subdev to
>>>>>>>>>>>>>> identify affected
>>>>>>>>>>>>>> cards? PCI Revision? Any
>>>>>>>>>>>>>> other way to identify the
>>>>>>>>>>>>>> device?  Please
>>>>>>>>>>>>>> provide lspci -nnvv for the
>>>>>>>>>>>>>> affected device kind. Is
>>>>>>>>>>>>>> there a way to
>>>>>>>>>>>>>> identify the RF part somehow?
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's rather difficult, for
>>>>>>>>>>>>> WCN685x, there are multiple
>>>>>>>>>>>>> evolved subseries for
>>>>>>>>>>>>> customized products. e.g.
>>>>>>>>>>>>>
>>>>>>>>>>>>> QCA6698AQ/hw2.1
>>>>>>>>>>>>> QCA2066/hw2.1
>>>>>>>>>>>>> WCN6855/hw2.0/hw2.1
>>>>>>>>>>>>> WCN6856/hw2.1
>>>>>>>>>>>>>
>>>>>>>>>>>>> They have the same PCIe ID
>>>>>>>>>>>>> (17cb:1103), the commit
>>>>>>>>>>>>> 5dc9d1a55e95 ("wifi:
>>>>>>>>>>>>> ath11k: add support for
>>>>>>>>>>>>> QCA2066") reads
>>>>>>>>>>>>> TCSR_SOC_HW_SUB_VER to enumerate
>>>>>>>>>>>>> all
>>>>>>>>>>>>> QCA2066 cards, it lacks of
>>>>>>>>>>>>> flexibility, as the list will
>>>>>>>>>>>>> become longer and
>>>>>>>>>>>>> longer. But it's the only choice
>>>>>>>>>>>>> for QCA2066, as it's customized
>>>>>>>>>>>>> for X86
>>>>>>>>>>>>> platform which without DT files.
>>>>>>>>>>>>
>>>>>>>>>>>> I guess, this is closer to Kalle's
>>>>>>>>>>>> expectations: being able to detect
>>>>>>>>>>>> the hardware instead of adding DT properties.
>>>>>>>>>>>>
>>>>>>>>>>>>> So for MSM those have DT file
>>>>>>>>>>>>> platforms, like SA8775P-RIDE/
>>>>>>>>>>>>> QCS8300-RIDE both
>>>>>>>>>>>>> attached to QCA6698AQ, we can specify the correct firmware to
>>>>>>>>>>>>> 'ath11k/WCN6855/hw2.1/qca6698aq',
>>>>>>>>>>>>> so it's not per-board firmware,
>>>>>>>>>>>>> it depends
>>>>>>>>>>>>> on the type of the products(x86 windows, IoT products or AUTO).
>>>>>>>>>>>>
>>>>>>>>>>>> No-no-no and no. The firmware used
>>>>>>>>>>>> must not be specific to the product
>>>>>>>>>>>> type.  This is what everybody here is trying to avoid. Please try
>>>>>>>>>>>> following the QCA2066 approach
>>>>>>>>>>>> instead. And note that it could use
>>>>>>>>>>>> new
>>>>>>>>>>>> TLD as it perfectly shows itself as a different hardware kind.
>>>>>>>>>>>
>>>>>>>>>>> Actually, TCSR_SOC_HW_SUB_VER is not SOC register, it's a TLMM hw
>>>>>>>>>>> revision register in BAR0 space, it's hard to maintain the list.
>>>>>>>>>>
>>>>>>>>>> How is it so?
>>>>>>>>>
>>>>>>>>> I think QCA2066 approach is just a workaround.
>>>>>>>>> Different batches of chip
>>>>>>>>> manufacture has different value in TCSR_SOC_HW_SUB_VER.
>>>>>>>>
>>>>>>>> Ok. So, subvendor / subdevice?
>>>>>>>
>>>>>>> The 'subvendor' is fixed to 0x17cb, so it's useless. And
>>>>>>> I don't have enough
>>>>>>> samples to decide to use 'subdevice', it's a risk for
>>>>>>> existing devices.
>>>>>>
>>>>>> What kind of risk? If subvendor is fixed, then it's Qualcomm who
>>>>>> enumerates subdevices.
>>>>>
>>>>> It's risk for there is not enough sample card to verify.
>>>>> Subdevice is never
>>>>> used by ath1xk drivers.
>>>>
>>>> Oh, so it's just about development. I'd say, please discuss such risks
>>>> with your management, unless Kalle or Jeff disagree with using the
>>>> subdevice for identification.
>>>
>>> Kalle & Jeff, any idea to introduce subdevice ?
>>>
>>>
>>
>> Whether 'QCA2066 approach' or 'subdevice approach', all need to introduce
>> lots of redundant code, as they share the same IP code.
>>
>> 'DT approach' only needs minor change, brings great flexibility. It's only
>> for Snapdragon boards, will not affect default firmware for X86 platforms.
>>
>>>>
>>>>>
>>>>>>
>>>>>> I'm really reluctant to bringing more DT usage into the PCIe space.
>>>>>> Especially if the user is able to swap cards.
>>>>>
>>>>> Understand your concern, automatic adaptation is always the best
>>>>> choice. But
>>>>> it may not work for MSM boards, the PCIe card (non m.2) is
>>>>> customized, which
>>>>> has special PMU control. User can't swap cards. And that's why power
>>>>> sequencing module was introduced.
>>>>
>>>> I know. Still, it's better to have less unnecessary data there for
>>>> autodiscoverable devices.
>>>
>>
>> We discussed internally, we have no other choice to enable NFA765 for non
>> X86 boards. Could you please approve this 'DT' approach ?
> 
> If you can't use subdevice approach for some reason, then we have no
> other choice that I can imagine.
> 

A new patch was submitted: 
https://lore.kernel.org/linux-wireless/20241031000541.3331606-1-quic_miaoqing@quicinc.com/. 
This patch will add QCA6698AQ support, which follows the approach done 
in commit 5dc9d1a55e95 ("wifi: ath11k: add support for QCA2066"), 
enumerates the subversion number to identify the specific card.

But there is still a problem enabling NFA765 m.2 card for IoT platforms, 
which requires ath11k to support board-specific firmware overrides.

Re: [PATCH v2 2/2] wifi: ath11k: support board-specific firmware overrides

[Kalle Valo]

Miaoqing Pan <quic_miaoqing@quicinc.com> writes:

>>>>>> Understand your concern, automatic adaptation is always the best
>>>>>> choice. But
>>>>>> it may not work for MSM boards, the PCIe card (non m.2) is
>>>>>> customized, which
>>>>>> has special PMU control. User can't swap cards. And that's why power
>>>>>> sequencing module was introduced.
>>>>>
>>>>> I know. Still, it's better to have less unnecessary data there for
>>>>> autodiscoverable devices.
>>>>
>>>
>>> We discussed internally, we have no other choice to enable NFA765 for non
>>> X86 boards. Could you please approve this 'DT' approach ?
>> If you can't use subdevice approach for some reason, then we have no
>> other choice that I can imagine.
>> 
>
> A new patch was submitted:
> https://lore.kernel.org/linux-wireless/20241031000541.3331606-1-quic_miaoqing@quicinc.com/.
> This patch will add QCA6698AQ support, which follows the approach done
> in commit 5dc9d1a55e95 ("wifi: ath11k: add support for QCA2066"),
> enumerates the subversion number to identify the specific card.
>
> But there is still a problem enabling NFA765 m.2 card for IoT
> platforms, which requires ath11k to support board-specific firmware
> overrides.

So there are multiple different hardware you want to support? This is
very confusing and the commit message does not really tell anything
about those. Can you list _all_ the hardware you want to support and
what firmware it needs?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches