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: <7b6867f4-54b2-f3b5-2b4e-87ea3000fa44@gmail.com>
Date:   Thu, 2 May 2019 04:39:44 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Mark Rutland <mark.rutland@....com>,
        Peter De Schrijver <pdeschrijver@...dia.com>,
        Prashant Gaikwad <pgaikwad@...dia.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Joseph Lo <josephl@...dia.com>, devicetree@...r.kernel.org,
        linux-clk <linux-clk@...r.kernel.org>,
        linux-tegra@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/4] dt-bindings: memory: Add binding for NVIDIA
 Tegra30 External Memory Controller

02.05.2019 3:52, Dmitry Osipenko пишет:
> 02.05.2019 3:17, Rob Herring пишет:
>> On Wed, May 1, 2019 at 7:06 PM Dmitry Osipenko <digetx@...il.com> wrote:
>>>
>>> 30.04.2019 1:05, Rob Herring пишет:
>>>> On Sun, Apr 14, 2019 at 11:20:07PM +0300, Dmitry Osipenko wrote:
>>>>> Add device-tree binding for NVIDIA Tegra30 External Memory Controller.
>>>>> The binding is based on the Tegra124 EMC binding since hardware is
>>>>> similar, although there are couple significant differences.
>>>>
>>>> My comments on Tegra124 binding apply here.
>>>
>>> The common timing definition doesn't fully match the definition that is
>>> used by Tegra's Memory Controller, thus the DQS (data strobe) timing
>>> parameter is comprised of multiple sub-parameters that describe how to
>>> generate the strobe in hardware. There are also more additional
>>> parameters that are specific to Tegra and they are individually
>>> characterized for each memory model and clock rate. Hence the common
>>> timing definition isn't usable.
>>
>> I don't understand. Every PC in the world can work with any DIMM
>> (within a given generation) just with SPD data. Why is that not
>> sufficient here?
> 
> Because this is not a standard PC, but a custom embedded hardware that
> is simpler and also doesn't fully follow the standards in some cases.

Even if there is a way to derive at least some of required parameters
from the common timing, I don't have information about how to do it and
there is pretty much no chance to get it into public.

Rob, please let me know if you're okay with this binding.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ