linux-kernel - Re: [PATCH v2 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories

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: <4e7b0a6d-491f-a764-f038-1aff5534320f@partner.samsung.com>
Date:   Thu, 19 Sep 2019 09:43:17 +0200
From:   Lukasz Luba <l.luba@...tner.samsung.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-pm@...r.kernel.org,
        "linux-samsung-soc@...r.kernel.org" 
        <linux-samsung-soc@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Bartłomiej Żołnierkiewicz 
        <b.zolnierkie@...sung.com>, kgene@...nel.org, mark.rutland@....com,
        robh+dt@...nel.org, Chanwoo Choi <cw00.choi@...sung.com>,
        kyungmin.park@...sung.com,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        s.nawrocki@...sung.com, myungjoo.ham@...sung.com,
        willy.mh.wolff.ml@...il.com
Subject: Re: [PATCH v2 3/3] dt-bindings: ddr: Add bindings for Samsung
 LPDDR3 memories



On 9/19/19 9:28 AM, Krzysztof Kozlowski wrote:
> On Thu, 19 Sep 2019 at 08:49, Lukasz Luba <l.luba@...tner.samsung.com> wrote:
>>
>> Hi Krzysztof,
>>
>> On 9/18/19 8:51 PM, Krzysztof Kozlowski wrote:
>>> On Mon, 16 Sep 2019 at 12:07, Lukasz Luba <l.luba@...tner.samsung.com> wrote:
>>>>
>>>> Add compatible for Samsung k3qf2f20db LPDDR3 memory bindings.
>>>> Introduce minor fixes in the old documentation.
>>>>
>>>> Signed-off-by: Lukasz Luba <l.luba@...tner.samsung.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/ddr/lpddr3.txt | 9 ++++++---
>>>>    1 file changed, 6 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>> index 3b2485b84b3f..49afe794daaa 100644
>>>> --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>> +++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>> @@ -1,7 +1,9 @@
>>>>    * LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C
>>>>
>>>>    Required properties:
>>>> -- compatible : Should be  - "jedec,lpddr3"
>>>> +- compatible : should be one of the following:
>>>> +       Generic default - "jedec,lpddr3".
>>>
>>> The convention is first compatible, then description. I gave you the
>>> example to base on - at25. Why making it different?
>>
>> I have checked at25 that you pointed me to and also checked at24, which
>> has a bit longer "compatible" section.
>>
>> I found that there are many "jedec,spi-nor" compatible devices, which I
>> thought would be a better example for my "jedec,lpddr3".
>> For example, two configurations, where you have a single labels or dual
>> (with specific device)
>> arch/arm/boot/dts/imx6dl-rex-basic.dts:
>> compatible = "sst,sst25vf016b", "jedec,spi-nor";
>> arch/arm/boot/dts/imx6q-ba16.dtsi:
>> compatible = "jedec,spi-nor";
>>
>> The 'compatible' in documentation for the "jedec,spi-nor" is slightly
>> different (similar to at24).
>> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> It has a long explanation, which is also OK. So I thought that it is
>> quite flexible what you put in there.
> 
> It is flexible but I see clear pattern in existing sources:
>    jedec,spi-nor.txt
>    compatible : May include a device-specific ..
>    ...
>    Supported chip names:
>      at25df321a
>      ...
> 
>    at25.txt:
>    - compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
>      Example "<vendor>,<type>" values:
>        "anvo,anv32e61w"
>        "microchip,25lc040"
> 
> In these cases the doc says that "compatible should be" and then you
> have the list of values. Your example says that the compatible should
> be "Generic default" or "For Samsung 542x SoC"... :) The difference is
> slight but putting the value first is a simple and elegant solution.
> In your case one has to go to the end of sentence to find the most
> important information - the compatible value.
> 
>> I have also checked Cadance QSPI controller.
>> Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
>> The controller might be built-in into different vendor SoC's
>> and the "compatible" is ready to reflect it in similar fashion but
>> with a short explanation in this section.
> 
> I see. I do not find this pattern as much readable as jedec-spi-nor or
> at25 therefore I mentioned them as an example to base on ("Exactly the
> same as AT24 or AT25 EEPROM bindings."). We can avoid also this entire
> discussion with YAML (which also follows approach of at25 - value
> first).
> 
>> Therefore, what you see in the patch draw heavily on Cadence's qspi,
>> with a bit of inspiration from jedec,spi-nor usage.
>>
>> Should I change it to at25 "compatible" style and send next patch?
> 
> Yes, please. Or go to YAML and make entire discussion obsolete.

OK I will change it to at25 style.

Regards,
Lukasz