From: Kalle Valo <kvalo@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Youghandhar Chintala <quic_youghand@quicinc.com>,
ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_mpubbise@quicinc.com,
rameshn@qti.qualcomm.com
Subject: Re: [PATCH v4] wifi: ath10k: Store WLAN firmware version in SMEM image table
Date: Fri, 02 Dec 2022 12:35:24 +0200 [thread overview]
Message-ID: <877cza3xg3.fsf@kernel.org> (raw)
In-Reply-To: <87sfi13tya.fsf@kernel.org> (Kalle Valo's message of "Wed, 30 Nov 2022 07:14:05 +0200")
Kalle Valo <kvalo@kernel.org> writes:
> Nathan Chancellor <nathan@kernel.org> writes:
>
>> On Thu, Nov 17, 2022 at 11:35:34PM +0530, Youghandhar Chintala wrote:
>>
>>> In a SoC based solution, it would be useful to know the versions of the
>>> various binary firmware blobs the system is running on. On a QCOM based
>>> SoC, this info can be obtained from socinfo debugfs infrastructure. For
>>> this to work, respective subsystem drivers have to export the firmware
>>> version information to an SMEM based version information table.
>>>
>>> Having firmware version information at one place will help quickly
>>> figure out the firmware versions of various subsystems on the device
>>> instead of going through builds/logs in an event of a system crash.
>>>
>>> Fill WLAN firmware version information in SMEM version table to be
>>> printed as part of socinfo debugfs infrastructure on a Qualcomm based
>>> SoC.
>>>
>>> This change is applicable only for SNOC/QMI based targets.
>>>
>>> Example:
>>> cat /sys/kernel/debug/qcom_socinfo/cnss/name
>>> QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
>>>
>>> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
>>>
>>> Signed-off-by: Youghandhar Chintala <quic_youghand@quicinc.com>
>>> ---
>>> Changes from v3:
>>> - Changed patch title
>>> - Changed naming conventions
>>> - Removed MAX_BUILD_ID_LEN usuage
>>> - Added condition to call API
>>> - Changed depends on QCOM_SMEM to select QCOM_SMEM
>>
>> You cannot blindly select user configurable symbols that have
>> dependencies, otherwise you end up with Kconfig warnings. I see the
>> following warning in -next when CONFIG_HWSPINLOCK is disabled:
>>
>> WARNING: unmet direct dependencies detected for QCOM_SMEM
>> Depends on [n]: (ARCH_QCOM [=y] || COMPILE_TEST [=n]) && HWSPINLOCK [=n]
>> Selected by [m]:
>> - ATH10K_SNOC [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && ATH10K [=m] && (ARCH_QCOM [=y] || COMPILE_TEST [=n])
>>
>> That should likely be changed back to 'depends on'. The reason the other
>> QCOM symbols are selected is because they are not user-selectable, so
>> they have to be selected by the configurations that need them.
>
> Thanks, I didn't realise this. I'll send a patch changing it to 'depends
> on'.
Here's the patch:
https://patchwork.kernel.org/project/linux-wireless/patch/20221202103027.25974-1-kvalo@kernel.org/
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Youghandhar Chintala <quic_youghand@quicinc.com>,
ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_mpubbise@quicinc.com,
rameshn@qti.qualcomm.com
Subject: Re: [PATCH v4] wifi: ath10k: Store WLAN firmware version in SMEM image table
Date: Fri, 02 Dec 2022 12:35:24 +0200 [thread overview]
Message-ID: <877cza3xg3.fsf@kernel.org> (raw)
In-Reply-To: <87sfi13tya.fsf@kernel.org> (Kalle Valo's message of "Wed, 30 Nov 2022 07:14:05 +0200")
Kalle Valo <kvalo@kernel.org> writes:
> Nathan Chancellor <nathan@kernel.org> writes:
>
>> On Thu, Nov 17, 2022 at 11:35:34PM +0530, Youghandhar Chintala wrote:
>>
>>> In a SoC based solution, it would be useful to know the versions of the
>>> various binary firmware blobs the system is running on. On a QCOM based
>>> SoC, this info can be obtained from socinfo debugfs infrastructure. For
>>> this to work, respective subsystem drivers have to export the firmware
>>> version information to an SMEM based version information table.
>>>
>>> Having firmware version information at one place will help quickly
>>> figure out the firmware versions of various subsystems on the device
>>> instead of going through builds/logs in an event of a system crash.
>>>
>>> Fill WLAN firmware version information in SMEM version table to be
>>> printed as part of socinfo debugfs infrastructure on a Qualcomm based
>>> SoC.
>>>
>>> This change is applicable only for SNOC/QMI based targets.
>>>
>>> Example:
>>> cat /sys/kernel/debug/qcom_socinfo/cnss/name
>>> QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
>>>
>>> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
>>>
>>> Signed-off-by: Youghandhar Chintala <quic_youghand@quicinc.com>
>>> ---
>>> Changes from v3:
>>> - Changed patch title
>>> - Changed naming conventions
>>> - Removed MAX_BUILD_ID_LEN usuage
>>> - Added condition to call API
>>> - Changed depends on QCOM_SMEM to select QCOM_SMEM
>>
>> You cannot blindly select user configurable symbols that have
>> dependencies, otherwise you end up with Kconfig warnings. I see the
>> following warning in -next when CONFIG_HWSPINLOCK is disabled:
>>
>> WARNING: unmet direct dependencies detected for QCOM_SMEM
>> Depends on [n]: (ARCH_QCOM [=y] || COMPILE_TEST [=n]) && HWSPINLOCK [=n]
>> Selected by [m]:
>> - ATH10K_SNOC [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && ATH10K [=m] && (ARCH_QCOM [=y] || COMPILE_TEST [=n])
>>
>> That should likely be changed back to 'depends on'. The reason the other
>> QCOM symbols are selected is because they are not user-selectable, so
>> they have to be selected by the configurations that need them.
>
> Thanks, I didn't realise this. I'll send a patch changing it to 'depends
> on'.
Here's the patch:
https://patchwork.kernel.org/project/linux-wireless/patch/20221202103027.25974-1-kvalo@kernel.org/
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2022-12-02 10:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 18:05 [PATCH v4] wifi: ath10k: Store WLAN firmware version in SMEM image table Youghandhar Chintala
2022-11-17 18:05 ` Youghandhar Chintala
2022-11-25 11:12 ` Kalle Valo
2022-11-25 11:12 ` Kalle Valo
2022-11-29 16:01 ` Nathan Chancellor
2022-11-29 16:01 ` Nathan Chancellor
2022-11-30 5:14 ` Kalle Valo
2022-11-30 5:14 ` Kalle Valo
2022-12-02 10:35 ` Kalle Valo [this message]
2022-12-02 10:35 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877cza3xg3.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath10k@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=quic_mpubbise@quicinc.com \
--cc=quic_youghand@quicinc.com \
--cc=rameshn@qti.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.