linux-kernel - Re: [markgross@...ngar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]

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:	Fri, 14 Oct 2011 06:23:32 -0700
From:	mark gross <markgross@...gnar.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	mark gross <markgross@...gnar.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, NeilBrown <neilb@...e.de>,
	linux-kernel@...r.kernel.org, John Stultz <john.stultz@...aro.org>,
	arve@...roid.com, amit.kucheria@...aro.org, farrowg@...ibm.com,
	"Dmitry Fink (Palm GBU)" <Dmitry.Fink@...m.com>,
	linux-pm@...ts.linux-foundation.org, khilman@...com,
	Magnus Damm <damm@...nsource.se>, mjg@...hat.com,
	peterz@...radead.org
Subject: Re: [markgross@...ngar.org: [RFC] wake up notifications and suspend
 blocking (aka more wakelock stuff)]

On Thu, Oct 13, 2011 at 11:06:35AM -0400, Alan Stern wrote:
> On Wed, 12 Oct 2011, mark gross wrote:
> 
> > > > > sometimes devices that are not wake up sources need critical sections
> > > > > where suspend is a problem.
> > > 
> > > Mark, can you give some examples?  This isn't the same as the firmware 
> > > update thing, is it?  That deserves to be handled by a completely 
> > > separate mechanism.
> > 
> > The biggest example I know of is any usb gadget implementation while
> > connected to a USB host.  If the device is connected to the USB bus then
> > it needs to not suspend because it cannot respond to the USB commands
> > for bus power.  i.e. if its connected to a laptop and the suspend the
> > laptop the gadget needs to handle the USB protocol packets.
> > 
> > Also, when charging battery under OS control we don't want to suspend
> > because it will be hard to respond to thermal events  or changing
> > battery conditions if the system is in suspend.
> 
> This is like the firmware update problem -- it has nothing to do with 
> wakeups.  It could be handled very easily either by abusing a wakeup 
> source as Neil suggested or by adding a different mechanism for 
> preventing system sleeps.

yes.  This is just another mechanism to prevent sleeps.

> > > Although many of these problems could be solved by adopting a suitable
> > > protocol in userspace, currently there is no such protocol.  Even if
> > > one did exist, the process of getting all the relevant programs to
> > > adopt it would take quite a while.  This is a case where a problem can
> > > be solved either in the kernel or in userspace, and the in-kernel
> > > solution may be simpler.
> > 
> > I do think a better solution would involve some kernel coordination.
> > 
> > I don't want to split hairs on if its 100% possible to implement a
> > correct solution only in user mode.  but, I think there are corner cases
> > that may be hard or impossible to get right with only user mode.  See
> > gadget issue above.  Not all gadgets have a user mode daemon backing up
> > the kernel part do they?
> 
> I don't know.  But if they don't have some sort of userspace component
> for power management then they never go into suspend, because the
> kernel doesn't initiate suspends by itself.

yes, but the kernel can / does block user initiated suspends from
various user mode initiators.  All this is for is to block suspend entry
until the driver is ok with it.  this patch is nothing more than that
really.

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