linux-kernel - Re: How to power gate a specific single device from outside?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20171025204239.47a80251@alans-desktop>
Date:   Wed, 25 Oct 2017 20:42:39 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Waldemar Rymarkiewicz <waldemar.rymarkiewicz@...il.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: How to power gate a specific single device from outside?

> Now, what I need in the kernel is to _selectively_ suspend devices
> that are not needed in the "backup/emergency" mode.

Which means you need to get the applications using them to die - or you
could rewrite the driver top to bottom to have locking sufficient to
ensure that your power management changes don't interact with any
existing functionality and every function neatly aborts or errors in a
safe way to the userspace which you've also modified extensively to cope.

I knmow which I'd choose.

> If current state of the power frameworks for system sleep, runtime pm,
> genpd etc. are not able to handle this transition, and as far as I
> understand these subsystems they cannot handle this straight away

Correct - nor can you handle it straight away because you might be in the
middle of doing something so need to finish a transactio before you can
drop to a lower power level.

> In DT we could specify which devices should go in low power state when
> in emergency mode eg.
> node {
>     ....
>     suspend-in-emergency;
>     .....
> }

If a component of your hardware has a low power mode then why aren't you
always putting it in lowest power mode except when it's in current use ?

> So the device driver knows if it should be suspended in
> PM_SUSPEND_EMERGENCY or not.  The driver has to provide a callback in
> pm_ops to handle this transition or we could reuse suspend callback if
> possible.

You need to re-use the existing power management logic, and in many cases
that means you'll need to shut down the userspace processes that are
keeping the device busy because they will be keeping it from going to
sleep.

> Just a brief idea. Does it make sense to anyone?

So the normal way you do this kind of stuff is to use runlevels with init
(or the systemd equivalents)

When the power goes poof you change runlevel. init kills off and
shuts down all the services you want to drop. Those close the devices,
which being well behaved shove themselves into the deepest sleep they can.

When the power comes back you switch runlevel back and stuff respawns.

Alan