linux-kernel - Re: [PATCH v2 12/13] dt-bindings: drm/msm/gpu: Extend bindings for chip-id

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: <CAF6AEGu-aRzi6ADqCnLU46DC0ZoWmSmhYU2sZj83wTyTbazbxg@mail.gmail.com>
Date:   Fri, 28 Jul 2023 08:29:19 -0700
From:   Rob Clark <robdclark@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
        linux-arm-msm@...r.kernel.org,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Akhil P Oommen <quic_akhilpo@...cinc.com>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Clark <robdclark@...omium.org>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Sean Paul <sean@...rly.run>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 12/13] dt-bindings: drm/msm/gpu: Extend bindings for chip-id

On Fri, Jul 28, 2023 at 12:27 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 27/07/2023 23:20, Rob Clark wrote:
> > From: Rob Clark <robdclark@...omium.org>
> >
> > Upcoming GPUs use an opaque chip-id for identifying the GPU.
>
> Examples?

We'll know when we bring up the hw.  But the main point is that we
shouldn't expect, for example, the high 8 bits to tell us the
generation, any more than we could if it was a pci id.

We may not end up needing to use this new binding much, I _think_ we
should be able to read it from the fw in most cases, at least for
android devices.  I'm unsure at this point about windows/chromebooks.

> Anyway, I think we should insist here of using something human-readable,
> even if Qualcomm/Adreno internally use some weird numbers.

I mean qcom,sc8280cx-adreno is human readable but not really very
informative.  Encoding the chip-id is just a way to avoid the
qcom,chipid field in the bindings, which qcom used downstream.  The
new pattern accomplishes the same thing as the existing one, but
without trying to imply some meaning that becomes increasingly
non-existent as qc moves to decouple the id from marketing names.

> >
> > Signed-off-by: Rob Clark <robdclark@...omium.org>
> > ---
> >  Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
> > index 58ca8912a8c3..56b9b247e8c2 100644
> > --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
> > +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
> > @@ -13,6 +13,12 @@ maintainers:
> >  properties:
> >    compatible:
> >      oneOf:
> > +      - description: |
> > +          The driver is parsing the compat string for Adreno to
> > +          figure out the chip-id.
> > +        items:
> > +          - pattern: '^qcom,adreno-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]$'
>
> {8} should work?
>

so '^qcom,adreno-[0-9a-f]{8}$'

BR,
-R

>
>
> Best regards,
> Krzysztof
>