On 26/03/2024 21:21, Jeff Johnson wrote:
> On 3/26/2024 10:51 AM, Dmitry Baryshkov wrote:
>
>> On Tue, 26 Mar 2024 at 19:45, Marc Gonzalez wrote:
>>>
>>> [ It has been pointed out to me that the previous message was unclear. ]
>>> [ Below is my 2nd attempt at a clearer message. ]
>>>
>>>
On 3/26/2024 10:51 AM, Dmitry Baryshkov wrote:
> On Tue, 26 Mar 2024 at 19:45, Marc Gonzalez wrote:
>>
>> [ It has been pointed out to me that the previous message was unclear. ]
>> [ Below is my 2nd attempt at a clearer message. ]
>>
>> Problem: firmware-5.bin has not been parsed yet when we
On Tue, 26 Mar 2024 at 19:45, Marc Gonzalez wrote:
>
> [ It has been pointed out to me that the previous message was unclear. ]
> [ Below is my 2nd attempt at a clearer message. ]
>
> Problem: firmware-5.bin has not been parsed yet when we have to handle
> the ATH10K_QMI_EVENT_SERVER_ARRIVE case,
[ It has been pointed out to me that the previous message was unclear. ]
[ Below is my 2nd attempt at a clearer message. ]
Problem: firmware-5.bin has not been parsed yet when we have to handle
the ATH10K_QMI_EVENT_SERVER_ARRIVE case, so we can't rely on feature bits
to work around the lack of
On 13/03/2024 16:09, Marc Gonzalez wrote:
> I'm still not quite sure where linux-firmware.git fits into all this.
https://packages.debian.org/sid/firmware-atheros
As far as I understand, Debian package "firmware-atheros (20230625-2)" includes:
ath10k/WCN3990/hw1.0/firmware-5.bin
On 19/03/2024 15:39, Marc Gonzalez wrote:
> What a dweeb... bitten by the very bug I'm supposed to fix :(
Is there a kernel bootcmd to force the kernel to probe devices sequentially,
in order to get (roughly) deterministic kernel logs I can run diff on?
(Even if it slows down boot by a factor of
On 19/03/2024 14:47, Marc Gonzalez wrote:
> [ 15.255763] remoteproc remoteproc0: powering up 408.remoteproc
> [ 15.263925] remoteproc remoteproc0: Booting fw image mba.mbn, size 234152
> [ 15.277228] ath10k_snoc 1880.wifi: received modem starting event
> [ 15.370471] qcom-q6v5-mss
On 18/03/2024 17:56, Marc Gonzalez wrote:
> Hmm, I don't see protection-domain-mapper running...
>
> Feb 27 17:44:01 venus pd-mapper[308]: no pd maps available
> Feb 27 17:44:01 venus pd-mapper[328]: no pd maps available
> Feb 27 17:44:02 venus pd-mapper[345]: no pd maps available
> Feb 27
On 13/03/2024 16:53, Dmitry Baryshkov wrote:
> Do you have pd-mapper, rmtfs and tqftpserv running? You also need to
> have wlanmdsp.mbn in the same directory as modem.mbn for your platform
> (see how this is handled for sdm845).
> If these points are implemented and you still don't have the wlan,
On 3/14/2024 10:52 AM, Marc Gonzalez wrote:
> Is this the line you're after:
> [ 32.367011] ath10k_snoc 1880.wifi: qmi fw_version 0x100204b2
> fw_build_timestamp 2019-09-04 03:01 fw_build_id
> QC_IMAGE_VERSION_STRING=WLAN.HL.1.0-01202-QCAHLSWMTPLZ-1.221523.2
perfect
> Is it legal for my
On 14/03/2024 15:33, Jeff Johnson wrote:
> On 3/7/2024 8:46 AM, Jeff Johnson wrote:
>
>> On 3/7/2024 7:29 AM, Marc Gonzalez wrote:
>>
>>> Have you heard back from the dev team?
>>>
>>> Do they confirm that an issue involving missing MSA_READY notifications
>>> was ever noticed?
>>>
>>> What
On 3/7/2024 8:46 AM, Jeff Johnson wrote:
> On 3/7/2024 7:29 AM, Marc Gonzalez wrote:
>> Have you heard back from the dev team?
>>
>> Do they confirm that an issue involving missing MSA_READY notifications
>> was ever noticed?
>>
>> What devices were affected? (All msm8998? A subset of msm8998?)
>>
On Thu, 14 Mar 2024 at 14:31, Marc Gonzalez wrote:
>
> On 13/03/2024 16:53, Dmitry Baryshkov wrote:
>
> > On Wed, 13 Mar 2024 at 17:09, Marc Gonzalez wrote:
> >
> >> On 05/03/2024 20:20, Kalle Valo wrote:
> >>
> >>> Marc Gonzalez wrote:
> >>>
> I need to build a kernel + rootfs + FW to test
On 13/03/2024 16:53, Dmitry Baryshkov wrote:
> On Wed, 13 Mar 2024 at 17:09, Marc Gonzalez wrote:
>
>> On 05/03/2024 20:20, Kalle Valo wrote:
>>
>>> Marc Gonzalez wrote:
>>>
I need to build a kernel + rootfs + FW to test the proposed solution,
then I can spin a formal submission.
>>>
On Wed, 13 Mar 2024 at 17:09, Marc Gonzalez wrote:
>
> [ Dropping the DT fellows ]
>
> On 05/03/2024 20:20, Kalle Valo wrote:
>
> > Marc Gonzalez wrote:
> >
> >> I need to build a kernel + rootfs + FW to test the proposed solution,
> >> then I can spin a formal submission.
> >
> > Yeah, please do
On 3/13/24 16:09, Marc Gonzalez wrote:
[ Dropping the DT fellows ]
On 05/03/2024 20:20, Kalle Valo wrote:
Marc Gonzalez wrote:
I need to build a kernel + rootfs + FW to test the proposed solution,
then I can spin a formal submission.
Yeah, please do test this to make sure we are not
[ Dropping the DT fellows ]
On 05/03/2024 20:20, Kalle Valo wrote:
> Marc Gonzalez wrote:
>
>> I need to build a kernel + rootfs + FW to test the proposed solution,
>> then I can spin a formal submission.
>
> Yeah, please do test this to make sure we are not missing anything :)
I used
On 3/7/2024 7:29 AM, Marc Gonzalez wrote:
> Have you heard back from the dev team?
>
> Do they confirm that an issue involving missing MSA_READY notifications
> was ever noticed?
>
> What devices were affected? (All msm8998? A subset of msm8998?)
>
> Was the issue eventually fixed?
> (Probably
On 29/02/2024 20:46, Jeff Johnson wrote:
> On 2/29/2024 10:40 AM, Conor Dooley wrote:
>
>> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
>>
>>> Marc Gonzalez writes:
>>
As mentioned in my other reply, there are several msm8998-based
devices affected by this issue. Is it
Marc Gonzalez writes:
> On 05/03/2024 15:31, Kalle Valo wrote:
>
>> Thanks, this is exactly what I'm proposing.
>
> With your suggestions, the patch becomes much simpler:
Nice, looks good to me.
> I need to build a kernel + rootfs + FW to test the proposed solution,
> then I can spin a formal
On 05/03/2024 15:31, Kalle Valo wrote:
> Thanks, this is exactly what I'm proposing.
With your suggestions, the patch becomes much simpler:
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 0032f8aa892ff..18d0abcf6f693 100644
---
Marc Gonzalez writes:
> On 29/02/2024 19:40, Conor Dooley wrote:
>
>> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
>>
>>> Marc Gonzalez wrote:
>>>
As mentioned in my other reply, there are several msm8998-based
devices affected by this issue. Is it not appropriate to
Conor Dooley writes:
> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
>> Marc Gonzalez writes:
>
>> > As mentioned in my other reply, there are several msm8998-based
>> > devices affected by this issue. Is it not appropriate to consider
>> > a kernel-based work-around?
>>
>>
Marc Gonzalez writes:
> On 01/03/2024 09:10, Kalle Valo wrote:
>
>> Marc Gonzalez wrote:
>>
>>> Kalle Valo wrote:
>>>
Here's one example where in ath10k we use a feature bit as a workaround:
/* Don't trust error code from otp.bin */
ATH10K_FW_FEATURE_IGNORE_OTP_RESULT
On 04/03/2024 20:34, Conor Dooley wrote:
> On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
>
>> On 29/02/2024 19:40, Conor Dooley wrote:
>>
>>> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
>>>
Marc Gonzalez wrote:
> As mentioned in my other reply, there
On 04/03/2024 21:21, Dmitry Baryshkov wrote:
> On Mon, 4 Mar 2024 at 22:17, Conor Dooley wrote:
>>
>> On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
>>> On Mon, 4 Mar 2024 at 21:46, Conor Dooley wrote:
On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
On Mon, 4 Mar 2024 at 22:17, Conor Dooley wrote:
>
> On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 4 Mar 2024 at 21:46, Conor Dooley wrote:
> > > On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> > > > On Mon, 4 Mar 2024 at 21:34, Conor Dooley
On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
> On Mon, 4 Mar 2024 at 21:46, Conor Dooley wrote:
> > On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, 4 Mar 2024 at 21:34, Conor Dooley wrote:
> > > > On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc
On Mon, 4 Mar 2024 at 21:46, Conor Dooley wrote:
>
> On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 4 Mar 2024 at 21:34, Conor Dooley wrote:
> > >
> > > On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
> > > > On 29/02/2024 19:40, Conor Dooley wrote:
On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> On Mon, 4 Mar 2024 at 21:34, Conor Dooley wrote:
> >
> > On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
> > > On 29/02/2024 19:40, Conor Dooley wrote:
> > >
> > > > On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle
On Mon, 4 Mar 2024 at 21:34, Conor Dooley wrote:
>
> On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
> > On 29/02/2024 19:40, Conor Dooley wrote:
> >
> > > On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
> > >
> > >> Marc Gonzalez wrote:
> > >>
> > >>> As mentioned in
On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
> On 29/02/2024 19:40, Conor Dooley wrote:
>
> > On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
> >
> >> Marc Gonzalez wrote:
> >>
> >>> As mentioned in my other reply, there are several msm8998-based
> >>> devices
On 29/02/2024 19:40, Conor Dooley wrote:
> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
>
>> Marc Gonzalez wrote:
>>
>>> As mentioned in my other reply, there are several msm8998-based
>>> devices affected by this issue. Is it not appropriate to consider
>>> a kernel-based
On 01/03/2024 09:10, Kalle Valo wrote:
> Marc Gonzalez wrote:
>
>> Kalle Valo wrote:
>>
>>> Here's one example where in ath10k we use a feature bit as a workaround:
>>>
>>> /* Don't trust error code from otp.bin */
>>> ATH10K_FW_FEATURE_IGNORE_OTP_RESULT = 7,
>>>
>>>
>>>
Marc Gonzalez writes:
>> Here's one example where in ath10k we use a feature bit as a workaround:
>>
>> /* Don't trust error code from otp.bin */
>> ATH10K_FW_FEATURE_IGNORE_OTP_RESULT = 7,
>>
>>
>>
>> if (!(skip_otp || test_bit(ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
On 2/29/2024 10:40 AM, Conor Dooley wrote:
> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
>> Marc Gonzalez writes:
>
>>> As mentioned in my other reply, there are several msm8998-based
>>> devices affected by this issue. Is it not appropriate to consider
>>> a kernel-based
On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
> Marc Gonzalez writes:
> > As mentioned in my other reply, there are several msm8998-based
> > devices affected by this issue. Is it not appropriate to consider
> > a kernel-based work-around?
>
> Sorry, not following you here. But
On 28/02/2024 15:59, Jeff Johnson wrote:
> On 2/28/2024 5:24 AM, Marc Gonzalez wrote:
>
>> The driver waits for this indicator before proceeding,
>> yet some WCNSS firmwares apparently do not send it.
>> On those devices, it seems safe to ignore the indicator,
>> and continue loading the
On 28/02/2024 17:37, Kalle Valo wrote:
> Marc Gonzalez writes:
>
>> On 28/02/2024 15:03, Kalle Valo wrote:
>>
>>> Marc Gonzalez writes:
>>>
+ qcom,no-msa-ready-indicator:
+type: boolean
+description:
+ The driver waits for this indicator before proceeding,
Marc Gonzalez writes:
> On 28/02/2024 15:03, Kalle Valo wrote:
>
>> Marc Gonzalez writes:
>>
>>> + qcom,no-msa-ready-indicator:
>>> +type: boolean
>>> +description:
>>> + The driver waits for this indicator before proceeding,
>>> + yet some WCNSS firmwares apparently do not
On 28/02/2024 15:03, Kalle Valo wrote:
> Marc Gonzalez writes:
>
>> The driver waits for this indicator before proceeding,
>> yet some WCNSS firmwares apparently do not send it.
>> On those devices, it seems safe to ignore the indicator,
>> and continue loading the firmware.
>>
>> Signed-off-by:
[ Adding Jami Kettunen who documented the same issue 3 years ago ]
[ Adding Jeffrey Hugo for his past work on msm8998 ]
On 28/02/2024 15:59, Jeff Johnson wrote:
> On 2/28/2024 5:24 AM, Marc Gonzalez wrote:
>
>> The driver waits for this indicator before proceeding,
>> yet some WCNSS firmwares
On 2/28/2024 5:24 AM, Marc Gonzalez wrote:
> The driver waits for this indicator before proceeding,
> yet some WCNSS firmwares apparently do not send it.
> On those devices, it seems safe to ignore the indicator,
> and continue loading the firmware.
Can you list the product/hardware/firmware
Marc Gonzalez writes:
> The driver waits for this indicator before proceeding,
> yet some WCNSS firmwares apparently do not send it.
> On those devices, it seems safe to ignore the indicator,
> and continue loading the firmware.
>
> Signed-off-by: Pierre-Hugues Husson
> Signed-off-by: Marc
The driver waits for this indicator before proceeding,
yet some WCNSS firmwares apparently do not send it.
On those devices, it seems safe to ignore the indicator,
and continue loading the firmware.
Signed-off-by: Pierre-Hugues Husson
Signed-off-by: Marc Gonzalez
---
45 matches
Mail list logo
