[PATCH v4] wifi: ath10k: Store WLAN firmware version in SMEM image table

Kalle Valo kvalo at kernel.org
Fri Dec 2 02:35:24 PST 2022

Kalle Valo <kvalo at kernel.org> writes:

> Nathan Chancellor <nathan at 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
>>> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
>>> Signed-off-by: Youghandhar Chintala <quic_youghand at 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:




More information about the ath10k mailing list