Suspend and Resume traces

[Sean McNeil]

Am I missing something in pcf50633.c as I can't see where the interrupt 
mask is restored on resume. I only see the resumers gettting set in suspend:

    __reg_write(pcf, PCF50633_REG_INT1M, ~pcf->pdata->resumers[0]);
    __reg_write(pcf, PCF50633_REG_INT2M, ~pcf->pdata->resumers[1]);
    __reg_write(pcf, PCF50633_REG_INT3M, ~pcf->pdata->resumers[2]);
    __reg_write(pcf, PCF50633_REG_INT4M, ~pcf->pdata->resumers[3]);
    __reg_write(pcf, PCF50633_REG_INT5M, ~pcf->pdata->resumers[4]);


Andy Green wrote:
> Somebody in the thread at some point said:
> | How about this:
> |
> | diff --git a/drivers/i2c/chips/pcf50633.c b/drivers/i2c/chips/pcf50633.c
> | index 90edce0..fa39463 100644
> | --- a/drivers/i2c/chips/pcf50633.c
> | +++ b/drivers/i2c/chips/pcf50633.c
> | @@ -687,7 +687,7 @@ static void pcf50633_work(struct work_struct *work)
> |
> |        /* hey did we just resume? */
> |
> | -       if (pcf->have_been_suspended) {
> | +       if (pcf->have_been_suspended == 2) {
> |                pcf->have_been_suspended = 0;
> |                /*
> |                 * grab a copy of resume interrupt reasons
> |
> |
>
> Huh.  This gave me the "crashing on resume" disease when I tried to
> amend it to require an == 3 "resume completion" concept in the work
> function, and likewise it continued to crash with any such qualification
> in it, which makes no actual sense unless some hidden tiger-dragon is in
> there (no doubt same as causes apparent double execution of suspends and
> so on).  That's the first time in a long while I have seen this kind of
> behaviour and there is no normal explanation for it.
>
> So it's the same as the "printk's make me crash" reports.
>
> -Andy