[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 at 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 at 1c00000/pcie at 0/wifi at 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.
>