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
