Comment 155 for bug 1283589

Very nice analysis and it's pretty cool to know what happened underneath, thanks a lot.

(In reply to Juan Manuel Cabo from comment #131)
> (In reply to Dennis Jansen from comment #130)
> > I can confirm this. Now we only have to turn this into a generic kernel
> > patch. Does it always make sense to read the EC until it's empty? Could
> > someone confirm this? Maybe this will fix other problems we were not even
> > aware of?
> > At least it seems the listed Samsung system should get a fix.
>
> A proper fix would be to have some way to tell the EC to not accumulate
> events during S3 sleep, failing that, running the loop right after suspend
> to empty those useless events produced during sleep I think is the best
> option. A good place to do that would be in <linuxkernel>/drivers/acpi/ec.c
> function acpi_ec_unblock_transactions_early() or in some other function
> called from sleep.c at resume.

Or add a resume callback for the EC driver and clear all the events gathered during sleep phase there.

>
> The events accumulated during S3 sleep are useless, so it is does make sense
> to clear them all. Again, the best fix would be to have a way to tell the EC
> not to try to report events during sleep.

I've no idea how to do that, sounds like we need some way of manipulating the EC?

>
> After all, the DSDT method _WAK() does Notify() whether the
> batterycharge/AC/LID changed during sleep, and does this independently of
> the EC.

Also, the LID/Battery/AC driver will also update the device's status on their resume callback so there doesn't seem to be any meaning to store these events to me.