linux-kernel - Re: [PATCH] ARM: dts: Add omap3-echo

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: <53e6cbbd-1094-cba2-4942-981502a738d4@dawncrow.de>
Date:   Fri, 27 Dec 2019 15:28:28 +0100
From:   André Hentschel <nerv@...ncrow.de>
To:     "H. Nikolaus Schaller" <hns@...delico.com>,
        Tony Lindgren <tony@...mide.com>,
        Adam Ford <aford173@...il.com>
Cc:     linux@....linux.org.uk, robh+dt@...nel.org, mark.rutland@....com,
        bcousson@...libre.com, linux-omap@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: Add omap3-echo

Am 25.12.19 um 18:01 schrieb H. Nikolaus Schaller:
> I think the am3703 is a dm3730 (omap3630) where the SGX and the
> DSP have not passed production test and are "disabled" by eFuses.
> This is a common procedure in silicon production to increase yield.
> 
> Therefore, there is a register which allows to dynamically determine
> what components (SGX and DSP) are available on a specific SoC chip.
> See "Table 1-6. Chip Identification" in the common
> "AM/DM37x Multimedia Device TRM".
> 
> Such bits exists for omap34xx and for omap36xx (aka am37xx/dm37xx).
> 
> That way there is no need to disable/enable sgx through device tree
> variations and introducing more complexity by introducing more and more
> DTS for variants (am3703.dtsi, am3715.dtsi, dm3720.dtsi, dm3730.dtsi?).
> 
> BTW: what about a board that is/was produced in either am3703 or dm3730
> variants? Can they still share an omap36xx.dtsi based DTB?
> 
> So IMHO if there is an issue with sgx enabled on am3703 but no SGX
> hardware available on a specific SoC, the sysc setup should somehow read
> the bits and effectively disable all SGX related setup if it is not
> available on the SoC. If I remember correctly, some older hwmods did
> such things by checking SoC variant bits.

I like the idea, but I'm not in the position to vote for it and I don't
understand the sysc code enough to implement that.

Am 25.12.19 um 13:53 schrieb Adam Ford:
> On Wed, Dec 25, 2019 at 6:05 AM André Hentschel <nerv@...ncrow.de> wrote:
>> And then include am3703.dtsi in omap36xx.dtsi before sgx support?
> I can see value in having a 3703 base and including that in the 36xx
> with SGX and DSP nodes, but why not jus make SGX disabled by default.
> Those who want/need it can enable it on a per-board basis.
>> Or would it be better to have sgx support in a separate dtsi?
> 
> I am not sure how much DSP stuff is in there, but the DM3730 is the
> AM3703 + DSP and 3D.

For clarification this reduced table should help:
     DM3730 | DM3725 | AM3715 | AM3703
DSP    X    |   X    |        |    
SGX    X    |        |   X    |    

Where X is "supported"