[PATCH 2/3] corenet: Support gpio power/reset for corenet
Scott Wood
scott.wood at nxp.com
Tue Sep 13 08:47:21 AEST 2016
On 09/10/2016 05:05 PM, Andy Fleming wrote:
>
>
> On Tuesday, September 6, 2016, Scott Wood <scott.wood at nxp.com
> <mailto: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.
Isn't that what it's supposed to do? If you want poweroff then ask for
poweroff.
> Or if you type poweroff without a high enough
> run level, apparently.
Hmm?
In any case, run levels have nothing to do with the kernel. The kernel
implements LINUX_REBOOT_CMD_HALT and LINUX_REBOOT_CMD_POWER_OFF, and
they should do what they're advertised to do.
> 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).
When did the behavior you're seeking ever exist?
> 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.
Well, let's figure out what it is that PPC should be doing to have
things work the way it does on ARM.
-Scott
More information about the Linuxppc-dev
mailing list