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]
Date:	Wed, 13 Apr 2016 17:42:23 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Mark Rutland <mark.rutland@....com>,
	Russell King <linux@....linux.org.uk>,
	Catalin Marinas <catalin.marinas@....com>,
	Wolfram Sang <wsa@...-dreams.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Subject: Re: [PATCH 3/6] ARM: PSCI: Register with kernel restart handler

On Wed, Apr 13, 2016 at 03:22:44PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 13, 2016 at 3:10 PM, Guenter Roeck <linux@...ck-us.net> wrote:
> > On 04/13/2016 04:05 AM, Mark Rutland wrote:
> >> On Fri, Apr 08, 2016 at 05:53:56AM -0700, Guenter Roeck wrote:
> >>>
> >>> Register with kernel restart handler instead of setting arm_pm_restart
> >>> directly. This enables support for replacing the PSCI restart handler
> >>> with a different handler if necessary for a specific board.
> >>>
> >>> Select a priority of 129 to indicate a higher than default priority, but
> >>> keep it as low as possible since PSCI reset is known to fail on some
> >>> boards.
> >>
> >> For reference, which boards?
> >>
> > Salvator-X, reported by Geert Uytterhoeven. Wolfram Sang also reported
> > that it is broken on a board he is using, but I don't recall if it is
> > the same board.
> 
> Yes it is.
> 
> >> It's unfortunate that that a PSCI 0.2+ implementation would be lacking a
> >> working SYSTEM_RESET implementation, and it's certainly a mistake to
> >> discourage.
> >>
> >>> Signed-off-by: Guenter Roeck <linux@...ck-us.net>
> >>> ---
> >>> It might make sense to introduce a restart-priority property for
> >>> devicetree
> >>> based configurations, but I am not sure if this would be acceptable.
> >>
> >>> From the DT side, I'm not keen on properties for priorities. They're
> >> incredibly fragile and don't really encode a HW property.
> >>
> > Depends. It is a convenient means to say "primary restart method" or
> > "may be broken".
> 
> The issue is supposed to be fixed in a more recent firmware, which I still have
> to try.
> 
> DT indeed isn't the right place to work around this. What we need is a
> blacklist of bad firmware versions...
> Or Perfect Firmware from Day One on (like Perfect DT from Day One ;-)
> 
That makes things quite tricky. Best I can think of is a series of boolean
devicetree properties, such as

	broken-reset-handler
	last-resort-restart-handler
	secondary-restart-handler
	default-restart-handler
	primary-restart-handler

which ends up being quite similar to the 'restart-priority' property. I'll
do this as follow-up patch, though - I do not see the point holding up the
series for this, and it is really a separate problem. I'll send rev2 with
the various Acked-by: and Reviewed-by: tags as well as the variable rename
suggested by Wolfram.

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ