On Fri, 25 Oct 2024 at 15:03, Miaoqing Pan <quic_miaoqing@xxxxxxxxxxx> wrote:
>
>
>
> On 10/25/2024 6:20 PM, Dmitry Baryshkov wrote:
> > On Fri, 25 Oct 2024 at 10:23, Miaoqing Pan <quic_miaoqing@xxxxxxxxxxx> 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
