[...] > > > However, while this approach is known to work fine on other boards, with > > > other GPIO and interrupt controllers (gpio-rcar, irq-renesas-irqc, > > > irq-renesas-intc-irqpin), it wouldn't work on Ebisu-4D, due to different > > > device suspend ordering. > > > > > > The proper ordering is: > > > 1. When gpio-keys is suspended, its suspend handler calls > > > enable_irq_wake(), invoking pca953x_irq_set_wake(), and causing > > > pca953x_chip.wakeup_path to be incremented, > > > 2. When gpio-pca953x is suspended, it checks pca953x_chip.wakeup_path, > > > and marks the device to be part of the wake-up path. > > > > Right. > > > > > > > > However, gpio-keys is suspended _after_ gpio-pca953x, breaking the > > > scheme :-( > > > > Would it make sense to fixup the ordering issue via creating a > > parent/child relationship or setting up a device link? > > Could that be due to gpio_keys not having rudimentary Runtime PM support? You are saying that the parent/child relation ship is already there? In such case, it shouldn't matter whether runtime PM is deployed or not, the PM core should propagate the wakeup_path flag from children to parents in __device_suspend() and in device_suspend_late(). If that doesn't happen there is bug in the PM core. Kind regards Uffe
