[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160414085242.GB1533@katana>
Date: Thu, 14 Apr 2016 10:52:43 +0200
From: Wolfram Sang <wsa@...-dreams.de>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Mark Rutland <mark.rutland@....com>,
Russell King <linux@....linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
"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
> 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
Please CC me on this. I wanted to tackle this problem as well today. My
findings/conclusions so far:
* There is one driver bringing 'priority' directly to DT already: gpio-restart
* Watchdog priorities are board dependant
* Having the priorities clear at boot-time is safer than configuring them
at run-time
* The linux scheme (0-255) shouldn't be enforced in DT
So, I wondered about a "priority" binding which just states "the higher,
the more important". Then any OS can decide what to do with it. In the
Linux case, this could be: sort them and give them priority 256 -
position_in_sorted_list.
Opinions?
> - I do not see the point holding up the series for this, and it is
> really a separate problem.
Ack.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists