linux-kernel - Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states

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: <20160912133854.GD13192@bill-the-cat>
Date:   Mon, 12 Sep 2016 09:38:54 -0400
From:   Tom Rini <trini@...sulko.com>
To:     Matthijs van Duin <matthijsvanduin@...il.com>
Cc:     Rob Herring <robh+dt@...nel.org>, Nishanth Menon <nm@...com>,
        Frank Rowand <frowand.list@...il.com>,
        Tony Lindgren <tony@...mide.com>,
        Grant Likely <grant.likely@...aro.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        Tero Kristo <t-kristo@...com>
Subject: Re: [PATCHv2] of: Add generic handling for ePAPR 1.1 fail-sss states

On Sat, Sep 10, 2016 at 03:11:17AM +0200, Matthijs van Duin wrote:

[snip]
> On 8 September 2016 at 16:20, Nishanth Menon <nm@...com> wrote:
> > Minor point here
> 
> It's not minor, it's quite crucial.
> 
> > maintaining dts per paper spin is just too impossible to maintain
> 
> Even if the per-spin dtsi just consists of including the common dtsi
> and then applying /delete-node/ per peripheral that is disabled in
> efuse? (or through firewalling, e.g. on HS devices)
> 
> > the variations if maintained as seperate dts might infact end up being
> > larger in number than all the dts we have in arch/arm/boot/dts
> 
> There are 813 dts files there. Even if there were a dra7xx and am57xx
> for every value of x (and there really isn't) you wouldn't get
> anywhere near there.
> 
> But, fair enough, efuse bits are definitely an excellent way to get
> combinatorial explosion.
> 
> Afaik those feature bits are readable through the control module on TI
> SoCs though. Assuming such a thing is the norm in SoC world maybe a
> "delete-if" property referencing some sort of test on register bits of
> a referenced syscon node might do the trick?
> 
> On the cortex-A8 doing auto-detection would be a feasible alternative,
> by reusing the existing exception mechanism to trap synchronous
> aborts, but e.g. the Cortex-A15 seems to use async aborts for *every*
> bus error, which makes things just very awful.

I think this still misses one of the keys which is that for the IP block
that has been efused (or whatever) into being unusable it's also still
true that the IP block needs to be properly turned off.  The IP in
question wasn't removed from the SoC but rather an ice pick was jammed
into a critical path meaning you can't use it and now it's in zombie
state.  The kernel needs to know about it so that it can finish the job.

-- 
Tom