linux-kernel - Re: [PATCH] of: Add generic handling for hardware incomplete fail state

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] [day] [month] [year] [list]

Date:	Tue, 12 Apr 2016 20:11:27 -0400
From:	Tom Rini <trini@...sulko.com>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Rob Herring <robh+dt@...nel.org>,
	Frank Rowand <frowand.list@...il.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>,
	Nishanth Menon <nm@...com>, Tero Kristo <t-kristo@...com>
Subject: Re: [PATCH] of: Add generic handling for hardware incomplete fail
 state

On Tue, Apr 12, 2016 at 03:27:32PM -0700, Tony Lindgren wrote:
> * Rob Herring <robh+dt@...nel.org> [160412 15:22]:
> > On Tue, Apr 12, 2016 at 4:41 PM, Frank Rowand <frowand.list@...il.com> wrote:
> > >>> Status of "fail-sss" is meant to indicate an error was detected in
> > >>> the device, and that the error might (or might not) be repairable.
> > >>>
> > >>> So the difference I see is state vs hardware description.
> > 
> > The question to ask is are we indicating the "operational status of a
> > device"? If yes, that is the definition of status and using it would
> > be appropriate.
> > 
> > IMO, I think we are.
> > 
> > >> OK thanks for the clarification. I don't see why "fail-hw-incomplete"
> > >> could not be set dynamically during the probe in some cases based
> > >> on the SoC revision detection for example. So from that point of
> > >> view using status with the "fail-sss" logic would make more sense.
> > >
> > > If the probe detects that the device should only be power managed
> > > based on the SoC revision, then it would simply be one more
> > > test added at the top of probe.  The patch would change from:
> > >
> > >    if (of_device_is_incomplete(pdev->dev.of_node)) {
> > >
> > > to:
> > >
> > >    if (of_device_is_incomplete(pdev->dev.of_node) || socrev == XXX) {
> > 
> > I think Tony meant the bootloader or platform code would do this and
> > tweak the DT. We don't have much of a standard API for revision
> > checking, so drivers don't check SoC revisions generally.
> 
> Yes bootloader may need to set these based on the SoC revision.
> There are already many boards with multiple SoC variants
> available. Would like to hear Tom's comments on this one as
> well from the u-boot point of view.

So, the first part of it is that any "smart" bootloader will have to
tweak the DT.  A "dumb" bootloader will just pass along a pre-corrected
DT.  In fact, some of the problems are going to probably still have to
be solved by passing in a correct base DT, given that not all changes
are run-time detectable.  But from my point of view, the important part
is that it won't matter what vendor the SoC is from but that we can say
fdt_fixup_hw_incomplete(blob, compatible) or something like that.

-- 
Tom

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)