linux-kernel - Re: A desktop environment[1] kernel wishlist

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, 31 Oct 2014 15:03:38 +0100
From:	Bastien Nocera <hadess@...ess.net>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	John Stultz <john.stultz@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: A desktop environment[1] kernel wishlist

On Thu, 2014-10-30 at 23:39 +0000, One Thousand Gnomes wrote:
> > > You'd have to solve it in the firmware.
> > 
> > Not if the kernel can tell us that the event occurred and when.
> 
> Which it can only do if the firmware told the kernel meaningfully !
> 
> > And I think I have one of those devices, an Intel Baytrail tablet.
> > 
> > > - Suspend/Resume on such machines are a Linux fake to keep legacy code
> > >   happy
> > 
> > Do you have a link to how this is implemented currently?
> 
> You ask for suspend and we put all the devices into lowest power state if
> they are not already there then sit on our backsides issuing mwaits
> asking for C7 state on BYT (C10 I think on HSW).
> 
> If you box is ever passive enough you can even randomly enter this state
> in the idle loop. You generally won't do this on current devices because
> you won't have suitable panels and most desktop OS's are far too noisy on
> wakeups. There's nothing preventing you having half your processors in
> deep idle.
> 
> That's where it is all heading though. Suspend will eventually go away.
> 
> > [1]: Reason for wake-up for each wake-up-able device, along with a
> > timestamp.
> 
> We may not know and the answer in many cases will be extremely device
> specific.

Which is why I'm interested in the device drivers providing that
information.

> It's a reasonable ask but answers even if available are likely
> to be things like "because GPE36" and GPE36 will just be some connection
> to something that could be anything from a lid switch to a light sensor
> or even a smart wifi chip deciding it wants the CPU to help out because
> you are out of range of the base station. We may not even know what it
> relates to.

But the device or platform driver would know that, presumably.

> A non suspend system will exit deep idle type status because they got
> an IRQ or perhaps some DMA needed the cache coherency. That doesn't mean
> they've got the foggiest which IRQ kicked them out if idle, just that hey
> I'm awake and there are four pending interrupts. That of course is
> assuming it even noticed it entered a deep idle state - you don't want to
> wake an idle CPU to tell it that its more idle than it was before.

Sure, the CPU might not be the best example of a device for which we
need to track the wakeup reason. The device drivers however...

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