[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6568fd31-113f-1581-4eff-45a4a1eb4e5d@canonical.com>
Date: Wed, 9 Feb 2022 09:58:34 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To: Julius Werner <jwerner@...omium.org>,
Dmitry Osipenko <digetx@...il.com>
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 09/02/2022 00:46, Julius Werner wrote:
>> Unfortunately I have no clue what patch you talk about ("this patch").
>> There is no context here, no link except the older LPDDR3.
>
> Sorry, I tried to reply to
> https://lore.kernel.org/all/20211006224659.21434-4-digetx@gmail.com/
> ([PATCH v5 3/9] dt-bindings: memory: lpddr2: Add revision-id
> properties) and was hoping that would automatically provide context.
> That patch added two one-cell properties `revision-id1` and
> `revision-id2` to "jedec,lpddr2". Earlier in
> https://www.spinics.net/lists/devicetree/msg413733.html ([PATCH]
> dt-bindings: ddr: Add optional manufacturer and revision ID to
> LPDDR3), I had added a single two-cell property `revision-id` for the
> same purpose to "jedec,lpddr3".
>
> I think it would be better if this was consistent between the two
> types of LPDDR memory. Should I just send a patch that replaces the
> two revision IDs in "jedec,lpddr2" with a single one according to the
> principle of "jedec,lpddr3"? Or is it too late for that now and the
> binding already considered stable and unchangeable?
Hi Julius,
Having same bindings for revision ID makes sense. Sadly this was not
spotted during review, eh, life... Unfortunately the bindings are
already in a mainline release, so they are considered stable. You can
however bring patches (bindings + drivers/memory/of + dts) which make
the revision-id[12] deprecated and introduce new revision-id.
It should be something similar to what I did for max-freq:
https://lore.kernel.org/all/20220206135807.211767-7-krzysztof.kozlowski@canonical.com/
Dmitry,
Any early comments on such approach from you?
Best regards,
Krzysztof
Powered by blists - more mailing lists