linux-kernel - Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 9 Feb 2022 16:32:25 -0800
From:   Julius Werner <jwerner@...omium.org>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Julius Werner <jwerner@...omium.org>,
        Rob Herring <robh@...nel.org>, linux-tegra@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        devicetree@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties

> I don't mind, but I also don't see where the revision-id property of
> LPDDR3 is used at all. I can't find any device-tree with LPDDR3
> revision-id and don't see it being used in the code either. Maybe it's
> the LPDDR3 binding that needs to be changed?

We are using the revision ID in userspace (read through
/proc/device-tree) for runtime memory identification. We don't have a
kernel driver bound to it. Our boot firmware is inserting this value
at runtime into the FDT (that's basically the reason we have this, our
firmware auto-detects memory during boot and we use the FDT to report
what it found to userspace), that's why you can't find it anywhere in
the static device trees in boot/dts/.

> I made each LPDDR2 revision-id property to correspond to a dedicated MR
> of LPDDR, which feels okay to me to since it matches h/w.

I'm not super married to my solution, so if that makes things easier
we can standardize on the two-property version as well. I mostly
designed it my way because I thought we may one day also want to do
something like this for the 8-byte LPDDR5 serial-id, and then it would
get kinda cumbersome to have serial-id1 through serial-id8 all as
separate properties. But that's also a bridge we can cross when we get
there.

My use case is in a position where we could still change this now
without requiring backwards-compatibility. Krzysztof, would you be
okay if I instead changed the "jedec,lpddr3" to the same thing
"jedec,lpddr2" does -- seeing as the original patch was from me, my
use case could handle the switch, there has never been any actual
kernel code using the property, and it seems very unlikely that anyone
else has silently started using the same thing in the time it's been
in the tree? Or do we also need to go the official deprecation route
for that?