linux-kernel - Re: [PATCH 3/4] drm/msm/adreno: Expose speedbin to userspace

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]

Date:   Mon, 17 Jan 2022 10:52:07 -0800
From:   Rob Clark <robdclark@...il.com>
To:     Akhil P Oommen <quic_akhilpo@...cinc.com>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
        <devicetree@...r.kernel.org>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Christian König <christian.koenig@....com>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        Jonathan Marek <jonathan@...ek.ca>,
        Jordan Crouse <jordan@...micpenguin.net>,
        Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
        Sean Paul <sean@...rly.run>,
        Stephen Boyd <swboyd@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/4] drm/msm/adreno: Expose speedbin to userspace

On Mon, Jan 17, 2022 at 6:38 AM Akhil P Oommen <quic_akhilpo@...cinc.com> wrote:
>
> On 1/13/2022 12:43 PM, Dmitry Baryshkov wrote:
> > On Thu, 13 Jan 2022 at 00:19, Rob Clark <robdclark@...il.com> wrote:
> >> On Tue, Jan 11, 2022 at 1:31 PM Akhil P Oommen <quic_akhilpo@...cinc.com> wrote:
> >>> Expose speedbin through MSM_PARAM_CHIP_ID parameter to help userspace
> >>> identify the sku.
> >>>
> >>> Signed-off-by: Akhil P Oommen <quic_akhilpo@...cinc.com>
> >>> ---
> >>>
> >>>   drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +++++----
> >>>   1 file changed, 5 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>> index f33cfa4..e970e6a 100644
> >>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> >>> @@ -242,10 +242,11 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value)
> >>>                  *value = !adreno_is_a650_family(adreno_gpu) ? 0x100000 : 0;
> >>>                  return 0;
> >>>          case MSM_PARAM_CHIP_ID:
> >>> -               *value = adreno_gpu->rev.patchid |
> >>> -                               (adreno_gpu->rev.minor << 8) |
> >>> -                               (adreno_gpu->rev.major << 16) |
> >>> -                               (adreno_gpu->rev.core << 24);
> >>> +               *value = (uint64_t) adreno_gpu->rev.patchid |
> >>> +                               (uint64_t) (adreno_gpu->rev.minor << 8) |
> >>> +                               (uint64_t) (adreno_gpu->rev.major << 16) |
> >>> +                               (uint64_t) (adreno_gpu->rev.core << 24) |
> >>> +                               (((uint64_t) adreno_gpu->rev.sku) << 32);
> >> How about this instead, so we are only changing the behavior for
> >> new/unreleased devices:
>
> I thought this property was only used for new devices whereas the
> existing devices rely on REVN.
>
> -Akhil.
>
> >>
> >> *value = adreno_gpu->rev.patchid |
> >> (adreno_gpu->rev.minor << 8) |
> >> (adreno_gpu->rev.major << 16) |
> >> (adreno_gpu->rev.core << 24);
> >> if (!adreno_gpu->info->revn)
> >> *value |= (((uint64_t) adreno_gpu->rev.sku) << 32);
> >>
> >> (sorry about the butchered indentation.. somehow gmail has become
> >> antagonistic about pasting code)
> > I assume that you would like to keep userspace compat for older chips.
> > thus the if.
> > Maybe we should introduce MSM_PARAM_CHIP_ID_SKU instead (and gradually
> > make userspace switch to it)?
> >

Existing userspace tools do query CHIP_ID, but match based on GPU_ID
(falling back to CHIP_ID only if GPU_ID==0).. still, out of an
abundance of caution, we should probably not change the behavior for
existing GPUs.  But so far the only thing with GPU_ID==0 does not
exist in the wild yet, so I think we can get away without having to
introduce a new param if we only set the upper bits of CHIP_ID when
GPU_ID==0.

BR,
-R