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]
Date:	Thu, 21 Feb 2008 11:59:45 +0000
From:	Richard Purdie <rpurdie@...nedhand.com>
To:	Kristoffer Ericson <kristoffer.ericson@...il.com>
Cc:	rjw@...k.pl, linux-main <linux-kernel@...r.kernel.org>
Subject: Re: Apm_emulation and proper suspend

On Thu, 2008-02-21 at 12:33 +0100, Kristoffer Ericson wrote:
> I'm reworking a couple of apm drivers and for whatever reason it
> doesn't seem to update my /proc/apm_bios. I was under the impression
> that it should do that when apm_bios was catted? Currently I have a
> value that never change. I export my get_power_status.. function
> properly but doesn't seem to touch it. I noticed that Richard had the
> extern int (void..apm_get_power) (...) declare an extra time (once in
> apm-emulation.h and another inside sharpsl.c), is that needed?

It should be removed from sharpsl.c in that case. The code was written
when the apm emulation code was arm specific and looked rather
different.

> Also, is apm the "brains" behind the suspend/resume interactions? By
> that I mean, should suspend be initiated through apm functions
> in order to be proper? I've tried to find examples but the best source
> of suspend related code is Richards code on sharp machines.

APM means you can can notify userspace of the suspend/resume events and
have some kind of interaction there through apmd. It gives a mechanism
where both userspace and kernel space can queue suspend requests and
where userspace can veto a voluntary suspend.

You can also suspend the system through "echo mem > /sys/power/state" in
userspace or calling pm_suspend() in kernel space but this doesn't give
anything else the opportunity to know about the event which is why we
still have apm.

Cheers,

Richard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ