| Message ID | 54ac2295-36b4-49fc-9583-a10db8d9d5d6@freebox.fr |
|---|---|
| State | New |
| Headers | show |
| Series | Work around missing MSA_READY indicator for msm8998 devices | expand |
On Mon, Apr 29, 2024 at 04:04:51PM +0200, 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. > > Kalle Valo first suggested setting a bit in firmware-5.bin to trigger > work-around in the driver. However, firmware-5.bin is parsed too late. > So we are stuck with a DT property. > > Signed-off-by: Pierre-Hugues Husson <phhusson@freebox.fr> > Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> This says "Pierre-Hugues certifies the origin of the patch" then "Marc certifies the origin of the patch". This would have to imply that Pierre-Hugues authored the patch, but you're listed as the author... Perhaps a suitable answer to this question would be to add "Co-developed-by: Pierre-Hugues ..." above his s-o-b, which implies that the two of you jointly came up with this and both certify the origin. Other than that, I think this looks good, so please upon addressing this problem feel free to add my: Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Regards, Bjorn > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml > index 9b3ef4bc37325..9070a41f7fc07 100644 > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml > @@ -122,6 +122,11 @@ properties: > Whether to skip executing an SCM call that reassigns the memory > region ownership. > > + qcom,no-msa-ready-indicator: > + type: boolean > + description: > + Don't wait for MSA_READY indicator to complete init. > + > qcom,smem-states: > $ref: /schemas/types.yaml#/definitions/phandle-array > description: State bits used by the AP to signal the WLAN Q6. > -- > 2.34.1 >
Bjorn Andersson <quic_bjorande@quicinc.com> writes: > On Mon, Apr 29, 2024 at 04:04:51PM +0200, 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. >> >> Kalle Valo first suggested setting a bit in firmware-5.bin to trigger >> work-around in the driver. However, firmware-5.bin is parsed too late. >> So we are stuck with a DT property. >> >> Signed-off-by: Pierre-Hugues Husson <phhusson@freebox.fr> >> Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> > > This says "Pierre-Hugues certifies the origin of the patch" then "Marc > certifies the origin of the patch". This would have to imply that > Pierre-Hugues authored the patch, but you're listed as the author... > > Perhaps a suitable answer to this question would be to add > "Co-developed-by: Pierre-Hugues ..." above his s-o-b, which implies that > the two of you jointly came up with this and both certify the origin. BTW I can add that in the pending branch, no need to resend because of this. Just need guidance from Marc. > Other than that, I think this looks good, so please upon addressing this > problem feel free to add my: > > Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Thanks, I'll then add this as well.
On Mon, 29 Apr 2024 16:04:51 +0200, 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. > > Kalle Valo first suggested setting a bit in firmware-5.bin to trigger > work-around in the driver. However, firmware-5.bin is parsed too late. > So we are stuck with a DT property. > > Signed-off-by: Pierre-Hugues Husson <phhusson@freebox.fr> > Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > Acked-by: Rob Herring (Arm) <robh@kernel.org>
Marc Gonzalez <mgonzalez@freebox.fr> 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. > > Kalle Valo first suggested setting a bit in firmware-5.bin to trigger > work-around in the driver. However, firmware-5.bin is parsed too late. > So we are stuck with a DT property. > > Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> > Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> > Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> > Acked-by: Rob Herring (Arm) <robh@kernel.org> > Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> 2 patches applied to ath-next branch of ath.git, thanks. 71b6e321e302 dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop 6d67d18014a8 wifi: ath10k: do not always wait for MSA_READY indicator
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml index 9b3ef4bc37325..9070a41f7fc07 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -122,6 +122,11 @@ properties: Whether to skip executing an SCM call that reassigns the memory region ownership. + qcom,no-msa-ready-indicator: + type: boolean + description: + Don't wait for MSA_READY indicator to complete init. + qcom,smem-states: $ref: /schemas/types.yaml#/definitions/phandle-array description: State bits used by the AP to signal the WLAN Q6.