On Wed, 3 Apr 2024 at 16:05, Marc Gonzalez <mgonza...@freebox.fr> wrote: > > On 02/04/2024 17:55, Dmitry Baryshkov wrote: > > > On Tue, 2 Apr 2024 at 18:31, Marc Gonzalez wrote: > > > >> So, if I understand correctly, I take this to mean that I should: > >> > >> 1) DELETE the qcom,no-msa-ready-indicator boolean property, > >> 2) ADD a "qcom,msm8998-wifi" (name OK?) compatible, > > > > I'd say, this is not correct. There is no "msm8998-wifi". > > Can you explain what you mean by: > 'There is no "msm8998-wifi".' ? > > Do you mean that: this compatible string does not exist? > (I am proposing that it be created.) > > Or do you mean that: "msm8998-wifi" is a bad name?
I mean, it is qcom,wcn3990-wifi, because the chip is wcn3990. > And these strings in ath11k: > > Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml: - > qcom,ipq8074-wifi > Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml: - > qcom,ipq6018-wifi > Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml: - > qcom,wcn6750-wifi > Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml: - > qcom,ipq5018-wifi I must admit, I don't know the IPQ product naming (it well might be that it is both the name of the SoC and the WiFI SoC). > > > I'd say, we should take a step back and actually verify how this was > > handled in the vendor kernel. > > In our commercial product, we use the ath10k driver in the vendor kernel > (v4.4 r38-rel). I see. > It looks like Jeff has already performed the code analysis > wrt vendor vs mainline (including user-space tools). >From his message it looks like we are expected to get MSA READY even on >msm8998. -- With best wishes Dmitry
