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

[Conor Dooley]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20240304/380f1223/attachment.sig>