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