On 09/10/2016 05:05 PM, Andy Fleming wrote: > > > On Tuesday, September 6, 2016, Scott Wood <scott.w...@nxp.com > <mailto:scott.w...@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
