linux-kernel - Re: [linux-usb-devel] error to be returned while suspended

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]

Date:	Sun, 8 Oct 2006 21:19:37 +0200
From:	Pavel Machek <pavel@....cz>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	David Brownell <david-b@...bell.net>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-usb-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [linux-usb-devel] error to be returned while suspended

Hi!

> > > OK, let me state the basics.
> > > 
> > > To get real power savings, we:
> > > - blank the display
> > > - spin down the hard drive
> > > - put the CPU into an ACPI sleep state
> > > 
> > > To do the latter well, we need to make sure there's no DMA. It is
> > > important that less or little DMA will not help. We need no DMA.
> > > So we need to handle the commonest scenarios fully.
> > > 
> > > I dare say that the commonest scenario involving USB is a laptop with
> > > an input device attached. Input devices are for practical purposes always
> > > opened. A simple resume upon open and suspend upon close is useless.
> > 
> > Okay, but you can simply do autosuspend with remote wakeup completely
> > inside input driver. You do ot need it to be controlled from X... at
> > most you need one variable ('autosuspend_inactivity_timeout')
> > controlled from userland.
> > 
> > That's what we already do for hdd spindown... you simply tell disk to
> > aitospindown after X seconds of inactivity.
> 
> The firmware in the drive supplies this function. It's hardly by choice
> that it is made available. The power management functions without
> timeout are also exported. For other power control features like
> cpu frequency considerable effort has been made to export them to
> user space.
> 
> A simple timeout solution has drawbacks.
> 
> - there's no guarantee the user wants wakeup (think laptop on
> crowded table)

If you do not want wakeups (=> do not want any input from that
device), then close that device.

> - you want to suspend immediately when you blank the screen (or switch to
> a text console)

I kind-of understand "when you blank", but I do not think this
mandatory. Why would you want to suspend when switching to text
console? Am I no longer allowed to use gpm?

> - you want to consider all devices' activity. I am not pleased if my mouse
> becomes less responsive just because I used only the keyboard for a
> few minutes. Coordinating this inside the driver is hard as some input
> devices might well be not usb (eg. bluetooth mouse, usb tablet)

Yep, that would be nice; but not at price of /sys/.../power/state like
monstrosity that never ever worked properly.
								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/