[PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop

[Dmitry Baryshkov]

On Mon, 4 Mar 2024 at 22:17, Conor Dooley <conor at kernel.org> wrote:
>
> On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 4 Mar 2024 at 21:46, Conor Dooley <conor at kernel.org> wrote:
> > > On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> > > > On Mon, 4 Mar 2024 at 21:34, Conor Dooley <conor at kernel.org> wrote:
> > > > > On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
>
> > > > > > Thus, anyone porting an msm8998 board to mainline would automatically
> > > > > > get the work-around, without having to hunt down the feature bit,
> > > > > > and tweak the FW files.
> > > > >
> > > > > How come the root node comes into this, don't you have a soc-specific
> > > > > compatible for the integration on this SoC?
> > > >
> > > > No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
> > >
> > > Suitability of either fix aside, can you explain this to me? Is the "WiFi
> > > SoC" accessible from the "main SoC" at a regular MMIO address? The
> > > "ath10k" compatible says it is SDIO-based & the other two compatibles
> > > seem to be MMIO.
> >
> > Yes, this is correct. MSM8996 uses PCI to access WiFi chip, MSM8998 uses MMIO.
>
> Thanks.
>
> A SoC-specific compatible sounds like it would be suitable in that case
> then, to deal with integration quirks for that specific SoC? I usually
> leave the ins and outs of these qcom SoCs to Krzysztof, but I can't help
> but wanna know what the justification is here for not using one.

We can probably start with "historically established" here. From the
hardware point of view msm8998, sdm845 and several other chipsets use
a variant of the same wcn3990 WiFi+BT chip. The actual issue is in the
DSP firmware, so it can be handled via the firmware-related means.

On the other hand, I see qcom,snoc-host-cap-8bit-quirk property, so
one can use DT properties to describe the issue.

-- 
With best wishes
Dmitry