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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
> On Mon, 4 Mar 2024 at 21:46, Conor Dooley <conor@xxxxxxxxxx> 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@xxxxxxxxxx> 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.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux