linux-kernel - Re: [PATCH v2] soc: qcom: ocmem: Add OCMEM hardware version print

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: <cac92fae-310f-79b1-7204-ac9deb2c3319@linaro.org>
Date:   Fri, 26 May 2023 21:39:44 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Luca Weiss <luca@...tu.xyz>, ~postmarketos/upstreaming@...ts.sr.ht,
        phone-devel@...r.kernel.org, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Brian Masney <masneyb@...tation.org>
Cc:     linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] soc: qcom: ocmem: Add OCMEM hardware version print



On 23.05.2023 22:32, Luca Weiss wrote:
> It might be useful to know what hardware version of the OCMEM block the
> SoC contains. Add a debug print for that.
> 
> Signed-off-by: Luca Weiss <luca@...tu.xyz>
> ---
> This patch is depends on [0] but could also be applied in the other
> order, if conflicts are resolved.
> 
> [0] https://lore.kernel.org/linux-arm-msm/20230506-msm8226-ocmem-v1-1-3e24e2724f01@z3ntu.xyz/
> ---
> Changes in v2:
> - Use FIELD_GET macros for getting correct bits from register (take
>   wording from mdp5: major, minor, step which hopefully is sort of
>   accurate)
Qualcomm uses that (or that-ish) nomenclature for many hw blocks, so
it's likely spot on.

> - Link to v1: https://lore.kernel.org/r/20230509-ocmem-hwver-v1-1-b83ece3f2168@z3ntu.xyz
> ---
>  drivers/soc/qcom/ocmem.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
> index c3e78411c637..9f7c3348cbb9 100644
> --- a/drivers/soc/qcom/ocmem.c
> +++ b/drivers/soc/qcom/ocmem.c
> @@ -76,6 +76,10 @@ struct ocmem {
>  #define OCMEM_REG_GFX_MPU_START			0x00001004
>  #define OCMEM_REG_GFX_MPU_END			0x00001008
>  
> +#define OCMEM_HW_VERSION_MAJOR(val)		FIELD_GET(GENMASK(31, 28), val)
> +#define OCMEM_HW_VERSION_MINOR(val)		FIELD_GET(GENMASK(27, 16), val)
> +#define OCMEM_HW_VERSION_STEP(val)		FIELD_GET(GENMASK(15, 0), val)
> +
>  #define OCMEM_HW_PROFILE_NUM_PORTS(val)		FIELD_GET(0x0000000f, (val))
>  #define OCMEM_HW_PROFILE_NUM_MACROS(val)	FIELD_GET(0x00003f00, (val))
>  
> @@ -355,6 +359,11 @@ static int ocmem_dev_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> +	reg = ocmem_read(ocmem, OCMEM_REG_HW_VERSION);
> +	dev_dbg(dev, "OCMEM hardware version: %ld.%ld.%ld\n",
reg is an unsigned long (u32), this should probably be %u

> +		OCMEM_HW_VERSION_MAJOR(reg), OCMEM_HW_VERSION_MINOR(reg),
> +		OCMEM_HW_VERSION_STEP(reg));
Nit: one per line would make this the tiniest bit easier to read

Konrad
> +
>  	reg = ocmem_read(ocmem, OCMEM_REG_HW_PROFILE);
>  	ocmem->num_ports = OCMEM_HW_PROFILE_NUM_PORTS(reg);
>  	ocmem->num_macros = OCMEM_HW_PROFILE_NUM_MACROS(reg);
> 
> ---
> base-commit: 8705151771af822ac794b44504cd72eebc423499
> change-id: 20230509-ocmem-hwver-99bcb33b028b
> 
> Best regards,