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: <CAODwPW_tcAAqKE66B+RbvMn-=favT07i3EK3TnAspVsWTAeJ4Q@mail.gmail.com>
Date:   Wed, 27 Jul 2022 17:22:42 -0700
From:   Julius Werner <jwerner@...omium.org>
To:     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>,
        Doug Anderson <dianders@...omium.org>,
        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

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

Yes, but the current compatible string format also requires the exact
part number, of which there are many thousands and it's impossible to
build a list in advance. Even for vendors, hardcoding 255 strings in a
tight firmware space would be an unnecessary burden. There's also an
update problem -- firmware may be built and signed and burned into ROM
long before the assembly of the final mainboard. Board manufacturers
want to be able to just drop-in replace a newly-sourced LPDDR part in
their existing production line without having to worry if the existing
(and possibly no longer changeable) firmware contains a string table
entry for this part.

If you just want the compatible string to be unique, encoding the
numbers like Doug suggested (e.g. jedec,lpddr3-ff-0100) would work for
us.

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

But the DT is the only interface that we have to pass information from
firmware to kernel and userspace. Where else should these properties
be encoded? They are auto-detectable, but not for the kernel itself
(only for memory-training firmware running in SRAM). Maybe the usual
rules of thumb don't apply here, because unlike all other peripheral
controllers the memory controller is special in that the kernel cannot
simply reinitialize it and get the same information from the original
source again.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ