On Mon, Oct 28, 2024 at 06:32:58PM +0800, Miaoqing Pan wrote:
>
>
> On 10/26/2024 10:31 AM, Miaoqing Pan wrote:
> >
> >
> > On 10/25/2024 11:27 PM, Dmitry Baryshkov wrote:
> > > 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.
> >
> > Kalle & Jeff, any idea to introduce subdevice ?
> >
> >
>
> Whether 'QCA2066 approach' or 'subdevice approach', all need to introduce
> lots of redundant code, as they share the same IP code.
>
> 'DT approach' only needs minor change, brings great flexibility. It's only
> for Snapdragon boards, will not affect default firmware for X86 platforms.
>
> > >
> > > >
> > > > >
> > > > > 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.
> >
>
> We discussed internally, we have no other choice to enable NFA765 for non
> X86 boards. Could you please approve this 'DT' approach ?
If you can't use subdevice approach for some reason, then we have no
other choice that I can imagine.
--
With best wishes
Dmitry
