linux-kernel - Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and related bindings

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]

Date:   Thu, 28 Jul 2022 09:35:49 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Doug Anderson <dianders@...omium.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Julius Werner <jwerner@...omium.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Dmitry Osipenko <digetx@...il.com>,
        Jian-Jia Su <jjsu@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Nikola Milosavljevic <mnidza@...look.com>
Subject: Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and
 related bindings

On 27/07/2022 16:07, Doug Anderson wrote:
> Hi,
> 
> On Wed, Jul 27, 2022 at 1:47 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>> On 21/07/2022 01:42, Julius Werner wrote:
>>> Sorry, got distracted from this for a bit. Sounds like we were pretty
>>> much on the same page about how the updated binding should look like
>>> here, the remaining question was just about the compatible string.
>>>
>>>>>> Yes, we can. You still would need to generate the compatible according
>>>>>> to the current bindings. Whether we can change it I am not sure. I think
>>>>>> it depends how much customization is possible per vendor, according to
>>>>>> JEDEC spec. If we never ever have to identify specific part, because
>>>>>> JEDEC spec and registers tell us everything, then we could skip it,
>>>>>> similarly to lpddr2 and jedec,spi-nor.
>>>>>
>>>>> Shouldn't that be decided per use case? In general LPDDR is a pretty
>>>>> rigid set of standards and memory controllers are generally compatible
>>>>> with any vendor without hardcoding vendor-specific behavior, so I
>>>>> don't anticipate that this would be likely (particularly since there
>>>>> is no "real" kernel device driver that needs to initialize the full
>>>>> memory controller, after all, these bindings are mostly
>>>>> informational).
>>>>
>>>> If decided per use case understood as "decided depending how to use the
>>>> bindings" then answer is rather not. For example Linux implementation is
>>>> usually not the best argument to shape the bindings and usually to such
>>>> arguments answer is: "implementation does not matter".
>>>>
>>>> If by "use case" you mean actual hardware or specification
>>>> characteristics, then yes, of course. This is why I wrote "it depends".
>>>
>>> By "use case" I mean our particular platform and firmware requirements
>>> -- or rather, the realities of building devices with widely
>>> multi-sourced LPDDR parts. One cannot efficiently build firmware that
>>> can pass an exact vendor-and-part-specific compatible string to Linux
>>> for this binding for every single LPDDR part used on such a platform.
>>
>> Why cannot? You want to pass them as numerical values which directly map
>> to vendor ID and some part, don't they?
> 
> If you really want this to be in the "compatible" string, maybe the
> right answer is to follow the lead of USB which encodes the VID/PID in
> the compatible string
> (Documentation/devicetree/bindings/usb/usb-device.yaml). It's solving
> this exact same problem of avoiding needing a table translating from
> an ID provided by a probable device to an human-readable string.

This makes sense. I would still argue that number of vendors is small
thus strings could be translated (there is like 20 of them in JEP166D -
JC-42.6), but for device ID this would work.

> 
> 
>>> And I don't see why that should be needed, either... that's kinda the
>>> point of having an interoperability standard, after all, that you can
>>> just assume the devices all work according to the same spec and don't
>>> need to hardcode details about each specific instance.
>>
>> If we talk about standard, then DT purpose is not for autodetectable
>> pieces. These values are autodetectable, so such properties should not
>> be encoded in DT.
> 
> In the case of DDR, I think that the firmware can auto-detect them but
> not the kernel. So from the kernel's point of view the DDR info should
> be in DT, right?

True, I thought memory controllers could provide such information, but
now I checked Exynos5422 DMC and it does not expose such register.


Best regards,
Krzysztof