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

Powered by Openwall GNU/*/Linux Powered by OpenVZ