On Mon, 4 Mar 2024 at 22:17, Conor Dooley <co...@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 <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.
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
