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 <[email protected]>
Signed-off-by: Marc Gonzalez <[email protected]>
---
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index 7758a55dd3286..145fa1a3c1c6a 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -121,6 +121,14 @@ 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 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.
+
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
Marc Gonzalez <[email protected]> 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 <[email protected]>
> Signed-off-by: Marc Gonzalez <[email protected]>
> ---
> Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index 7758a55dd3286..145fa1a3c1c6a 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -121,6 +121,14 @@ 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 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.
This sounds more like a firmware feature, not a hardware feature. What
about having a flag in enum ath10k_fw_features in firmware-2.bin?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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 where this is observed?
Would prefer to fix the firmware if the issue is there
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: Pierre-Hugues Husson <[email protected]>
>> Signed-off-by: Marc Gonzalez <[email protected]>
>> ---
>> Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
>> index 7758a55dd3286..145fa1a3c1c6a 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
>> @@ -121,6 +121,14 @@ 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 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.
>
> This sounds more like a firmware feature, not a hardware feature. What
> about having a flag in enum ath10k_fw_features in firmware-2.bin?
Are you using the word "feature" as in "it was done purposefully" ?
This looks very much like a FW bug to my untrained eye.
Is enum ath10k_fw_features also supposed to include work-arounds?
Sorry, I've grepped over the entire Linux source code,
and I cannot find where ath10k_fw_features is used,
other than in ath10k_core_get_fw_feature_str().
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?
Regards
[ 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 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 where this is observed?
> Would prefer to fix the firmware if the issue is there
This issue is observed on an apq8098 (msm8998) SoC using
QC_IMAGE_VERSION_STRING = WLAN.HL.1.0-01202-QCAHLSWMTPLZ-1.221523.2
according to /sys/kernel/debug/qcom_soc_info/cnss/name
We are not the first to run into the issue:
https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN
"Currently if you get FW details printed in dmesg from ath10k
with nothing else seemingly happening, you'll most likely have
to fake an MSA ready indication"
https://github.com/JamiKettunen/linux-mainline-oneplus5/commit/088eaa9153803e2b028e092f88539036442da4a3
The issue is also observed on an F(x)tec Pro1 phone (msm8998-based)
with unknown firmware.
The issue was apparently also observed on the OnePlus 5,
also msm8998/sdm835-based, also unknown firmware.
If the firmwares are signed, and the signature is verified by some remote proc,
then working around the issue in the kernel seems a more pragmatic solution?
Regards
Marc Gonzalez <[email protected]> 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 send it.
>>> + On those devices, it seems safe to ignore the indicator,
>>> + and continue loading the firmware.
>>
>> This sounds more like a firmware feature, not a hardware feature. What
>> about having a flag in enum ath10k_fw_features in firmware-2.bin?
>
> Are you using the word "feature" as in "it was done purposefully" ?
No, there's no bigger meaning like that. It's more like ath10k has to do
something differently when a certain bit is enabled in the firmware. I
just had to pick a word for the enum and from my limited vocabulary I
chose "feature" :)
> Is enum ath10k_fw_features also supposed to include work-arounds?
Yes, and we already use.
> Sorry, I've grepped over the entire Linux source code,
> and I cannot find where ath10k_fw_features is used,
> other than in ath10k_core_get_fw_feature_str().
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,
ar->running_fw->fw_file.fw_features)) &&
result != 0) {
ath10k_err(ar, "otp calibration failed: %d", result);
return -EINVAL;
}
BTW for modifying firmware-N.bin files we have a script here:
https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder
> 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 I'll try to answer anyway:
I have understood that Device Tree is supposed to describe hardware, not
software. This is why having this property in DT does not look right
place for this. For example, if the ath10k firmware is fixed then DT
would have to be changed even though nothing changed in hardware. But of
course DT maintainers have the final say.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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,
>>>> + yet some WCNSS firmwares apparently do not send it.
>>>> + On those devices, it seems safe to ignore the indicator,
>>>> + and continue loading the firmware.
>>>
>>> This sounds more like a firmware feature, not a hardware feature. What
>>> about having a flag in enum ath10k_fw_features in firmware-2.bin?
>>
>> Are you using the word "feature" as in "it was done purposefully" ?
>
> No, there's no bigger meaning like that. It's more like ath10k has to do
> something differently when a certain bit is enabled in the firmware. I
> just had to pick a word for the enum and from my limited vocabulary I
> chose "feature" :)
Understood!
>> Is enum ath10k_fw_features also supposed to include work-arounds?
>
> Yes, and we already use.
>
>> Sorry, I've grepped over the entire Linux source code,
>> and I cannot find where ath10k_fw_features is used,
>> other than in ath10k_core_get_fw_feature_str().
>
> 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,
> ar->running_fw->fw_file.fw_features)) &&
> result != 0) {
> ath10k_err(ar, "otp calibration failed: %d", result);
> return -EINVAL;
> }
>
> BTW for modifying firmware-N.bin files we have a script here:
>
> https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder
If I understand correctly, you are saying that there is
(maybe... probably) a bug in the FW, so it makes sense to
tag that specific FW file with a special bit which the kernel
will interpret as "this FW is broken in a specific way;
and here's how to work around the issue."
So this bit would serve the same purpose as my proposed
"qcom,no-msa-ready-indicator" bit (that bit existed instead
in my board's device tree).
The problem I see is that the firmware files are signed.
Thus, changing a single bit breaks the verification...
UNLESS the FW format allows for a signed section ALONG-SIDE
an unsigned section?
>> 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 I'll try to answer anyway:
>
> I have understood that Device Tree is supposed to describe hardware, not
> software. This is why having this property in DT does not look right
> place for this. For example, if the ath10k firmware is fixed then DT
> would have to be changed even though nothing changed in hardware. But of
> course DT maintainers have the final say.
At some point, we start wandering into meta-physical considerations
such as "if FW cannot ever be changed, when does FIRM become HARD?"
(and other GPLv3 niceties). But this is a discussion for another list.
Regards
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 firmware.
>
> Can you list the product/hardware/firmware where this is observed?
> Would prefer to fix the firmware if the issue is there
Hello Jeff,
Do you think it is possible that the ath10k IP block in the msm8998/sdm835
has never actually sent the MSA_READY indication?
Perhaps the vendor driver does not wait for MSA_READY, and therefore this
issue has never caused a problem downstream?
In that case, we could enable the work-around for all msm8998 boards?
Regards
On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
> Marc Gonzalez <[email protected]> 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 I'll try to answer anyway:
>
> I have understood that Device Tree is supposed to describe hardware, not
> software. This is why having this property in DT does not look right
> place for this. For example, if the ath10k firmware is fixed then DT
> would have to be changed even though nothing changed in hardware. But of
> course DT maintainers have the final say.
I dunno, if the firmware affects the functionality of the hardware in a
way that cannot be detected from the operating system at runtime how
else is it supposed to deal with that?
The devicetree is supposed to describe hardware, yes, but at a certain
point the line between firmware and hardware is invisible :)
Not describing software is mostly about not using it to determine
software policy in the operating system.
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 <[email protected]> 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 I'll try to answer anyway:
>>
>> I have understood that Device Tree is supposed to describe hardware, not
>> software. This is why having this property in DT does not look right
>> place for this. For example, if the ath10k firmware is fixed then DT
>> would have to be changed even though nothing changed in hardware. But of
>> course DT maintainers have the final say.
>
> I dunno, if the firmware affects the functionality of the hardware in a
> way that cannot be detected from the operating system at runtime how
> else is it supposed to deal with that?
> The devicetree is supposed to describe hardware, yes, but at a certain
> point the line between firmware and hardware is invisible :)
> Not describing software is mostly about not using it to determine
> software policy in the operating system.
FWIW I've compared ath10k to the out-of-tree Android driver and there
are discrepancies in this area. I've asked the development team that
supports ath10k to provide a recommendation.
/jeff
Marc Gonzalez <[email protected]> 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,
>> ar->running_fw->fw_file.fw_features)) &&
>> result != 0) {
>> ath10k_err(ar, "otp calibration failed: %d", result);
>> return -EINVAL;
>> }
>>
>> BTW for modifying firmware-N.bin files we have a script here:
>>
>> https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder
>
> If I understand correctly, you are saying that there is
> (maybe... probably) a bug in the FW, so it makes sense to
> tag that specific FW file with a special bit which the kernel
> will interpret as "this FW is broken in a specific way;
> and here's how to work around the issue."
>
> So this bit would serve the same purpose as my proposed
> "qcom,no-msa-ready-indicator" bit (that bit existed instead
> in my board's device tree).
>
> The problem I see is that the firmware files are signed.
> Thus, changing a single bit breaks the verification...
> UNLESS the FW format allows for a signed section ALONG-SIDE
> an unsigned section?
firmware-N.bin is ath10k specific container file format and we (the
Linux community) have full access to it using ath10k-fwencoder, there's
no signing or anything like that. One of the major reasons why it was
designed was to handle differences between firmware branches, just like
in this case.
Of course plan A should be to fix the firmware but if that doesn't work
out then plan B could be using the feature bit in firmware-N.bin.
BTW related to this Dmitry is extending firmware-N.bin handling for
WCN3990, you will most likely need to use that:
https://patchwork.kernel.org/project/linux-wireless/cover/[email protected]/
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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,
>>>
>>> ....
>>>
>>> if (!(skip_otp || test_bit(ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
>>> ar->running_fw->fw_file.fw_features)) &&
>>> result != 0) {
>>> ath10k_err(ar, "otp calibration failed: %d", result);
>>> return -EINVAL;
>>> }
>>>
>>> BTW for modifying firmware-N.bin files we have a script here:
>>>
>>> https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder
>>
>> If I understand correctly, you are saying that there is
>> (maybe... probably) a bug in the FW, so it makes sense to
>> tag that specific FW file with a special bit which the kernel
>> will interpret as "this FW is broken in a specific way;
>> and here's how to work around the issue."
>>
>> So this bit would serve the same purpose as my proposed
>> "qcom,no-msa-ready-indicator" bit (that bit existed instead
>> in my board's device tree).
>>
>> The problem I see is that the firmware files are signed.
>> Thus, changing a single bit breaks the verification...
>> UNLESS the FW format allows for a signed section ALONG-SIDE
>> an unsigned section?
>
> firmware-N.bin is ath10k specific container file format and we (the
> Linux community) have full access to it using ath10k-fwencoder, there's
> no signing or anything like that. One of the major reasons why it was
> designed was to handle differences between firmware branches, just like
> in this case.
>
> Of course plan A should be to fix the firmware but if that doesn't work
> out then plan B could be using the feature bit in firmware-N.bin.
>
> BTW related to this Dmitry is extending firmware-N.bin handling for
> WCN3990, you will most likely need to use that:
>
> https://patchwork.kernel.org/project/linux-wireless/cover/[email protected]/
If I understand correctly (happy to have anyone correct any
misunderstandings), if the FW cannot be fixed (for any reason),
then we would have to do something like this:
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 0032f8aa892ff..c8778ebe922af 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -769,6 +769,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
[ATH10K_FW_FEATURE_SINGLE_CHAN_INFO_PER_CHANNEL] = "single-chan-info-per-channel",
[ATH10K_FW_FEATURE_PEER_FIXED_RATE] = "peer-fixed-rate",
[ATH10K_FW_FEATURE_IRAM_RECOVERY] = "iram-recovery",
+ [ATH10K_FW_FEATURE_NO_MSA_READY] = "no-msa-ready-indicator",
};
static unsigned int ath10k_core_get_fw_feature_str(char *buf,
@@ -2941,6 +2942,9 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
ar->running_fw = fw;
+ if (test_bit(ATH10K_FW_FEATURE_NO_MSA_READY, fw->fw_file.fw_features))
+ ar->fake_msa_ready = true;
+
if (!test_bit(ATH10K_FW_FEATURE_NON_BMI,
ar->running_fw->fw_file.fw_features)) {
ath10k_bmi_start(ar);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index c110d15528bd0..ce71097b97a1d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -835,6 +835,9 @@ enum ath10k_fw_features {
/* Firmware support IRAM recovery */
ATH10K_FW_FEATURE_IRAM_RECOVERY = 22,
+ /* Firware does not send MSA_READY indicator */
+ ATH10K_FW_FEATURE_NO_MSA_READY = 23,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
@@ -1151,6 +1154,9 @@ struct ath10k {
u8 cfg_tx_chainmask;
u8 cfg_rx_chainmask;
+ /* FW does not send MSA_READY indicator. Fake it */
+ bool fake_msa_ready; /* bool or u8? or s8? or bitfield? */
+
struct completion install_key_done;
int last_wmi_vdev_start_status;
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 38e939f572a9e..0776e79b25f3a 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1040,6 +1040,8 @@ static void ath10k_qmi_driver_event_work(struct work_struct *work)
switch (event->type) {
case ATH10K_QMI_EVENT_SERVER_ARRIVE:
ath10k_qmi_event_server_arrive(qmi);
+ if (ar->fake_msa_ready)
+ ath10k_qmi_event_msa_ready(qmi);
break;
case ATH10K_QMI_EVENT_SERVER_EXIT:
ath10k_qmi_event_server_exit(qmi);
--
Regards
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 work-around?
>>
>> Sorry, not following you here. But I'll try to answer anyway:
>>
>> I have understood that Device Tree is supposed to describe hardware, not
>> software. This is why having this property in DT does not look right
>> place for this. For example, if the ath10k firmware is fixed then DT
>> would have to be changed even though nothing changed in hardware. But of
>> course DT maintainers have the final say.
>
> I dunno, if the firmware affects the functionality of the hardware in a
> way that cannot be detected from the operating system at runtime how
> else is it supposed to deal with that?
> The devicetree is supposed to describe hardware, yes, but at a certain
> point the line between firmware and hardware is invisible :)
> Not describing software is mostly about not using it to determine
> software policy in the operating system.
Recording here what was discussed a few days ago on IRC:
If all msm8998 boards are affected, then it /might/ make sense
to work around the issue for ALL msm8998 boards:
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 0776e79b25f3a..9da06da518fb6 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1076,6 +1076,9 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
qmi->ar = ar;
ar_snoc->qmi = qmi;
+ if (of_device_is_compatible(of_root, "qcom,msm8998")
+ qmi->no_point_in_waiting_for_msa_ready_indicator = true;
+
if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
qmi->msa_fixed_perm = true;
Thus, anyone porting an msm8998 board to mainline would automatically
get the work-around, without having to hunt down the feature bit,
and tweak the FW files.
--
Regards
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 affected by this issue. Is it not appropriate to consider
> >>> a kernel-based work-around?
> >>
> >> Sorry, not following you here. But I'll try to answer anyway:
> >>
> >> I have understood that Device Tree is supposed to describe hardware, not
> >> software. This is why having this property in DT does not look right
> >> place for this. For example, if the ath10k firmware is fixed then DT
> >> would have to be changed even though nothing changed in hardware. But of
> >> course DT maintainers have the final say.
> >
> > I dunno, if the firmware affects the functionality of the hardware in a
> > way that cannot be detected from the operating system at runtime how
> > else is it supposed to deal with that?
> > The devicetree is supposed to describe hardware, yes, but at a certain
> > point the line between firmware and hardware is invisible :)
> > Not describing software is mostly about not using it to determine
> > software policy in the operating system.
>
> Recording here what was discussed a few days ago on IRC:
>
> If all msm8998 boards are affected, then it /might/ make sense
> to work around the issue for ALL msm8998 boards:
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> index 0776e79b25f3a..9da06da518fb6 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -1076,6 +1076,9 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
> qmi->ar = ar;
> ar_snoc->qmi = qmi;
>
> + if (of_device_is_compatible(of_root, "qcom,msm8998")
> + qmi->no_point_in_waiting_for_msa_ready_indicator = true;
> +
> if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
> qmi->msa_fixed_perm = true;
>
>
> Thus, anyone porting an msm8998 board to mainline would automatically
> get the work-around, without having to hunt down the feature bit,
> and tweak the FW files.
How come the root node comes into this, don't you have a soc-specific
compatible for the integration on this SoC?
(I am assuming that this is not the SDIO variant, given then it'd not be
fixed to this particular implementation)
On Mon, 4 Mar 2024 at 21:34, Conor Dooley <[email protected]> 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 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 I'll try to answer anyway:
> > >>
> > >> I have understood that Device Tree is supposed to describe hardware, not
> > >> software. This is why having this property in DT does not look right
> > >> place for this. For example, if the ath10k firmware is fixed then DT
> > >> would have to be changed even though nothing changed in hardware. But of
> > >> course DT maintainers have the final say.
> > >
> > > I dunno, if the firmware affects the functionality of the hardware in a
> > > way that cannot be detected from the operating system at runtime how
> > > else is it supposed to deal with that?
> > > The devicetree is supposed to describe hardware, yes, but at a certain
> > > point the line between firmware and hardware is invisible :)
> > > Not describing software is mostly about not using it to determine
> > > software policy in the operating system.
> >
> > Recording here what was discussed a few days ago on IRC:
> >
> > If all msm8998 boards are affected, then it /might/ make sense
> > to work around the issue for ALL msm8998 boards:
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> > index 0776e79b25f3a..9da06da518fb6 100644
> > --- a/drivers/net/wireless/ath/ath10k/qmi.c
> > +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> > @@ -1076,6 +1076,9 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
> > qmi->ar = ar;
> > ar_snoc->qmi = qmi;
> >
> > + if (of_device_is_compatible(of_root, "qcom,msm8998")
> > + qmi->no_point_in_waiting_for_msa_ready_indicator = true;
> > +
> > if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
> > qmi->msa_fixed_perm = true;
> >
> >
> > Thus, anyone porting an msm8998 board to mainline would automatically
> > get the work-around, without having to hunt down the feature bit,
> > and tweak the FW files.
>
> How come the root node comes into this, don't you have a soc-specific
> compatible for the integration on this SoC?
No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
My 2c: I think it's easier to fix the firmware features bits, it's
more future proof (and error proof).
> (I am assuming that this is not the SDIO variant, given then it'd not be
> fixed to this particular implementation)
--
With best wishes
Dmitry
On Mon, 4 Mar 2024 at 21:46, Conor Dooley <[email protected]> wrote:
>
> On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 4 Mar 2024 at 21:34, Conor Dooley <[email protected]> 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 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 I'll try to answer anyway:
> > > > >>
> > > > >> I have understood that Device Tree is supposed to describe hardware, not
> > > > >> software. This is why having this property in DT does not look right
> > > > >> place for this. For example, if the ath10k firmware is fixed then DT
> > > > >> would have to be changed even though nothing changed in hardware. But of
> > > > >> course DT maintainers have the final say.
> > > > >
> > > > > I dunno, if the firmware affects the functionality of the hardware in a
> > > > > way that cannot be detected from the operating system at runtime how
> > > > > else is it supposed to deal with that?
> > > > > The devicetree is supposed to describe hardware, yes, but at a certain
> > > > > point the line between firmware and hardware is invisible :)
> > > > > Not describing software is mostly about not using it to determine
> > > > > software policy in the operating system.
> > > >
> > > > Recording here what was discussed a few days ago on IRC:
> > > >
> > > > If all msm8998 boards are affected, then it /might/ make sense
> > > > to work around the issue for ALL msm8998 boards:
> > > >
> > > > diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> > > > index 0776e79b25f3a..9da06da518fb6 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/qmi.c
> > > > +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> > > > @@ -1076,6 +1076,9 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
> > > > qmi->ar = ar;
> > > > ar_snoc->qmi = qmi;
> > > >
> > > > + if (of_device_is_compatible(of_root, "qcom,msm8998")
> > > > + qmi->no_point_in_waiting_for_msa_ready_indicator = true;
> > > > +
> > > > if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
> > > > qmi->msa_fixed_perm = true;
> > > >
> > > >
> > > > Thus, anyone porting an msm8998 board to mainline would automatically
> > > > get the work-around, without having to hunt down the feature bit,
> > > > and tweak the FW files.
> > >
> > > How come the root node comes into this, don't you have a soc-specific
> > > compatible for the integration on this SoC?
> >
> > No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
>
> Suitability of either fix aside, can you explain this to me? Is the "WiFi
> SoC" accessible from the "main SoC" at a regular MMIO address? The
> "ath10k" compatible says it is SDIO-based & the other two compatibles
> seem to be MMIO.
Yes, this is correct. MSM8996 uses PCI to access WiFi chip, MSM8998 uses MMIO.
--
With best wishes
Dmitry
On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> On Mon, 4 Mar 2024 at 21:34, Conor Dooley <[email protected]> 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 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 I'll try to answer anyway:
> > > >>
> > > >> I have understood that Device Tree is supposed to describe hardware, not
> > > >> software. This is why having this property in DT does not look right
> > > >> place for this. For example, if the ath10k firmware is fixed then DT
> > > >> would have to be changed even though nothing changed in hardware. But of
> > > >> course DT maintainers have the final say.
> > > >
> > > > I dunno, if the firmware affects the functionality of the hardware in a
> > > > way that cannot be detected from the operating system at runtime how
> > > > else is it supposed to deal with that?
> > > > The devicetree is supposed to describe hardware, yes, but at a certain
> > > > point the line between firmware and hardware is invisible :)
> > > > Not describing software is mostly about not using it to determine
> > > > software policy in the operating system.
> > >
> > > Recording here what was discussed a few days ago on IRC:
> > >
> > > If all msm8998 boards are affected, then it /might/ make sense
> > > to work around the issue for ALL msm8998 boards:
> > >
> > > diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> > > index 0776e79b25f3a..9da06da518fb6 100644
> > > --- a/drivers/net/wireless/ath/ath10k/qmi.c
> > > +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> > > @@ -1076,6 +1076,9 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
> > > qmi->ar = ar;
> > > ar_snoc->qmi = qmi;
> > >
> > > + if (of_device_is_compatible(of_root, "qcom,msm8998")
> > > + qmi->no_point_in_waiting_for_msa_ready_indicator = true;
> > > +
> > > if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
> > > qmi->msa_fixed_perm = true;
> > >
> > >
> > > Thus, anyone porting an msm8998 board to mainline would automatically
> > > get the work-around, without having to hunt down the feature bit,
> > > and tweak the FW files.
> >
> > How come the root node comes into this, don't you have a soc-specific
> > compatible for the integration on this SoC?
>
> No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
Suitability of either fix aside, can you explain this to me? Is the "WiFi
SoC" accessible from the "main SoC" at a regular MMIO address? The
"ath10k" compatible says it is SDIO-based & the other two compatibles
seem to be MMIO.
On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
> On Mon, 4 Mar 2024 at 21:46, Conor Dooley <[email protected]> wrote:
> > On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, 4 Mar 2024 at 21:34, Conor Dooley <[email protected]> wrote:
> > > > On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
> > > > > Thus, anyone porting an msm8998 board to mainline would automatically
> > > > > get the work-around, without having to hunt down the feature bit,
> > > > > and tweak the FW files.
> > > >
> > > > How come the root node comes into this, don't you have a soc-specific
> > > > compatible for the integration on this SoC?
> > >
> > > No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
> >
> > Suitability of either fix aside, can you explain this to me? Is the "WiFi
> > SoC" accessible from the "main SoC" at a regular MMIO address? The
> > "ath10k" compatible says it is SDIO-based & the other two compatibles
> > seem to be MMIO.
>
> Yes, this is correct. MSM8996 uses PCI to access WiFi chip, MSM8998 uses MMIO.
Thanks.
A SoC-specific compatible sounds like it would be suitable in that case
then, to deal with integration quirks for that specific SoC? I usually
leave the ins and outs of these qcom SoCs to Krzysztof, but I can't help
but wanna know what the justification is here for not using one.
On Mon, 4 Mar 2024 at 22:17, Conor Dooley <[email protected]> wrote:
>
> On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 4 Mar 2024 at 21:46, Conor Dooley <[email protected]> wrote:
> > > On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> > > > On Mon, 4 Mar 2024 at 21:34, Conor Dooley <[email protected]> wrote:
> > > > > On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
>
> > > > > > Thus, anyone porting an msm8998 board to mainline would automatically
> > > > > > get the work-around, without having to hunt down the feature bit,
> > > > > > and tweak the FW files.
> > > > >
> > > > > How come the root node comes into this, don't you have a soc-specific
> > > > > compatible for the integration on this SoC?
> > > >
> > > > No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
> > >
> > > Suitability of either fix aside, can you explain this to me? Is the "WiFi
> > > SoC" accessible from the "main SoC" at a regular MMIO address? The
> > > "ath10k" compatible says it is SDIO-based & the other two compatibles
> > > seem to be MMIO.
> >
> > Yes, this is correct. MSM8996 uses PCI to access WiFi chip, MSM8998 uses MMIO.
>
> Thanks.
>
> A SoC-specific compatible sounds like it would be suitable in that case
> then, to deal with integration quirks for that specific SoC? I usually
> leave the ins and outs of these qcom SoCs to Krzysztof, but I can't help
> but wanna know what the justification is here for not using one.
We can probably start with "historically established" here. From the
hardware point of view msm8998, sdm845 and several other chipsets use
a variant of the same wcn3990 WiFi+BT chip. The actual issue is in the
DSP firmware, so it can be handled via the firmware-related means.
On the other hand, I see qcom,snoc-host-cap-8bit-quirk property, so
one can use DT properties to describe the issue.
--
With best wishes
Dmitry
On 04/03/2024 21:21, Dmitry Baryshkov wrote:
> On Mon, 4 Mar 2024 at 22:17, Conor Dooley <[email protected]> wrote:
>>
>> On Mon, Mar 04, 2024 at 09:59:13PM +0200, Dmitry Baryshkov wrote:
>>> On Mon, 4 Mar 2024 at 21:46, Conor Dooley <[email protected]> wrote:
>>>> On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
>>>>> On Mon, 4 Mar 2024 at 21:34, Conor Dooley <[email protected]> wrote:
>>>>>> On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
>>
>>>>>>> Thus, anyone porting an msm8998 board to mainline would automatically
>>>>>>> get the work-around, without having to hunt down the feature bit,
>>>>>>> and tweak the FW files.
>>>>>>
>>>>>> How come the root node comes into this, don't you have a soc-specific
>>>>>> compatible for the integration on this SoC?
>>>>>
>>>>> No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
>>>>
>>>> Suitability of either fix aside, can you explain this to me? Is the "WiFi
>>>> SoC" accessible from the "main SoC" at a regular MMIO address? The
>>>> "ath10k" compatible says it is SDIO-based & the other two compatibles
>>>> seem to be MMIO.
>>>
>>> Yes, this is correct. MSM8996 uses PCI to access WiFi chip, MSM8998 uses MMIO.
>>
>> Thanks.
>>
>> A SoC-specific compatible sounds like it would be suitable in that case
>> then, to deal with integration quirks for that specific SoC? I usually
>> leave the ins and outs of these qcom SoCs to Krzysztof, but I can't help
>> but wanna know what the justification is here for not using one.
>
> We can probably start with "historically established" here. From the
> hardware point of view msm8998, sdm845 and several other chipsets use
> a variant of the same wcn3990 WiFi+BT chip. The actual issue is in the
> DSP firmware, so it can be handled via the firmware-related means.
>
The WiFi+BT chips are separate products, so they are not usually
considered part of the SoC, even though they can be integrated into the
SoC like here. I guess correct approach would be to add SoC-specific
compatible for them.
Best regards,
Krzysztof
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 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 I'll try to answer anyway:
>>>>
>>>> I have understood that Device Tree is supposed to describe hardware, not
>>>> software. This is why having this property in DT does not look right
>>>> place for this. For example, if the ath10k firmware is fixed then DT
>>>> would have to be changed even though nothing changed in hardware. But of
>>>> course DT maintainers have the final say.
>>>
>>> I dunno, if the firmware affects the functionality of the hardware in a
>>> way that cannot be detected from the operating system at runtime how
>>> else is it supposed to deal with that?
>>> The devicetree is supposed to describe hardware, yes, but at a certain
>>> point the line between firmware and hardware is invisible :)
>>> Not describing software is mostly about not using it to determine
>>> software policy in the operating system.
>>
>> Recording here what was discussed a few days ago on IRC:
>>
>> If all msm8998 boards are affected, then it /might/ make sense
>> to work around the issue for ALL msm8998 boards:
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
>> index 0776e79b25f3a..9da06da518fb6 100644
>> --- a/drivers/net/wireless/ath/ath10k/qmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
>> @@ -1076,6 +1076,9 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
>> qmi->ar = ar;
>> ar_snoc->qmi = qmi;
>>
>> + if (of_device_is_compatible(of_root, "qcom,msm8998")
>> + qmi->no_point_in_waiting_for_msa_ready_indicator = true;
>> +
>> if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
>> qmi->msa_fixed_perm = true;
>>
>>
>> Thus, anyone porting an msm8998 board to mainline would automatically
>> get the work-around, without having to hunt down the feature bit,
>> and tweak the FW files.
>
> How come the root node comes into this, don't you have a soc-specific
> compatible for the integration on this SoC?
> (I am assuming that this is not the SDIO variant, given then it'd not be
> fixed to this particular implementation)
I see only
"qcom,ipq4019-wifi"
"qcom,wcn3990-wifi"
"qcom,wcn6750-wifi"
arch/arm64/boot/dts/qcom/msm8998.dtsi uses "qcom,wcn3990-wifi"
(which is also used for 9 other SoCs).
IIUC, you're saying there probably should have been a generic
compatible AND a board-specific compatible, like for ufshc:
$ git grep qcom,ufshc arch/arm64/boot/dts/qcom
arch/arm64/boot/dts/qcom/msm8996.dtsi: compatible = "qcom,msm8996-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/msm8998.dtsi: compatible = "qcom,msm8998-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
arch/arm64/boot/dts/qcom/sa8775p.dtsi: compatible = "qcom,sa8775p-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
arch/arm64/boot/dts/qcom/sc7280.dtsi: compatible = "qcom,sc7280-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sc8180x.dtsi: compatible = "qcom,sc8180x-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sc8280xp.dtsi: compatible = "qcom,sc8280xp-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sc8280xp.dtsi: compatible = "qcom,sc8280xp-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sdm845.dtsi: compatible = "qcom,sdm845-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sm6115.dtsi: compatible = "qcom,sm6115-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
arch/arm64/boot/dts/qcom/sm6125.dtsi: compatible = "qcom,sm6125-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
arch/arm64/boot/dts/qcom/sm6350.dtsi: compatible = "qcom,sm6350-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sm8150.dtsi: compatible = "qcom,sm8150-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sm8250.dtsi: compatible = "qcom,sm8250-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sm8350.dtsi: compatible = "qcom,sm8350-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sm8450.dtsi: compatible = "qcom,sm8450-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sm8550.dtsi: compatible = "qcom,sm8550-ufshc", "qcom,ufshc",
arch/arm64/boot/dts/qcom/sm8650.dtsi: compatible = "qcom,sm8650-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
If all msm8998-based device trees had (for example)
a qcom,msm8998-wcn3990-wifi compatible, we could have
matched that to apply a quirk to all msm8998 boards.
Did I understand correctly?
(In the toy code I provided, I matched the of_root because
there is no SoC-specific compatible for the device itself.)
--
Regards
Marc Gonzalez <[email protected]> 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 = 7,
>>>>
>>>> ....
>>>>
>>>> if (!(skip_otp || test_bit(ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
>>>> ar->running_fw->fw_file.fw_features)) &&
>>>> result != 0) {
>>>> ath10k_err(ar, "otp calibration failed: %d", result);
>>>> return -EINVAL;
>>>> }
>>>>
>>>> BTW for modifying firmware-N.bin files we have a script here:
>>>>
>>>> https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder
>>>
>>> If I understand correctly, you are saying that there is
>>> (maybe... probably) a bug in the FW, so it makes sense to
>>> tag that specific FW file with a special bit which the kernel
>>> will interpret as "this FW is broken in a specific way;
>>> and here's how to work around the issue."
>>>
>>> So this bit would serve the same purpose as my proposed
>>> "qcom,no-msa-ready-indicator" bit (that bit existed instead
>>> in my board's device tree).
>>>
>>> The problem I see is that the firmware files are signed.
>>> Thus, changing a single bit breaks the verification...
>>> UNLESS the FW format allows for a signed section ALONG-SIDE
>>> an unsigned section?
>>
>> firmware-N.bin is ath10k specific container file format and we (the
>> Linux community) have full access to it using ath10k-fwencoder, there's
>> no signing or anything like that. One of the major reasons why it was
>> designed was to handle differences between firmware branches, just like
>> in this case.
>>
>> Of course plan A should be to fix the firmware but if that doesn't work
>> out then plan B could be using the feature bit in firmware-N.bin.
>>
>> BTW related to this Dmitry is extending firmware-N.bin handling for
>> WCN3990, you will most likely need to use that:
>>
>> https://patchwork.kernel.org/project/linux-wireless/cover/[email protected]/
>
>
> If I understand correctly (happy to have anyone correct any
> misunderstandings), if the FW cannot be fixed (for any reason),
> then we would have to do something like this:
Thanks, this is exactly what I'm proposing.
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index 0032f8aa892ff..c8778ebe922af 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -769,6 +769,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
> [ATH10K_FW_FEATURE_SINGLE_CHAN_INFO_PER_CHANNEL] = "single-chan-info-per-channel",
> [ATH10K_FW_FEATURE_PEER_FIXED_RATE] = "peer-fixed-rate",
> [ATH10K_FW_FEATURE_IRAM_RECOVERY] = "iram-recovery",
> + [ATH10K_FW_FEATURE_NO_MSA_READY] = "no-msa-ready-indicator",
For consistency I would have just "no-msa-ready".
> @@ -1151,6 +1154,9 @@ struct ath10k {
> u8 cfg_tx_chainmask;
> u8 cfg_rx_chainmask;
>
> + /* FW does not send MSA_READY indicator. Fake it */
> + bool fake_msa_ready; /* bool or u8? or s8? or bitfield? */
Hopefully not needed, see below.
> struct completion install_key_done;
>
> int last_wmi_vdev_start_status;
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> index 38e939f572a9e..0776e79b25f3a 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -1040,6 +1040,8 @@ static void ath10k_qmi_driver_event_work(struct work_struct *work)
> switch (event->type) {
> case ATH10K_QMI_EVENT_SERVER_ARRIVE:
> ath10k_qmi_event_server_arrive(qmi);
> + if (ar->fake_msa_ready)
> + ath10k_qmi_event_msa_ready(qmi);
Unless I'm missing something I would use here test_bit() directly:
if (test_bit(ATH10K_FW_FEATURE_NO_MSA_READY, ar->running_fw->fw_file.fw_features))
ath10k_qmi_event_msa_ready(qmi);
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Conor Dooley <[email protected]> writes:
> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
>> Marc Gonzalez <[email protected]> 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 I'll try to answer anyway:
>>
>> I have understood that Device Tree is supposed to describe hardware, not
>> software. This is why having this property in DT does not look right
>> place for this. For example, if the ath10k firmware is fixed then DT
>> would have to be changed even though nothing changed in hardware. But of
>> course DT maintainers have the final say.
>
> I dunno, if the firmware affects the functionality of the hardware in a
> way that cannot be detected from the operating system at runtime how
> else is it supposed to deal with that?
This is why we implemented in ath10k firmware-N.bin with all sorts of
meta data about the firmware. There are a lots of different ath10k
firmware branches and they have differences which ath10k needs to take
into account. firmware-N.bin tells all that info to ath10k runtime, per
firmware release.
> The devicetree is supposed to describe hardware, yes, but at a certain
> point the line between firmware and hardware is invisible :)
> Not describing software is mostly about not using it to determine
> software policy in the operating system.
For me it feels wrong to use DT for handling WLAN firmware differences.
For example, what if the ath10k firmware in linux-firmware is fixed? Are
we expecting that DT in existing boards is updated? But how is the DT
update going to be synced with linux-firmware releases? Sure, in this
case it most likely won't matter but as a generic solution this looks
very fragile to me.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Marc Gonzalez <[email protected]> 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 consider
>>>> a kernel-based work-around?
>>>
>>> Sorry, not following you here. But I'll try to answer anyway:
>>>
>>> I have understood that Device Tree is supposed to describe hardware, not
>>> software. This is why having this property in DT does not look right
>>> place for this. For example, if the ath10k firmware is fixed then DT
>>> would have to be changed even though nothing changed in hardware. But of
>>> course DT maintainers have the final say.
>>
>> I dunno, if the firmware affects the functionality of the hardware in a
>> way that cannot be detected from the operating system at runtime how
>> else is it supposed to deal with that?
>> The devicetree is supposed to describe hardware, yes, but at a certain
>> point the line between firmware and hardware is invisible :)
>> Not describing software is mostly about not using it to determine
>> software policy in the operating system.
>
> Recording here what was discussed a few days ago on IRC:
>
> If all msm8998 boards are affected, then it /might/ make sense
> to work around the issue for ALL msm8998 boards:
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> index 0776e79b25f3a..9da06da518fb6 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -1076,6 +1076,9 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
> qmi->ar = ar;
> ar_snoc->qmi = qmi;
>
> + if (of_device_is_compatible(of_root, "qcom,msm8998")
> + qmi->no_point_in_waiting_for_msa_ready_indicator = true;
> +
> if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
> qmi->msa_fixed_perm = true;
>
>
> Thus, anyone porting an msm8998 board to mainline would automatically
> get the work-around, without having to hunt down the feature bit,
> and tweak the FW files.
The point with firmware-N.bin file is that NO tweaking or hunting down
firmware files is necessary. All the files would be in
linux-firmware.git and ath10k would automatically choose the correct
firmware-N file. From ath10k side all is needed is Dmitry's patchset[1]
and your (Marc) patch adding the feature bit check to ath10k.
And if later the firmware is fixed, we will update the firmware-N.bin
file at the same time in linux-firmware.git and the user doesn't notice
anything.
[1] https://patchwork.kernel.org/project/linux-wireless/cover/[email protected]/
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -769,6 +769,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
[ATH10K_FW_FEATURE_SINGLE_CHAN_INFO_PER_CHANNEL] = "single-chan-info-per-channel",
[ATH10K_FW_FEATURE_PEER_FIXED_RATE] = "peer-fixed-rate",
[ATH10K_FW_FEATURE_IRAM_RECOVERY] = "iram-recovery",
+ [ATH10K_FW_FEATURE_NO_MSA_READY] = "no-msa-ready",
};
static unsigned int ath10k_core_get_fw_feature_str(char *buf,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index c110d15528bd0..1ac8ea02cc088 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -835,6 +835,9 @@ enum ath10k_fw_features {
/* Firmware support IRAM recovery */
ATH10K_FW_FEATURE_IRAM_RECOVERY = 22,
+ /* Firmware does not send MSA_READY indicator */
+ ATH10K_FW_FEATURE_NO_MSA_READY = 23,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 38e939f572a9e..7e408fd63cdb8 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1040,6 +1040,8 @@ static void ath10k_qmi_driver_event_work(struct work_struct *work)
switch (event->type) {
case ATH10K_QMI_EVENT_SERVER_ARRIVE:
ath10k_qmi_event_server_arrive(qmi);
+ if (test_bit(ATH10K_FW_FEATURE_NO_MSA_READY, ar->running_fw->fw_file.fw_features))
+ ath10k_qmi_event_msa_ready(qmi);
break;
case ATH10K_QMI_EVENT_SERVER_EXIT:
ath10k_qmi_event_server_exit(qmi);
I need to build a kernel + rootfs + FW to test the proposed solution,
then I can spin a formal submission.
(I didn't understand why this patch requires Dmitry's series?)
Do I need to submit a symmetric patch to linux-firmware to define bit 23?
And also a patch to add the bit to some firmwares? (All msm8998 FWs?)
Regards
Marc Gonzalez <[email protected]> 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 submission.
Yeah, please do test this to make sure we are not missing anything :)
> (I didn't understand why this patch requires Dmitry's series?)
Dmitry's patchset is needed so that we can have board specific
firmware-N.bin files. At the moment there can be only one firmware-N.bin
(ath10k/WCN3990/hw1.0/firmware-5.bin) for all boards with WCN3990.
Your patch can be applied to ath.git independently from Dmitry's
patchset but we need Dmitry's patchset applied before updating
linux-firmware.git.
> Do I need to submit a symmetric patch to linux-firmware to define bit 23?
> And also a patch to add the bit to some firmwares? (All msm8998 FWs?)
Me and Jeff can handle linux-firmware.git submission. We will also add
the new bit to ath10k-fwencoder.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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 not appropriate to consider
>>>> a kernel-based work-around?
>>>
>>> Sorry, not following you here. But I'll try to answer anyway:
>>>
>>> I have understood that Device Tree is supposed to describe hardware, not
>>> software. This is why having this property in DT does not look right
>>> place for this. For example, if the ath10k firmware is fixed then DT
>>> would have to be changed even though nothing changed in hardware. But of
>>> course DT maintainers have the final say.
>>
>> I dunno, if the firmware affects the functionality of the hardware in a
>> way that cannot be detected from the operating system at runtime how
>> else is it supposed to deal with that?
>> The devicetree is supposed to describe hardware, yes, but at a certain
>> point the line between firmware and hardware is invisible :)
>> Not describing software is mostly about not using it to determine
>> software policy in the operating system.
>
> FWIW I've compared ath10k to the out-of-tree Android driver and there
> are discrepancies in this area. I've asked the development team that
> supports ath10k to provide a recommendation.
Hello Jeff,
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 fixed, otherwise newer devices would be affected)
--
Regards.
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 fixed, otherwise newer devices would be affected)
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.
So my preference would be to use the firmware capability in the board
file that Kalle has recommended.
/jeff
[ 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 buildroot ( https://buildroot.org ) to generate a kernel + rootfs
for my board (a variation of qcom/msm8998-mtp.dts)
Not sure if I must use the vendor FW blobs? Or if I can use the blobs
from linux-firmware-20240115.tar.xz (as supported by BR2).
All I see from the ath10k driver (with debugging cranked to the max) is:
[ 0.539801] ath10k_snoc 18800000.wifi: Adding to iommu group 0
[ 0.541941] ath10k_snoc 18800000.wifi: snoc xo-cal-data return -22
[ 0.543633] ath10k_snoc 18800000.wifi: supply vdd-3.3-ch1 not found, using dummy regulator
[ 0.544002] ath10k_snoc 18800000.wifi: qmi msa.paddr: 0x0000000094400000 , msa.vaddr: 0x(____ptrval____)
[ 0.544271] ath10k_snoc 18800000.wifi: snoc probe
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 34:27:92:82:48:ec brd ff:ff:ff:ff:ff:ff
No wlan device at this point.
I got shell-shock from reading these setup steps:
https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN
https://github.com/jhugo/linux/blob/5.5rc2_wifi/README
Jeffrey, Bjorn, Konrad,
Has someone written idiot-proof (such as myself) steps to enable
the ath10k core on a msm8998 board?
I'm still not quite sure where linux-firmware.git fits into all this.
Regards
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 missing anything :)
>
> I used buildroot ( https://buildroot.org ) to generate a kernel + rootfs
> for my board (a variation of qcom/msm8998-mtp.dts)
>
> Not sure if I must use the vendor FW blobs? Or if I can use the blobs
> from linux-firmware-20240115.tar.xz (as supported by BR2).
>
>
> All I see from the ath10k driver (with debugging cranked to the max) is:
>
> [ 0.539801] ath10k_snoc 18800000.wifi: Adding to iommu group 0
> [ 0.541941] ath10k_snoc 18800000.wifi: snoc xo-cal-data return -22
> [ 0.543633] ath10k_snoc 18800000.wifi: supply vdd-3.3-ch1 not found, using dummy regulator
> [ 0.544002] ath10k_snoc 18800000.wifi: qmi msa.paddr: 0x0000000094400000 , msa.vaddr: 0x(____ptrval____)
> [ 0.544271] ath10k_snoc 18800000.wifi: snoc probe
>
>
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 34:27:92:82:48:ec brd ff:ff:ff:ff:ff:ff
>
> No wlan device at this point.
>
> I got shell-shock from reading these setup steps:
>
> https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN
> https://github.com/jhugo/linux/blob/5.5rc2_wifi/README
>
>
> Jeffrey, Bjorn, Konrad,
> Has someone written idiot-proof (such as myself) steps to enable
> the ath10k core on a msm8998 board?
$ cat /tmp/x.json
[
{"names": ["bus=snoc,qmi-board-id=stinkyboard"], "data": "board_stink.bin"}
]
$ ls -lh board_stink.bin
-rw-rw-r-- 1 konrad konrad 19K Mar 13 16:42 board_stink.bin
$ python3 ~/qca-swiss-army-knife/tools/scripts/ath10k/ath10k-bdencoder -c /tmp/x.json -o board-2.bin
board binary file 'board-2.bin' is created
I believe Kalle aggregates these boardfiles and then uploads a big
combined board-2.bin to linux-firmware nowadays?
Konrad
On Wed, 13 Mar 2024 at 17:09, Marc Gonzalez <[email protected]> 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 missing anything :)
>
> I used buildroot ( https://buildroot.org ) to generate a kernel + rootfs
> for my board (a variation of qcom/msm8998-mtp.dts)
>
> Not sure if I must use the vendor FW blobs? Or if I can use the blobs
> from linux-firmware-20240115.tar.xz (as supported by BR2).
>
>
> All I see from the ath10k driver (with debugging cranked to the max) is:
>
> [ 0.539801] ath10k_snoc 18800000.wifi: Adding to iommu group 0
> [ 0.541941] ath10k_snoc 18800000.wifi: snoc xo-cal-data return -22
> [ 0.543633] ath10k_snoc 18800000.wifi: supply vdd-3.3-ch1 not found, using dummy regulator
> [ 0.544002] ath10k_snoc 18800000.wifi: qmi msa.paddr: 0x0000000094400000 , msa.vaddr: 0x(____ptrval____)
> [ 0.544271] ath10k_snoc 18800000.wifi: snoc probe
>
>
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 34:27:92:82:48:ec brd ff:ff:ff:ff:ff:ff
>
> No wlan device at this point.
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,
please check for tqftpserv messages in syslog.
>
> I got shell-shock from reading these setup steps:
>
> https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN
> https://github.com/jhugo/linux/blob/5.5rc2_wifi/README
These readmes are mostly correct. You don't need qrtr now, it is
provided by the kernel. pd-mapper (protection-domain-mapper),
tqftpserv and rmtfs usually can be installed from your distro.
You can mostly ignore the part for board.bin / board-2.bin for now.
You'll get to that point later, when the driver complains about
missing board data.
Also, if you pick up series at [1], you can put your bdwlan.XXX file
as ath10k/WCN3990/hw1.0/board.bin and skip all the json and stuff.
This will work for the bringup, then you can follow the process at [2]
and submit your file for inclusion into board-2.bin.
[1] https://lore.kernel.org/ath10k/[email protected]/
[2] https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles
>
>
> Jeffrey, Bjorn, Konrad,
> Has someone written idiot-proof (such as myself) steps to enable
> the ath10k core on a msm8998 board?
>
> I'm still not quite sure where linux-firmware.git fits into all this.
>
> Regards
>
--
With best wishes
Dmitry
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.
>>>
>>> Yeah, please do test this to make sure we are not missing anything :)
>>
>> I used buildroot ( https://buildroot.org ) to generate a kernel + rootfs
>> for my board (a variation of qcom/msm8998-mtp.dts)
>>
>> Not sure if I must use the vendor FW blobs? Or if I can use the blobs
>> from linux-firmware-20240115.tar.xz (as supported by BR2).
>>
>>
>> All I see from the ath10k driver (with debugging cranked to the max) is:
>>
>> [ 0.539801] ath10k_snoc 18800000.wifi: Adding to iommu group 0
>> [ 0.541941] ath10k_snoc 18800000.wifi: snoc xo-cal-data return -22
>> [ 0.543633] ath10k_snoc 18800000.wifi: supply vdd-3.3-ch1 not found, using dummy regulator
>> [ 0.544002] ath10k_snoc 18800000.wifi: qmi msa.paddr: 0x0000000094400000 , msa.vaddr: 0x(____ptrval____)
>> [ 0.544271] ath10k_snoc 18800000.wifi: snoc probe
>>
>>
>> # ip link
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
>> link/ether 34:27:92:82:48:ec brd ff:ff:ff:ff:ff:ff
>>
>> No wlan device at this point.
>
> 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,
> please check for tqftpserv messages in syslog.
I first tried using buildroot, which doesn't package these tools AFAICT.
I have now generated a debian rootfs, which does package them.
>> I got shell-shock from reading these setup steps:
>>
>> https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN
>> https://github.com/jhugo/linux/blob/5.5rc2_wifi/README
>
> These readmes are mostly correct. You don't need qrtr now, it is
> provided by the kernel. pd-mapper (protection-domain-mapper),
> tqftpserv and rmtfs usually can be installed from your distro.
Can you explain a little bit why all the steps are required
just to be able to talk to the ath10k IP block?
It's just an MMIO device, right?
wifi: wifi@18800000 {
compatible = "qcom,wcn3990-wifi";
reg = <0x18800000 0x800000>;
reg-names = "membase";
Is the IP block behind some kind of switch that must be programmed
by a remote processor on the SoC?
Regards
On Thu, 14 Mar 2024 at 14:31, Marc Gonzalez <[email protected]> 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 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 buildroot ( https://buildroot.org ) to generate a kernel + rootfs
> >> for my board (a variation of qcom/msm8998-mtp.dts)
> >>
> >> Not sure if I must use the vendor FW blobs? Or if I can use the blobs
> >> from linux-firmware-20240115.tar.xz (as supported by BR2).
> >>
> >>
> >> All I see from the ath10k driver (with debugging cranked to the max) is:
> >>
> >> [ 0.539801] ath10k_snoc 18800000.wifi: Adding to iommu group 0
> >> [ 0.541941] ath10k_snoc 18800000.wifi: snoc xo-cal-data return -22
> >> [ 0.543633] ath10k_snoc 18800000.wifi: supply vdd-3.3-ch1 not found, using dummy regulator
> >> [ 0.544002] ath10k_snoc 18800000.wifi: qmi msa.paddr: 0x0000000094400000 , msa.vaddr: 0x(____ptrval____)
> >> [ 0.544271] ath10k_snoc 18800000.wifi: snoc probe
> >>
> >>
> >> # ip link
> >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >> 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
> >> link/ether 34:27:92:82:48:ec brd ff:ff:ff:ff:ff:ff
> >>
> >> No wlan device at this point.
> >
> > 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,
> > please check for tqftpserv messages in syslog.
>
> I first tried using buildroot, which doesn't package these tools AFAICT.
> I have now generated a debian rootfs, which does package them.
>
>
> >> I got shell-shock from reading these setup steps:
> >>
> >> https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN
> >> https://github.com/jhugo/linux/blob/5.5rc2_wifi/README
> >
> > These readmes are mostly correct. You don't need qrtr now, it is
> > provided by the kernel. pd-mapper (protection-domain-mapper),
> > tqftpserv and rmtfs usually can be installed from your distro.
>
> Can you explain a little bit why all the steps are required
> just to be able to talk to the ath10k IP block?
>
> It's just an MMIO device, right?
>
> wifi: wifi@18800000 {
> compatible = "qcom,wcn3990-wifi";
> reg = <0x18800000 0x800000>;
> reg-names = "membase";
>
> Is the IP block behind some kind of switch that must be programmed
> by a remote processor on the SoC?
It has a separate core, with the firmware to load, etc. For some
reason the firmware is loaded in a complex way, via the modem
remoteproc.
--
With best wishes
Dmitry
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?)
>>
>> Was the issue eventually fixed?
>> (Probably fixed, otherwise newer devices would be affected)
>
> 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.
>
> So my preference would be to use the firmware capability in the board
> file that Kalle has recommended.
Marc,
I finally have an engineer who wants to research this further.
Can you provide the kernel log that shows the firmware version being used?
/jeff
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 devices were affected? (All msm8998? A subset of msm8998?)
>>>
>>> Was the issue eventually fixed?
>>> (Probably fixed, otherwise newer devices would be affected)
>>
>> 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.
>>
>> So my preference would be to use the firmware capability in the board
>> file that Kalle has recommended.
>
> Marc,
> I finally have an engineer who wants to research this further.
> Can you provide the kernel log that shows the firmware version being used?
Hello Jeff,
Is this the line you're after:
[ 32.367011] ath10k_snoc 18800000.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
Hopefully, my Debian setup will soon be 100% functional
so I can easily tweak the kernel, and add more logs.
Bonus question:
Is it legal for my company to publish our versions of qcom firmwares on linux-firmware?
(Perhaps a generic set of FWs would work; but AFAIU, there is some kind
of signature verification at some point)
Regards
On 3/14/2024 10:52 AM, Marc Gonzalez wrote:
> Is this the line you're after:
> [ 32.367011] ath10k_snoc 18800000.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 company to publish our versions of qcom firmwares on linux-firmware?
> (Perhaps a generic set of FWs would work; but AFAIU, there is some kind
> of signature verification at some point)
I'll let Kalle respond to that since he has more expertise.
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,
> please check for tqftpserv messages in syslog.
I have not been able to reach a functional system yet :(
(I'll provide the kernel log at the end.)
These are the processes running in user-space:
# ps aux | grep -v ' \['
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.4 0.2 21640 10752 ? Ss 17:43 0:03 /sbin/init
root 203 0.1 0.2 34268 11272 ? Ss 17:43 0:01 /usr/lib/systemd/systemd-journald
root 232 0.1 0.1 24552 5888 ? Ss 17:43 0:01 /usr/lib/systemd/systemd-udevd
root 291 0.0 0.0 6704 2048 ? Ss 17:44 0:00 /usr/sbin/cron -f
root 295 0.0 0.0 2204 1152 ? Ss 17:44 0:00 /usr/bin/qrtr-ns -f 1
root 297 0.0 0.1 16704 7128 ? Ss 17:44 0:00 /usr/bin/rmtfs -r -P -s
root 298 0.0 0.0 2336 1152 ? Ss 17:44 0:00 /usr/bin/tqftpserv
root 330 0.0 0.0 4600 1920 ? Ss 17:44 0:00 /usr/sbin/dropbear -EF -p 22 -W 65536
root 336 0.0 0.0 5252 1664 tty1 Ss+ 17:44 0:00 /sbin/agetty -o -p -- \u --noclear - linux
root 338 0.0 0.0 5252 1536 tty2 Ss+ 17:44 0:00 /sbin/agetty -o -p -- \u --noclear - linux
root 339 0.0 0.0 5252 1408 tty3 Ss+ 17:44 0:00 /sbin/agetty -o -p -- \u --noclear - linux
root 340 0.0 0.0 5252 1664 tty4 Ss+ 17:44 0:00 /sbin/agetty -o -p -- \u --noclear - linux
root 341 0.0 0.0 5252 1536 tty5 Ss+ 17:44 0:00 /sbin/agetty -o -p -- \u --noclear - linux
root 342 0.0 0.0 5252 1408 tty6 Ss+ 17:44 0:00 /sbin/agetty -o -p -- \u --noclear - linux
root 343 0.0 0.0 9012 2816 ttyMSM0 Ss 17:44 0:00 /bin/login -p --
root 365 0.0 0.0 7088 3456 ttyMSM0 S+ 17:44 0:00 -bash
root 369 0.0 0.0 4600 2560 ? Ss 17:44 0:00 /usr/sbin/dropbear -EF -p 22 -W 65536 -2 7
root 370 0.0 0.0 7088 3584 pts/0 Ss 17:44 0:00 -bash
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 17:44:02 venus pd-mapper[347]: no pd maps available
Is the package supposed to install one or several "pd maps" ?
The system journal contains:
Feb 27 17:43:57 venus systemd-journald[203]: Journal started
Feb 27 17:43:57 venus systemd-journald[203]: Runtime Journal (/run/log/journal/0f2e92c39e6f4f3fa6585b56f928c8ed) is 8.0M, max 73.3M, 65.3M free.
Feb 27 17:43:57 venus systemd-random-seed[211]: Kernel entropy pool is not initialized yet, waiting until it is.
Feb 27 17:43:57 venus systemd-journald[203]: Time spent on flushing to /var/log/journal/0f2e92c39e6f4f3fa6585b56f928c8ed is 19.931ms for 3 entries.
Feb 27 17:43:57 venus systemd-journald[203]: System Journal (/var/log/journal/0f2e92c39e6f4f3fa6585b56f928c8ed) is 8.0M, max 4.0G, 3.9G free.
Feb 27 17:43:58 venus systemd-udevd[232]: Using default interface naming scheme 'v255'.
Feb 27 17:44:01 venus cron[291]: (CRON) INFO (pidfile fd = 3)
Feb 27 17:44:01 venus qrtr-ns[295]: ERROR qrtr-ns: nameserver already running, going dormant: Address already in use
Feb 27 17:44:01 venus pd-mapper[296]: no pd maps available
Feb 27 17:44:01 venus cron[291]: (CRON) INFO (Running @reboot jobs)
Feb 27 17:44:01 venus pd-mapper[308]: no pd maps available
Feb 27 17:44:01 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_1', rejecting
Feb 27 17:44:01 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_2', rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus pd-mapper[328]: no pd maps available
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] WRQ: /readwrite/server_check.txt (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:01 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octetinvalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:01 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:02 venus tqftpserv[298]: )
Feb 27 17:44:02 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:02 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:02 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:02 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:02 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:02 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:02 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:02 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
[...]
Feb 27 17:44:10 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2), reject
Feb 27 17:44:10 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/firmware/image/wlanmdsp.mbn (octet)
Feb 27 17:44:10 venus tqftpserv[298]: [TQFTP] unable to open /readonly/firmware/image/wlanmdsp.mbn (9), reject
Feb 27 17:44:10 venus tqftpserv[298]: [TQFTP] RRQ: /readonly/vendor/firmware/wlanmdsp.mbn (octet)
Feb 27 17:44:10 venus tqftpserv[298]: [TQFTP] unable to open /readonly/vendor/firmware/wlanmdsp.mbn (2)invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:10 venus tqftpserv[298]: invalid path /readonly/vendor/firmware/wlanmdsp.mbn, rejecting
Feb 27 17:44:10 venus tqftpserv[298]: ERROR libqrtr: socket(AF_QIPCRTR): Too many open files
Feb 27 17:44:15 venus login[365]: ROOT LOGIN on '/dev/ttyMSM0'
Feb 27 17:44:31 venus tqftpserv[298]: ERROR libqrtr: socket(AF_QIPCRTR): Too many open files
Feb 27 17:44:41 venus tqftpserv[298]: ERROR libqrtr: socket(AF_QIPCRTR): Too many open files
Feb 27 17:44:42 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_1', rejecting
Feb 27 17:44:42 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_2', rejecting
Feb 27 17:44:42 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:45:12 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:45:22 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:45:24 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_1', rejecting
Feb 27 17:45:24 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_2', rejecting
Feb 27 17:45:24 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:45:54 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:46:04 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:46:04 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_1', rejecting
Feb 27 17:46:04 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_2', rejecting
Feb 27 17:46:05 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:46:35 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:46:45 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:46:45 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_1', rejecting
Feb 27 17:46:45 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_2', rejecting
Feb 27 17:46:46 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:47:16 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:47:26 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Feb 27 17:47:26 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_1', rejecting
Feb 27 17:47:26 venus rmtfs[297]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_2', rejecting
Feb 27 17:47:27 venus tqftpserv[298]: tqftpserv: failed top open /tmp/tqftpserv: Too many open files
Corresponding kernel logs:
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x51af8014]
[ 0.000000] Linux version 6.7.0-10016-g0cea4ace5459 (mgonzalez@venus) (aarch64-none-linux-gnu-gcc (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205, GNU ld (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 2.39.0.20221210) #3 SMP PREEMPT Mon Mar 18 16:59:35 CET 2024
[ 0.000000] KASLR disabled due to lack of seed
[ 0.000000] Machine model: Freebox Delta
[ 0.000000] earlycon: msm_serial_dm0 at MMIO 0x000000000c1b0000 (options '')
[ 0.000000] printk: legacy bootconsole [msm_serial_dm0] enabled
[ 0.000000] efi: UEFI not found.
[ 0.000000] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!
[ 0.000000] OF: reserved mem: 0x00000000bfffc000..0x00000000bfffffff (16 KiB) nomap non-reusable mpss-metadata
[ 0.000000] OF: reserved mem: 0x0000000085800000..0x0000000085dfffff (6144 KiB) nomap non-reusable memory@85800000
[ 0.000000] OF: reserved mem: 0x0000000085e00000..0x0000000085efffff (1024 KiB) nomap non-reusable memory@85e00000
[ 0.000000] OF: reserved mem: 0x0000000086000000..0x00000000861fffff (2048 KiB) nomap non-reusable smem-mem@86000000
[ 0.000000] OF: reserved mem: 0x0000000086200000..0x0000000088efffff (46080 KiB) nomap non-reusable memory@86200000
[ 0.000000] OF: reserved mem: 0x0000000088f00000..0x00000000890fffff (2048 KiB) nomap non-reusable memory@88f00000
[ 0.000000] OF: reserved mem: 0x000000008ab00000..0x000000008b1fffff (7168 KiB) nomap non-reusable memory@8ab00000
[ 0.000000] OF: reserved mem: 0x000000008b200000..0x000000008cbfffff (26624 KiB) nomap non-reusable memory@8b200000
[ 0.000000] OF: reserved mem: 0x000000008cc00000..0x0000000093bfffff (114688 KiB) nomap non-reusable memory@8cc00000
[ 0.000000] OF: reserved mem: 0x0000000093c00000..0x00000000940fffff (5120 KiB) nomap non-reusable memory@93c00000
[ 0.000000] OF: reserved mem: 0x0000000094100000..0x00000000942fffff (2048 KiB) nomap non-reusable memory@94100000
[ 0.000000] OF: reserved mem: 0x0000000094300000..0x00000000943fffff (1024 KiB) nomap non-reusable memory@95600000
[ 0.000000] OF: reserved mem: 0x0000000094400000..0x00000000944fffff (1024 KiB) nomap non-reusable memory@95700000
[ 0.000000] Reserved memory: created DMA memory pool at 0x00000000f5400000, size 0 MiB
[ 0.000000] OF: reserved mem: initialized node gpu@f5400000, compatible id shared-dma-pool
[ 0.000000] OF: reserved mem: 0x00000000f5400000..0x00000000f5401fff (8 KiB) nomap non-reusable gpu@f5400000
[ 0.000000] NUMA: No NUMA configuration found
[ 0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x000000017e3fffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x17dbf59c0-0x17dbf7fff]
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000080000000-0x00000000ffffffff]
[ 0.000000] DMA32 empty
[ 0.000000] Normal [mem 0x0000000100000000-0x000000017e3fffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080000000-0x00000000857fffff]
[ 0.000000] node 0: [mem 0x0000000085800000-0x0000000085efffff]
[ 0.000000] node 0: [mem 0x0000000085f00000-0x0000000085ffffff]
[ 0.000000] node 0: [mem 0x0000000086000000-0x00000000890fffff]
[ 0.000000] node 0: [mem 0x0000000089100000-0x000000008aafffff]
[ 0.000000] node 0: [mem 0x000000008ab00000-0x00000000944fffff]
[ 0.000000] node 0: [mem 0x0000000094500000-0x00000000bfffbfff]
[ 0.000000] node 0: [mem 0x00000000bfffc000-0x00000000bfffffff]
[ 0.000000] node 0: [mem 0x00000000c0000000-0x00000000f53fffff]
[ 0.000000] node 0: [mem 0x00000000f5400000-0x00000000f5401fff]
[ 0.000000] node 0: [mem 0x00000000f5402000-0x000000017e3fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000017e3fffff]
[ 0.000000] On node 0, zone Normal: 7168 pages in unavailable ranges
[ 0.000000] cma: Reserved 32 MiB at 0x00000000fe000000 on node -1
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.0 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.0
[ 0.000000] psci: OSI mode supported.
[ 0.000000] psci: [Firmware Bug]: failed to set PC mode: -3
[ 0.000000] percpu: Embedded 22 pages/cpu s49640 r8192 d32280 u90112
[ 0.000000] pcpu-alloc: s49640 r8192 d32280 u90112 alloc=22*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] CPU features: detected: GIC system register CPU interface
[ 0.000000] CPU features: detected: Spectre-v4
[ 0.000000] CPU features: detected: ARM erratum 845719
[ 0.000000] alternatives: applying boot alternatives
[ 0.000000] Kernel command line: earlycon=msm_serial_dm,0xc1b0000 clk_ignore_unused ip=dhcp root=/dev/nfs rw debug systemd.log_level=info
[ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[ 0.000000] Fallback order for Node 0: 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 1025136
[ 0.000000] Policy zone: Normal
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] software IO TLB: area num 8.
[ 0.000000] software IO TLB: mapped [mem 0x00000000fa000000-0x00000000fe000000] (64MB)
[ 0.000000] Memory: 3719276K/4165632K available (17408K kernel code, 3212K rwdata, 24488K rodata, 5632K init, 541K bss, 413588K reserved, 32768K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] GICv3: 608 SPIs implemented
[ 0.000000] GICv3: 0 Extended SPIs implemented
[ 0.000000] Root IRQ handler: gic_handle_irq
[ 0.000000] GICv3: GICv3 features: 16 PPIs
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000017b00000
[ 0.000000] ITS: No ITS available, not enabling LPIs
[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000] arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[ 0.000000] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[ 0.010935] Console: colour dummy device 80x25
[ 0.018737] printk: legacy console [tty0] enabled
[ 0.023246] printk: legacy bootconsole [msm_serial_dm0] disabled
[ 0.028082] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
[ 0.028099] pid_max: default: 32768 minimum: 301
[ 0.028167] LSM: initializing lsm=capability,integrity
[ 0.028256] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 0.028278] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 0.029799] RCU Tasks: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
[ 0.029860] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
[ 0.030038] rcu: Hierarchical SRCU implementation.
[ 0.030047] rcu: Max phase no-delay instances is 1000.
[ 0.031289] EFI services will not be available.
[ 0.031564] smp: Bringing up secondary CPUs ...
[ 0.033830] Detected VIPT I-cache on CPU1
[ 0.033894] GICv3: CPU1: found redistributor 1 region 0:0x0000000017b20000
[ 0.033967] CPU1: Booted secondary processor 0x0000000001 [0x51af8014]
[ 0.036318] Detected VIPT I-cache on CPU2
[ 0.036362] GICv3: CPU2: found redistributor 2 region 0:0x0000000017b40000
[ 0.036415] CPU2: Booted secondary processor 0x0000000002 [0x51af8014]
[ 0.038958] Detected VIPT I-cache on CPU3
[ 0.039003] GICv3: CPU3: found redistributor 3 region 0:0x0000000017b60000
[ 0.039054] CPU3: Booted secondary processor 0x0000000003 [0x51af8014]
[ 0.042127] CPU features: detected: Spectre-v2
[ 0.042164] Detected VIPT I-cache on CPU4
[ 0.042310] GICv3: CPU4: found redistributor 100 region 0:0x0000000017b80000
[ 0.042404] CPU4: Booted secondary processor 0x0000000100 [0x51af8001]
[ 0.045680] Detected VIPT I-cache on CPU5
[ 0.045833] GICv3: CPU5: found redistributor 101 region 0:0x0000000017ba0000
[ 0.045923] CPU5: Booted secondary processor 0x0000000101 [0x51af8001]
[ 0.049428] Detected VIPT I-cache on CPU6
[ 0.049591] GICv3: CPU6: found redistributor 102 region 0:0x0000000017bc0000
[ 0.049682] CPU6: Booted secondary processor 0x0000000102 [0x51af8001]
[ 0.053450] Detected VIPT I-cache on CPU7
[ 0.053622] GICv3: CPU7: found redistributor 103 region 0:0x0000000017be0000
[ 0.053712] CPU7: Booted secondary processor 0x0000000103 [0x51af8001]
[ 0.053903] smp: Brought up 1 node, 8 CPUs
[ 0.054029] SMP: Total of 8 processors activated.
[ 0.054037] CPU: All CPU(s) started at EL1
[ 0.054061] CPU features: detected: 32-bit EL0 Support
[ 0.054070] CPU features: detected: 32-bit EL1 Support
[ 0.054080] CPU features: detected: CRC32 instructions
[ 0.054159] alternatives: applying system-wide alternatives
[ 0.056828] devtmpfs: initialized
[ 0.066961] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.066999] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[ 0.067843] pinctrl core: initialized pinctrl subsystem
[ 0.068367] DMI not present or invalid.
[ 0.069294] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.070111] DMA: preallocated 512 KiB GFP_KERNEL pool for atomic allocations
[ 0.070246] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[ 0.070424] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[ 0.070460] audit: initializing netlink subsys (disabled)
[ 0.070597] audit: type=2000 audit(0.056:1): state=initialized audit_enabled=0 res=1
[ 0.070936] thermal_sys: Registered thermal governor 'step_wise'
[ 0.070942] thermal_sys: Registered thermal governor 'power_allocator'
[ 0.070996] cpuidle: using governor menu
[ 0.071116] NET: Registered PF_QIPCRTR protocol family
[ 0.071260] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[ 0.071471] ASID allocator initialised with 65536 entries
[ 0.071879] Serial: AMBA PL011 UART driver
[ 0.071932] builtin-fbxserial: Found valid serial infos !
[ 0.081977] platform 1da4000.ufshc: Fixed dependency cycle(s) with /soc@0/phy@1da7000
[ 0.087287] platform c8c0000.clock-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-phy@c9a0600
[ 0.087544] platform c900000.display-subsystem: Fixed dependency cycle(s) with /soc@0/interconnect@1744000
[ 0.087606] platform c900000.display-subsystem: Fixed dependency cycle(s) with /soc@0/clock-controller@c8c0000
[ 0.090183] platform hdmi-bridge: Fixed dependency cycle(s) with /hdmi-out/port/endpoint
[ 0.090894] Modules: 19888 pages in range for non-PLT usage
[ 0.090898] Modules: 511408 pages in range for PLT usage
[ 0.091555] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
[ 0.091572] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
[ 0.091583] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages
[ 0.091592] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page
[ 0.091601] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
[ 0.091611] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
[ 0.091621] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages
[ 0.091630] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page
[ 0.092767] ACPI: Interpreter disabled.
[ 0.094364] iommu: Default domain type: Translated
[ 0.094375] iommu: DMA domain TLB invalidation policy: strict mode
[ 0.094606] SCSI subsystem initialized
[ 0.094722] libata version 3.00 loaded.
[ 0.094891] usbcore: registered new interface driver usbfs
[ 0.094920] usbcore: registered new interface driver hub
[ 0.094952] usbcore: registered new device driver usb
[ 0.095189] mc: Linux media interface: v0.10
[ 0.095239] videodev: Linux video capture interface: v2.00
[ 0.095307] pps_core: LinuxPPS API ver. 1 registered
[ 0.095317] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]>
[ 0.095336] PTP clock support registered
[ 0.095368] EDAC MC: Ver: 3.0.0
[ 0.095672] scmi_core: SCMI protocol bus registered
[ 0.095749] qcom_scm: convention: smc arm 64
[ 0.097724] FPGA manager framework
[ 0.097806] Advanced Linux Sound Architecture Driver Initialized.
[ 0.098383] Bluetooth: Core ver 2.22
[ 0.098409] NET: Registered PF_BLUETOOTH protocol family
[ 0.098419] Bluetooth: HCI device and connection manager initialized
[ 0.098432] Bluetooth: HCI socket layer initialized
[ 0.098443] Bluetooth: L2CAP socket layer initialized
[ 0.098459] Bluetooth: SCO socket layer initialized
[ 0.098795] vgaarb: loaded
[ 0.099245] clocksource: Switched to clocksource arch_sys_counter
[ 0.099429] VFS: Disk quotas dquot_6.6.0
[ 0.099460] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.099612] pnp: PnP ACPI: disabled
[ 0.107847] NET: Registered PF_INET protocol family
[ 0.107991] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear)
[ 0.110159] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
[ 0.110204] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.110260] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
[ 0.110431] TCP bind hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[ 0.111114] TCP: Hash tables configured (established 32768 bind 32768)
[ 0.111218] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
[ 0.111337] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
[ 0.111508] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.111881] RPC: Registered named UNIX socket transport module.
[ 0.111892] RPC: Registered udp transport module.
[ 0.111900] RPC: Registered tcp transport module.
[ 0.111906] RPC: Registered tcp-with-tls transport module.
[ 0.111914] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.112718] PCI: CLS 0 bytes, default 64
[ 0.112829] s3: Bringing 0uV into 1352000-1352000uV
[ 0.113015] s4: Bringing 0uV into 1800000-1800000uV
[ 0.113143] s5: Bringing 0uV into 1904000-1904000uV
[ 0.113272] s7: Bringing 0uV into 900000-900000uV
[ 0.113524] l1: Bringing 0uV into 880000-880000uV
[ 0.113654] l2: Bringing 0uV into 1200000-1200000uV
[ 0.113792] l3: Bringing 0uV into 1000000-1000000uV
[ 0.113926] l5: Bringing 0uV into 800000-800000uV
[ 0.114056] l6: Bringing 0uV into 1808000-1808000uV
[ 0.114206] l7: Bringing 0uV into 1800000-1800000uV
[ 0.114335] l8: Bringing 0uV into 1200000-1200000uV
[ 0.114468] l9: Bringing 0uV into 1808000-1808000uV
[ 0.114619] l10: Bringing 0uV into 1808000-1808000uV
[ 0.114760] l11: Bringing 0uV into 1000000-1000000uV
[ 0.114897] l12: Bringing 0uV into 1800000-1800000uV
[ 0.115041] l13: Bringing 0uV into 1808000-1808000uV
[ 0.115188] l14: Bringing 0uV into 1880000-1880000uV
[ 0.115350] l15: Bringing 0uV into 1800000-1800000uV
[ 0.115499] l16: Bringing 0uV into 2704000-2704000uV
[ 0.115642] l17: Bringing 0uV into 1304000-1304000uV
[ 0.115781] l18: Bringing 0uV into 2704000-2704000uV
[ 0.115939] l19: Bringing 0uV into 3008000-3008000uV
[ 0.116083] l20: Bringing 0uV into 2960000-2960000uV
[ 0.116249] l21: Bringing 0uV into 2960000-2960000uV
[ 0.116398] l22: Bringing 0uV into 2864000-2864000uV
[ 0.116547] l23: Bringing 0uV into 3312000-3312000uV
[ 0.116707] l24: Bringing 0uV into 3088000-3088000uV
[ 0.116855] l25: Bringing 0uV into 3104000-3104000uV
[ 0.117006] l26: Bringing 0uV into 1200000-1200000uV
[ 0.117165] l28: Bringing 0uV into 3008000-3008000uV
[ 0.118145] kvm [1]: HYP mode not available
[ 0.119172] Initialise system trusted keyrings
[ 0.119420] workingset: timestamp_bits=42 max_order=20 bucket_order=0
[ 0.119660] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.119925] NFS: Registering the id_resolver key type
[ 0.119949] Key type id_resolver registered
[ 0.119958] Key type id_legacy registered
[ 0.119979] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 0.119991] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[ 0.120141] 9p: Installing v9fs 9p2000 file system support
[ 0.218778] Key type asymmetric registered
[ 0.218826] Asymmetric key parser 'x509' registered
[ 0.218961] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 239)
[ 0.219005] io scheduler mq-deadline registered
[ 0.219031] io scheduler kyber registered
[ 0.233350] EINJ: ACPI disabled.
[ 0.254810] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.260412] msm_serial: driver initialized
[ 0.262381] arm-smmu 1680000.iommu: probing hardware configuration...
[ 0.262426] arm-smmu 1680000.iommu: SMMUv2 with:
[ 0.262487] arm-smmu 1680000.iommu: stage 1 translation
[ 0.262526] arm-smmu 1680000.iommu: address translation ops
[ 0.262558] arm-smmu 1680000.iommu: non-coherent table walk
[ 0.262590] arm-smmu 1680000.iommu: (IDR0.CTTW overridden by FW configuration)
[ 0.262628] arm-smmu 1680000.iommu: stream matching with 16 register groups
[ 0.262690] arm-smmu 1680000.iommu: 6 context banks (0 stage-2 only)
[ 0.263094] arm-smmu 1680000.iommu: Supported page sizes: 0x63315000
[ 0.263137] arm-smmu 1680000.iommu: Stage-1: 36-bit VA -> 36-bit IPA
[ 0.263512] arm-smmu 1680000.iommu: preserved 0 boot mappings
[ 0.265555] arm-smmu 16c0000.iommu: probing hardware configuration...
[ 0.265601] arm-smmu 16c0000.iommu: SMMUv2 with:
[ 0.265658] arm-smmu 16c0000.iommu: stage 1 translation
[ 0.265698] arm-smmu 16c0000.iommu: address translation ops
[ 0.265729] arm-smmu 16c0000.iommu: non-coherent table walk
[ 0.265759] arm-smmu 16c0000.iommu: (IDR0.CTTW overridden by FW configuration)
[ 0.265796] arm-smmu 16c0000.iommu: stream matching with 14 register groups
[ 0.265857] arm-smmu 16c0000.iommu: 10 context banks (0 stage-2 only)
[ 0.266199] arm-smmu 16c0000.iommu: Supported page sizes: 0x63315000
[ 0.266243] arm-smmu 16c0000.iommu: Stage-1: 36-bit VA -> 36-bit IPA
[ 0.266529] arm-smmu 16c0000.iommu: preserved 0 boot mappings
[ 0.288283] loop: module loaded
[ 0.294030] spmi spmi-0: PMIC arbiter version v3 (0x30000000)
[ 0.309304] s1: Bringing 752000uV into 988000-988000uV
[ 0.314466] tun: Universal TUN/TAP device driver, 1.6
[ 0.320136] ath10k_snoc 18800000.wifi: Adding to iommu group 0
[ 0.322321] ath10k_snoc 18800000.wifi: snoc xo-cal-data return -22
[ 0.324011] ath10k_snoc 18800000.wifi: supply vdd-3.3-ch1 not found, using dummy regulator
[ 0.324358] ath10k_snoc 18800000.wifi: qmi msa.paddr: 0x0000000094400000 , msa.vaddr: 0x(____ptrval____)
[ 0.324594] ath10k_snoc 18800000.wifi: snoc probe
[ 0.325081] usbcore: registered new interface driver rtl8xxxu
[ 0.325784] VFIO - User Level meta-driver version: 0.3
[ 0.329634] usbcore: registered new interface driver usb-storage
[ 0.336508] rtc-pm8xxx 800f000.spmi:pmic@0:rtc@6000: registered as rtc0
[ 0.336614] rtc-pm8xxx 800f000.spmi:pmic@0:rtc@6000: setting system clock to 1970-01-01T00:00:10 UTC (10)
[ 0.336978] i2c_dev: i2c /dev entries driver
[ 0.339118] IR NEC protocol handler initialized
[ 0.339150] IR RC5(x/sz) protocol handler initialized
[ 0.339175] IR RC6 protocol handler initialized
[ 0.343522] input: pm8941_pwrkey as /devices/platform/soc@0/800f000.spmi/spmi-0/0-00/800f000.spmi:pmic@0:pon@800/800f000.spmi:pmic@0:pon@800:pwrkey/input/input0
[ 0.361278] Bluetooth: HCI UART driver ver 2.3
[ 0.361323] Bluetooth: HCI UART protocol H4 registered
[ 0.361355] Bluetooth: HCI UART protocol BCSP registered
[ 0.361427] Bluetooth: HCI UART protocol LL registered
[ 0.361486] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 0.361695] Bluetooth: HCI UART protocol Broadcom registered
[ 0.361752] Bluetooth: HCI UART protocol QCA registered
[ 0.361806] Bluetooth: HCI UART protocol Marvell registered
[ 0.361879] usbcore: registered new interface driver btusb
[ 0.365582] sdhci: Secure Digital Host Controller Interface driver
[ 0.365618] sdhci: Copyright(c) Pierre Ossman
[ 0.366520] Synopsys Designware Multimedia Card Interface Driver
[ 0.368060] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.374502] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.376699] hid: raw HID events driver (C) Jiri Kosina
[ 0.379404] usbcore: registered new interface driver usbhid
[ 0.379585] usbhid: USB HID core driver
[ 0.449175] NET: Registered PF_PACKET protocol family
[ 0.449806] Bluetooth: RFCOMM TTY layer initialized
[ 0.449860] Bluetooth: RFCOMM socket layer initialized
[ 0.449908] Bluetooth: RFCOMM ver 1.11
[ 0.449952] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 0.449991] Bluetooth: BNEP socket layer initialized
[ 0.450017] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 0.450049] Bluetooth: HIDP socket layer initialized
[ 0.450219] 9pnet: Installing 9P2000 support
[ 0.450390] Key type dns_resolver registered
[ 0.474122] registered taskstats version 1
[ 0.474498] Loading compiled-in X.509 certificates
[ 0.531526] qcom-qusb2-phy c012000.phy: supply vdd not found, using dummy regulator
[ 0.532359] qcom-qusb2-phy c012000.phy: Registered Qcom-QUSB2 phy
[ 0.535633] qcom-pcie 1c00000.pcie: supply vdda not found, using dummy regulator
[ 0.535897] qcom-pcie 1c00000.pcie: supply vddpe-3v3 not found, using dummy regulator
[ 0.536147] qcom-pcie 1c00000.pcie: host bridge /soc@0/pcie@1c00000 ranges:
[ 0.536253] qcom-pcie 1c00000.pcie: IO 0x001b200000..0x001b2fffff -> 0x0000000000
[ 0.536323] qcom-pcie 1c00000.pcie: MEM 0x001b300000..0x001bffffff -> 0x001b300000
[ 0.584583] msm_serial c171000.serial: msm_serial: detected port #1
[ 0.584670] msm_serial c171000.serial: uartclk = 19200000
[ 0.585350] c171000.serial: ttyMSM1 at MMIO 0xc171000 (irq = 59, base_baud = 1200000) is a MSM
[ 0.585835] serial serial0: tty port ttyMSM1 registered
[ 0.587096] msm_serial c1b0000.serial: msm_serial: detected port #0
[ 0.587169] msm_serial c1b0000.serial: uartclk = 1843200
[ 0.587738] c1b0000.serial: ttyMSM0 at MMIO 0xc1b0000 (irq = 60, base_baud = 115200) is a MSM
[ 0.587813] msm_serial: console setup on port #0
[ 0.587943] printk: legacy console [ttyMSM0] enabled
[ 0.649910] qcom-pcie 1c00000.pcie: iATU: unroll F, 32 ob, 8 ib, align 4K, limit 4G
[ 0.654705] arm-smmu 5040000.iommu: probing hardware configuration...
[ 0.655406] Bluetooth: hci0: setting up wcn399x
[ 0.660410] qcom-pcie 1c00000.pcie: Invalid eDMA IRQs found
[ 0.759304] qcom-pcie 1c00000.pcie: PCIe Gen.1 x1 link up
[ 0.764221] arm-smmu 5040000.iommu: SMMUv2 with:
[ 0.775309] qcom-pcie 1c00000.pcie: PCI host bridge to bus 0000:00
[ 0.784943] arm-smmu 5040000.iommu: stage 1 translation
[ 0.792727] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.800937] arm-smmu 5040000.iommu: address translation ops
[ 0.800952] arm-smmu 5040000.iommu: non-coherent table walk
[ 0.800964] arm-smmu 5040000.iommu: (IDR0.CTTW overridden by FW configuration)
[ 0.800977] arm-smmu 5040000.iommu: stream matching with 3 register groups
[ 0.801012] Bluetooth: hci0: Frame reassembly failed (-84)
[ 0.810965] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff]
[ 0.815178] arm-smmu 5040000.iommu: 3 context banks (0 stage-2 only)
[ 0.822228] pci_bus 0000:00: root bus resource [mem 0x1b300000-0x1bffffff]
[ 0.822284] pci 0000:00:00.0: [17cb:0105] type 01 class 0x060400
[ 0.827706] arm-smmu 5040000.iommu: Supported page sizes: 0x63315000
[ 0.830325] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x00000fff]
[ 0.836290] arm-smmu 5040000.iommu: Stage-1: 48-bit VA -> 36-bit IPA
[ 0.840132] pci 0000:00:00.0: PME# supported from D0 D3hot
[ 0.845689] arm-smmu 5040000.iommu: preserved 0 boot mappings
[ 0.863885] pci 0000:01:00.0: [1969:1083] type 00 class 0x020000
[ 0.869632] arm-smmu cd00000.iommu: probing hardware configuration...
[ 0.872814] pci 0000:01:00.0: reg 0x10: [mem 0x1b300000-0x1b33ffff 64bit]
[ 0.878086] arm-smmu cd00000.iommu: SMMUv2 with:
[ 0.884627] pci 0000:01:00.0: reg 0x18: [io 0x1b200000-0x1b20007f]
[ 0.890609] arm-smmu cd00000.iommu: stage 1 translation
[ 0.898599] pci 0000:01:00.0: [Firmware Bug]: disabling VPD access (can't determine size of non-standard VPD format)
[ 0.903081] arm-smmu cd00000.iommu: address translation ops
[ 0.909301] pci 0000:01:00.0: quirk_blacklist_vpd+0x0/0x34 took 10452 usecs
[ 0.912077] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.915599] arm-smmu cd00000.iommu: non-coherent table walk
[ 0.936133] pci 0000:00:00.0: BAR 8: assigned [mem 0x1b300000-0x1b3fffff]
[ 0.941484] arm-smmu cd00000.iommu: (IDR0.CTTW overridden by FW configuration)
[ 0.946482] pci 0000:00:00.0: BAR 0: assigned [mem 0x1b400000-0x1b400fff]
[ 0.946514] pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
[ 0.951229] arm-smmu cd00000.iommu: stream matching with 54 register groups
[ 0.956090] pci 0000:01:00.0: BAR 0: assigned [mem 0x1b300000-0x1b33ffff 64bit]
[ 0.957580] Bluetooth: hci0: QCA Product ID :0x0000000a
[ 0.957587] Bluetooth: hci0: QCA SOC Version :0x40010214
[ 0.957590] Bluetooth: hci0: QCA ROM Version :0x00000201
[ 0.957593] Bluetooth: hci0: QCA Patch Version:0x00000001
[ 0.961043] arm-smmu cd00000.iommu: 17 context banks (0 stage-2 only)
[ 0.965834] pci 0000:01:00.0: BAR 2: assigned [io 0x1000-0x107f]
[ 0.970075] arm-smmu cd00000.iommu: Supported page sizes: 0x63315000
[ 0.974540] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[ 0.980086] Bluetooth: hci0: QCA controller version 0x02140201
[ 0.980094] Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv
[ 0.981000] arm-smmu cd00000.iommu: Stage-1: 32-bit VA -> 36-bit IPA
[ 0.986993] pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
[ 0.993969] arm-smmu cd00000.iommu: preserved 0 boot mappings
[ 0.997587] pci 0000:00:00.0: bridge window [mem 0x1b300000-0x1b3fffff]
[ 0.998157] atl1c 0000:01:00.0: Adding to iommu group 1
[ 1.455435] Bluetooth: hci0: QCA Downloading qca/crnv21.bin
[ 1.464815] atl1c 0000:01:00.0: enabling device (0000 -> 0002)
[ 1.532273] Bluetooth: hci0: QCA setup on UART is completed
[ 3.013898] spi_qup c175000.spi: IN:block:16, fifo:64, OUT:block:16, fifo:64
[ 3.017632] spidev@0 enforce active low on GPIO handle
[ 3.024550] spidev@3 enforce active low on GPIO handle
[ 3.027057] Bluetooth: hci0: AOSP extensions version v0.96
[ 3.034409] Bluetooth: hci0: AOSP quality report is not supported
[ 3.040386] spi_qup c1b7000.spi: IN:block:16, fifo:64, OUT:block:16, fifo:64
[ 3.063037] Bluetooth: hci0: Frame reassembly failed (-84)
[ 3.071896] Bluetooth: hci0: Frame reassembly failed (-84)
[ 3.150629] rtl8367c_spi spi1.0: RTL8367C driver loaded, chip id=6367 ver=0040
[ 3.232093] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[ 3.232177] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 1
[ 3.236679] xhci-hcd xhci-hcd.1.auto: hcc params 0x0230fe65 hci version 0x110 quirks 0x0000000002000010
[ 3.244169] xhci-hcd xhci-hcd.1.auto: irq 90, io mem 0x0a800000
[ 3.253573] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[ 3.259336] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 2
[ 3.264928] xhci-hcd xhci-hcd.1.auto: Host supports USB 3.0 SuperSpeed
[ 3.274742] hub 1-0:1.0: USB hub found
[ 3.279215] hub 1-0:1.0: 1 port detected
[ 3.283091] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 3.287695] hub 2-0:1.0: USB hub found
[ 3.295002] hub 2-0:1.0: 1 port detected
[ 3.312877] tusb8042 1-0044: supply vdd not found, using dummy regulator
[ 3.313363] tusb8042 1-0044: supply vdd33 not found, using dummy regulator
[ 3.321820] tusb8042 1-0044: hub probed successfully, vid:0451 pid:8240
[ 3.326033] ld6710_fbx 1-0068: probe
[ 3.334032] ld6710_fbx 1-0068: LD6710 chip 00, fw 04
[ 3.335838] ld6710_fbx 1-0068: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
[ 3.352992] ufshcd-qcom 1da4000.ufshc: ufshcd_populate_vreg: Unable to find vdd-hba-supply regulator, assuming enabled
[ 3.358048] scsi host0: ufshcd
[ 3.378944] remoteproc remoteproc0: 4080000.remoteproc is available
[ 3.385572] remoteproc remoteproc1: 17300000.remoteproc is available
[ 3.385918] remoteproc remoteproc1: powering up 17300000.remoteproc
[ 3.393812] remoteproc remoteproc1: Booting fw image adsp.mdt, size 7260
[ 3.429385] adreno 5000000.gpu: Adding to iommu group 2
[ 3.434150] msm-mdss c900000.display-subsystem: Adding to iommu group 3
[ 3.438369] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /hdmi-bridge/ports/port@0/endpoint
[ 3.440220] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/display-controller@c901000/ports/port@2/endpoint
[ 3.440292] scsi 0:0:0:49488: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c150hN
[ 3.457755] qcom-venus cc00000.video-codec: Adding to iommu group 4
[ 3.463049] scsi 0:0:0:49488: Well-known LUN SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.492111] scsi 0:0:0:49476: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c144hN
[ 3.492274] scsi 0:0:0:49476: Well-known LUN SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.514052] scsi 0:0:0:49456: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c130hN
[ 3.514221] scsi 0:0:0:49456: Well-known LUN SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.533481] scsi 0:0:0:0: Direct-Access SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.541662] scsi 0:0:0:1: Direct-Access SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.541683] sd 0:0:0:0: [sda] 7732224 4096-byte logical blocks: (31.7 GB/29.5 GiB)
[ 3.549162] sd 0:0:0:0: [sda] 16384-byte physical blocks
[ 3.556897] sd 0:0:0:0: [sda] Write Protect is off
[ 3.562031] sd 0:0:0:0: [sda] Mode Sense: 00 32 00 10
[ 3.567248] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 3.567290] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 3.571538] sd 0:0:0:0: [sda] Preferred minimum I/O size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.586496] sd 0:0:0:0: [sda] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.600109] sd 0:0:0:1: [sdb] 2048 4096-byte logical blocks: (8.39 MB/8.00 MiB)
[ 3.601876] scsi 0:0:0:2: Direct-Access SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.607037] sda: sda1 sda2 sda3 sda4 sda5 sda7 sda8
[ 3.607508] sd 0:0:0:1: [sdb] 16384-byte physical blocks
[ 3.607791] sd 0:0:0:1: [sdb] Write Protect is off
[ 3.612076] sd 0:0:0:0: [sda] Attached SCSI disk
[ 3.620553] sd 0:0:0:2: [sdc] 2048 4096-byte logical blocks: (8.39 MB/8.00 MiB)
[ 3.623007] sd 0:0:0:1: [sdb] Mode Sense: 00 32 00 10
[ 3.623166] scsi 0:0:0:3: Direct-Access SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.627991] sd 0:0:0:2: [sdc] 16384-byte physical blocks
[ 3.628155] sd 0:0:0:2: [sdc] Write Protect is off
[ 3.633542] sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 3.638019] sd 0:0:0:2: [sdc] Mode Sense: 00 32 00 10
[ 3.642699] sd 0:0:0:1: [sdb] Preferred minimum I/O size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.642714] sd 0:0:0:1: [sdb] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.697473] sd 0:0:0:1: [sdb] Attached SCSI disk
[ 3.699170] sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 3.701222] remoteproc remoteproc1: remote processor 17300000.remoteproc is now up
[ 3.703433] sd 0:0:0:3: [sdd] 1024 4096-byte logical blocks: (4.19 MB/4.00 MiB)
[ 3.703443] sd 0:0:0:3: [sdd] 16384-byte physical blocks
[ 3.704351] sd 0:0:0:3: [sdd] Write Protect is off
[ 3.704359] sd 0:0:0:3: [sdd] Mode Sense: 00 32 00 10
[ 3.704382] scsi 0:0:0:4: Direct-Access SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.705126] sd 0:0:0:3: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 3.705134] sd 0:0:0:3: [sdd] Preferred minimum I/O size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.705140] sd 0:0:0:3: [sdd] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.714009] sd 0:0:0:4: [sde] 1024 4096-byte logical blocks: (4.19 MB/4.00 MiB)
[ 3.714014] scsi 0:0:0:5: Direct-Access SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.715010] sdd: sdd1 sdd2 sdd3 sdd4 sdd5 sdd6
[ 3.720825] sd 0:0:0:2: [sdc] Preferred minimum I/O size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.721112] sd 0:0:0:3: [sdd] Attached SCSI disk
[ 3.721154] sd 0:0:0:5: [sdf] 2048 4096-byte logical blocks: (8.39 MB/8.00 MiB)
[ 3.721160] sd 0:0:0:5: [sdf] 16384-byte physical blocks
[ 3.721552] sd 0:0:0:5: [sdf] Write Protect is off
[ 3.721558] sd 0:0:0:5: [sdf] Mode Sense: 00 32 00 10
[ 3.721595] scsi 0:0:0:6: Direct-Access SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.722077] sd 0:0:0:5: [sdf] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 3.722085] sd 0:0:0:5: [sdf] Preferred minimum I/O size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.722091] sd 0:0:0:5: [sdf] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.723726] sd 0:0:0:6: [sdg] 18432 4096-byte logical blocks: (75.5 MB/72.0 MiB)
[ 3.723733] sd 0:0:0:6: [sdg] 16384-byte physical blocks
[ 3.723998] sd 0:0:0:6: [sdg] Write Protect is off
[ 3.724003] sd 0:0:0:6: [sdg] Mode Sense: 00 32 00 10
[ 3.724354] scsi 0:0:0:7: Direct-Access SAMSUNG KLUBG4G1CE-B0B1 0800 PQ: 0 ANSI: 6
[ 3.724626] sd 0:0:0:6: [sdg] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 3.724633] sd 0:0:0:6: [sdg] Preferred minimum I/O size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.724639] sd 0:0:0:6: [sdg] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.726686] sdf: sdf1 sdf2 sdf3
[ 3.728049] sd 0:0:0:6: [sdg] Attached SCSI disk
[ 3.728249] sd 0:0:0:4: [sde] 16384-byte physical blocks
[ 3.728619] sd 0:0:0:5: [sdf] Attached SCSI disk
[ 3.728813] sd 0:0:0:7: [sdh] 16384 4096-byte logical blocks: (67.1 MB/64.0 MiB)
[ 3.728819] sd 0:0:0:7: [sdh] 16384-byte physical blocks
[ 3.728971] sd 0:0:0:7: [sdh] Write Protect is off
[ 3.728977] sd 0:0:0:7: [sdh] Mode Sense: 00 32 00 10
[ 3.729093] sd 0:0:0:7: [sdh] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 3.729101] sd 0:0:0:7: [sdh] Preferred minimum I/O size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.729106] sd 0:0:0:7: [sdh] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.730945] sd 0:0:0:7: [sdh] Attached SCSI disk
[ 3.735465] sd 0:0:0:2: [sdc] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.743096] sd 0:0:0:2: [sdc] Attached SCSI disk
[ 3.745972] sd 0:0:0:4: [sde] Write Protect is off
[ 3.768657] hdmi_msm c9a0000.hdmi-tx: supply core-vdda not found, using dummy regulator
[ 3.777944] sd 0:0:0:4: [sde] Mode Sense: 00 32 00 10
[ 3.778973] sd 0:0:0:4: [sde] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 3.788591] hdmi_msm c9a0000.hdmi-tx: supply core-vcc not found, using dummy regulator
[ 3.795615] sd 0:0:0:4: [sde] Preferred minimum I/O size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.809385] msm_dpu c901000.display-controller: bound c9a0000.hdmi-tx (ops msm_hdmi_ops)
[ 3.817468] hub 1-1:1.0: USB hub found
[ 3.817918] hub 1-1:1.0: 4 ports detected
[ 3.818863] sd 0:0:0:4: [sde] Optimal transfer size 8192 bytes not a multiple of physical block size (16384 bytes)
[ 3.830064] sde: sde1 sde2 sde3 sde4 sde5
[ 3.833354] adreno 5000000.gpu: supply vdd not found, using dummy regulator
[ 3.840405] sd 0:0:0:4: [sde] Attached SCSI disk
[ 3.841478] adreno 5000000.gpu: supply vddcx not found, using dummy regulator
[ 3.895884] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 3.903813] msm_dpu c901000.display-controller: bound 5000000.gpu (ops a3xx_ops)
[ 4.143114] [drm:dpu_kms_hw_init:1057] dpu hardware revision:0x30000000
[ 4.265461] [drm] Initialized msm 1.12.0 20130625 for c901000.display-controller on minor 0
[ 4.265826] msm_dpu c901000.display-controller: [drm:adreno_request_fw] loaded qcom/a530_pm4.fw from new location
[ 4.273179] msm_dpu c901000.display-controller: [drm:adreno_request_fw] loaded qcom/a530_pfp.fw from new location
[ 4.283409] msm_dpu c901000.display-controller: [drm:adreno_request_fw] loaded qcom/a540_gpmu.fw2 from new location
[ 4.297054] msm_dpu c901000.display-controller: [drm:adreno_request_fw] loaded qcom/a540_zap.mdt from new location
[ 4.326314] debugfs: File 'pfp' in directory 'c901000.display-controller' already present!
[ 4.326437] debugfs: File 'me' in directory 'c901000.display-controller' already present!
[ 4.333595] debugfs: File 'meq' in directory 'c901000.display-controller' already present!
[ 4.341817] debugfs: File 'roq' in directory 'c901000.display-controller' already present!
[ 4.349971] debugfs: File 'reset' in directory 'c901000.display-controller' already present!
[ 4.424861] hdmi_8998_pll_set_clk_rate 148500000 19200000
[ 4.425470] hdmi_8998_pll_prepare
[ 4.426793] msm_hdmi_hdcp_read_validate_aksv: AKSV QFPROM doesn't have 20 1's, 20 0's
[ 4.426808] msm_hdmi_hdcp_read_validate_aksv: QFPROM AKSV chk failed (AKSV=0000000000)
[ 4.426822] msm_hdmi_hdcp_auth_prepare: ASKV validation failed
[ 4.426829] msm_hdmi_hdcp_auth_work: auth prepare failed -524
[ 4.426841] msm_hdmi_hdcp_auth_work: hdcp is not supported
[ 4.426901] fb0: Framebuffer is not in virtual address space.
[ 4.427007] fb0: Framebuffer is not in virtual address space.
[ 4.464193] Console: switching to colour frame buffer device 240x67
[ 4.549776] msm_dpu c901000.display-controller: [drm] fb0: msmdrmfb frame buffer device
[ 4.559864] input: gpio_keys as /devices/platform/gpio_keys/input/input1
[ 4.585452] hub 2-1:1.0: USB hub found
[ 4.585989] hub 2-1:1.0: 4 ports detected
[ 5.588358] atl1c 0000:01:00.0: atl1c: eth0 NIC Link is Up<1000 Mbps Full Duplex>
[ 5.611594] Sending DHCP requests .., OK
[ 8.355586] IP-Config: Got DHCP answer from 10.126.6.1, my address is 10.126.6.60
[ 8.358520] IP-Config: Complete: [SNIP]
[ 8.394201] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 8.407657] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 8.410836] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[ 8.412963] clk: Not disabling unused clocks
[ 8.420274] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 8.424237] cfg80211: failed to load regulatory.db
[ 8.437397] ALSA device list:
[ 8.437808] No soundcards found.
[ 8.474132] VFS: Mounted root (nfs filesystem) on device 0:21.
[ 8.479811] Freeing unused kernel memory: 5632K
[ 8.507720] Run /sbin/init as init process
[ 8.507917] with arguments:
[ 8.510819] /sbin/init
[ 8.513899] with environment:
[ 8.516474] HOME=/
[ 8.519501] TERM=linux
[ 9.121206] systemd[1]: System time before build time, advancing clock.
[ 11.924787] systemd-journald[203]: Collecting audit messages is disabled.
[ 12.067431] systemd-journald[203]: Received client request to flush runtime journal.
[ 12.611332] random: crng init done
[ 13.593233] atl1c 0000:01:00.0 enp1s0: renamed from eth0 (while UP)
[ 15.276168] remoteproc remoteproc0: powering up 4080000.remoteproc
[ 15.280059] remoteproc remoteproc0: Booting fw image mba.mbn, size 234152
[ 15.285687] ath10k_snoc 18800000.wifi: received modem starting event
[ 15.383271] qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss
[ 15.727551] ath10k_snoc 18800000.wifi: received modem running event
[ 15.735940] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up
[ 56.014848] qcom-q6v5-mss 4080000.remoteproc: fatal error received: dog_virtual_root.c:204:DOG_VIR : User-PD grace timer expired with asid = 1, na
[ 56.015156] remoteproc remoteproc0: crash detected in 4080000.remoteproc: type fatal error
[ 56.027254] remoteproc remoteproc0: handling crash #1 in 4080000.remoteproc
[ 56.035329] remoteproc remoteproc0: recovering 4080000.remoteproc
[ 56.043849] ath10k_snoc 18800000.wifi: received modem crashed event
[ 56.151287] qcom-q6v5-mss 4080000.remoteproc: port failed halt
[ 56.153275] ath10k_snoc 18800000.wifi: received modem offline event
[ 56.158268] remoteproc remoteproc0: stopped remote processor 4080000.remoteproc
[ 56.166158] ath10k_snoc 18800000.wifi: received modem starting event
[ 56.275276] qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss
[ 56.795372] ath10k_snoc 18800000.wifi: received modem running event
[ 56.797788] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up
### FOLLOWING 12 LINES ARE REPEATED EVERY ~40 seconds
[ 96.987102] qcom-q6v5-mss 4080000.remoteproc: fatal error received: dog_virtual_root.c:204:DOG_VIR : User-PD grace timer expired with asid = 1, na
[ 96.987427] remoteproc remoteproc0: crash detected in 4080000.remoteproc: type fatal error
[ 96.999457] remoteproc remoteproc0: handling crash #2 in 4080000.remoteproc
[ 97.007541] remoteproc remoteproc0: recovering 4080000.remoteproc
[ 97.016034] ath10k_snoc 18800000.wifi: received modem crashed event
[ 97.122811] qcom-q6v5-mss 4080000.remoteproc: port failed halt
[ 97.125928] ath10k_snoc 18800000.wifi: received modem offline event
[ 97.132323] remoteproc remoteproc0: stopped remote processor 4080000.remoteproc
[ 97.136852] ath10k_snoc 18800000.wifi: received modem starting event
[ 97.251330] qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss
[ 98.125357] ath10k_snoc 18800000.wifi: received modem running event
[ 98.127095] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up
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 17:44:02 venus pd-mapper[347]: no pd maps available
Doh! I had the firmware blobs properly embedded in the kernel,
but the user-space tools needed them in the root filesystem.
With that latest change, the kernel issue disappears,
and most of the user-space tools seem happy:
systemd-journald[199]: Journal started
systemd-journald[199]: Runtime Journal (/run/log/journal/0f2e92c39e6f4f3fa6585b56f928c8ed) is 8.0M, max 73.3M, 65.3M free.
systemd-random-seed[206]: Kernel entropy pool is not initialized yet, waiting until it is.
systemd-journald[199]: Time spent on flushing to /var/log/journal/0f2e92c39e6f4f3fa6585b56f928c8ed is 12.074ms for 3 entries.
systemd-journald[199]: System Journal (/var/log/journal/0f2e92c39e6f4f3fa6585b56f928c8ed) is 8.0M, max 4.0G, 3.9G free.
systemd-udevd[227]: Using default interface naming scheme 'v255'.
cron[285]: (CRON) INFO (pidfile fd = 3)
cron[285]: (CRON) INFO (Running @reboot jobs)
qrtr-ns[288]: ERROR qrtr-ns: nameserver already running, going dormant: Address already in use
rmtfs[291]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_1', rejecting
rmtfs[291]: [RMTFS storage] request for unknown partition '/boot/modem_fsg_oem_2', rejecting
Corresponding kernel log:
[ 0.321715] ath10k_snoc 18800000.wifi: Adding to iommu group 0
[ 0.323787] ath10k_snoc 18800000.wifi: snoc xo-cal-data return -22
[ 0.325443] ath10k_snoc 18800000.wifi: supply vdd-3.3-ch1 not found, using dummy regulator
[ 0.325767] ath10k_snoc 18800000.wifi: qmi msa.paddr: 0x0000000094400000 , msa.vaddr: 0x(____ptrval____)
[ 0.325999] ath10k_snoc 18800000.wifi: snoc probe
...
[ 8.430099] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 8.443287] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 8.446323] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[ 8.451411] clk: Not disabling unused clocks
[ 8.454159] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[ 8.468829] ALSA device list[ 8.506030] VFS: Mounted root (nfs filesystem) on device 0:21.
[ 8.511551] Freeing unused kernel memory: 5632K
[ 9.122863] systemd[1]: System time before build time, advancing clock.
[ 12.009922] systemd-journald[204]: Collecting audit messages is disabled.
[ 12.193174] systemd-journald[204]: Received client request to flush runtime journal.
[ 12.803236] random: crng init done
[ 13.580077] atl1c 0000:01:00.0 enp1s0: renamed from eth0 (while UP)
[ 15.255763] remoteproc remoteproc0: powering up 4080000.remoteproc
[ 15.263925] remoteproc remoteproc0: Booting fw image mba.mbn, size 234152
[ 15.277228] ath10k_snoc 18800000.wifi: received modem starting event
[ 15.370471] qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss
[ 16.020964] ath10k_snoc 18800000.wifi: received modem running event
[ 16.029559] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up
[ 18.649633] ath10k_snoc 18800000.wifi: wifi fw qmi service found
[ 18.649870] ath10k_snoc 18800000.wifi: qmi wifi fw qmi service connected
[ 18.658200] ath10k_snoc 18800000.wifi: qmi indication register request completed
[ 18.666483] ath10k_snoc 18800000.wifi: qmi host capability request completed
[ 18.674486] ath10k_snoc 18800000.wifi: qmi msa mem region 0 addr 0x0x0000000094400000 size 0x4000 flag 0x00000001
[ 18.676164] ath10k_snoc 18800000.wifi: qmi msa mem region 1 addr 0x0x0000000094404000 size 0xfc000 flag 0x00000000
[ 18.686350] ath10k_snoc 18800000.wifi: qmi msa mem info request completed
[ 18.738546] ath10k_snoc 18800000.wifi: qmi msa mem ready request completed
[ 18.791705] ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40010002
[ 18.792014] ath10k_snoc 18800000.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
Yet, I still don't have a wlan network interface.
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 34:27:92:82:48:ec brd ff:ff:ff:ff:ff:ff
I'm kinda stumped at this point... :(
Regards
On 19/03/2024 14:47, Marc Gonzalez wrote:
> [ 15.255763] remoteproc remoteproc0: powering up 4080000.remoteproc
> [ 15.263925] remoteproc remoteproc0: Booting fw image mba.mbn, size 234152
> [ 15.277228] ath10k_snoc 18800000.wifi: received modem starting event
> [ 15.370471] qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss
> [ 16.020964] ath10k_snoc 18800000.wifi: received modem running event
> [ 16.029559] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up
> [ 18.649633] ath10k_snoc 18800000.wifi: wifi fw qmi service found
> [ 18.649870] ath10k_snoc 18800000.wifi: qmi wifi fw qmi service connected
> [ 18.658200] ath10k_snoc 18800000.wifi: qmi indication register request completed
> [ 18.666483] ath10k_snoc 18800000.wifi: qmi host capability request completed
> [ 18.674486] ath10k_snoc 18800000.wifi: qmi msa mem region 0 addr 0x0x0000000094400000 size 0x4000 flag 0x00000001
> [ 18.676164] ath10k_snoc 18800000.wifi: qmi msa mem region 1 addr 0x0x0000000094404000 size 0xfc000 flag 0x00000000
> [ 18.686350] ath10k_snoc 18800000.wifi: qmi msa mem info request completed
> [ 18.738546] ath10k_snoc 18800000.wifi: qmi msa mem ready request completed
> [ 18.791705] ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40010002
> [ 18.792014] ath10k_snoc 18800000.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
>
> Yet, I still don't have a wlan network interface.
What a dweeb... bitten by the very bug I'm supposed to fix :(
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 38e939f572a9e..b4af48b7ec6db 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1040,6 +1040,7 @@ static void ath10k_qmi_driver_event_work(struct work_struct *work)
switch (event->type) {
case ATH10K_QMI_EVENT_SERVER_ARRIVE:
ath10k_qmi_event_server_arrive(qmi);
+ ath10k_qmi_event_msa_ready(qmi);
break;
case ATH10K_QMI_EVENT_SERVER_EXIT:
ath10k_qmi_event_server_exit(qmi);
[ 18.334050] ath10k_snoc 18800000.wifi: wifi fw qmi service found
[ 18.334197] ath10k_snoc 18800000.wifi: qmi wifi fw qmi service connected
[ 18.342968] ath10k_snoc 18800000.wifi: qmi indication register request completed
[ 18.350886] ath10k_snoc 18800000.wifi: qmi host capability request completed
[ 18.358927] ath10k_snoc 18800000.wifi: qmi msa mem region 0 addr 0x0x0000000094400000 size 0x4000 flag 0x00000001
[ 18.360430] ath10k_snoc 18800000.wifi: qmi msa mem region 1 addr 0x0x0000000094404000 size 0xfc000 flag 0x00000000
[ 18.370640] ath10k_snoc 18800000.wifi: qmi msa mem info request completed
[ 18.421465] ath10k_snoc 18800000.wifi: qmi msa mem ready request completed
[ 18.474494] ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40010002
[ 18.474675] ath10k_snoc 18800000.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
[ 18.483671] ath10k_snoc 18800000.wifi: DT bdf variant name not set.
[ 18.499350] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
[ 18.505661] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
[ 18.515352] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff'
[ 18.555414] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/board-2.bin': 0
[ 18.555820] ath10k_snoc 18800000.wifi: board name
[ 18.563247] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.568043] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 rd-id=67
[ 18.578242] ath10k_snoc 18800000.wifi: board name
[ 18.587717] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.592589] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 rd-id=ff
[ 18.602762] ath10k_snoc 18800000.wifi: board name
[ 18.612283] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.617137] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 2c 71 6d 69 2d 63 68 69 rd-id=67,qmi-chi
[ 18.627419] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 34 33 32 30 2c 76 61 72 69 61 6e p-id=4320,varian
[ 18.637716] ath10k_snoc 18800000.wifi: 00000030: 74 3d 47 4f 5f 50 4f 4d 50 4f 4d t=GO_POMPOM
[ 18.648036] ath10k_snoc 18800000.wifi: board name
[ 18.657898] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.662707] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 2c 71 6d 69 2d 63 68 69 rd-id=67,qmi-chi
[ 18.672955] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 32 30 2c 76 61 72 69 61 6e 74 p-id=320,variant
[ 18.683317] ath10k_snoc 18800000.wifi: 00000030: 3d 47 4f 5f 50 4f 4d 50 4f 4d =GO_POMPOM
[ 18.693598] ath10k_snoc 18800000.wifi: board name
[ 18.703470] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.708190] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 2c 71 6d 69 2d 63 68 69 rd-id=67,qmi-chi
[ 18.718433] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 34 33 32 30 2c 76 61 72 69 61 6e p-id=4320,varian
[ 18.728763] ath10k_snoc 18800000.wifi: 00000030: 74 3d 47 4f 5f 4c 41 5a 4f 52 t=GO_LAZOR
[ 18.739081] ath10k_snoc 18800000.wifi: board name
[ 18.748953] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.753676] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 2c 71 6d 69 2d 63 68 69 rd-id=67,qmi-chi
[ 18.763920] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 32 30 2c 76 61 72 69 61 6e 74 p-id=320,variant
[ 18.774283] ath10k_snoc 18800000.wifi: 00000030: 3d 47 4f 5f 4c 41 5a 4f 52 =GO_LAZOR
[ 18.784566] ath10k_snoc 18800000.wifi: board name
[ 18.794089] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.799075] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 2c 71 6d 69 2d 63 68 69 rd-id=67,qmi-chi
[ 18.809339] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 32 30 2c 76 61 72 69 61 6e 74 p-id=320,variant
[ 18.819652] ath10k_snoc 18800000.wifi: 00000030: 3d 47 4f 5f 51 55 41 43 4b 49 4e 47 53 54 49 43 =GO_QUACKINGSTIC
[ 18.829978] ath10k_snoc 18800000.wifi: 00000040: 4b K
[ 18.840276] ath10k_snoc 18800000.wifi: board name
[ 18.849126] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.854109] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 2c 71 6d 69 2d 63 68 69 rd-id=67,qmi-chi
[ 18.864353] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 34 33 32 30 2c 76 61 72 69 61 6e p-id=4320,varian
[ 18.874672] ath10k_snoc 18800000.wifi: 00000030: 74 3d 47 4f 5f 51 55 41 43 4b 49 4e 47 53 54 49 t=GO_QUACKINGSTI
[ 18.885022] ath10k_snoc 18800000.wifi: 00000040: 43 4b CK
[ 18.895333] ath10k_snoc 18800000.wifi: board name
[ 18.904510] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.909231] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 2c 71 6d 69 2d 63 68 69 rd-id=67,qmi-chi
[ 18.919474] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 32 30 2c 76 61 72 69 61 6e 74 p-id=320,variant
[ 18.929802] ath10k_snoc 18800000.wifi: 00000030: 3d 47 4f 5f 51 55 41 43 4b 49 4e 47 53 54 49 43 =GO_QUACKINGSTIC
[ 18.940147] ath10k_snoc 18800000.wifi: 00000040: 4b 5f 4c 54 45 K_LTE
[ 18.950446] ath10k_snoc 18800000.wifi: board name
[ 18.959627] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 18.964613] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 36 37 2c 71 6d 69 2d 63 68 69 rd-id=67,qmi-chi
[ 18.974895] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 34 33 32 30 2c 76 61 72 69 61 6e p-id=4320,varian
[ 18.985256] ath10k_snoc 18800000.wifi: 00000030: 74 3d 47 4f 5f 51 55 41 43 4b 49 4e 47 53 54 49 t=GO_QUACKINGSTI
[ 19.002585] ath10k_snoc 18800000.wifi: 00000040: 43 4b 5f 4c 54 45 CK_LTE
[ 19.013010] ath10k_snoc 18800000.wifi: board name
[ 19.022479] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 19.029881] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 2c 71 6d 69 2d 63 68 69 rd-id=ff,qmi-chi
[ 19.039078] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 34 33 32 30 2c 76 61 72 69 61 6e p-id=4320,varian
[ 19.049454] ath10k_snoc 18800000.wifi: 00000030: 74 3d 47 4f 5f 48 4f 4d 45 53 54 41 52 t=GO_HOMESTAR
[ 19.059914] ath10k_snoc 18800000.wifi: board name
[ 19.069703] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 19.077270] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 2c 71 6d 69 2d 63 68 69 rd-id=ff,qmi-chi
[ 19.086469] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 32 30 2c 76 61 72 69 61 6e 74 p-id=320,variant
[ 19.096881] ath10k_snoc 18800000.wifi: 00000030: 3d 47 4f 5f 48 4f 4d 45 53 54 41 52 =GO_HOMESTAR
[ 19.107202] ath10k_snoc 18800000.wifi: board name
[ 19.116993] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 19.124477] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 2c 71 6d 69 2d 63 68 69 rd-id=ff,qmi-chi
[ 19.133675] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 34 33 32 30 2c 76 61 72 69 61 6e p-id=4320,varian
[ 19.144128] ath10k_snoc 18800000.wifi: 00000030: 74 3d 47 4f 5f 57 4f 52 4d 44 49 4e 47 4c 45 52 t=GO_WORMDINGLER
[ 19.154503] ath10k_snoc 18800000.wifi: board name
[ 19.164791] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 19.172543] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 2c 71 6d 69 2d 63 68 69 rd-id=ff,qmi-chi
[ 19.181702] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 32 30 2c 76 61 72 69 61 6e 74 p-id=320,variant
[ 19.192084] ath10k_snoc 18800000.wifi: 00000030: 3d 47 4f 5f 57 4f 52 4d 44 49 4e 47 4c 45 52 =GO_WORMDINGLER
[ 19.202404] ath10k_snoc 18800000.wifi: board name
[ 19.212616] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 19.220364] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 2c 71 6d 69 2d 63 68 69 rd-id=ff,qmi-chi
[ 19.229564] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 34 33 32 30 2c 76 61 72 69 61 6e p-id=4320,varian
[ 19.239885] ath10k_snoc 18800000.wifi: 00000030: 74 3d 47 4f 5f 4d 52 42 4c 41 4e 44 t=GO_MRBLAND
[ 19.250240] ath10k_snoc 18800000.wifi: board name
[ 19.260102] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 19.267858] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 2c 71 6d 69 2d 63 68 69 rd-id=ff,qmi-chi
[ 19.277048] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 32 30 2c 76 61 72 69 61 6e 74 p-id=320,variant
[ 19.287390] ath10k_snoc 18800000.wifi: 00000030: 3d 47 4f 5f 4d 52 42 4c 41 4e 44 =GO_MRBLAND
[ 19.297730] ath10k_snoc 18800000.wifi: board name
[ 19.307602] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 19.315384] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 2c 71 6d 69 2d 63 68 69 rd-id=ff,qmi-chi
[ 19.324567] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 30 32 31 34 2c 76 61 72 69 61 p-id=30214,varia
[ 19.334892] ath10k_snoc 18800000.wifi: 00000030: 6e 74 3d 54 68 75 6e 64 65 72 63 6f 6d 6d 5f 44 nt=Thundercomm_D
[ 19.345267] ath10k_snoc 18800000.wifi: 00000040: 42 38 34 35 43 B845C
[ 19.355577] ath10k_snoc 18800000.wifi: board name
[ 19.364698] ath10k_snoc 18800000.wifi: 00000000: 62 75 73 3d 73 6e 6f 63 2c 71 6d 69 2d 62 6f 61 bus=snoc,qmi-boa
[ 19.372459] ath10k_snoc 18800000.wifi: 00000010: 72 64 2d 69 64 3d 66 66 2c 71 6d 69 2d 63 68 69 rd-id=ff,qmi-chi
[ 19.381631] ath10k_snoc 18800000.wifi: 00000020: 70 2d 69 64 3d 33 30 32 31 34 p-id=30214
[ 19.391978] ath10k_snoc 18800000.wifi: boot found match for name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
[ 19.401933] ath10k_snoc 18800000.wifi: boot found board data for 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
[ 19.411680] ath10k_snoc 18800000.wifi: using board api 2
[ 19.426886] ath10k_snoc 18800000.wifi: qmi bdf download request completed
[ 19.436034] ath10k_snoc 18800000.wifi: qmi cal report request completed
[ 22.645730] ath10k_snoc 18800000.wifi: wifi fw ready event received
[ 22.653332] ath10k_snoc 18800000.wifi: ath10k_snoc_hif_power_up:WCN3990 driver state = 0
[ 22.660822] ath10k_snoc 18800000.wifi: soc power on
[ 22.674974] ath10k_snoc 18800000.wifi: qmi mode 0 config 00000000d4ac2648
[ 22.691524] ath10k_snoc 18800000.wifi: qmi config request completed
[ 22.756845] ath10k_snoc 18800000.wifi: qmi wlan mode req completed: 0
[ 22.764304] ath10k_snoc 18800000.wifi: boot init ce src ring id 0 entries 16 base_addr 000000008a771643
[ 22.771723] ath10k_snoc 18800000.wifi: boot ce dest ring id 1 entries 512 base_addr 00000000456c5b44
[ 22.779938] ath10k_snoc 18800000.wifi: boot ce dest ring id 2 entries 64 base_addr 00000000dacea75c
[ 22.789124] ath10k_snoc 18800000.wifi: boot init ce src ring id 3 entries 32 base_addr 000000009d09a7e8
[ 22.797937] ath10k_snoc 18800000.wifi: boot init ce src ring id 4 entries 2048 base_addr 000000001b01ecda
[ 22.807246] ath10k_snoc 18800000.wifi: boot ce dest ring id 5 entries 512 base_addr 00000000d75a5547
[ 22.816935] ath10k_snoc 18800000.wifi: boot init ce src ring id 7 entries 2 base_addr 000000000f5bef9f
[ 22.826117] ath10k_snoc 18800000.wifi: boot ce dest ring id 7 entries 2 base_addr 0000000042113a43
[ 22.835231] ath10k_snoc 18800000.wifi: boot ce dest ring id 8 entries 128 base_addr 00000000fc8c671c
[ 22.844099] ath10k_snoc 18800000.wifi: boot ce dest ring id 9 entries 512 base_addr 0000000041b1f577
[ 22.853348] ath10k_snoc 18800000.wifi: boot ce dest ring id 10 entries 512 base_addr 00000000670dc8b3
[ 22.862415] ath10k_snoc 18800000.wifi: boot ce dest ring id 11 entries 512 base_addr 00000000fd62644d
[ 22.871524] ath10k_snoc 18800000.wifi: Hardware name wcn3990 hw1.0 version 0x8
[ 22.882456] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/pre-cal-snoc-18800000.wifi.bin': -2
[ 22.890396] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/cal-snoc-18800000.wifi.bin': -2
[ 22.897361] ath10k_snoc 18800000.wifi: trying fw api 6
[ 22.907107] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-6.bin': -2
[ 22.914837] ath10k_snoc 18800000.wifi: trying fw api 5
[ 22.929033] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-5.bin': 0
[ 22.937607] ath10k_snoc 18800000.wifi: found fw timestamp 1539237028
[ 22.945416] ath10k_snoc 18800000.wifi: found firmware features ie (3 B)
[ 22.953667] ath10k_snoc 18800000.wifi: Enabling feature bit: 6
[ 22.961046] ath10k_snoc 18800000.wifi: Enabling feature bit: 18
[ 22.969963] ath10k_snoc 18800000.wifi: Enabling feature bit: 19
[ 22.978899] ath10k_snoc 18800000.wifi: features
[ 22.986469] ath10k_snoc 18800000.wifi: 00000000: 40 00 0c 00 00 00 00 00 @.......
[ 22.992940] ath10k_snoc 18800000.wifi: found fw ie wmi op version 4
[ 23.001282] ath10k_snoc 18800000.wifi: found fw ie htt op version 3
[ 23.007632] ath10k_snoc 18800000.wifi: using fw api 5
[ 23.013826] ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000
[ 23.020081] ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 1 tracing 0 dfs 0 testmode 0
[ 23.028162] ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790
[ 23.036548] ath10k_snoc 18800000.wifi: snoc hif map service
[ 23.047238] ath10k_snoc 18800000.wifi: boot htc service 'Control' ul pipe 0 dl pipe 2 eid 0 ready
[ 23.053428] ath10k_snoc 18800000.wifi: boot htc service 'Control' eid 0 TX flow control disabled
[ 23.061734] ath10k_snoc 18800000.wifi: htt tx max num pending tx 1056
[ 23.070954] ath10k_snoc 18800000.wifi: htt rx ring size 2048 fill_level 2047
[ 23.082569] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 20
[ 23.085448] ath10k_snoc 18800000.wifi: htc rx completion ep 0 skb 00000000732bd6c4
[ 23.100773] ath10k_snoc 18800000.wifi: boot hif start
[ 23.106787] ath10k_snoc 18800000.wifi: Target ready! transmit resources: 1 size:2184 actual credits:2
[ 23.112725] ath10k_snoc 18800000.wifi: Extended ready message RX bundle size 0 alt size 0
[ 23.120836] ath10k_snoc 18800000.wifi: boot htc service HTT Data does not allocate target credits
[ 23.129034] ath10k_snoc 18800000.wifi: ath10k_htc_build_tx_ctrl_skb: skb 00000000a29e6712
[ 23.137965] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fed3e04c len 16 n_items 1
[ 23.146114] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 0 skb 00000000a29e6712
[ 23.151729] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 20
[ 23.160549] ath10k_snoc 18800000.wifi: htc rx completion ep 0 skb 00000000ac1cd2b0
[ 23.166556] ath10k_snoc 18800000.wifi: HTC Service HTT Data connect response: status: 0x0, assigned ep: 0x1
[ 23.176988] ath10k_snoc 18800000.wifi: snoc hif map service
[ 23.186436] ath10k_snoc 18800000.wifi: boot htc service 'HTT Data' ul pipe 4 dl pipe 1 eid 1 ready
[ 23.192282] ath10k_snoc 18800000.wifi: boot htc service 'HTT Data' eid 1 TX flow control disabled
[ 23.201085] ath10k_snoc 18800000.wifi: ath10k_htc_build_tx_ctrl_skb: skb 000000001e6b1281
[ 23.209988] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe8f004c len 16 n_items 1
[ 23.218595] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 0 skb 000000001e6b1281
[ 23.223955] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 20
[ 23.232767] ath10k_snoc 18800000.wifi: htc rx completion ep 0 skb 000000009a413c60
[ 23.238803] ath10k_snoc 18800000.wifi: HTC Service WMI connect response: status: 0x0, assigned ep: 0x2
[ 23.249130] ath10k_snoc 18800000.wifi: snoc hif map service
[ 23.258271] ath10k_snoc 18800000.wifi: boot htc service 'WMI' ul pipe 3 dl pipe 2 eid 2 ready
[ 23.264082] ath10k_snoc 18800000.wifi: ath10k_htc_build_tx_ctrl_skb: skb 0000000080367b62
[ 23.272479] ath10k_snoc 18800000.wifi: HTC is using TX credit flow control
[ 23.280676] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe32b04c len 20 n_items 1
[ 23.287464] ath10k_snoc 18800000.wifi: snoc hif map service
[ 23.287492] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 0 skb 0000000080367b62
[ 23.290290] ath10k_snoc 18800000.wifi: unsupported HTC pktlog service id: 1536
[ 23.295912] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 336
[ 23.323227] ath10k_snoc 18800000.wifi: htc rx completion ep 2 skb 000000005a1336ea
[ 23.326097] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 832
[ 23.326421] ath10k_snoc 18800000.wifi: wmi tlv abi 0x01000000 ?= 0x01000000, 0x5f414351 ?= 0x5f414351, 0x00004c4d ?= 0x00004c4d, 0x00000000 ?= 0x00000000, 0x00000000 ?= 0x00000000
[ 23.329720] ath10k_snoc 18800000.wifi: htc rx completion ep 2 skb 000000001342908e
[ 23.329728] ath10k_snoc 18800000.wifi: Unknown eventid: 16393
[ 23.371591] ath10k_snoc 18800000.wifi: wmi svc: 00000000: 0d 00 00 00 07 00 00 00 0d 00 00 00 03 00 00 00 ................
[ 23.377879] ath10k_snoc 18800000.wifi: wmi svc: 00000010: 0f 00 00 00 09 00 00 00 0b 00 00 00 0f 00 00 00 ................
[ 23.387677] ath10k_snoc 18800000.wifi: wmi svc: 00000020: 0a 00 00 00 09 00 00 00 02 00 00 00 0a 00 00 00 ................
[ 23.398759] ath10k_snoc 18800000.wifi: wmi svc: 00000030: 01 00 00 00 0d 00 00 00 07 00 00 00 0f 00 00 00 ................
[ 23.409868] ath10k_snoc 18800000.wifi: wmi svc: 00000040: 0b 00 00 00 04 00 00 00 04 00 00 00 0b 00 00 00 ................
[ 23.420945] ath10k_snoc 18800000.wifi: wmi svc: 00000050: 07 00 00 00 00 00 00 00 08 00 00 00 01 00 00 00 ................
[ 23.432079] ath10k_snoc 18800000.wifi: wmi svc: 00000060: 09 00 00 00 03 00 00 00 05 00 00 00 00 00 00 00 ................
[ 23.443099] ath10k_snoc 18800000.wifi: wmi svc: 00000070: 01 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 ................
[ 23.454146] ath10k_snoc 18800000.wifi: wmi sys_cap_info 0x0
[ 23.465226] ath10k_snoc 18800000.wifi: wmi event service ready min_tx_power 0x0000003f max_tx_power 0x0000003f ht_cap 0x0000381b vht_cap 0x739139b2 vht_supp_mcs 0x0000fffe sw_ver0 0x01000000 sw_ver1 0x000001ab fw_build 0x100204b2 phy_capab 0x00000003 num_rf_chains 0x00000002 eeprom_rd 0x00000000 low_2ghz_chan 2312 high_2ghz_chan 2732 low_5ghz_chan 4912 high_5ghz_chan 6100 num_mem_reqs 0x00000000
[ 23.490641] ath10k_snoc 18800000.wifi: firmware 1.0.0.427 booted
[ 23.506500] ath10k_snoc 18800000.wifi: wmi tlv init
[ 23.512933] ath10k_snoc 18800000.wifi: htc ep 2 consumed 1 credits total 0
[ 23.519410] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe165ac0 len 228 n_items 1
[ 23.526324] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 2 skb 0000000062479e09
[ 23.555734] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 60
[ 23.558938] ath10k_snoc 18800000.wifi: htc rx completion ep 2 skb 0000000025ab7e7b
[ 23.563704] ath10k_snoc 18800000.wifi: wmi event ready sw_version 0x01000000 abi_version 427 mac_addr 00:00:00:00:00:00 status 0
[ 23.571446] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 16
[ 23.571859] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe164740 len 12 n_items 1
[ 23.579846] ath10k_snoc 18800000.wifi: htc ep 2 got 1 credits (total 1)
[ 23.609073] ath10k_snoc 18800000.wifi: snoc rx ce pipe 1 len 12
[ 23.616483] ath10k_snoc 18800000.wifi: htc rx completion ep 1 skb 000000000d2065ff
[ 23.623317] ath10k_snoc 18800000.wifi: htt rx, msg_type: 0x0
[ 23.630433] ath10k_snoc 18800000.wifi: htt target version 3.44
[ 23.637214] ath10k_snoc 18800000.wifi: htt frag desc bank cmd
[ 23.643861] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe15f240 len 72 n_items 1
[ 23.650558] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe15ef40 len 56 n_items 1
[ 23.658000] ath10k_snoc 18800000.wifi: htt h2t aggr cfg msg amsdu 3 ampdu 64
[ 23.666647] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe15da40 len 12 n_items 1
[ 23.674012] ath10k_snoc 18800000.wifi: wmi tlv pktlog disable
[ 23.682390] ath10k_snoc 18800000.wifi: htc ep 2 consumed 1 credits total 0
[ 23.689079] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe15c840 len 20 n_items 1
[ 23.696575] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 16
[ 23.697086] ath10k_snoc 18800000.wifi: qmi fw log request completed, mode: 0
[ 23.703676] ath10k_snoc 18800000.wifi: htc ep 2 got 1 credits (total 1)
[ 23.703733] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 2 skb 00000000ab3d1c86
[ 23.703767] ath10k_snoc 18800000.wifi: htt-ver 3.44 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1
[ 23.745328] ath10k_snoc 18800000.wifi: wmi tlv pktlog disable
[ 23.752813] ath10k_snoc 18800000.wifi: htc ep 2 consumed 1 credits total 0
[ 23.760113] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe15ce40 len 20 n_items 1
[ 23.766804] ath10k_snoc 18800000.wifi: wmi tlv pdev suspend
[ 23.767283] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 16
[ 23.767680] ath10k_snoc 18800000.wifi: htc insufficient credits ep 2 required 1 available 0 consume 1
[ 23.798608] ath10k_snoc 18800000.wifi: htc ep 2 got 1 credits (total 1)
[ 23.805223] ath10k_snoc 18800000.wifi: htc ep 2 consumed 1 credits total 0
[ 23.811842] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 2 skb 000000001598dc5c
[ 23.811886] ath10k_snoc 18800000.wifi: snoc tx item 0 paddr 0x00000007fe164040 len 24 n_items 1
[ 23.833603] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 2 skb 000000001ad99932
[ 23.842329] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 16
[ 23.848856] ath10k_snoc 18800000.wifi: htc ep 2 got 1 credits (total 1)
[ 23.855332] ath10k_snoc 18800000.wifi: snoc rx ce pipe 2 len 12
[ 23.861748] ath10k_snoc 18800000.wifi: htc rx completion ep 0 skb 00000000b2951d6d
[ 23.868182] ath10k_snoc 18800000.wifi: boot suspend complete
[ 23.885505] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 1 skb 00000000688df7bf
[ 23.892492] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 1 skb 0000000008c6dd9a
[ 23.899862] ath10k_snoc 18800000.wifi: ath10k_htc_notify_tx_completion: ep 1 skb 0000000039d3abae
[ 23.943506] ath10k_snoc 18800000.wifi: boot hif stop
[ 23.984772] ath10k_snoc 18800000.wifi: boot hif power down
[ 24.000360] ath10k_snoc 18800000.wifi: qmi wlan mode req completed: 4
[ 24.006755] ath10k_snoc 18800000.wifi: soc power off
[ 24.020185] ath10k_snoc 18800000.wifi: invalid MAC address; choosing random
[ 24.026803] ath10k_snoc 18800000.wifi: fallback to eeprom programmed regulatory settings
[ 24.033287] ath: EEPROM regdomain: 0x0
[ 24.040513] ath: EEPROM indicates default country code should be used
[ 24.046836] ath: doing EEPROM country->regdmn map search
[ 24.053108] ath: country maps to regdmn code: 0x3a
[ 24.059307] ath: Country alpha2 being used: US
[ 24.066331] ath: Regpair used: 0x3a
[ 24.074047] ath10k_snoc 18800000.wifi: WBRF is not supported
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 34:27:92:82:48:ec brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 2a:0b:f9:eb:00:57 brd ff:ff:ff:ff:ff:ff
Looking at commit b70b3a36ec33a2 with eyebrow raised over my head.
Regards
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 10)
Regards
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
ath10k/WCN3990/hw1.0/board-2.bin
ath10k/WCN3990/hw1.0/wlanmdsp.mbn
# dmesg | grep ' fw '
[ 2.769265] remoteproc remoteproc1: Booting fw image adsp.mdt, size 7260
[ 14.923181] remoteproc remoteproc0: Booting fw image mba.mbn, size 234152
[ 17.087567] ath10k_snoc 18800000.wifi: wifi fw qmi service found
[ 17.087642] ath10k_snoc 18800000.wifi: qmi wifi fw qmi service connected
[ 17.298173] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/board-2.bin': 0
[ 20.995327] ath10k_snoc 18800000.wifi: wifi fw ready event received
[ 21.189610] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/pre-cal-snoc-18800000.wifi.bin': -2
[ 21.195201] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/cal-snoc-18800000.wifi.bin': -2
[ 21.203285] ath10k_snoc 18800000.wifi: trying fw api 6
[ 21.212893] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-6.bin': -2
[ 21.216866] ath10k_snoc 18800000.wifi: trying fw api 5
[ 21.229645] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-5.bin': 0
[ 21.230840] ath10k_snoc 18800000.wifi: found fw timestamp 1539237028
[ 21.274453] ath10k_snoc 18800000.wifi: found fw ie wmi op version 4
[ 21.284111] ath10k_snoc 18800000.wifi: found fw ie htt op version 3
[ 21.290301] ath10k_snoc 18800000.wifi: using fw api 5
[ 21.939112] ath10k_snoc 18800000.wifi: qmi fw log request completed, mode: 0
$ ./ath10k-fwencoder --info /lib/firmware/ath10k/WCN3990/hw1.0/firmware-5.bin
FileSize: 60
FileCRC32: b3d4b790
FileMD5: d16e3444f68ee48c548a891b9f9279e1
Timestamp: 2018-10-11 05:50:28
Features: wowlan,mgmt-tx-by-ref,non-bmi
WMIOpVersion: tlv
HTTOpVersion: tlv
wowlan,mgmt-tx-by-ref,non-bmi = b6,b18,b19 = 0xc0040
However, the vendor kernel hard-codes value = 0x82E = b11,b5,b3,b2,b1
https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/drivers/net/wireless/ath/ath10k/hw.c#L529
WMI_10X (Deprecated)
HAS_WMI_MGMT_TX
NO_P2P
MULTI_VIF_PS_SUPPORT
SUPPORTS_ADAPTIVE_CCA
Not sure which value I should encode for this board's firmware-5.bin ...
I'll try the upstream value.
diff --git a/tools/scripts/ath10k/ath10k-fwencoder b/tools/scripts/ath10k/ath10k-fwencoder
index ceb26b4..44fef64 100755
--- a/tools/scripts/ath10k/ath10k-fwencoder
+++ b/tools/scripts/ath10k/ath10k-fwencoder
@@ -65,7 +65,9 @@ ATH10K_FW_FEATURE_MGMT_TX_BY_REF = 18
ATH10K_FW_FEATURE_NON_BMI = 19
ATH10K_FW_FEATURE_SINGLE_CHAN_INFO_PER_CHANNEL = 20
ATH10K_FW_FEATURE_PEER_FIXED_RATE = 21
-ATH10K_FW_FEATURE_MAX = 22
+ATH10K_FW_FEATURE_IRAM_RECOVERY = 22
+ATH10K_FW_FEATURE_NO_MSA_READY = 23
+ATH10K_FW_FEATURE_MAX = 24
feature_map = {
'ext-wmi-mgmt-rx': ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX,
@@ -91,6 +93,8 @@ feature_map = {
'non-bmi': ATH10K_FW_FEATURE_NON_BMI,
'single-chan-info-per-channel': ATH10K_FW_FEATURE_SINGLE_CHAN_INFO_PER_CHANNEL,
'peer-fixed-rate': ATH10K_FW_FEATURE_PEER_FIXED_RATE,
+ 'iram-recovery': ATH10K_FW_FEATURE_IRAM_RECOVERY,
+ 'no-msa-ready': ATH10K_FW_FEATURE_NO_MSA_READY,
}
# from enum ath10k_fw_wmi_op_version in ath10k/hw.h
$ ./ath10k-fwencoder -d --modify --features=wowlan,mgmt-tx-by-ref,non-bmi,no-msa-ready firmware-5.bin
DEBUG: adding id 1 len(value) 4padding_len 0
DEBUG: adding id 2 len(value) 3padding_len 1
DEBUG: adding id 5 len(value) 4padding_len 0
DEBUG: adding id 6 len(value) 4padding_len 0
firmware-5.bin modified: 60 B
$ ./ath10k-fwencoder --info firmware-5.bin
FileSize: 60
FileCRC32: 3ec1ac4b
FileMD5: dcfd93d86255c481d908af85c30a23b5
Timestamp: 2024-03-26 13:45:25
Features: wowlan,mgmt-tx-by-ref,non-bmi,no-msa-ready
WMIOpVersion: tlv
HTTOpVersion: tlv
Don't know how to say:
"Use THIS firmware-5.bin for all msm8998 platforms"
Testing patch proposed on March 5...
"Houston, we have a problem."
QMI stuff happens much EARLIER than firmware-5.bin handling.
(ar->running_fw is still NULL)
[ 14.547563] ath10k_snoc 18800000.wifi: qmi wifi fw qmi service connected
[ 14.555054] ath10k_snoc 18800000.wifi: qmi indication register request completed
[ 14.561406] ath10k_snoc 18800000.wifi: qmi host capability request completed
[ 14.568365] ath10k_snoc 18800000.wifi: qmi msa mem region 0 addr 0x0x0000000094400000 size 0x4000 flag 0x00000001
[ 14.573775] ath10k_snoc 18800000.wifi: qmi msa mem region 1 addr 0x0x0000000094404000 size 0xfc000 flag 0x00000000
[ 14.583896] ath10k_snoc 18800000.wifi: qmi msa mem info request completed
[ 14.630179] ath10k_snoc 18800000.wifi: qmi msa mem ready request completed
[ 14.681647] ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40010002
[ 14.681726] ath10k_snoc 18800000.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
*** ATH10K_QMI_EVENT_SERVER_ARRIVE is handled at this point
[ 14.690657] ath10k_snoc 18800000.wifi: DT bdf variant name not set.
[ 14.706423] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
[ 14.712587] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
[ 14.722309] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff'
[ 14.745634] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/board-2.bin': 0
... snip boards dump
[ 15.560607] ath10k_snoc 18800000.wifi: boot found match for name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
[ 15.570590] ath10k_snoc 18800000.wifi: boot found board data for 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
[ 15.580393] ath10k_snoc 18800000.wifi: using board api 2
[ 15.591465] ath10k_snoc 18800000.wifi: qmi bdf download request completed
[ 15.595786] ath10k_snoc 18800000.wifi: qmi cal report request completed
[ 18.667441] ath10k_snoc 18800000.wifi: wifi fw ready event received
[ 18.667519] ath10k_snoc 18800000.wifi: ath10k_snoc_hif_power_up:WCN3990 driver state = 0
[ 18.672579] ath10k_snoc 18800000.wifi: soc power on
[ 18.684550] ath10k_snoc 18800000.wifi: qmi mode 0 config 00000000313ae0ca
[ 18.692591] ath10k_snoc 18800000.wifi: qmi config request completed
[ 18.748262] ath10k_snoc 18800000.wifi: qmi wlan mode req completed: 0
[ 18.748370] ath10k_snoc 18800000.wifi: boot init ce src ring id 0 entries 16 base_addr 00000000b9feff9c
[ 18.753792] ath10k_snoc 18800000.wifi: boot ce dest ring id 1 entries 512 base_addr 000000005f850e88
[ 18.762971] ath10k_snoc 18800000.wifi: boot ce dest ring id 2 entries 64 base_addr 000000002467084e
[ 18.772375] ath10k_snoc 18800000.wifi: boot init ce src ring id 3 entries 32 base_addr 00000000ded78c3f
[ 18.781122] ath10k_snoc 18800000.wifi: boot init ce src ring id 4 entries 2048 base_addr 00000000c9e8883a
[ 18.790482] ath10k_snoc 18800000.wifi: boot ce dest ring id 5 entries 512 base_addr 00000000309e9375
[ 18.800220] ath10k_snoc 18800000.wifi: boot init ce src ring id 7 entries 2 base_addr 00000000e5e3fb73
[ 18.809395] ath10k_snoc 18800000.wifi: boot ce dest ring id 7 entries 2 base_addr 00000000c08890b2
[ 18.818507] ath10k_snoc 18800000.wifi: boot ce dest ring id 8 entries 128 base_addr 000000006af0777e
[ 18.827466] ath10k_snoc 18800000.wifi: boot ce dest ring id 9 entries 512 base_addr 00000000f2c0ce43
[ 18.836770] ath10k_snoc 18800000.wifi: boot ce dest ring id 10 entries 512 base_addr 00000000269a2564
[ 18.845863] ath10k_snoc 18800000.wifi: boot ce dest ring id 11 entries 512 base_addr 00000000f4a8c90e
[ 18.855002] ath10k_snoc 18800000.wifi: Hardware name wcn3990 hw1.0 version 0x8
[ 18.865605] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/pre-cal-snoc-18800000.wifi.bin': -2
[ 18.871747] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/cal-snoc-18800000.wifi.bin': -2
[ 18.880307] ath10k_snoc 18800000.wifi: trying fw api 6
[ 18.889520] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-6.bin': -2
[ 18.894020] ath10k_snoc 18800000.wifi: trying fw api 5
*** firmware-5.bin is handled at this point
[ 18.904176] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-5.bin': 0
[ 18.907802] ath10k_snoc 18800000.wifi: found fw timestamp 1539237028
[ 18.916460] ath10k_snoc 18800000.wifi: found firmware features ie (3 B)
[ 18.923027] ath10k_snoc 18800000.wifi: Enabling feature bit: 6
[ 18.929373] ath10k_snoc 18800000.wifi: Enabling feature bit: 18
[ 18.935279] ath10k_snoc 18800000.wifi: Enabling feature bit: 19
[ 18.941085] ath10k_snoc 18800000.wifi: features
[ 18.946975] ath10k_snoc 18800000.wifi: 00000000: 40 00 0c 00 00 00 00 00 @.......
[ 18.951534] ath10k_snoc 18800000.wifi: found fw ie wmi op version 4
[ 18.961235] ath10k_snoc 18800000.wifi: found fw ie htt op version 3
[ 18.967390] ath10k_snoc 18800000.wifi: using fw api 5
I don't know how to solve this problem.
(If we just skip waiting for MSA_READY, there is no problem)
Kalle, Jeff, do you see a way out of this conundrum?
Regards.
[ 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 MSA_READY indicator.
On 26/03/2024 16:04, Marc Gonzalez wrote:
> QMI stuff happens much EARLIER than firmware-5.bin handling.
> (ar->running_fw is still NULL)
>
>
> [ 14.547563] ath10k_snoc 18800000.wifi: qmi wifi fw qmi service connected
> [ 14.555054] ath10k_snoc 18800000.wifi: qmi indication register request completed
> [ 14.561406] ath10k_snoc 18800000.wifi: qmi host capability request completed
> [ 14.568365] ath10k_snoc 18800000.wifi: qmi msa mem region 0 addr 0x0x0000000094400000 size 0x4000 flag 0x00000001
> [ 14.573775] ath10k_snoc 18800000.wifi: qmi msa mem region 1 addr 0x0x0000000094404000 size 0xfc000 flag 0x00000000
> [ 14.583896] ath10k_snoc 18800000.wifi: qmi msa mem info request completed
> [ 14.630179] ath10k_snoc 18800000.wifi: qmi msa mem ready request completed
> [ 14.681647] ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40010002
> [ 14.681726] ath10k_snoc 18800000.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
> *** ATH10K_QMI_EVENT_SERVER_ARRIVE is handled at this point
> [ 14.690657] ath10k_snoc 18800000.wifi: DT bdf variant name not set.
> [ 14.706423] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> [ 14.712587] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> [ 14.722309] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff'
> [ 14.745634] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/board-2.bin': 0
> ... snip boards dump
> [ 15.560607] ath10k_snoc 18800000.wifi: boot found match for name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> [ 15.570590] ath10k_snoc 18800000.wifi: boot found board data for 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> [ 15.580393] ath10k_snoc 18800000.wifi: using board api 2
> [ 15.591465] ath10k_snoc 18800000.wifi: qmi bdf download request completed
> [ 15.595786] ath10k_snoc 18800000.wifi: qmi cal report request completed
> [ 18.667441] ath10k_snoc 18800000.wifi: wifi fw ready event received
> [ 18.667519] ath10k_snoc 18800000.wifi: ath10k_snoc_hif_power_up:WCN3990 driver state = 0
> [ 18.672579] ath10k_snoc 18800000.wifi: soc power on
> [ 18.684550] ath10k_snoc 18800000.wifi: qmi mode 0 config 00000000313ae0ca
> [ 18.692591] ath10k_snoc 18800000.wifi: qmi config request completed
> [ 18.748262] ath10k_snoc 18800000.wifi: qmi wlan mode req completed: 0
> [ 18.748370] ath10k_snoc 18800000.wifi: boot init ce src ring id 0 entries 16 base_addr 00000000b9feff9c
> [ 18.753792] ath10k_snoc 18800000.wifi: boot ce dest ring id 1 entries 512 base_addr 000000005f850e88
> [ 18.762971] ath10k_snoc 18800000.wifi: boot ce dest ring id 2 entries 64 base_addr 000000002467084e
> [ 18.772375] ath10k_snoc 18800000.wifi: boot init ce src ring id 3 entries 32 base_addr 00000000ded78c3f
> [ 18.781122] ath10k_snoc 18800000.wifi: boot init ce src ring id 4 entries 2048 base_addr 00000000c9e8883a
> [ 18.790482] ath10k_snoc 18800000.wifi: boot ce dest ring id 5 entries 512 base_addr 00000000309e9375
> [ 18.800220] ath10k_snoc 18800000.wifi: boot init ce src ring id 7 entries 2 base_addr 00000000e5e3fb73
> [ 18.809395] ath10k_snoc 18800000.wifi: boot ce dest ring id 7 entries 2 base_addr 00000000c08890b2
> [ 18.818507] ath10k_snoc 18800000.wifi: boot ce dest ring id 8 entries 128 base_addr 000000006af0777e
> [ 18.827466] ath10k_snoc 18800000.wifi: boot ce dest ring id 9 entries 512 base_addr 00000000f2c0ce43
> [ 18.836770] ath10k_snoc 18800000.wifi: boot ce dest ring id 10 entries 512 base_addr 00000000269a2564
> [ 18.845863] ath10k_snoc 18800000.wifi: boot ce dest ring id 11 entries 512 base_addr 00000000f4a8c90e
> [ 18.855002] ath10k_snoc 18800000.wifi: Hardware name wcn3990 hw1.0 version 0x8
> [ 18.865605] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/pre-cal-snoc-18800000.wifi.bin': -2
> [ 18.871747] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/cal-snoc-18800000.wifi.bin': -2
> [ 18.880307] ath10k_snoc 18800000.wifi: trying fw api 6
> [ 18.889520] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-6.bin': -2
> [ 18.894020] ath10k_snoc 18800000.wifi: trying fw api 5
> *** firmware-5.bin is handled at this point
> [ 18.904176] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-5.bin': 0
> [ 18.907802] ath10k_snoc 18800000.wifi: found fw timestamp 1539237028
> [ 18.916460] ath10k_snoc 18800000.wifi: found firmware features ie (3 B)
> [ 18.923027] ath10k_snoc 18800000.wifi: Enabling feature bit: 6
> [ 18.929373] ath10k_snoc 18800000.wifi: Enabling feature bit: 18
> [ 18.935279] ath10k_snoc 18800000.wifi: Enabling feature bit: 19
> [ 18.941085] ath10k_snoc 18800000.wifi: features
> [ 18.946975] ath10k_snoc 18800000.wifi: 00000000: 40 00 0c 00 00 00 00 00 @.......
> [ 18.951534] ath10k_snoc 18800000.wifi: found fw ie wmi op version 4
> [ 18.961235] ath10k_snoc 18800000.wifi: found fw ie htt op version 3
> [ 18.967390] ath10k_snoc 18800000.wifi: using fw api 5
>
>
>
> I don't know how to solve this problem.
> (If we just skip waiting for MSA_READY, there is no problem)
>
> Kalle, Jeff, do you see a way out of this conundrum?
Regards.
On Tue, 26 Mar 2024 at 19:45, Marc Gonzalez <[email protected]> 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, so we can't rely on feature bits
> to work around the lack of MSA_READY indicator.
Then, I'd say, we have to resort to the DT property, unless Kalle or
Jeff have other proposals.
>
>
> On 26/03/2024 16:04, Marc Gonzalez wrote:
>
> > QMI stuff happens much EARLIER than firmware-5.bin handling.
> > (ar->running_fw is still NULL)
> >
> >
> > [ 14.547563] ath10k_snoc 18800000.wifi: qmi wifi fw qmi service connected
> > [ 14.555054] ath10k_snoc 18800000.wifi: qmi indication register request completed
> > [ 14.561406] ath10k_snoc 18800000.wifi: qmi host capability request completed
> > [ 14.568365] ath10k_snoc 18800000.wifi: qmi msa mem region 0 addr 0x0x0000000094400000 size 0x4000 flag 0x00000001
> > [ 14.573775] ath10k_snoc 18800000.wifi: qmi msa mem region 1 addr 0x0x0000000094404000 size 0xfc000 flag 0x00000000
> > [ 14.583896] ath10k_snoc 18800000.wifi: qmi msa mem info request completed
> > [ 14.630179] ath10k_snoc 18800000.wifi: qmi msa mem ready request completed
> > [ 14.681647] ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40010002
> > [ 14.681726] ath10k_snoc 18800000.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
> > *** ATH10K_QMI_EVENT_SERVER_ARRIVE is handled at this point
> > [ 14.690657] ath10k_snoc 18800000.wifi: DT bdf variant name not set.
> > [ 14.706423] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> > [ 14.712587] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> > [ 14.722309] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff'
> > [ 14.745634] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/board-2.bin': 0
> > ... snip boards dump
> > [ 15.560607] ath10k_snoc 18800000.wifi: boot found match for name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> > [ 15.570590] ath10k_snoc 18800000.wifi: boot found board data for 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> > [ 15.580393] ath10k_snoc 18800000.wifi: using board api 2
> > [ 15.591465] ath10k_snoc 18800000.wifi: qmi bdf download request completed
> > [ 15.595786] ath10k_snoc 18800000.wifi: qmi cal report request completed
> > [ 18.667441] ath10k_snoc 18800000.wifi: wifi fw ready event received
> > [ 18.667519] ath10k_snoc 18800000.wifi: ath10k_snoc_hif_power_up:WCN3990 driver state = 0
> > [ 18.672579] ath10k_snoc 18800000.wifi: soc power on
> > [ 18.684550] ath10k_snoc 18800000.wifi: qmi mode 0 config 00000000313ae0ca
> > [ 18.692591] ath10k_snoc 18800000.wifi: qmi config request completed
> > [ 18.748262] ath10k_snoc 18800000.wifi: qmi wlan mode req completed: 0
> > [ 18.748370] ath10k_snoc 18800000.wifi: boot init ce src ring id 0 entries 16 base_addr 00000000b9feff9c
> > [ 18.753792] ath10k_snoc 18800000.wifi: boot ce dest ring id 1 entries 512 base_addr 000000005f850e88
> > [ 18.762971] ath10k_snoc 18800000.wifi: boot ce dest ring id 2 entries 64 base_addr 000000002467084e
> > [ 18.772375] ath10k_snoc 18800000.wifi: boot init ce src ring id 3 entries 32 base_addr 00000000ded78c3f
> > [ 18.781122] ath10k_snoc 18800000.wifi: boot init ce src ring id 4 entries 2048 base_addr 00000000c9e8883a
> > [ 18.790482] ath10k_snoc 18800000.wifi: boot ce dest ring id 5 entries 512 base_addr 00000000309e9375
> > [ 18.800220] ath10k_snoc 18800000.wifi: boot init ce src ring id 7 entries 2 base_addr 00000000e5e3fb73
> > [ 18.809395] ath10k_snoc 18800000.wifi: boot ce dest ring id 7 entries 2 base_addr 00000000c08890b2
> > [ 18.818507] ath10k_snoc 18800000.wifi: boot ce dest ring id 8 entries 128 base_addr 000000006af0777e
> > [ 18.827466] ath10k_snoc 18800000.wifi: boot ce dest ring id 9 entries 512 base_addr 00000000f2c0ce43
> > [ 18.836770] ath10k_snoc 18800000.wifi: boot ce dest ring id 10 entries 512 base_addr 00000000269a2564
> > [ 18.845863] ath10k_snoc 18800000.wifi: boot ce dest ring id 11 entries 512 base_addr 00000000f4a8c90e
> > [ 18.855002] ath10k_snoc 18800000.wifi: Hardware name wcn3990 hw1.0 version 0x8
> > [ 18.865605] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/pre-cal-snoc-18800000.wifi.bin': -2
> > [ 18.871747] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/cal-snoc-18800000.wifi.bin': -2
> > [ 18.880307] ath10k_snoc 18800000.wifi: trying fw api 6
> > [ 18.889520] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-6.bin': -2
> > [ 18.894020] ath10k_snoc 18800000.wifi: trying fw api 5
> > *** firmware-5.bin is handled at this point
> > [ 18.904176] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-5.bin': 0
> > [ 18.907802] ath10k_snoc 18800000.wifi: found fw timestamp 1539237028
> > [ 18.916460] ath10k_snoc 18800000.wifi: found firmware features ie (3 B)
> > [ 18.923027] ath10k_snoc 18800000.wifi: Enabling feature bit: 6
> > [ 18.929373] ath10k_snoc 18800000.wifi: Enabling feature bit: 18
> > [ 18.935279] ath10k_snoc 18800000.wifi: Enabling feature bit: 19
> > [ 18.941085] ath10k_snoc 18800000.wifi: features
> > [ 18.946975] ath10k_snoc 18800000.wifi: 00000000: 40 00 0c 00 00 00 00 00 @.......
> > [ 18.951534] ath10k_snoc 18800000.wifi: found fw ie wmi op version 4
> > [ 18.961235] ath10k_snoc 18800000.wifi: found fw ie htt op version 3
> > [ 18.967390] ath10k_snoc 18800000.wifi: using fw api 5
> >
> >
> >
> > I don't know how to solve this problem.
> > (If we just skip waiting for MSA_READY, there is no problem)
> >
> > Kalle, Jeff, do you see a way out of this conundrum?
>
> Regards.
>
--
With best wishes
Dmitry
On 3/26/2024 10:51 AM, Dmitry Baryshkov wrote:
> On Tue, 26 Mar 2024 at 19:45, Marc Gonzalez <[email protected]> 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, so we can't rely on feature bits
>> to work around the lack of MSA_READY indicator.
>
> Then, I'd say, we have to resort to the DT property, unless Kalle or
> Jeff have other proposals.
Another option is to follow the downstream driver model and only expect this
based upon static configuration within the driver.
Downstream driver has:
if (priv->device_id == ADRASTEA_DEVICE_ID) {
ret = wlfw_msa_mem_info_send_sync_msg(priv);
ret = wlfw_msa_ready_send_sync_msg(priv);
}
https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/platform/-/blob/wlan-platform.lnx.1.0.r4-rel/icnss2/main.c?ref_type=heads#L968
The downstream MSA logic (including some other code that populates MSA-related
fields in the QMI messages) is only invoked for ADRASTEA_DEVICE_ID.
We could introduce a new hw_params parameter to have the same semantics.
But I'm OK with the DT option as well.
Kalle?
/jeff
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. ]
>>>
>>> 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 MSA_READY indicator.
>>
>> Then, I'd say, we have to resort to the DT property, unless Kalle or
>> Jeff have other proposals.
>
> Another option is to follow the downstream driver model and only expect this
> based upon static configuration within the driver.
>
> Downstream driver has:
> if (priv->device_id == ADRASTEA_DEVICE_ID) {
> ret = wlfw_msa_mem_info_send_sync_msg(priv);
> ret = wlfw_msa_ready_send_sync_msg(priv);
> }
>
> https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/platform/-/blob/wlan-platform.lnx.1.0.r4-rel/icnss2/main.c?ref_type=heads#L968
>
> The downstream MSA logic (including some other code that populates MSA-related
> fields in the QMI messages) is only invoked for ADRASTEA_DEVICE_ID.
>
> We could introduce a new hw_params parameter to have the same semantics.
>
> But I'm OK with the DT option as well.
>
> Kalle?
I'll send a v2 series with the DT option + setting the quirk flag for
all msm8998 devices. I'll include msm8998 board maintainers for feedback.
Regards