linux-kernel - Re: [PATCH v2 3/5] drm/msm/adreno: Introduce gmu

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: <243c0432-a681-4932-957b-e80f2f4ef295@linaro.org>
Date: Sat, 29 Jun 2024 15:06:22 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Akhil P Oommen <quic_akhilpo@...cinc.com>,
 freedreno <freedreno@...ts.freedesktop.org>,
 dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
 OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
 <devicetree@...r.kernel.org>, Bjorn Andersson <andersson@...nel.org>,
 Rob Clark <robdclark@...il.com>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Krzysztof Kozlowski <krzk@...nel.org>, Will Deacon <will@...nel.org>
Cc: Abhinav Kumar <quic_abhinavk@...cinc.com>, Daniel Vetter
 <daniel@...ll.ch>, David Airlie <airlied@...il.com>,
 Marijn Suijten <marijn.suijten@...ainline.org>, Sean Paul <sean@...rly.run>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/5] drm/msm/adreno: Introduce gmu_chipid for a740 &
 a750

On 29.06.2024 3:49 AM, Akhil P Oommen wrote:
> To simplify, introduce the new gmu_chipid for a740 & a750 GPUs.
> 
> Signed-off-by: Akhil P Oommen <quic_akhilpo@...cinc.com>
> ---

This gets rid of getting patchid from dts, but I suppose that's fine,
as we can just add a new entry to the id table

[...]

> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -771,7 +771,7 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu, unsigned int state)
>  	struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
>  	const struct a6xx_info *a6xx_info = adreno_gpu->info->a6xx;
>  	u32 fence_range_lower, fence_range_upper;
> -	u32 chipid, chipid_min = 0;
> +	u32 chipid = 0;

The initialization doesn't seem necessary

otherwise:

Reviewed-by: Konrad Dybcio <konrad.dybcio@...aro.org>

Konrad