From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Dmitry Osipenko <digetx@gmail.com>, Julius Werner <jwerner@chromium.org>
Cc: Rob Herring <robh@kernel.org>,
linux-tegra@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties
Date: Fri, 11 Feb 2022 08:55:21 +0100 [thread overview]
Message-ID: <416c07c1-c563-c72c-edfd-ae14ecf0cf13@canonical.com> (raw)
In-Reply-To: <20220211021739.14f3614c@dimatab>
On 11/02/2022 00:17, Dmitry Osipenko wrote:
> В Wed, 9 Feb 2022 16:32:25 -0800
> Julius Werner <jwerner@chromium.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
next prev parent reply other threads:[~2022-02-11 7:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 22:46 [PATCH v5 0/9] tegra20-emc: Identify memory chip by LPDDR configuration Dmitry Osipenko
2021-10-06 22:46 ` [PATCH v5 1/9] dt-bindings: Relocate DDR bindings Dmitry Osipenko
2021-10-14 21:22 ` Rob Herring
2021-10-06 22:46 ` [PATCH v5 2/9] dt-bindings: memory: lpddr2: Convert to schema Dmitry Osipenko
2021-10-14 21:50 ` Rob Herring
2021-10-06 22:46 ` [PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id properties Dmitry Osipenko
2021-10-14 21:51 ` Rob Herring
2022-02-08 2:06 ` Julius Werner
2022-02-08 8:10 ` Krzysztof Kozlowski
2022-02-08 23:46 ` Julius Werner
2022-02-09 8:58 ` Krzysztof Kozlowski
2022-02-09 11:49 ` Dmitry Osipenko
2022-02-10 0:32 ` Julius Werner
2022-02-10 23:17 ` Dmitry Osipenko
2022-02-11 7:55 ` Krzysztof Kozlowski [this message]
2021-10-06 22:46 ` [PATCH v5 4/9] dt-bindings: memory: lpddr2: Document Elpida B8132B2PB-6D-F Dmitry Osipenko
2021-10-14 21:51 ` Rob Herring
2021-10-06 22:46 ` [PATCH v5 5/9] dt-bindings: Add vendor prefix for Elpida Memory Dmitry Osipenko
2021-10-14 21:51 ` Rob Herring
2021-10-06 22:46 ` [PATCH v5 6/9] ARM: dts: elpida_ecb240abacn: Change Elpida compatible Dmitry Osipenko
2021-10-06 22:46 ` [PATCH v5 7/9] dt-bindings: memory: tegra20: emc: Document new LPDDR2 sub-node Dmitry Osipenko
2021-10-14 21:52 ` Rob Herring
2021-10-06 22:46 ` [PATCH v5 8/9] memory: Add LPDDR2-info helpers Dmitry Osipenko
2021-10-06 22:46 ` [PATCH v5 9/9] memory: tegra20-emc: Support matching timings by LPDDR2 configuration Dmitry Osipenko
2021-10-15 7:20 ` [PATCH v5 0/9] tegra20-emc: Identify memory chip by LPDDR configuration Krzysztof Kozlowski
2021-10-18 18:10 ` Dmitry Osipenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=416c07c1-c563-c72c-edfd-ae14ecf0cf13@canonical.com \
--to=krzysztof.kozlowski@canonical.com \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).