On 02.10.14 01:28, Scott Wood wrote: > On Thu, 2014-10-02 at 01:21 +0200, Alexander Graf wrote: >> >> On 02.10.14 00:39, Scott Wood wrote: >>> On Wed, 2014-10-01 at 15:27 +0200, Alexander Graf wrote: >>>> The generic Linux framework to power off the machine is a function pointer >>>> called pm_power_off. The trick about this pointer is that device drivers >>>> can >>>> potentially implement it rather than board files. >>>> >>>> Today on PowerPC we set pm_power_off to invoke our generic full machine >>>> power >>>> off logic which then calls ppc_md.power_off to invoke machine specific >>>> power >>>> off. >>>> >>>> However, when we want to add a power off GPIO via the "gpio-poweroff" >>>> driver, >>>> this card house falls apart. That driver only registers itself if >>>> pm_power_off >>>> is NULL to ensure it doesn't override board specific logic. However, since >>>> we >>>> always set pm_power_off to the generic power off logic (which will just not >>>> power off the machine if no ppc_md.power_off call is implemented), we can't >>>> implement power off via the generic GPIO power off driver. >>>> >>>> To fix this up, let's get rid of the ppc_md.power_off logic and just >>>> always use >>>> pm_power_off as was intended. Then individual drivers such as the GPIO >>>> power off >>>> driver can implement power off logic via that function pointer. >>>> >>>> With this patch set applied and a few patches on top of QEMU that >>>> implement a >>>> power off GPIO on the virt e500 machine, I can successfully turn off my >>>> virtual >>>> machine after halt. >>> >>> Are there any plans to handle restart similarly? >> >> I don't see an immediate need for it, as we do have access to reset via >> the guts device. > > The guts device is problematic from a hardware description perspective, > as we advertise a bunch of things to the guest that we don't implement. > E.g. the only reason we don't currently have a problem with Linux trying > to use guts to sync the timebase across cores is that by chance we > happen to expose a guts that corresponds to a single-cpu SoC.
True, and it is slightly ugly to expose a specific SoC's guts in our generic pv machine type. > >> I also don't see any generic driver in Linux that would implement reset >> via a gpio controller device, so apparently it's not incredibly common >> to implement reset via gpio. > > There wasn't a generic gpio-power-off driver either until a couple years > ago... Regardless of whether it's done via gpio, using ppc_md for it is > bad for the same reasons as for power-off. I agree. Today, only ARM has a comparable mechanism for drivers to hook a reset handler into the machine specific reset path. I'd say let's wait for Guenter to finish the power off rework and then tackle a generic reset call chain based approach next. Alex _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
