| Message ID | 84f20fb5-5d48-419c-8eff-d7044afb81c0@freebox.fr (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Work around missing MSA_READY indicator for msm8998 devices | expand |
On 28/03/2024 18:36, 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. > This is v2, so where is the changelog? Best regards, Krzysztof
On 30/03/2024 19:20, Krzysztof Kozlowski wrote: > On 28/03/2024 18:36, 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. >> > > This is v2, so where is the changelog? Expecting reviewer to dig previous discussions will not help your case. It helps reviewers if you provide necessary information, like resolution of previous discussion in the changelog. I dig the previous discussion, since you did not mention it here, and it seems you entirely ignored its outcome. That's not a DT property. NAK, sorry. Please go back to v1 and read the comments you got there. Best regards, Krzysztof
On 30/03/2024 19:23, Krzysztof Kozlowski wrote: > On 30/03/2024 19:20, Krzysztof Kozlowski wrote: > >> On 28/03/2024 18:36, 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. >> >> This is v2, so where is the changelog? > > Expecting reviewer to dig previous discussions will not help your case. > It helps reviewers if you provide necessary information, like resolution > of previous discussion in the changelog. > > I dig the previous discussion, since you did not mention it here, and it > seems you entirely ignored its outcome. That's not a DT property. > > NAK, sorry. Please go back to v1 and read the comments you got there. My apologies for omitting the changelog. And I don't blame you for missing the thread's resolution, since I made a bit of a mess of it with my various messages. The firmware-5.bin approach was deemed DOA since these files are parsed too late with respect to the required work-around. Thus, we went back to either DT or a to-be-written system used in the vendor driver. Jeff Johnson (one of the maintainers) concluded with: "But I'm OK with the DT option as well. Kalle?" Thus, I spun v2 to get Kalle's Ack, and more crucially to give a heads-up to the msm8998 users my patch would impact. Regards
On 30/03/2024 23:04, Marc Gonzalez wrote: > On 30/03/2024 19:23, Krzysztof Kozlowski wrote: > >> On 30/03/2024 19:20, Krzysztof Kozlowski wrote: >> >>> On 28/03/2024 18:36, 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. >>> >>> This is v2, so where is the changelog? >> >> Expecting reviewer to dig previous discussions will not help your case. >> It helps reviewers if you provide necessary information, like resolution >> of previous discussion in the changelog. >> >> I dig the previous discussion, since you did not mention it here, and it >> seems you entirely ignored its outcome. That's not a DT property. >> >> NAK, sorry. Please go back to v1 and read the comments you got there. > > My apologies for omitting the changelog. > > And I don't blame you for missing the thread's resolution, > since I made a bit of a mess of it with my various messages. > > The firmware-5.bin approach was deemed DOA since these files > are parsed too late with respect to the required work-around. > Thus, we went back to either DT or a to-be-written system used > in the vendor driver. Then please mention it briefly in the commit msg. Explain there why such implementation is the correct way to solve your problem. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml index 9b3ef4bc37325..1680604cd1b7e 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -122,6 +122,13 @@ properties: Whether to skip executing an SCM call that reassigns the memory region ownership. + qcom,no-msa-ready-indicator: + type: boolean + description: + The driver waits for an MSA_READY indicator to complete init. + If the indicator is not received, interface remains unusable. + Pretending we received the indicator works around the issue. + qcom,smem-states: $ref: /schemas/types.yaml#/definitions/phandle-array description: State bits used by the AP to signal the WLAN Q6.