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 for Android: free password hash cracker in your pocket

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

Message-ID: <20230525025445.lxfvmnlm2ezzi45g@ripper>
Date:   Wed, 24 May 2023 19:54:45 -0700
From:   Bjorn Andersson <andersson@...nel.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     Trilok Soni <quic_tsoni@...cinc.com>,
        Robert Marko <robimarko@...il.com>, agross@...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, ansuelsmth@...il.com
Subject: Re: [PATCH v2 2/4] soc: qcom: smem: introduce qcom_smem_get_msm_id()

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.
> 

Returning the value in CPU-native endian sounds very reasonable, so we
don't need __le32_to_cpu() on the calling side.

If we want to worry about this value going beyond 31 bits the
appropriate way would be to take, and assign, a unsigned int* argument
and return 0/-errno to indicate success/failure.

Regards,
Bjorn

> 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
> > 
> >