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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110426210627.GA28033@elf.ucw.cz>
Date:	Tue, 26 Apr 2011 23:06:27 +0200
From:	Pavel Machek <pavel@....cz>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	MyungJoo Ham <myungjoo.ham@...sung.com>,
	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, myungjoo.ham@...il.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,
	utx@...guin.cz, zaurus-devel@...ts.linuxtogo.org,
	Marek Vasut <marek.vasut@...il.com>
Subject: Re: [RFC PATCH v2 1/3] PM / Core: suspend_again callback for
 device PM.

Hi!

> > > "too heavy" (in fact it's much lighter weight than resuming all devices
> > > that your approach doesn't prevent from happening, so for example on my
> > > desktop/notebook machines I woulnd't mind at all if user space were
> > > thawed after all of the devices had been resumed).
> > 
> > Well, it would be behavior change for the user. I told the zaurus to
> > go s2ram, I do not expect it to wake up after 5 minutes because it
> > needed to check battery status.
> > 
> > I'd have to modify my userland to retry suspend again and again and
> > again...
> 
> And that's exactly what should be done.  Have a user space process controlling
> that, because avoiding to thaw user space doesn't buy us almost
> anything.

That makes Zaurus implement different user-kernel interface than PC
class machine, because of hardware quirk.

> Now, I know that it's probably easier to modify the kernel than to write
> a user space tool for that, test it and so on, but "easier" is not necessarily
> "better".

It is easier, allows us to keep same user-kernel interface on PC and
Zaurus, and is compatible with 2.6.38.

Heck, I'm used to typing "echo mem > /sys/power/state". I should not
have to learn different interface just because Zaurus does not have
proper hardware charger.

> > I'm not sure if we need to cover hibernation. Do you know any machine
> > that needs this for hibernation case?
> 
> Yes, any machine that "needs" it while suspended.  What's the difference,
> after all?  The only difference is that there's an image on permanent storage
> in the hibernation case.  You still can overheat a battery when charging it
> while hibernated, right?

No, you can not; not on Zaurus.

It can not really power down; it is always sleeping. s2ram is sleep in
operating system, hibernation or poweroff is sleep in bootloader.

Bootloader takes care of battery in that case.

> > > To conclude, I'm not sure about the approach.  In particular, I'm not sure
> > > if the benefit is worth the effort and the resulting complications (ie. the
> > > possibility of having to deal with wakeup signals not requested by user
> > > space) seem to be a bit too far reaching.
> > 
> > We already have platform-specific hacks to do exactly this at least on
> > Zaurus. Moving it to common code means that hacks are not duplicated..
> 
> Well, good to know they are there, but I'm still not sure what to do about
> that.  At the moment I feel like having too little information to really
> decide, so perhaps please point me to the code you're talking about for
> starters.

Ok, see the spitz_should_wakeup() function in arch/arm/mach-pxa/* and
should_wakeup() usage.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/