Hello Doug, On 06/26/2014 06:29 PM, Doug Anderson wrote: > Javier, > > On Thu, Jun 26, 2014 at 9:18 AM, Javier Martinez Canillas > <javier.martinez@xxxxxxxxxxxxxxx> wrote: >> Hello Doug, >> >> On 06/26/2014 06:12 PM, Doug Anderson wrote: >>> Javier, >>> >>> On Thu, Jun 26, 2014 at 4:13 AM, Javier Martinez Canillas >>> <javier.martinez@xxxxxxxxxxxxxxx> wrote: >>>>>> + >>>>>> +#ifdef CONFIG_PM_SLEEP >>>>>> +static int max77802_suspend(struct device *dev) >>>>>> +{ >>>>>> + struct i2c_client *i2c = container_of(dev, struct i2c_client, dev); >>>>>> + struct max77802_dev *max77802 = i2c_get_clientdata(i2c); >>>>>> + >>>>>> + if (device_may_wakeup(dev)) >>>>>> + enable_irq_wake(max77802->irq); >>>>>> + >>>>>> + disable_irq(max77802->irq); >>>>> >>>>> Can you add short comment why this is needed? I know why but just for >>>>> future generations which will wonder: "why do we need to disable the IRQ >>>>> while suspending?" :). Especially that this is rather a workaround for >>>>> issue in other driver (I2C bus). >>>>> >>>> >>>> Good idea, I'll add a comment here on next version so code archaeologists can >>>> figure out what what's going on here. >>> >>> Is the disable_irq() needed if you have >>> <https://patchwork.kernel.org/patch/4421891/>? >>> >> >> Probably not but I added the following comment: >> >> /* >> * The IRQ must be disabled during suspend since due wakeup >> * ordering issues it may be possible that the I2C controller >> * is still suspended when the interrupt happens so the IRQ >> * handler will fail to read the I2C bus. >> */ >> disable_irq(max77802->irq); >> >> since in theory this PMIC can be used in other SoCs besides >> Exynos5420/Exynos5800 and it may be possible that the I2C controller driver for >> these other SoCs may not resume at noirq time. >> >> But on a second thought, this PMIC seems to be designed specially for these two >> Exynos SoCs so I guess it's safe to assume that it is not needed? > > Right, there's a close coupling between PMICs and SoCs. The PMIC has > special sequencing and default voltage levels that were tuned exactly > for this SoC. > > Note: Wolfram has not actually responded to my patch much less > accepted it. It's entirely possible that in another month or two > we'll hear back a big fat NAK. In that case your solution will be the > best one I can think of. > Ok, in that case I'll leave as is for now and add the comment but later once/if your patch is merged, this can be removed. > > -Doug > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html