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:   Fri, 11 Feb 2022 02:17:39 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Julius Werner <jwerner@...omium.org>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        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

В Wed, 9 Feb 2022 16:32:25 -0800
Julius Werner <jwerner@...omium.org> пишет:

> > 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/.

Thank you for the clarification. Which device is that and why userspace
needs to know so much about memory?

> > 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?

If you're going to use multiple cells for other properties, then indeed
will be better to keep it consistent.