linux-kernel - Re: [PATCH v2 2/4] soc: qcom: smem: introduce qcom_smem_get_msm

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 May 2023 22:53:59 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Christian Marangi <ansuelsmth@...il.com>
Cc:     Trilok Soni <quic_tsoni@...cinc.com>,
        Robert Marko <robimarko@...il.com>, agross@...nel.org,
        andersson@...nel.org, ilia.lin@...nel.org, rafael@...nel.org,
        viresh.kumar@...aro.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 2/4] soc: qcom: smem: introduce qcom_smem_get_msm_id()



On 24.05.2023 21:57, Christian Marangi wrote:
> On Wed, May 24, 2023 at 08:27:03PM +0200, Konrad Dybcio wrote:
>>
>>
>> On 24.05.2023 20:16, Trilok Soni wrote:
>>> On 5/24/2023 9:23 AM, Robert Marko wrote:
>>>> Introduce a helper to return the SoC SMEM ID, which is used to identify the
>>>> exact SoC model as there may be differences in the same SoC family.
>>>>
>>>> Currently, cpufreq-nvmem does this completely in the driver and there has
>>>> been more interest expresed for other drivers to use this information so
>>>> lets expose a common helper to prevent redoing it in individual drivers
>>>> since this field is present on every SMEM table version.
>>>>
>>>> Signed-off-by: Robert Marko <robimarko@...il.com>
>>>> ---
>>>>   drivers/soc/qcom/smem.c       | 19 +++++++++++++++++++
>>>>   include/linux/soc/qcom/smem.h |  2 ++
>>>>   2 files changed, 21 insertions(+)
>>>>
>>>> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
>>>> index 6be7ea93c78c..0d6ba9bce8cb 100644
>>>> --- a/drivers/soc/qcom/smem.c
>>>> +++ b/drivers/soc/qcom/smem.c
>>>> @@ -14,6 +14,7 @@
>>>>   #include <linux/sizes.h>
>>>>   #include <linux/slab.h>
>>>>   #include <linux/soc/qcom/smem.h>
>>>> +#include <linux/soc/qcom/socinfo.h>
>>>>     /*
>>>>    * The Qualcomm shared memory system is a allocate only heap structure that
>>>> @@ -772,6 +773,24 @@ phys_addr_t qcom_smem_virt_to_phys(void *p)
>>>>   }
>>>>   EXPORT_SYMBOL(qcom_smem_virt_to_phys);
>>>>   +/**
>>>> + * qcom_smem_get_msm_id() - return the SoC ID
>>>> + *
>>>> + * Look up SoC ID from HW/SW build ID and return it.
>>>> + */
>>>> +int qcom_smem_get_msm_id(void)
>> On top of Trilok's point, this should return le32, or at least unsigned int.
>>
> 
> Mhhh why unsigned? We would lose error and qcom_smem_get can return all
> sort of errors. Also I think le32 is problematic as we are converting
> the value with __le32_to_cpu.
Hm right.. Qcom didn't really think this through then, but hopefully
they don't randomly jump from e.g. 547 to 1<<31

Konrad
> 
>>>> +{
>>>> +    size_t len;
>>>> +    struct socinfo *info;
>>>> +
>>>> +    info = qcom_smem_get(QCOM_SMEM_HOST_ANY, SMEM_HW_SW_BUILD_ID, &len);
>>>> +    if (IS_ERR(info))
>>>> +        return PTR_ERR(info);
>>>> +
>>>> +    return __le32_to_cpu(info->id);
>>>> +}
>>>> +EXPORT_SYMBOL(qcom_smem_get_msm_id);
>>>
>>> EXPORT_SYMBOL_GPL please?
>>>
>>> Please change it for other symbols in the driver as well w/ separate patch.
>>>
>>> ---Trilok Soni
>>>
>>>
>