On 27 February 2018 at 11:06, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
> On 27/02/18 10:45, Ulf Hansson wrote:
>> On 14 February 2018 at 13:56, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>>> Commit 03dbaa04a2e5 ("mmc: slot-gpio: Add support to enable irq wake on
>>> cd_irq") enabled wakeup irrespective of the host controller's PM flags.
>>> However, users also want to control it from sysfs power/wakeup attribute.
>>> That means the driver needs to check the PM flags before enabling it in the
>>> suspend callback. Add helper function mmc_gpio_set_cd_wake() to make it
>>> easy for drivers to do that.
>>
>> Depending on if device_may_wakeup() returns true to allow GPIO card
>> detect IRQ to be configured as a wakeup IRQ is problematic.
>>
>> The reason is related to PM domains (genpd) when it checks the
>> dev->power.wakeup_path in system suspend. In case device_may_wakeup()
>> returns true, it may lead to the PM domain is kept powered during
>> system suspend, while in fact this may not be needed for the GPIO IRQ
>> to be configured as wakeup (because the SoC have external HW logic to
>> deal with wakeup IRQs).
>>
>> So I can't apply this, until we have a solution of how to deal with
>> the above situation and I have been working on that. According to the
>> latest discussions [1], between me and Rafael, it seems like the
>> solution must also take runtime PM wakeups into account.
>>
>> Or perhaps you have some other ideas of how we can move forward?
>
> What about removing device_may_wakeup() from mmc_gpio_set_cd_wake()
> and leaving it to the driver (sdhci-pci) to decide whether to call
> device_may_wakeup()?
Yes, that's would be fine for now.
[...]
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
