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