linux-kernel - Re: [RFC PATCH v2 1/3] PM / Core: suspend

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1303897603.4431.16.camel@oct.suse.cz>
Date:	Wed, 27 Apr 2011 11:46:43 +0200
From:	Stanislav Brabec <utx@...guin.cz>
To:	MyungJoo Ham <myungjoo.ham@...sung.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@....cz>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-pm@...ts.linux-foundation.org,
	Len Brown <len.brown@...el.com>,
	"Jean Delvare (PC drivers core)" <khali@...ux-fr.org>,
	"Ben Dooks (embedded platforms)" <ben-linux@...ff.org>,
	kyungmin.park@...sung.com, LKML <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>, rpurdie@...ys.net,
	lenz@...wisc.edu, arminlitzel@....de, Cyril Hrubis <metan@....cz>,
	thommycheck@...il.com,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	dbaryshkov@...il.com, omegamoon@...il.com, eric.y.miao@...il.com,
	zaurus-devel@...ts.linuxtogo.org,
	Marek Vasut <marek.vasut@...il.com>, myungjoo.ham@...il.com
Subject: Re: [RFC PATCH v2 1/3] PM / Core: suspend_again callback for
 device PM.

MyungJoo Ham wrote:

> As long as sysdevs are resumed and some devices/subsystems (I2C-PMIC,
> ADC, and RTC in my cases) can be selectively resumed and suspended, it
> is fine.
> Thus, your "alternative" suggestion is perfect with me. Actually, this
> is almost going back to the original hack. =)
> 
> I'll submit next revision with platform_suspend_ops later.

Does kernel have something like "sleepy task" interface, e. g. special
mode that is triggered by some sort of interrupt and instead of going to
perform full resume, it just lets a hook to wake up "manually" needed
devices, perform the "sleepy task" and then tell the system whether full
resume is requested?

It can fit for Zaurus battery charging monitoring - timer interrupt
needs to wake just the SPI bus.

But I can imagine a GPS logger using such interface to save energy -
serial interrupt semi-wakes the system each second, but will not go to
do full resume. It just processes NMEA sentence and buffers the result.
Only if buffer becomes full, it issues full resume and writes data
somewhere.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@...e.cz
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

--
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/