On Fri, Oct 25, 2024 at 10:23:45PM +0800, Miaoqing Pan wrote:
>
>
> On 10/25/2024 10:01 PM, Dmitry Baryshkov wrote:
> > 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.
>
> It's risk for there is not enough sample card to verify. Subdevice is never
> used by ath1xk drivers.
Oh, so it's just about development. I'd say, please discuss such risks
with your management, unless Kalle or Jeff disagree with using the
subdevice for identification.
>
> >
> > I'm really reluctant to bringing more DT usage into the PCIe space.
> > Especially if the user is able to swap cards.
>
> Understand your concern, automatic adaptation is always the best choice. But
> it may not work for MSM boards, the PCIe card (non m.2) is customized, which
> has special PMU control. User can't swap cards. And that's why power
> sequencing module was introduced.
I know. Still, it's better to have less unnecessary data there for
autodiscoverable 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.
> >
> > 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)?
> >
>
> Only specific IoT M.2 cards.
But they are (or are going to be available) for purchase? And more
importantly, what prevents the user of a normal card to use "featureful"
firmware with the laptop card?
--
With best wishes
Dmitry
