linux-kernel - Re: [PATCH v4] wifi: ath10k: Store WLAN firmware version in SMEM image table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <877cza3xg3.fsf@kernel.org>
Date:   Fri, 02 Dec 2022 12:35:24 +0200
From:   Kalle Valo <kvalo@...nel.org>
To:     Nathan Chancellor <nathan@...nel.org>
Cc:     Youghandhar Chintala <quic_youghand@...cinc.com>,
        ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
        linux-kernel@...r.kernel.org, quic_mpubbise@...cinc.com,
        rameshn@....qualcomm.com
Subject: Re: [PATCH v4] wifi: ath10k: Store WLAN firmware version in SMEM image table

Kalle Valo <kvalo@...nel.org> writes:

> Nathan Chancellor <nathan@...nel.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@...cinc.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