[PATCH 2/3] corenet: Support gpio power/reset for corenet

[Andy Fleming]

On Tuesday, September 6, 2016, Scott Wood <scott.wood at nxp.com> wrote:

> On 09/06/2016 02:12 PM, Andy Fleming wrote:
> > Boards can implement power and reset functionality over gpio using
> > these drivers:
> >   drivers/power/reset/gpio-poweroff.c
> >   drivers/power/reset/gpio-restart.c
> >
> > While not all corenet boards use gpio for power/reset, this
> > support can be added without interfering with boards that do not
> > use this functionality.
> >
> > If a board's device tree has the related nodes, they are now probed.
> > Also, gpio-poweroff uses the global pm_power_off callback to implement
> > the shutdown. However, pm_power_off was not invoked when the kernel
> > halted, although that is usually the desired behavior. If the board
> > provides gpio power and reset support, it is reasonable to assume that
> > halting should also power down the system, unless it has chosen to
> > pass those calls on to hypervisor.
>
> Halt and poweroff are not the same thing.  If userspace requests a
> poweroff, then kernel_power_off() will call machine_power_off() which
> will call pm_power_off().
>
> Why do we need anything corenet-specific here?


>
> We don't, but then the board will halt instead of power off when you type
> shutdown -h now. Or if you type poweroff without a high enough run level,
> apparently. I'm amenable to removing the halt code, but there are concerns
> that this will cause the systems to behave unintentionally as intended, in
> that most systems that users interact with shut down when you call shutdown
> -h now. There may be scripts that depend on that behavior (or at least
> assume it). Perhaps I could add a config option?
> CONFIG_TREAT_HALT_AS_POWEROFF? CONFIG_POWEROFF_ON_HALT?


> I'll note that there is one other board that is doing the same thing, but
> they've implemented their own gpio poweroff driver. See
> commit 5611fe48c545a22e62273428ed74c9bfae4a9406. That commit also points
> vaguely in the direction of an answer to your second question...


>
> > @@ -127,6 +137,12 @@ static const struct of_device_id of_device_ids[] = {
> >       {
> >               .name           = "handles",
> >       },
> > +     {
> > +             .name           = "gpio-poweroff",
> > +     },
> > +     {
> > +             .name           = "gpio-restart",
> > +     },
> >       {}
> >  };
> >
>
> I don't see any other platforms doing this.  How do the nodes get probed
> for them?


> The answer is I don't know, but this is a common issue with adding new
> devices to the device tree in embedded powerpc. The only other platforms
> which have gpio-poweroff nodes in their trees are in arch/arm, and none of
> those platforms call the probing function of_platform_bus_probe. I suspect
> they either probe every root node, or they somehow construct the match_id.
> As noted in the above-referenced commit, putting the nodes under the gpio
> bus does not cause them to get probed. This seemed like the best way under
> the current corenet code.
>
> -Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20160910/32bfce86/attachment-0001.html>