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