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 ?
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?
We can't prevent the user to use 'featureful' firmware, but it's not
fully tested on the x86 platform, they need to bear the risk of
instability.
