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

Message-ID: <416c07c1-c563-c72c-edfd-ae14ecf0cf13@canonical.com>
Date:   Fri, 11 Feb 2022 08:55:21 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        Julius Werner <jwerner@...omium.org>
Cc:     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

On 11/02/2022 00:17, Dmitry Osipenko wrote:
> В Wed, 9 Feb 2022 16:32:25 -0800
> Julius Werner <jwerner@...omium.org> пишет:
> > 
>>> 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.

Yeah, LPDDR5 is a nice argument. Let's go with the array approach (so
LPDDR3).

Julius,
Official deprecation is needed, because the property might be used also
in other projects or customers. But this is not a big deal - we will
just keep old property for some time.

Will you send a patch for it?

Best regards,
Krzysztof