| Message ID | 0914f96e-fcfd-4088-924a-fc1991bce75f@freebox.fr (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | Work around missing MSA_READY indicator for msm8998 devices | expand |
On 4/29/2024 7:07 AM, Marc Gonzalez wrote: > The ath10k driver waits for an "MSA_READY" indicator > to complete initialization. If the indicator is not > received, then the device remains unusable. > > cf. ath10k_qmi_driver_event_work() > > Several msm8998-based devices are affected by this issue. > Oddly, it seems safe to NOT wait for the indicator, and > proceed immediately when QMI_EVENT_SERVER_ARRIVE. > > Jeff Johnson wrote: > > The feedback I received was "it might be ok to change all ath10k qmi > to skip waiting for msa_ready", and it was pointed out that ath11k > (and ath12k) do not wait for it. > > However with so many deployed devices, "might be ok" isn't a strong > argument for changing the default behavior. > > cf. also > https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN > > Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
On 29/04/2024 16:07, Marc Gonzalez wrote: > The ath10k driver waits for an "MSA_READY" indicator > to complete initialization. If the indicator is not > received, then the device remains unusable. > > cf. ath10k_qmi_driver_event_work() > > Several msm8998-based devices are affected by this issue. > Oddly, it seems safe to NOT wait for the indicator, and > proceed immediately when QMI_EVENT_SERVER_ARRIVE. > > Jeff Johnson wrote: > > The feedback I received was "it might be ok to change all ath10k qmi > to skip waiting for msa_ready", and it was pointed out that ath11k > (and ath12k) do not wait for it. > > However with so many deployed devices, "might be ok" isn't a strong > argument for changing the default behavior. > > cf. also > https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN > > Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> > --- > arch/arm64/boot/dts/qcom/msm8998.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi > index 67b8374ddf02f..4e6245095adfc 100644 > --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi > +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi > @@ -3234,6 +3234,7 @@ wifi: wifi@18800000 { > iommus = <&anoc2_smmu 0x1900>, > <&anoc2_smmu 0x1901>; > qcom,snoc-host-cap-8bit-quirk; > + qcom,no-msa-ready-indicator; > }; > }; > }; Bjorn, This patch is supposed to go through your tree, right? Regards
On 5/6/24 12:39, Marc Gonzalez wrote: > On 29/04/2024 16:07, Marc Gonzalez wrote: > >> The ath10k driver waits for an "MSA_READY" indicator >> to complete initialization. If the indicator is not >> received, then the device remains unusable. >> >> cf. ath10k_qmi_driver_event_work() >> >> Several msm8998-based devices are affected by this issue. >> Oddly, it seems safe to NOT wait for the indicator, and >> proceed immediately when QMI_EVENT_SERVER_ARRIVE. >> >> Jeff Johnson wrote: >> >> The feedback I received was "it might be ok to change all ath10k qmi >> to skip waiting for msa_ready", and it was pointed out that ath11k >> (and ath12k) do not wait for it. >> >> However with so many deployed devices, "might be ok" isn't a strong >> argument for changing the default behavior. >> >> cf. also >> https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN >> >> Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> >> --- >> arch/arm64/boot/dts/qcom/msm8998.dtsi | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi >> index 67b8374ddf02f..4e6245095adfc 100644 >> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi >> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi >> @@ -3234,6 +3234,7 @@ wifi: wifi@18800000 { >> iommus = <&anoc2_smmu 0x1900>, >> <&anoc2_smmu 0x1901>; >> qcom,snoc-host-cap-8bit-quirk; >> + qcom,no-msa-ready-indicator; >> }; >> }; >> }; > > > Bjorn, > > This patch is supposed to go through your tree, right? Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Konrad
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi index 67b8374ddf02f..4e6245095adfc 100644 --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi @@ -3234,6 +3234,7 @@ wifi: wifi@18800000 { iommus = <&anoc2_smmu 0x1900>, <&anoc2_smmu 0x1901>; qcom,snoc-host-cap-8bit-quirk; + qcom,no-msa-ready-indicator; }; }; };
The ath10k driver waits for an "MSA_READY" indicator to complete initialization. If the indicator is not received, then the device remains unusable. cf. ath10k_qmi_driver_event_work() Several msm8998-based devices are affected by this issue. Oddly, it seems safe to NOT wait for the indicator, and proceed immediately when QMI_EVENT_SERVER_ARRIVE. Jeff Johnson wrote: The feedback I received was "it might be ok to change all ath10k qmi to skip waiting for msa_ready", and it was pointed out that ath11k (and ath12k) do not wait for it. However with so many deployed devices, "might be ok" isn't a strong argument for changing the default behavior. cf. also https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> --- arch/arm64/boot/dts/qcom/msm8998.dtsi | 1 + 1 file changed, 1 insertion(+)