[Discussion] how to implement external power down for ARM

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

Hi?

I am looking at adding support for external power down and reboot to
ARM VMs.  With ACPI this is fairly straight forward and requires only
adding a GPIO controller to the virt machine model and extending ACPI
appropriately (see code here [1]). In addition Linaro LEG also have
done a test that uses GPIO as power button to shutdown OS on fast model
(see detail here [2]).

However, we would like for this to work in systems that do not use
ACPI as well. Adding a GPIO controller will still work, but we would
need a generic way to tell Linux how to handle the GPIO events without
adding any board-specific code to the VIRT platform. And what guest
kernel driver do we need? Do we need another user-level daemon like acpid?

Note that external shutdown can also be accomplished using the qemu
guest agent [3], but maybe this is not a sufficiently stable approach.

Any input on the approach to take here is very welcome.

Thanks,
Shannon

[1] https://git.linaro.org/people/shannon.zhao/qemu.git/shortlog/refs/heads/PowerButton
[2] https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/GPIOPowerButton
[3] http://wiki.qemu.org/Features/QAPI/GuestAgent

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Thursday 30 April 2015 09:03:22 Shannon Zhao wrote:
> 
> I am looking at adding support for external power down and reboot to
> ARM VMs.  With ACPI this is fairly straight forward and requires only
> adding a GPIO controller to the virt machine model and extending ACPI
> appropriately (see code here [1]). In addition Linaro LEG also have
> done a test that uses GPIO as power button to shutdown OS on fast model
> (see detail here [2]).
> 
> However, we would like for this to work in systems that do not use
> ACPI as well. Adding a GPIO controller will still work, but we would
> need a generic way to tell Linux how to handle the GPIO events without
> adding any board-specific code to the VIRT platform. And what guest
> kernel driver do we need? Do we need another user-level daemon like acpid?
> 
> Note that external shutdown can also be accomplished using the qemu
> guest agent [3], but maybe this is not a sufficiently stable approach.
> 
> Any input on the approach to take here is very welcome.

I would expect drivers/power/reset/gpio-poweroff.c to work in an identical
way with ACPI and DT, once you have added an ACPI binding for it.

You can add further properties if you need to drive the GPIO differently.

	Arnd

[Discussion] how to implement external power down for ARM

[Peter Maydell]

On 30 April 2015 at 09:03, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 30 April 2015 09:03:22 Shannon Zhao wrote:
>>
>> I am looking at adding support for external power down and reboot to
>> ARM VMs.  With ACPI this is fairly straight forward and requires only
>> adding a GPIO controller to the virt machine model and extending ACPI
>> appropriately (see code here [1]). In addition Linaro LEG also have
>> done a test that uses GPIO as power button to shutdown OS on fast model
>> (see detail here [2]).
>>
>> However, we would like for this to work in systems that do not use
>> ACPI as well. Adding a GPIO controller will still work, but we would
>> need a generic way to tell Linux how to handle the GPIO events without
>> adding any board-specific code to the VIRT platform. And what guest
>> kernel driver do we need? Do we need another user-level daemon like acpid?
>>
>> Note that external shutdown can also be accomplished using the qemu
>> guest agent [3], but maybe this is not a sufficiently stable approach.
>>
>> Any input on the approach to take here is very welcome.
>
> I would expect drivers/power/reset/gpio-poweroff.c to work in an identical
> way with ACPI and DT, once you have added an ACPI binding for it.

Looking at Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
that appears to be for "let the guest kernel turn off the system
from the inside by toggling a GPIO line". What we want is the
opposite: the external system (QEMU, in this case) toggles a GPIO
line in order to request the guest kernel to do a clean shutdown
or reboot. Or have I misunderstood what gpio-poweroff can do?

[I would expect the shutdown itself to be done via PSCI.]

thanks
-- PMM

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Thursday 30 April 2015 10:08:05 Peter Maydell wrote:
> On 30 April 2015 at 09:03, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 30 April 2015 09:03:22 Shannon Zhao wrote:
> >>
> >> I am looking at adding support for external power down and reboot to
> >> ARM VMs.  With ACPI this is fairly straight forward and requires only
> >> adding a GPIO controller to the virt machine model and extending ACPI
> >> appropriately (see code here [1]). In addition Linaro LEG also have
> >> done a test that uses GPIO as power button to shutdown OS on fast model
> >> (see detail here [2]).
> >>
> >> However, we would like for this to work in systems that do not use
> >> ACPI as well. Adding a GPIO controller will still work, but we would
> >> need a generic way to tell Linux how to handle the GPIO events without
> >> adding any board-specific code to the VIRT platform. And what guest
> >> kernel driver do we need? Do we need another user-level daemon like acpid?
> >>
> >> Note that external shutdown can also be accomplished using the qemu
> >> guest agent [3], but maybe this is not a sufficiently stable approach.
> >>
> >> Any input on the approach to take here is very welcome.
> >
> > I would expect drivers/power/reset/gpio-poweroff.c to work in an identical
> > way with ACPI and DT, once you have added an ACPI binding for it.
> 
> Looking at Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
> that appears to be for "let the guest kernel turn off the system
> from the inside by toggling a GPIO line". What we want is the
> opposite: the external system (QEMU, in this case) toggles a GPIO
> line in order to request the guest kernel to do a clean shutdown
> or reboot. Or have I misunderstood what gpio-poweroff can do?
> 
> [I would expect the shutdown itself to be done via PSCI.]

Ok, my mistake. What we need then is a "gpio-keys" device that has
a single gpio with a button that emits KEY_POWER (or a second
one if you also want KEY_RESTART).

An example from arch/arm/boot/dts/kirkwood-dnskw.dtsi would be

        gpio_keys {
                compatible = "gpio-keys";
                #address-cells = <1>;
                #size-cells = <0>;
                pinctrl-0 = <&pmx_button_power &pmx_button_unmount
                             &pmx_button_reset>;
                pinctrl-names = "default";

                button at 1 {
                        label = "Power button";
                        linux,code = <KEY_POWER>;
                        gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
                };
                button at 2 {
                        label = "USB unmount button";
                        linux,code = <KEY_EJECTCD>;
                        gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
                };
                button at 3 {
                        label = "Reset button";
                        linux,code = <KEY_RESTART>;
                        gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
                };
        };

This also includes pinctrl configuration, which you can skip on
qemu, if you assume that the gpio is already configured in the
right way.

>From the user space side, this should work just like the ACPI
button stuff that emits KEY_POWER or KEY_SLEEP on its
input-device.

	Arnd

[Discussion] how to implement external power down for ARM

[Mark Rutland]

On Thu, Apr 30, 2015 at 10:08:05AM +0100, Peter Maydell wrote:
> On 30 April 2015 at 09:03, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 30 April 2015 09:03:22 Shannon Zhao wrote:
> >>
> >> I am looking at adding support for external power down and reboot to
> >> ARM VMs.  With ACPI this is fairly straight forward and requires only
> >> adding a GPIO controller to the virt machine model and extending ACPI
> >> appropriately (see code here [1]). In addition Linaro LEG also have
> >> done a test that uses GPIO as power button to shutdown OS on fast model
> >> (see detail here [2]).
> >>
> >> However, we would like for this to work in systems that do not use
> >> ACPI as well. Adding a GPIO controller will still work, but we would
> >> need a generic way to tell Linux how to handle the GPIO events without
> >> adding any board-specific code to the VIRT platform. And what guest
> >> kernel driver do we need? Do we need another user-level daemon like acpid?
> >>
> >> Note that external shutdown can also be accomplished using the qemu
> >> guest agent [3], but maybe this is not a sufficiently stable approach.
> >>
> >> Any input on the approach to take here is very welcome.
> >
> > I would expect drivers/power/reset/gpio-poweroff.c to work in an identical
> > way with ACPI and DT, once you have added an ACPI binding for it.
> 
> Looking at Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
> that appears to be for "let the guest kernel turn off the system
> from the inside by toggling a GPIO line". What we want is the
> opposite: the external system (QEMU, in this case) toggles a GPIO
> line in order to request the guest kernel to do a clean shutdown
> or reboot. Or have I misunderstood what gpio-poweroff can do?

No, you're correct.

There are a few "power button" bindings around, but it looks like they
all rely on platform details and aren't that generic.

With ACPI what events may be singalled? Just power off, or reset, etc?

Which of these do we need to be able to handle with DT?

Mark.

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Thursday 30 April 2015 10:29:53 Mark Rutland wrote:
> On Thu, Apr 30, 2015 at 10:08:05AM +0100, Peter Maydell wrote:
> > On 30 April 2015 at 09:03, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thursday 30 April 2015 09:03:22 Shannon Zhao wrote:
> > >>
> > >> I am looking at adding support for external power down and reboot to
> > >> ARM VMs.  With ACPI this is fairly straight forward and requires only
> > >> adding a GPIO controller to the virt machine model and extending ACPI
> > >> appropriately (see code here [1]). In addition Linaro LEG also have
> > >> done a test that uses GPIO as power button to shutdown OS on fast model
> > >> (see detail here [2]).
> > >>
> > >> However, we would like for this to work in systems that do not use
> > >> ACPI as well. Adding a GPIO controller will still work, but we would
> > >> need a generic way to tell Linux how to handle the GPIO events without
> > >> adding any board-specific code to the VIRT platform. And what guest
> > >> kernel driver do we need? Do we need another user-level daemon like acpid?
> > >>
> > >> Note that external shutdown can also be accomplished using the qemu
> > >> guest agent [3], but maybe this is not a sufficiently stable approach.
> > >>
> > >> Any input on the approach to take here is very welcome.
> > >
> > > I would expect drivers/power/reset/gpio-poweroff.c to work in an identical
> > > way with ACPI and DT, once you have added an ACPI binding for it.
> > 
> > Looking at Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
> > that appears to be for "let the guest kernel turn off the system
> > from the inside by toggling a GPIO line". What we want is the
> > opposite: the external system (QEMU, in this case) toggles a GPIO
> > line in order to request the guest kernel to do a clean shutdown
> > or reboot. Or have I misunderstood what gpio-poweroff can do?
> 
> No, you're correct.
> 
> There are a few "power button" bindings around, but it looks like they
> all rely on platform details and aren't that generic.
> 
> With ACPI what events may be singalled? Just power off, or reset, etc?
> 
> Which of these do we need to be able to handle with DT?

Actually, there are at least three different ways to do this:

a) have an input device send the KEY_POWEROFF or KEY_REBOOT events to
   user space, and have some process (e.g. desktop environment, or daemon)
   handle the event by doing an appropriate action. This seems to be
   what ACPI does on x86, and a lot of device tree based systems do
   the same thing using gpio-keys.

b) Have a special driver that calls orderly_poweroff or orderly_reboot.
   Only PowerPC (OPAL) uses the orderly_reboot() here, but a few platforms
   (Xen, fsl_hypervisor, and some sparc and powerpc machines) as well
   as some device drivers (thermal management etc) call this as well.
   The effect is to call a user-configured binary (/sbin/reboot and
   /sbin/poweroff by default).

c) call ctrl_alt_del(): a bunch of platforms do this, and user space
   has to configure whether this immediately calls kernel_restart(),
   or sends SIGINT to the init process, which can then do an orderly
   reboot. Again, highbank does this as the reboot action, but very
   few other systems seem to do it, aside from the vt keyboard driver
   that is used on all machines that have normal keyboard.

	Arnd

[Discussion] how to implement external power down for ARM

[Hanjun Guo]

On 2015?04?30? 17:29, Mark Rutland wrote:
> On Thu, Apr 30, 2015 at 10:08:05AM +0100, Peter Maydell wrote:
>> On 30 April 2015 at 09:03, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Thursday 30 April 2015 09:03:22 Shannon Zhao wrote:
>>>>
>>>> I am looking at adding support for external power down and reboot to
>>>> ARM VMs.  With ACPI this is fairly straight forward and requires only
>>>> adding a GPIO controller to the virt machine model and extending ACPI
>>>> appropriately (see code here [1]). In addition Linaro LEG also have
>>>> done a test that uses GPIO as power button to shutdown OS on fast model
>>>> (see detail here [2]).
>>>>
>>>> However, we would like for this to work in systems that do not use
>>>> ACPI as well. Adding a GPIO controller will still work, but we would
>>>> need a generic way to tell Linux how to handle the GPIO events without
>>>> adding any board-specific code to the VIRT platform. And what guest
>>>> kernel driver do we need? Do we need another user-level daemon like acpid?
>>>>
>>>> Note that external shutdown can also be accomplished using the qemu
>>>> guest agent [3], but maybe this is not a sufficiently stable approach.
>>>>
>>>> Any input on the approach to take here is very welcome.
>>>
>>> I would expect drivers/power/reset/gpio-poweroff.c to work in an identical
>>> way with ACPI and DT, once you have added an ACPI binding for it.
>>
>> Looking at Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
>> that appears to be for "let the guest kernel turn off the system
>> from the inside by toggling a GPIO line". What we want is the
>> opposite: the external system (QEMU, in this case) toggles a GPIO
>> line in order to request the guest kernel to do a clean shutdown
>> or reboot. Or have I misunderstood what gpio-poweroff can do?
>
> No, you're correct.
>
> There are a few "power button" bindings around, but it looks like they
> all rely on platform details and aren't that generic.
>
> With ACPI what events may be singalled? Just power off, or reset, etc?

For the ACPI events, we generally have three events:
  - sleep event
  - power off event
  - wakeup event

>
> Which of these do we need to be able to handle with DT?

I think power off event is the most used event, sleep
and wakeup events are often used for laptops.

For ACPI based power off, there will be a GPIO singled
event (hardware reduced platform such as ARM64) or a
special interrupt called SCI signaled to OS to let
OS know there is a button event happened, then there is
a driver handle this interrupt to tell the detail event,
the driver will send the event to user space using input
framework(deprecated) or netlink event.

I think DT can do it in a similar way, using input framework
or netlink sending power button to user space and shutdown
the system.

If any detail information needed, please let me know.

Thanks
Hanjun

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/4/30 21:38, Hanjun Guo wrote:
> On 2015?04?30? 17:29, Mark Rutland wrote:
>> On Thu, Apr 30, 2015 at 10:08:05AM +0100, Peter Maydell wrote:
>>> On 30 April 2015 at 09:03, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Thursday 30 April 2015 09:03:22 Shannon Zhao wrote:
>>>>>
>>>>> I am looking at adding support for external power down and reboot to
>>>>> ARM VMs.  With ACPI this is fairly straight forward and requires only
>>>>> adding a GPIO controller to the virt machine model and extending ACPI
>>>>> appropriately (see code here [1]). In addition Linaro LEG also have
>>>>> done a test that uses GPIO as power button to shutdown OS on fast
>>>>> model
>>>>> (see detail here [2]).
>>>>>
>>>>> However, we would like for this to work in systems that do not use
>>>>> ACPI as well. Adding a GPIO controller will still work, but we would
>>>>> need a generic way to tell Linux how to handle the GPIO events without
>>>>> adding any board-specific code to the VIRT platform. And what guest
>>>>> kernel driver do we need? Do we need another user-level daemon like
>>>>> acpid?
>>>>>
>>>>> Note that external shutdown can also be accomplished using the qemu
>>>>> guest agent [3], but maybe this is not a sufficiently stable approach.
>>>>>
>>>>> Any input on the approach to take here is very welcome.
>>>>
>>>> I would expect drivers/power/reset/gpio-poweroff.c to work in an
>>>> identical
>>>> way with ACPI and DT, once you have added an ACPI binding for it.
>>>
>>> Looking at Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
>>> that appears to be for "let the guest kernel turn off the system
>>> from the inside by toggling a GPIO line". What we want is the
>>> opposite: the external system (QEMU, in this case) toggles a GPIO
>>> line in order to request the guest kernel to do a clean shutdown
>>> or reboot. Or have I misunderstood what gpio-poweroff can do?
>>
>> No, you're correct.
>>
>> There are a few "power button" bindings around, but it looks like they
>> all rely on platform details and aren't that generic.
>>
>> With ACPI what events may be singalled? Just power off, or reset, etc?
> 
> For the ACPI events, we generally have three events:
>  - sleep event
>  - power off event
>  - wakeup event
> 

In addition, we might need hotplug event later if we want to support
hotplug with DT.

>>
>> Which of these do we need to be able to handle with DT?
> 
> I think power off event is the most used event, sleep
> and wakeup events are often used for laptops.
> 
> For ACPI based power off, there will be a GPIO singled
> event (hardware reduced platform such as ARM64) or a
> special interrupt called SCI signaled to OS to let
> OS know there is a button event happened, then there is
> a driver handle this interrupt to tell the detail event,
> the driver will send the event to user space using input
> framework(deprecated) or netlink event.
> 
> I think DT can do it in a similar way, using input framework
> or netlink sending power button to user space and shutdown
> the system.
> 

Yes, we could do it like ACPI. But then they are almost same. I just
wonder the necessity of this.

> If any detail information needed, please let me know.
> 
> Thanks
> Hanjun

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/4/30 17:56, Arnd Bergmann wrote:
> On Thursday 30 April 2015 10:29:53 Mark Rutland wrote:
>> On Thu, Apr 30, 2015 at 10:08:05AM +0100, Peter Maydell wrote:
>>> On 30 April 2015 at 09:03, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Thursday 30 April 2015 09:03:22 Shannon Zhao wrote:
>>>>>
>>>>> I am looking at adding support for external power down and reboot to
>>>>> ARM VMs.  With ACPI this is fairly straight forward and requires only
>>>>> adding a GPIO controller to the virt machine model and extending ACPI
>>>>> appropriately (see code here [1]). In addition Linaro LEG also have
>>>>> done a test that uses GPIO as power button to shutdown OS on fast model
>>>>> (see detail here [2]).
>>>>>
>>>>> However, we would like for this to work in systems that do not use
>>>>> ACPI as well. Adding a GPIO controller will still work, but we would
>>>>> need a generic way to tell Linux how to handle the GPIO events without
>>>>> adding any board-specific code to the VIRT platform. And what guest
>>>>> kernel driver do we need? Do we need another user-level daemon like acpid?
>>>>>
>>>>> Note that external shutdown can also be accomplished using the qemu
>>>>> guest agent [3], but maybe this is not a sufficiently stable approach.
>>>>>
>>>>> Any input on the approach to take here is very welcome.
>>>>
>>>> I would expect drivers/power/reset/gpio-poweroff.c to work in an identical
>>>> way with ACPI and DT, once you have added an ACPI binding for it.
>>>
>>> Looking at Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
>>> that appears to be for "let the guest kernel turn off the system
>>> from the inside by toggling a GPIO line". What we want is the
>>> opposite: the external system (QEMU, in this case) toggles a GPIO
>>> line in order to request the guest kernel to do a clean shutdown
>>> or reboot. Or have I misunderstood what gpio-poweroff can do?
>>
>> No, you're correct.
>>
>> There are a few "power button" bindings around, but it looks like they
>> all rely on platform details and aren't that generic.
>>
>> With ACPI what events may be singalled? Just power off, or reset, etc?
>>
>> Which of these do we need to be able to handle with DT?
> 
> Actually, there are at least three different ways to do this:
> 
> a) have an input device send the KEY_POWEROFF or KEY_REBOOT events to
>    user space, and have some process (e.g. desktop environment, or daemon)

About this daemon, do we need a doc or spec to standardize it?

>    handle the event by doing an appropriate action. This seems to be
>    what ACPI does on x86, and a lot of device tree based systems do
>    the same thing using gpio-keys.
> 

Yeah, it seems like ACPI.

> b) Have a special driver that calls orderly_poweroff or orderly_reboot.
>    Only PowerPC (OPAL) uses the orderly_reboot() here, but a few platforms
>    (Xen, fsl_hypervisor, and some sparc and powerpc machines) as well
>    as some device drivers (thermal management etc) call this as well.
>    The effect is to call a user-configured binary (/sbin/reboot and
>    /sbin/poweroff by default).
> 

This looks good which reuses existing user space process.

> c) call ctrl_alt_del(): a bunch of platforms do this, and user space
>    has to configure whether this immediately calls kernel_restart(),
>    or sends SIGINT to the init process, which can then do an orderly
>    reboot. Again, highbank does this as the reboot action, but very
>    few other systems seem to do it, aside from the vt keyboard driver
>    that is used on all machines that have normal keyboard.
> 

This only supports reboot, but we also need poweroff.

> 	Arnd
> 

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Monday 04 May 2015 10:09:04 Shannon Zhao wrote:
> On 2015/4/30 17:56, Arnd Bergmann wrote:
> > On Thursday 30 April 2015 10:29:53 Mark Rutland wrote:

> > a) have an input device send the KEY_POWEROFF or KEY_REBOOT events to
> >    user space, and have some process (e.g. desktop environment, or daemon)
> 
> About this daemon, do we need a doc or spec to standardize it?

There is probably documentation about this that we just need to locate.
On my workstation, the power button device is owned by "systemd-logind",
I'd assume something like that to be present elsewhere as well. 

> > b) Have a special driver that calls orderly_poweroff or orderly_reboot.
> >    Only PowerPC (OPAL) uses the orderly_reboot() here, but a few platforms
> >    (Xen, fsl_hypervisor, and some sparc and powerpc machines) as well
> >    as some device drivers (thermal management etc) call this as well.
> >    The effect is to call a user-configured binary (/sbin/reboot and
> >    /sbin/poweroff by default).
> > 
> 
> This looks good which reuses existing user space process.
> 
> > c) call ctrl_alt_del(): a bunch of platforms do this, and user space
> >    has to configure whether this immediately calls kernel_restart(),
> >    or sends SIGINT to the init process, which can then do an orderly
> >    reboot. Again, highbank does this as the reboot action, but very
> >    few other systems seem to do it, aside from the vt keyboard driver
> >    that is used on all machines that have normal keyboard.
> > 
> 
> This only supports reboot, but we also need poweroff.

Well, I think these traditionally go together, and a lot of platforms
use c) for reboot and b) for poweroff, because c) was there first
and b) was introduced later to provide the reboot handling. The
orderly_reboot in turn was only just introduced last month.

Joel Stanly wrote that patch for PowerPC, maybe he can explain why
this PowerPC is doing it this way instead of having an input device
that sends KEY_RESTART. It's probably a good idea to have ARM and
PowerPC normally do the same thing here, especially if there are
problems with just using a gpio-key device.

	Arnd

[Discussion] how to implement external power down for ARM

[Joel Stanley]

Hello,

On Tue, May 5, 2015 at 1:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 04 May 2015 10:09:04 Shannon Zhao wrote:
>> On 2015/4/30 17:56, Arnd Bergmann wrote:
>> > On Thursday 30 April 2015 10:29:53 Mark Rutland wrote:
>
>> > a) have an input device send the KEY_POWEROFF or KEY_REBOOT events to
>> >    user space, and have some process (e.g. desktop environment, or daemon)
>>
>> About this daemon, do we need a doc or spec to standardize it?
>
> There is probably documentation about this that we just need to locate.
> On my workstation, the power button device is owned by "systemd-logind",
> I'd assume something like that to be present elsewhere as well.
>
>> > b) Have a special driver that calls orderly_poweroff or orderly_reboot.
>> >    Only PowerPC (OPAL) uses the orderly_reboot() here, but a few platforms
>> >    (Xen, fsl_hypervisor, and some sparc and powerpc machines) as well
>> >    as some device drivers (thermal management etc) call this as well.
>> >    The effect is to call a user-configured binary (/sbin/reboot and
>> >    /sbin/poweroff by default).
>> >
>>
>> This looks good which reuses existing user space process.
>>
>
> Joel Stanly wrote that patch for PowerPC, maybe he can explain why
> this PowerPC is doing it this way instead of having an input device
> that sends KEY_RESTART. It's probably a good idea to have ARM and
> PowerPC normally do the same thing here, especially if there are
> problems with just using a gpio-key device.

We wanted to support reboot and poweroff on existing distributions
without having to rely on new userspace.

I chatted to a few people at linux.conf.au this year and we came to
the conclusion that the options were orderly_poweroff() or ACPI for
doing a graceful shutdown involving userspace. ACPI required acpid or
a desktop environment listening to the netlink message (plus we aren't
an ACPI machine) so that was out.

KEY_POWEROFF looks useful, but how would you support userspace that
does not have a systemd-logind, or anything listening to that input
event?

Cheers,

Joel

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Tuesday 05 May 2015 12:27:54 Joel Stanley wrote:
> On Tue, May 5, 2015 at 1:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 04 May 2015 10:09:04 Shannon Zhao wrote:
> >> On 2015/4/30 17:56, Arnd Bergmann wrote:
> >> > On Thursday 30 April 2015 10:29:53 Mark Rutland wrote:
> >
> >> > a) have an input device send the KEY_POWEROFF or KEY_REBOOT events to
> >> >    user space, and have some process (e.g. desktop environment, or daemon)
> >>
> >> About this daemon, do we need a doc or spec to standardize it?
> >
> > There is probably documentation about this that we just need to locate.
> > On my workstation, the power button device is owned by "systemd-logind",
> > I'd assume something like that to be present elsewhere as well.
> >
> >> > b) Have a special driver that calls orderly_poweroff or orderly_reboot.
> >> >    Only PowerPC (OPAL) uses the orderly_reboot() here, but a few platforms
> >> >    (Xen, fsl_hypervisor, and some sparc and powerpc machines) as well
> >> >    as some device drivers (thermal management etc) call this as well.
> >> >    The effect is to call a user-configured binary (/sbin/reboot and
> >> >    /sbin/poweroff by default).
> >> >
> >>
> >> This looks good which reuses existing user space process.
> >>
> >
> > Joel Stanly wrote that patch for PowerPC, maybe he can explain why
> > this PowerPC is doing it this way instead of having an input device
> > that sends KEY_RESTART. It's probably a good idea to have ARM and
> > PowerPC normally do the same thing here, especially if there are
> > problems with just using a gpio-key device.
> 
> We wanted to support reboot and poweroff on existing distributions
> without having to rely on new userspace.
> 
> I chatted to a few people at linux.conf.au this year and we came to
> the conclusion that the options were orderly_poweroff() or ACPI for
> doing a graceful shutdown involving userspace. ACPI required acpid or
> a desktop environment listening to the netlink message (plus we aren't
> an ACPI machine) so that was out.
> 
> KEY_POWEROFF looks useful, but how would you support userspace that
> does not have a systemd-logind, or anything listening to that input
> event?

Ok, thanks for providing that background. I was under the impression
that the power button was not handled through netlink but instead
through the input subsystem, and I just checked the acpid source
code and found that it basically handles acpi events and input
events separately and should still work fine if only one of the
two is present.

I still find it hard to come up with a good decision for ARM here:
I think either way will work in most cases but has minor downsides
(orderly_poweroff() and orderly_reboot() being less configurable
vs input events requiring some user space to run).
Unfortunately, it is not an option to just "do both", because the
orderly_reboot() will unconditionally reboot the system, so any
user configuration is just ignored here.

Maybe we just use the the input framework for now, because it
requires zero kernel changes and is already used on ARM platforms
today, and see if we run into problems with that.

	Arnd

[Discussion] how to implement external power down for ARM

[Christoffer Dall]

On Tue, May 5, 2015 at 11:53 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 05 May 2015 12:27:54 Joel Stanley wrote:
>> On Tue, May 5, 2015 at 1:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday 04 May 2015 10:09:04 Shannon Zhao wrote:
>> >> On 2015/4/30 17:56, Arnd Bergmann wrote:
>> >> > On Thursday 30 April 2015 10:29:53 Mark Rutland wrote:
>> >
>> >> > a) have an input device send the KEY_POWEROFF or KEY_REBOOT events to
>> >> >    user space, and have some process (e.g. desktop environment, or daemon)
>> >>
>> >> About this daemon, do we need a doc or spec to standardize it?
>> >
>> > There is probably documentation about this that we just need to locate.
>> > On my workstation, the power button device is owned by "systemd-logind",
>> > I'd assume something like that to be present elsewhere as well.
>> >
>> >> > b) Have a special driver that calls orderly_poweroff or orderly_reboot.
>> >> >    Only PowerPC (OPAL) uses the orderly_reboot() here, but a few platforms
>> >> >    (Xen, fsl_hypervisor, and some sparc and powerpc machines) as well
>> >> >    as some device drivers (thermal management etc) call this as well.
>> >> >    The effect is to call a user-configured binary (/sbin/reboot and
>> >> >    /sbin/poweroff by default).
>> >> >
>> >>
>> >> This looks good which reuses existing user space process.
>> >>
>> >
>> > Joel Stanly wrote that patch for PowerPC, maybe he can explain why
>> > this PowerPC is doing it this way instead of having an input device
>> > that sends KEY_RESTART. It's probably a good idea to have ARM and
>> > PowerPC normally do the same thing here, especially if there are
>> > problems with just using a gpio-key device.
>>
>> We wanted to support reboot and poweroff on existing distributions
>> without having to rely on new userspace.
>>
>> I chatted to a few people at linux.conf.au this year and we came to
>> the conclusion that the options were orderly_poweroff() or ACPI for
>> doing a graceful shutdown involving userspace. ACPI required acpid or
>> a desktop environment listening to the netlink message (plus we aren't
>> an ACPI machine) so that was out.
>>
>> KEY_POWEROFF looks useful, but how would you support userspace that
>> does not have a systemd-logind, or anything listening to that input
>> event?
>
> Ok, thanks for providing that background. I was under the impression
> that the power button was not handled through netlink but instead
> through the input subsystem, and I just checked the acpid source
> code and found that it basically handles acpi events and input
> events separately and should still work fine if only one of the
> two is present.
>
> I still find it hard to come up with a good decision for ARM here:
> I think either way will work in most cases but has minor downsides
> (orderly_poweroff() and orderly_reboot() being less configurable
> vs input events requiring some user space to run).
> Unfortunately, it is not an option to just "do both", because the
> orderly_reboot() will unconditionally reboot the system, so any
> user configuration is just ignored here.
>
> Maybe we just use the the input framework for now, because it
> requires zero kernel changes and is already used on ARM platforms
> today, and see if we run into problems with that.
>
Do ARM distributions (Fedora, Ubuntu, Debian, ...) support the
necessary userspace handling so that things work with the input
subsystem?

-Christoffer

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Tuesday 05 May 2015 12:51:57 Christoffer Dall wrote:
> On Tue, May 5, 2015 at 11:53 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 05 May 2015 12:27:54 Joel Stanley wrote:
> >
> Do ARM distributions (Fedora, Ubuntu, Debian, ...) support the
> necessary userspace handling so that things work with the input
> subsystem?

I think the latest releases all use systemd, so it should work in theory,
but I have not tried it, and I don't know if they have something else
on older versions.

	Arnd

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/5 18:55, Arnd Bergmann wrote:
> On Tuesday 05 May 2015 12:51:57 Christoffer Dall wrote:
>> On Tue, May 5, 2015 at 11:53 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Tuesday 05 May 2015 12:27:54 Joel Stanley wrote:
>>>
>> Do ARM distributions (Fedora, Ubuntu, Debian, ...) support the
>> necessary userspace handling so that things work with the input
>> subsystem?
> 
> I think the latest releases all use systemd, so it should work in theory,
> but I have not tried it, and I don't know if they have something else
> on older versions.
> 

Thanks, will try to use gpio-keys and check whether systemd works.

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/5 19:13, Shannon Zhao wrote:
> 
> 
> On 2015/5/5 18:55, Arnd Bergmann wrote:
>> On Tuesday 05 May 2015 12:51:57 Christoffer Dall wrote:
>>> On Tue, May 5, 2015 at 11:53 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Tuesday 05 May 2015 12:27:54 Joel Stanley wrote:
>>>>
>>> Do ARM distributions (Fedora, Ubuntu, Debian, ...) support the
>>> necessary userspace handling so that things work with the input
>>> subsystem?
>>
>> I think the latest releases all use systemd, so it should work in theory,
>> but I have not tried it, and I don't know if they have something else
>> on older versions.
>>
> 
> Thanks, will try to use gpio-keys and check whether systemd works.
> 

I've added a PL061 GPIO controller and gpio-keys node in QEMU like
following format:

        pl061 at 9030000 {
                phandle = <0x8002>;
                clock-names = "apb_pclk";
                clocks = <0x8000>;
                interrupts = <0x0 0x7 0x4>;
                gpio-controller;
                #gpio-cells = <0x2>;
                compatible = "arm,pl061";
                reg = <0x0 0x9030000 0x0 0x1000>;
        };
        gpio-keys {
                autorepeat;
                #address-cells = <0x1>;
                #size-cells = <0x0>;
                compatible = "gpio-keys";

                poweroff {
                        gpios = <0x8002 0x3 0x0>;
                        linux,code = <0x74>;
                        label = "GPIO Key Poweroff";
                };
        };

Configure kernel to select GPIO Buttons and Polled GPIO buttons. Use a
Redhat filesystem "Red Hat Enterprise Linux Server for ARM Development
Preview release 1.5" which has systemd and systemd-logind. Start VM and
when it starts well type "system_powerdown" on QEMU monitor, the guest
goes to poweroff. So this way works.


Note: we must check the /lib/udev/rules.d/70-power-switch.rules in the
fs and add one following line in it if it doesn't exist.

SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="platform",
ATTRS{keys}=="116", TAG+="power-switch"

Then when execute journalctl -u systemd-logind in guest, we can see
something like below:

Jan 01 00:01:02 localhost systemd[1]: Starting Login Service...
Jan 01 00:01:07 localhost systemd[1]: Started Login Service.
Jan 01 00:01:07 localhost systemd-logind[927]: Watching system buttons
on /dev/input/event0 (gpio-keys)
Jan 01 00:01:07 localhost systemd-logind[927]: New seat seat0.
Jan 01 00:01:25 localhost systemd-logind[927]: New session c1 of user root.

Visit https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1347776 for
details.

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Wednesday 06 May 2015 14:56:58 Shannon Zhao wrote:
> On 2015/5/5 19:13, Shannon Zhao wrote:
>         gpio-keys {
>                 autorepeat;
>                 #address-cells = <0x1>;
>                 #size-cells = <0x0>;
>                 compatible = "gpio-keys";
> 
>                 poweroff {
>                         gpios = <0x8002 0x3 0x0>;
>                         linux,code = <0x74>;
>                         label = "GPIO Key Poweroff";
>                 };
>         };
> 
> Configure kernel to select GPIO Buttons and Polled GPIO buttons. Use a
> Redhat filesystem "Red Hat Enterprise Linux Server for ARM Development
> Preview release 1.5" which has systemd and systemd-logind. Start VM and
> when it starts well type "system_powerdown" on QEMU monitor, the guest
> goes to poweroff. So this way works.

Ok, very good.

> Note: we must check the /lib/udev/rules.d/70-power-switch.rules in the
> fs and add one following line in it if it doesn't exist.
> 
> SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="platform",
> ATTRS{keys}=="116", TAG+="power-switch"
> 
> Then when execute journalctl -u systemd-logind in guest, we can see
> something like below:
> 
> Jan 01 00:01:02 localhost systemd[1]: Starting Login Service...
> Jan 01 00:01:07 localhost systemd[1]: Started Login Service.
> Jan 01 00:01:07 localhost systemd-logind[927]: Watching system buttons
> on /dev/input/event0 (gpio-keys)
> Jan 01 00:01:07 localhost systemd-logind[927]: New seat seat0.
> Jan 01 00:01:25 localhost systemd-logind[927]: New session c1 of user root.
> 
> Visit https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1347776 for
> details.

How about Ubuntu or Debian releases that do not use systemd?

I guess we should check with a Debian Wheezy or Ubuntu Trusty release.
My guess is that it will work fine, but some minor adjustment might
be needed.

	Arnd

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/6 15:29, Arnd Bergmann wrote:
> On Wednesday 06 May 2015 14:56:58 Shannon Zhao wrote:
>> > On 2015/5/5 19:13, Shannon Zhao wrote:
>> >         gpio-keys {
>> >                 autorepeat;
>> >                 #address-cells = <0x1>;
>> >                 #size-cells = <0x0>;
>> >                 compatible = "gpio-keys";
>> > 
>> >                 poweroff {
>> >                         gpios = <0x8002 0x3 0x0>;
>> >                         linux,code = <0x74>;
>> >                         label = "GPIO Key Poweroff";
>> >                 };
>> >         };
>> > 
>> > Configure kernel to select GPIO Buttons and Polled GPIO buttons. Use a
>> > Redhat filesystem "Red Hat Enterprise Linux Server for ARM Development
>> > Preview release 1.5" which has systemd and systemd-logind. Start VM and
>> > when it starts well type "system_powerdown" on QEMU monitor, the guest
>> > goes to poweroff. So this way works.
> Ok, very good.
> 
>> > Note: we must check the /lib/udev/rules.d/70-power-switch.rules in the
>> > fs and add one following line in it if it doesn't exist.
>> > 
>> > SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="platform",
>> > ATTRS{keys}=="116", TAG+="power-switch"
>> > 
>> > Then when execute journalctl -u systemd-logind in guest, we can see
>> > something like below:
>> > 
>> > Jan 01 00:01:02 localhost systemd[1]: Starting Login Service...
>> > Jan 01 00:01:07 localhost systemd[1]: Started Login Service.
>> > Jan 01 00:01:07 localhost systemd-logind[927]: Watching system buttons
>> > on /dev/input/event0 (gpio-keys)
>> > Jan 01 00:01:07 localhost systemd-logind[927]: New seat seat0.
>> > Jan 01 00:01:25 localhost systemd-logind[927]: New session c1 of user root.
>> > 
>> > Visit https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1347776 for
>> > details.
> How about Ubuntu or Debian releases that do not use systemd?
> 
> I guess we should check with a Debian Wheezy or Ubuntu Trusty release.
> My guess is that it will work fine, but some minor adjustment might
> be needed.

Will check Debian Wheezy and Ubuntu Trusty release later.
BTW, I don't have them on hand, where can I get these filesystem for ARM?

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Wednesday 06 May 2015 16:19:59 Shannon Zhao wrote:
> > How about Ubuntu or Debian releases that do not use systemd?
> > 
> > I guess we should check with a Debian Wheezy or Ubuntu Trusty release.
> > My guess is that it will work fine, but some minor adjustment might
> > be needed.
> 
> Will check Debian Wheezy and Ubuntu Trusty release later.
> BTW, I don't have them on hand, where can I get these filesystem for ARM?
> 

I think these should work for Debian:

https://people.debian.org/~aurel32/qemu/armhf/

but you will have to provide a newer kernel.

The image is a 32-bit user space, but it should work with both 32-bit
and 64-bit kernels. It's probably enough to test either ubuntu or
debian.

	Arnd

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/6 16:37, Arnd Bergmann wrote:
> On Wednesday 06 May 2015 16:19:59 Shannon Zhao wrote:
>>> > > How about Ubuntu or Debian releases that do not use systemd?
>>> > > 
>>> > > I guess we should check with a Debian Wheezy or Ubuntu Trusty release.
>>> > > My guess is that it will work fine, but some minor adjustment might
>>> > > be needed.
>> > 
>> > Will check Debian Wheezy and Ubuntu Trusty release later.
>> > BTW, I don't have them on hand, where can I get these filesystem for ARM?
>> > 
> I think these should work for Debian:
> 
> https://people.debian.org/~aurel32/qemu/armhf/
> 
> but you will have to provide a newer kernel.
> 
> The image is a 32-bit user space, but it should work with both 32-bit
> and 64-bit kernels. It's probably enough to test either ubuntu or
> debian.

Ok, thanks. Will have a try.

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Christoffer Dall]

On Wed, May 6, 2015 at 10:19 AM, Shannon Zhao <shannon.zhao@linaro.org> wrote:
>
> On 2015/5/6 15:29, Arnd Bergmann wrote:
>> On Wednesday 06 May 2015 14:56:58 Shannon Zhao wrote:
>>> > On 2015/5/5 19:13, Shannon Zhao wrote:
>>> >         gpio-keys {
>>> >                 autorepeat;
>>> >                 #address-cells = <0x1>;
>>> >                 #size-cells = <0x0>;
>>> >                 compatible = "gpio-keys";
>>> >
>>> >                 poweroff {
>>> >                         gpios = <0x8002 0x3 0x0>;
>>> >                         linux,code = <0x74>;
>>> >                         label = "GPIO Key Poweroff";
>>> >                 };
>>> >         };
>>> >
>>> > Configure kernel to select GPIO Buttons and Polled GPIO buttons. Use a
>>> > Redhat filesystem "Red Hat Enterprise Linux Server for ARM Development
>>> > Preview release 1.5" which has systemd and systemd-logind. Start VM and
>>> > when it starts well type "system_powerdown" on QEMU monitor, the guest
>>> > goes to poweroff. So this way works.
>> Ok, very good.
>>
>>> > Note: we must check the /lib/udev/rules.d/70-power-switch.rules in the
>>> > fs and add one following line in it if it doesn't exist.
>>> >
>>> > SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="platform",
>>> > ATTRS{keys}=="116", TAG+="power-switch"
>>> >
>>> > Then when execute journalctl -u systemd-logind in guest, we can see
>>> > something like below:
>>> >
>>> > Jan 01 00:01:02 localhost systemd[1]: Starting Login Service...
>>> > Jan 01 00:01:07 localhost systemd[1]: Started Login Service.
>>> > Jan 01 00:01:07 localhost systemd-logind[927]: Watching system buttons
>>> > on /dev/input/event0 (gpio-keys)
>>> > Jan 01 00:01:07 localhost systemd-logind[927]: New seat seat0.
>>> > Jan 01 00:01:25 localhost systemd-logind[927]: New session c1 of user root.
>>> >
>>> > Visit https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1347776 for
>>> > details.
>> How about Ubuntu or Debian releases that do not use systemd?
>>
>> I guess we should check with a Debian Wheezy or Ubuntu Trusty release.
>> My guess is that it will work fine, but some minor adjustment might
>> be needed.
>
> Will check Debian Wheezy and Ubuntu Trusty release later.
> BTW, I don't have them on hand, where can I get these filesystem for ARM?
>
Try this for Ubuntu trusty:
http://www.cs.columbia.edu/~cdall/linaro-trusty.tar.bz2

(It's a Linaro minimal FS so some things like manpages may be missing
for existing packages, let me know if you run into problems.)

-Christoffer

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/6 15:29, Arnd Bergmann wrote:
> On Wednesday 06 May 2015 14:56:58 Shannon Zhao wrote:
>> On 2015/5/5 19:13, Shannon Zhao wrote:
>>         gpio-keys {
>>                 autorepeat;
>>                 #address-cells = <0x1>;
>>                 #size-cells = <0x0>;
>>                 compatible = "gpio-keys";
>>
>>                 poweroff {
>>                         gpios = <0x8002 0x3 0x0>;
>>                         linux,code = <0x74>;
>>                         label = "GPIO Key Poweroff";
>>                 };
>>         };
>>
>> Configure kernel to select GPIO Buttons and Polled GPIO buttons. Use a
>> Redhat filesystem "Red Hat Enterprise Linux Server for ARM Development
>> Preview release 1.5" which has systemd and systemd-logind. Start VM and
>> when it starts well type "system_powerdown" on QEMU monitor, the guest
>> goes to poweroff. So this way works.
> 
> Ok, very good.
> 
>> Note: we must check the /lib/udev/rules.d/70-power-switch.rules in the
>> fs and add one following line in it if it doesn't exist.
>>
>> SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="platform",
>> ATTRS{keys}=="116", TAG+="power-switch"
>>
>> Then when execute journalctl -u systemd-logind in guest, we can see
>> something like below:
>>
>> Jan 01 00:01:02 localhost systemd[1]: Starting Login Service...
>> Jan 01 00:01:07 localhost systemd[1]: Started Login Service.
>> Jan 01 00:01:07 localhost systemd-logind[927]: Watching system buttons
>> on /dev/input/event0 (gpio-keys)
>> Jan 01 00:01:07 localhost systemd-logind[927]: New seat seat0.
>> Jan 01 00:01:25 localhost systemd-logind[927]: New session c1 of user root.
>>
>> Visit https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1347776 for
>> details.
> 
> How about Ubuntu or Debian releases that do not use systemd?
> 
> I guess we should check with a Debian Wheezy or Ubuntu Trusty release.
> My guess is that it will work fine, but some minor adjustment might
> be needed.
> 

Hi Arnd,

If the Debian Wheezy or Ubuntu Trusty release doesn't use systemd, what
user space process do they use to handle the input device event?

I tried Ubuntu Trusty from Christoffer, when typing "system_powerdown"
on QEMU monitor, "cat /dev/input/event0 | hexdump" shows the event is
triggered but the guest doesn't poweroff.

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Thursday 07 May 2015 10:39:35 Shannon Zhao wrote:
> On 2015/5/6 15:29, Arnd Bergmann wrote:
> > On Wednesday 06 May 2015 14:56:58 Shannon Zhao wrote:
> >> On 2015/5/5 19:13, Shannon Zhao wrote:
> >>
> >> Jan 01 00:01:02 localhost systemd[1]: Starting Login Service...
> >> Jan 01 00:01:07 localhost systemd[1]: Started Login Service.
> >> Jan 01 00:01:07 localhost systemd-logind[927]: Watching system buttons
> >> on /dev/input/event0 (gpio-keys)
> >> Jan 01 00:01:07 localhost systemd-logind[927]: New seat seat0.
> >> Jan 01 00:01:25 localhost systemd-logind[927]: New session c1 of user root.
> >>
> >> Visit https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1347776 for
> >> details.
> > 
> > How about Ubuntu or Debian releases that do not use systemd?
> > 
> > I guess we should check with a Debian Wheezy or Ubuntu Trusty release.
> > My guess is that it will work fine, but some minor adjustment might
> > be needed.
> > 
> 
> Hi Arnd,
> 
> If the Debian Wheezy or Ubuntu Trusty release doesn't use systemd, what
> user space process do they use to handle the input device event?

I don't really know, there are probably multiple tools available, but
they might not be installed by default
 
> I tried Ubuntu Trusty from Christoffer, when typing "system_powerdown"
> on QEMU monitor, "cat /dev/input/event0 | hexdump" shows the event is
> triggered but the guest doesn't poweroff.

Can you try installing acpid by running 'sudo apt-get install acpid' in
the image? I suspect it should just work by scanning the event devices
even in the absence of ACPI on the platform.

	Arnd

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/7 16:55, Arnd Bergmann wrote:
> On Thursday 07 May 2015 10:39:35 Shannon Zhao wrote:
>> On 2015/5/6 15:29, Arnd Bergmann wrote:
>>> On Wednesday 06 May 2015 14:56:58 Shannon Zhao wrote:
>>>> On 2015/5/5 19:13, Shannon Zhao wrote:
>>>>
>>>> Jan 01 00:01:02 localhost systemd[1]: Starting Login Service...
>>>> Jan 01 00:01:07 localhost systemd[1]: Started Login Service.
>>>> Jan 01 00:01:07 localhost systemd-logind[927]: Watching system buttons
>>>> on /dev/input/event0 (gpio-keys)
>>>> Jan 01 00:01:07 localhost systemd-logind[927]: New seat seat0.
>>>> Jan 01 00:01:25 localhost systemd-logind[927]: New session c1 of user root.
>>>>
>>>> Visit https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1347776 for
>>>> details.
>>>
>>> How about Ubuntu or Debian releases that do not use systemd?
>>>
>>> I guess we should check with a Debian Wheezy or Ubuntu Trusty release.
>>> My guess is that it will work fine, but some minor adjustment might
>>> be needed.
>>>
>>
>> Hi Arnd,
>>
>> If the Debian Wheezy or Ubuntu Trusty release doesn't use systemd, what
>> user space process do they use to handle the input device event?
> 
> I don't really know, there are probably multiple tools available, but
> they might not be installed by default
>  
>> I tried Ubuntu Trusty from Christoffer, when typing "system_powerdown"
>> on QEMU monitor, "cat /dev/input/event0 | hexdump" shows the event is
>> triggered but the guest doesn't poweroff.
> 
> Can you try installing acpid by running 'sudo apt-get install acpid' in
> the image? I suspect it should just work by scanning the event devices
> even in the absence of ACPI on the platform.
> 

Cool, I start acpid and the poweroff works.

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Thursday 07 May 2015 17:18:45 Shannon Zhao wrote:
> On 2015/5/7 16:55, Arnd Bergmann wrote:
> > On Thursday 07 May 2015 10:39:35 Shannon Zhao wrote:
> >> I tried Ubuntu Trusty from Christoffer, when typing "system_powerdown"
> >> on QEMU monitor, "cat /dev/input/event0 | hexdump" shows the event is
> >> triggered but the guest doesn't poweroff.
> > 
> > Can you try installing acpid by running 'sudo apt-get install acpid' in
> > the image? I suspect it should just work by scanning the event devices
> > even in the absence of ACPI on the platform.
> > 
> 
> Cool, I start acpid and the poweroff works.

Ok, great, thanks for confirming this! Have you tried reboot as well?

>From looking at the acpid source code, I suspect it does not work unless
extra configuration files are added, but that would be the same as for the
ACPI case.

	Arnd

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/7 17:43, Arnd Bergmann wrote:
> On Thursday 07 May 2015 17:18:45 Shannon Zhao wrote:
>> > On 2015/5/7 16:55, Arnd Bergmann wrote:
>>> > > On Thursday 07 May 2015 10:39:35 Shannon Zhao wrote:
>>>> > >> I tried Ubuntu Trusty from Christoffer, when typing "system_powerdown"
>>>> > >> on QEMU monitor, "cat /dev/input/event0 | hexdump" shows the event is
>>>> > >> triggered but the guest doesn't poweroff.
>>> > > 
>>> > > Can you try installing acpid by running 'sudo apt-get install acpid' in
>>> > > the image? I suspect it should just work by scanning the event devices
>>> > > even in the absence of ACPI on the platform.
>>> > > 
>> > 
>> > Cool, I start acpid and the poweroff works.
> Ok, great, thanks for confirming this! Have you tried reboot as well?
> 
>>From looking at the acpid source code, I suspect it does not work unless
> extra configuration files are added, but that would be the same as for the
> ACPI case.

I test reboot and it doesn't work for both acpid and systemd.

BTW, IIUC QEMU doesn't support the gracefully reboot support. The reboot
depends on libvirt or other management tools. So the reboot case in
virtualization is firstly poweroff, then start again.

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Peter Maydell]

On 7 May 2015 at 13:10, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> BTW, IIUC QEMU doesn't support the gracefully reboot support. The reboot
> depends on libvirt or other management tools. So the reboot case in
> virtualization is firstly poweroff, then start again.

I'm not sure what you mean by this -- QEMU supports 'reset this
VM' at the machine emulation level, so if we can tell the guest
to reboot then it should as part of this process issue the
PSCI SYSTEM_RESET command, which QEMU/KVM will then handle
to do a reset of the VM.

-- PMM

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/7 20:12, Peter Maydell wrote:
> On 7 May 2015 at 13:10, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> BTW, IIUC QEMU doesn't support the gracefully reboot support. The reboot
>> depends on libvirt or other management tools. So the reboot case in
>> virtualization is firstly poweroff, then start again.
> 
> I'm not sure what you mean by this -- QEMU supports 'reset this
> VM' at the machine emulation level, so if we can tell the guest
> to reboot then it should as part of this process issue the
> PSCI SYSTEM_RESET command, which QEMU/KVM will then handle
> to do a reset of the VM.
> 

Yes, QEMU supports reset, but doesn't support (gracefully) reboot. And
reset doesn't depends on the guest, it just restart VM forcefully.
Reboot likes poweroff and start, while reset likes destroy and start.

-- 
Shannon

[Discussion] how to implement external power down for ARM

[Peter Maydell]

On 7 May 2015 at 13:18, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> On 2015/5/7 20:12, Peter Maydell wrote:
>> On 7 May 2015 at 13:10, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>> BTW, IIUC QEMU doesn't support the gracefully reboot support. The reboot
>>> depends on libvirt or other management tools. So the reboot case in
>>> virtualization is firstly poweroff, then start again.
>>
>> I'm not sure what you mean by this -- QEMU supports 'reset this
>> VM' at the machine emulation level, so if we can tell the guest
>> to reboot then it should as part of this process issue the
>> PSCI SYSTEM_RESET command, which QEMU/KVM will then handle
>> to do a reset of the VM.

> Yes, QEMU supports reset, but doesn't support (gracefully) reboot.

Isn't that what this ACPI work is about? Tell the guest to initiate
a graceful reboot, and then the guest will tell QEMU to reboot
the emulated h/w when it's ready.

> And
> reset doesn't depends on the guest, it just restart VM forcefully.
> Reboot likes poweroff and start, while reset likes destroy and start.

I (and QEMU) think there is no visible difference between
poweroff-and-restart and destroy-recreate-and-restart...

-- PMM

[Discussion] how to implement external power down for ARM

[Arnd Bergmann]

On Thursday 07 May 2015 13:34:10 Peter Maydell wrote:
> On 7 May 2015 at 13:18, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> > On 2015/5/7 20:12, Peter Maydell wrote:
> >> On 7 May 2015 at 13:10, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> >>> BTW, IIUC QEMU doesn't support the gracefully reboot support. The reboot
> >>> depends on libvirt or other management tools. So the reboot case in
> >>> virtualization is firstly poweroff, then start again.
> >>
> >> I'm not sure what you mean by this -- QEMU supports 'reset this
> >> VM' at the machine emulation level, so if we can tell the guest
> >> to reboot then it should as part of this process issue the
> >> PSCI SYSTEM_RESET command, which QEMU/KVM will then handle
> >> to do a reset of the VM.
> 
> > Yes, QEMU supports reset, but doesn't support (gracefully) reboot.
> 
> Isn't that what this ACPI work is about? Tell the guest to initiate
> a graceful reboot, and then the guest will tell QEMU to reboot
> the emulated h/w when it's ready.
> 

The problem here is user space: acpid only listens for KEY_POWER
events, not KEY_RESTART. This means graceful shutdown works as
expected, but graceful reboot requires a process that listens
to the input device and calls /sbin/reboot if it KEY_RESTART
appears. I think that can be done by adding a configuration file
in /etc/acpi/events/, but it's not there by default because PCs
only have a power button and no reset button (they use CTRL+ALT+DEL
on the keyboard for that).

	Arnd

[Discussion] how to implement external power down for ARM

[Shannon Zhao]

On 2015/5/7 20:34, Peter Maydell wrote:
> On 7 May 2015 at 13:18, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> On 2015/5/7 20:12, Peter Maydell wrote:
>>> On 7 May 2015 at 13:10, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>>> BTW, IIUC QEMU doesn't support the gracefully reboot support. The reboot
>>>> depends on libvirt or other management tools. So the reboot case in
>>>> virtualization is firstly poweroff, then start again.
>>>
>>> I'm not sure what you mean by this -- QEMU supports 'reset this
>>> VM' at the machine emulation level, so if we can tell the guest
>>> to reboot then it should as part of this process issue the
>>> PSCI SYSTEM_RESET command, which QEMU/KVM will then handle
>>> to do a reset of the VM.
> 
>> Yes, QEMU supports reset, but doesn't support (gracefully) reboot.
> 
> Isn't that what this ACPI work is about? Tell the guest to initiate
> a graceful reboot, and then the guest will tell QEMU to reboot
> the emulated h/w when it's ready.
> 

The ACPI only tells guest to poweroff not reboot. I checked this on x86.
When using libvirt to start a VM, libvirt pass "-no-shutdown" to QEMU
that makes sure the QEMU process will not disappear when guest
poweroffs. When executing "virsh reboot VMname", libvirt send
"system_powerdown" to QEMU and when guest poweroffs libvirt send
"system_reset" to QEMU to restart VM.

So there is not a single external reboot command for ACPI.

>> And
>> reset doesn't depends on the guest, it just restart VM forcefully.
>> Reboot likes poweroff and start, while reset likes destroy and start.
> 
> I (and QEMU) think there is no visible difference between
> poweroff-and-restart and destroy-recreate-and-restart...
> 

It is different to guest.

-- 
Shannon