[Top] [All Lists]

Re: [PATCH 00/11] RFC: Common machine reset handling

To: Stephen Warren <>
Subject: Re: [PATCH 00/11] RFC: Common machine reset handling
From: Domenico Andreoli <>
Date: Fri, 1 Nov 2013 06:16:10 +0100
Cc: Domenico Andreoli <>,, Russell King <>, Arnd Bergmann <>, Ralf Baechle <>,, Olof Johansson <>,
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to; bh=9H1fXFdsBi3jVS5m+KfSlM4PcS99kgBWwnG3kpYlSYs=; b=rDS2AaObUp/Q6T8k6M2yzICETEyzlMxWWjeRdiLM1DAvy22JmRRFIJSlXxox8mWze/ Q85AY35SkbHHl4aqk62+jrzKMA3WQUHeIPG0+gAmzHQ/K2hb0/iZMIgnSrGN9X2HH9h3 6ouz2yXNrF8mWSwuyz0XJ54t3Er2Gsa9FhnUp2AuxGBdq00imsmnWLBNJKbtRlG3lWa8 a6J6n7x1v4TzsUqJZiWAMyNi99SuAVaDzXbDRjC7+OkxyHsrJyFDoj9ZsrSseJ7v/E6i LTeVnTrfPrbBXPMSl/93tmrOXUmQwCITyF+YUR/cVSyfrmzpwaiA87+hqEMhl4QWV9vO Ydlg==
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Mail-followup-to: Stephen Warren <>, Domenico Andreoli <>,, Russell King <>, Arnd Bergmann <>, Ralf Baechle <>,, Olof Johansson <>,
Original-recipient: rfc822;
References: <> <>
On Thu, Oct 31, 2013 at 03:49:18PM -0600, Stephen Warren wrote:
> On 10/31/2013 12:27 AM, Domenico Andreoli wrote:
> > Hi,
> > 
> >   I've been looking for a solution to my bcm4760 watchdog based restart
> > hook when I noticed that the kernel reboot/shutdown mechanism is having
> > a few unaddressed issues.
> > 
> > Those I identified are:
> > 
> >  1) context pointer often needed by the reset hook
> >     (currently local static data is used for this pourpose)
> >  2) unclear ownership/policy in case of multiple reset hooks
> >     (currently almost nobody seems to care much)
> I'm not sure how this patchset solves (2); even with the new API, it's
> still the case that whichever code calls set_machine_reset() last wins,
> just like before where whichever code wrote to pm_power_off won. I'm not
> sure what this series attempts to solve.

That's right, the last wins. But the previous has a chance to know.

I only supposed there is somebody in charge of selecting the best handler
for the machine. Don't know how fancy this decision is but at least for
the vexpress there is also a sysfs way to configure different reset methods
from user-space.

So cleaning up things after the handler is replaced seemed a sensible
thing to do.

Another "problem" this patch would solve is the registration of the
reset handler in a architecture independent way. Now an otherwise platform
generic gpio HW reset driver would need to do different things on different


<Prev in Thread] Current Thread [Next in Thread>