pm: record / retain actual reason of last system wakeup??

[Andreas Mohr]

Hi,

I'm wondering whether we're actually recording / retaining
any info about the precise reason for the machine wakeup
that was responsible for having woken up the current (continued) session
(e.g. WOL, RTC, configured keyboard wakeup, ...).

See also
http://superuser.com/questions/297057/linux-how-to-get-the-reason-for-wakeup
, which comes up pretty much empty on this topic.

The reason that I'm asking is that I've got a nice (well not so nice)
PCI card which is acting up
which I'm trying to debug
(see "fw-ohci: ALi M52xx unsupported" https://bugzilla.kernel.org/show_bug.cgi?id=10935 for details)
which even prevents proper shutdown or pm-suspend of the PC
(somehow causes immediate re-launch).
Needless to say I don't see anything in dmesg (currently on 4.1-rc5 BTW)
which would hint at why exactly the re-launch occurred
i.e. through which means exactly it managed to force re-launch
(this would be important to further nail down its misbehaviour).

Rather than having such very important information
turn up temporarily in dmesg output,
it should be reliably recorded/retained in a specific sysfs attribute anyway,
in a *system-global* / generic / non-ACPI-specific manner.
I.e. there should perhaps be a kernel-global sink for such information,
to be written to by whichever component is able to indicate
why a wakeup occurred.

Pseudo code could be:
if (directly_prior_to_suspend)
    wakeup_reason_zero();

if (platform_knows_stuff)
    wakeup_reason_append(generic_knowledge);

if (special_driver_knows_stuff)
    wakeup_reason_append(very_magic_special_info);


wakeup_reason_zero()
{
    wakeup_reason_sysfs_attr_zero();
}

wakeup_reason_append(info)
{
    wakeup_reason_sysfs_attr_append(info);
}

And once (the moment that) such an implementation got created,
it should be documented,
since currently grepping of Documentation/ for wakeup|grep -i reason
does not show any hints.

Thanks,

Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/