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: <55E6481C-2137-4086-ACDF-5F7D86E41A21@goldelico.com>
Date:   Tue, 31 Dec 2019 09:14:12 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     André Hentschel <nerv@...ncrow.de>,
        Adam Ford <aford173@...il.com>, 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

Hi Tony,

> Am 30.12.2019 um 18:29 schrieb Tony Lindgren <tony@...mide.com>:
> 
> * André Hentschel <nerv@...ncrow.de> [191227 14:29]:
>> 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.
> 
> We can easily do both. So no worries, I can easily add SoC capabilites
> support at some point.
> 
>> 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"
> 
> And let's also add minimal dm3725.dtsi, am3715.dtsi and am3703.dtsi
> to make things simple.

Well, is that "simple"?

We also have to add omap3503, omap3515, omap3520, omap3530.dtsi.
And probably am3351,2,4,6,7,8,9 variants with different capabilities
(PRU, SGX, CAN, ZCZ ports to name some).

And to be correct, there should be a different "compatible".

Rob asked me when reviewing the pvrsgx bindings if the img,5xx variants
can be autodetected to reduce bindings complexity.

> The device tree is supposed to describe the
> hardware, and in most cases the SoC version is fixed and need no
> dynamic detection.

There may be exactly the same board populated with either one since
they are drop-in pin compatible. So this may proliferate to the
board.dts files and u-boot can have to load different .dtb.

> 
> André, can you please add those three dtsi files since you have at
> least one test case? :)
> 
> Regards,
> 
> Tony

BR,
Nikolaus