On Tue, 2014-10-28 at 22:57 +0000, One Thousand Gnomes wrote: > > If the firmware eats that button (which I hope it wouldn't, but I > > probably should know better then to expect sane behavior), how does > > the kernel know anything more? > > The firmware is generally going to do whatever it believes is "correct", > which may nor may not be determined by what the hardware itself does > (if wakeup is a GPIO off the controller then it'll be determined by the > widget the other end what is eaten) > > > button). If those button presses don't reliably get communicated, I > > think that's a better problem to solve in the kernel. > > You'd have to solve it in the firmware.
Not if the kernel can tell us that the event occurred and when. > > But the other part of why I'm pushing back is that on future hardware, > > we may not have a "suspend" mode, and systems may just be in a deep > > idle, with selected interrupts disabled > > Nothing future about this. Some ARM devices have had that kind of mindset > for a long time, some x86 platforms can run that way but don't currently > do so under Linux (eg Baytrail/T). On those x86 platforms 'suspend' and > 'resume' are in fact entirely Linux constructs to fake legacy behaviour > on top of an ultra low power idle. > > If you are planning for the future then I wouldn't be too hooked on ideas > like "suspend", "lid switches" or assumptions that a "closed" device > should be kept suspended. It's a broken model. It's bad enough that > systemd tries to do magic hackery to fake this up and gets it wrong in > some case (despite making a very good effort) without propogating the mess > further. > > - S3 has already gone away on some Intel SoC devices 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? > - In such an environment your "wakeup" model changes entirely because you > drop into deep idle whever there isn't stuff annoying the CPU > regularly. With the right kinds of video and audio that could even mean > doing it between keypresses (feature parity approaching 1980s 8bit > laptops ;-) ) > > Instead think long term that > > - There may be no such thing as suspend or resume, just make your code > very well behaved on wakeup events, and closing unneeded > devices/resources whenever it can. > - On/off is an extreme action rarely taken (feature parity with 1970s > VAXen ;-) ) > - The "blob with a lid" model of construction is no longer useful. Even a > keyboarded device is quite likely have a removable keyboard. Except that what I requested (at least the amended version[1]) would also work with devices that don't have suspend. And would also work on the millions of other devices that do have a suspend state, and exist in the wild. [1]: Reason for wake-up for each wake-up-able device, along with a timestamp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
