Conor Dooley writes:
> On Thu, Apr 25, 2024 at 06:42:16PM +0300, Kalle Valo wrote:
>
>> Marc Gonzalez writes:
>>
>> > On 25/04/2024 11:42, Kalle Valo wrote:
>> >
>> >> Marc Gonzalez wrote:
>> >>
>> >>> Do you prefer:
>> >>>
>> >>> Option A = never waiting for the MSA_READY indicator for ANYONE
On Thu, Apr 25, 2024 at 06:42:16PM +0300, Kalle Valo wrote:
> Marc Gonzalez writes:
>
> > On 25/04/2024 11:42, Kalle Valo wrote:
> >
> >> Marc Gonzalez wrote:
> >>
> >>> Do you prefer:
> >>>
> >>> Option A = never waiting for the MSA_READY indicator for ANYONE
> >>> Option B = not waiting for th
Marc Gonzalez writes:
> On 25/04/2024 11:42, Kalle Valo wrote:
>
>> Marc Gonzalez wrote:
>>
>>> Do you prefer:
>>>
>>> Option A = never waiting for the MSA_READY indicator for ANYONE
>>> Option B = not waiting for the MSA_READY indicator when
>>> qcom,no-msa-ready-indicator is defined
>>> Option
On 25/04/2024 11:42, Kalle Valo wrote:
> Marc Gonzalez wrote:
>
>> Do you prefer:
>>
>> Option A = never waiting for the MSA_READY indicator for ANYONE
>> Option B = not waiting for the MSA_READY indicator when
>> qcom,no-msa-ready-indicator is defined
>> Option C = not waiting for the MSA_READY
Marc Gonzalez writes:
> On 04/04/2024 17:28, Kalle Valo wrote:
>
>> Marc Gonzalez wrote:
>>
>>> On 04/04/2024 13:57, Kalle Valo wrote:
>>>
Dmitry Baryshkov wrote:
> I'd say, we should take a step back and actually verify how this was
> handled in the vendor kernel.
On
On 04/04/2024 17:28, Kalle Valo wrote:
> Marc Gonzalez wrote:
>
>> On 04/04/2024 13:57, Kalle Valo wrote:
>>
>>> Dmitry Baryshkov wrote:
>>>
I'd say, we should take a step back and actually verify how this was
handled in the vendor kernel.
>>>
>>> One comment related to this: usually ve
Marc Gonzalez writes:
> On 04/04/2024 13:57, Kalle Valo wrote:
>
>> Dmitry Baryshkov wrote:
>>
>>> I'd say, we should take a step back and actually verify how this was
>>> handled in the vendor kernel.
>>
>> One comment related to this: usually vendor driver and firmware branches
>> go "hand in
On Thu, 4 Apr 2024 at 15:30, Marc Gonzalez wrote:
>
> On 04/04/2024 13:57, Kalle Valo wrote:
>
> > Dmitry Baryshkov wrote:
> >
> >> I'd say, we should take a step back and actually verify how this was
> >> handled in the vendor kernel.
> >
> > One comment related to this: usually vendor driver and
On 04/04/2024 13:57, Kalle Valo wrote:
> Dmitry Baryshkov wrote:
>
>> I'd say, we should take a step back and actually verify how this was
>> handled in the vendor kernel.
>
> One comment related to this: usually vendor driver and firmware branches
> go "hand in hand", meaning that a version of
Dmitry Baryshkov writes:
>> 3) ADD that compatible to the wifi node in msm8998.dtsi
>>compatible = "qcom,wcn3990-wifi", "qcom,msm8998-wifi";
>> 4) In the driver, set qmi->fake_msa_ready_indicator to true if we
>> detect "qcom,msm8998-wifi"
>>
>> And this approach would be acceptable to both a
On 03/04/2024 16:12, Dmitry Baryshkov wrote:
> From [Jeff's] message it looks like we are expected to get MSA READY even on
> msm8998.
This is the code we're using:
https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/drivers/net/wireless/ath/ath10k/qmi.c
On 03/04/2024 15:05, Marc Gonzalez 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
On Wed, 3 Apr 2024 at 16:05, Marc Gonzalez 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
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
On 4/2/2024 11:25 AM, Alexey Minnekhanov wrote:
>
>
> On 02.04.2024 18:55, Dmitry Baryshkov wrote:
>> I'd say, we should take a step back and actually verify how this was
>> handled in the vendor kernel.
>
>
> AFAIK there is no such thing in vendor kernel driver for this, as
> this startup proc
On Tue, 2 Apr 2024 at 21:25, Alexey Minnekhanov
wrote:
>
>
>
> On 02.04.2024 18:55, Dmitry Baryshkov wrote:
> > I'd say, we should take a step back and actually verify how this was
> > handled in the vendor kernel.
>
>
> AFAIK there is no such thing in vendor kernel driver for this, as
> this star
On Tue, 2 Apr 2024 at 21:22, Jeff Johnson wrote:
>
> On 4/2/2024 8:55 AM, Dmitry Baryshkov wrote:
> > I'd say, we should take a step back and actually verify how this was
> > handled in the vendor kernel.
>
> (error handling and other non-QMI code removed from the following for
> readability)
>
>
On 02.04.2024 18:55, Dmitry Baryshkov wrote:
I'd say, we should take a step back and actually verify how this was
handled in the vendor kernel.
AFAIK there is no such thing in vendor kernel driver for this, as
this startup procedure is likely handled entirely in userspace in
cnss_daemon.
B
On 4/2/2024 8:55 AM, Dmitry Baryshkov wrote:
> I'd say, we should take a step back and actually verify how this was
> handled in the vendor kernel.
(error handling and other non-QMI code removed from the following for
readability)
In ath10k we unconditionally call the following in
ath10k_qmi_eve
On Tue, 2 Apr 2024 at 18:31, Marc Gonzalez wrote:
>
> On 02/04/2024 16:34, Konrad Dybcio wrote:
>
> > On 30.03.2024 7:25 PM, Krzysztof Kozlowski wrote:
> >
> >> On 28/03/2024 18:39, Marc Gonzalez wrote:
> >>
> >>> The ath10k driver waits for an "MSA_READY" indicator
> >>> to complete initializatio
On 02/04/2024 16:34, Konrad Dybcio wrote:
> On 30.03.2024 7:25 PM, Krzysztof Kozlowski wrote:
>
>> On 28/03/2024 18:39, 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 unu
On 30.03.2024 7:25 PM, Krzysztof Kozlowski wrote:
> On 28/03/2024 18:39, 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()
>>
>>
On 28/03/2024 18:39, 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.
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
24 matches
Mail list logo
