Message-ID: <20141103182213.GA10640@roeck-us.net>
Date:	Mon, 3 Nov 2014 10:22:13 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Felipe Balbi <balbi@...com>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	Alan Cox <gnomes@...rguk.ukuu.org.uk>,
	Alexander Graf <agraf@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Heiko Stuebner <heiko@...ech.de>,
	Lee Jones <lee.jones@...aro.org>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Romain Perier <romain.perier@...il.com>,
	Linux ARM Kernel Mailing List 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Russell King <linux@....linux.org.uk>
Subject: Re: [PATCH v3 00/47] kernel: Add support for power-off handler call
 chain

On Mon, Nov 03, 2014 at 11:59:35AM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
> > Various drivers implement architecture and/or device specific means to
> > remove power from the system.  For the most part, those drivers set the
> > global variable pm_power_off to point to a function within the driver.
> > 
> > This mechanism has a number of drawbacks.  Typically only one means
> > to remove power is supported (at least if pm_power_off is used).
> > At least in theory there can be multiple means to remove power, some of
> > which may be less desirable.  For example, one mechanism might power off the
> > entire system through an I/O port or gpio pin, while another might power off
> > a board by disabling its power controller. Other mechanisms may really just
> > execute a restart sequence or drop into the ROM monitor, or put the CPU into
> > sleep mode.  Using pm_power_off can also be racy if the function pointer is
> > set from a driver built as module, as the driver may be in the process of
> > being unloaded when pm_power_off is called.  If there are multiple power-off
> > handlers in the system, removing a module with such a handler may
> > inadvertently reset the pointer to pm_power_off to NULL, leaving the system
> > with no means to remove power.
> > 
> > Introduce a system power-off handler call chain to solve the described
> > problems.  This call chain is expected to be executed from the architecture
> > specific machine_power_off() function.  Drivers providing system power-off
> > functionality are expected to register with this call chain.  By using the
> > priority field in the notifier block, callers can control power-off handler
> > execution sequence and thus ensure that the power-off handler with the
> > optimal capabilities to remove power for a given system is called first.
> > A call chain instead of a single call to the highest priority handler is
> > used to provide fallback: If multiple power-off handlers are installed,
> > all handlers will be called until one actually succeeds to power off the
> > system.
> > 
> > Patch 01/47 implements the power-off handler API.
> > 
> > Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
> > pm_power_off to a common location.
> > 
> > Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
> > bindings descriptions.
> > 
> > Patch 08/47 moves the pm_power_off variable from architecture code to
> > kernel/reboot.c. 
> > 
> > Patches 09/47 to 34/47 convert various drivers to register with the kernel
> > power-off handler instead of setting pm_power_off directly.
> > 
> > Patches 35/47 to 46/47 do the same for architecture code.
> > 
> > Patch 47/47 finally removes pm_power_off.
> > 
> > For the most part, the individual patches include explanations why specific
> > priorities were chosen, at least if the selected priority is not the default
> > priority. Subsystem and architecture maintainers are encouraged to have a look
> > at the selected priorities and suggest improvements.
> > 
> > I ran the final code through my normal build and qemu tests. Results are
> > available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
> > column. I also built all available configurations for arm, mips, powerpc,
> > m68k, and sh architectures.
> > 
> > The series is available in branch poweroff-handler of my repository at
> > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
> > It is based on 3.18-rc2.
> > 
> > A note on Cc: In the initial submission I had way too many Cc:, causing the
> > patchset to be treated as spam by many mailers and mailing list handlers,
> > which of course defeated the purpose. This time around I am cutting down
> > the distribution list down significantly. My apologies to anyone I may have
> > failed to copy this time around.
> 
> you touch every single architecture with this patchset, but you didn't
> care about Ccing any of the arch-specific mailing lists, like lakml ?
> 
What is lakml ? linux-kernel@...r.kernel.org was copied, if that is what you
refer to. I don't find a reference to lakml anywhere, sorry. I'll be happy to
add it manually if you provide the address.

Architecture specific mailing lists were copied on individual patches as long
as those mailing lists are reported by the MAINTAINERS file.

> Please resend with proper people in Cc, IIRC RMK had a few very
> important comments about the idea behind this series.
> 
Felipe,

That doesn't work. I tried with rev 1. The result was that the patch series
was flagged as spam and got dropped by most mailing lists, as explained above,
and I got tagged as spammer by Google and several other mail servers,
preventing me from posting _anything_ for several days.

Please point me to the comments you refer to above in case I missed them.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists