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