On Tuesday, June 26, 2018 12:06:16 PM CEST Geert Uytterhoeven wrote: > On Wed, Jun 20, 2018 at 3:25 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Wed, Jun 20, 2018 at 02:15:38PM +0200, Rafael J. Wysocki wrote: > > > On Wed, Jun 20, 2018 at 12:35 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > > > The flip side of that is that either suspend and resume or poweroff are > > > > broken for userspace unless they know about this magic sysfs file which > > > > isn't great either. > > > > > But to me that isn't that much different from an RTC wake alarm, say. > > > > > Enabling it to wake up the system in general isn't sufficient, you > > > also need to actually set the alarm using a different interface. > > The RTC wake alarm time is indeed different, as it is not a simple boolean flag. > It is also more natural for the user, who expects to need to find some way to > configure the wake-up time. OK, take Ethernet. You need to configure WoL on that to wake up the system in addition to setting power/wakeup for it. Take WiFi: You need to set up WoW on that. And so on. > > It seems more like hardware breakage we're trying to fix than a feature > > - it's not like it's adding something we didn't have already (like > > setting a time in an alarm where the alarm is an additional thing), more > > just trying to execute on an existing user interface successfully. I > > can see that there's a case that it doesn't map very well onto the > > standard interfaces so perhaps we have to add something on the side as > > the hardware is just too horrible to fit in with the standard interfaces > > and we have to do that. > > My main worry is usability: with a separate sysfs file, we need to document the > file, and the user needs to be aware of it. That's right, but it will be very hard to convince me that changing the meaning of the "wakeup" attribute just in order to work around this issue (which arguably is a consequence of "unfortunate" hardware design) is a good idea. :-)
