On Mon, Jan 7, 2019 at 4:42 PM Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxx> wrote: > This patch almost solves the problem. It doesn't work as-is, because it > assumes that runtime PM is used by all GPIO controllers, which is not > the case. When runtime PM is not enabled, pm_runtime_get_sync() fails > with -EACCES, and the whole gpiochip_irq_reqres() function aborts. (...) > However, I must say that from a design perspective, I am not a big fan > of this solution. Indeed for the normal GPIO ->request() and ->free() > hooks, it is currently the GPIO driver itself that is responsible for > runtime PM get/put, so it would be weird to have the runtime PM get/put > for the IRQ request/free be done by the GPIO core. > > I believe that either the GPIO core should be in charge of the entire > runtime PM interaction, or it should entirely be the responsibility of > each GPIO controller driver. Having a mixed solution seems very > confusing. My stance is that the driver is responsible of enabling and managing runtime PM for its hardware block(s). Runtime PM in the core should only be added if the core needs to be aware about it, such as is the case when e.g. a block device needs to drain its write buffer before going to runtime sleep. I fail so see why the GPIO core need to be aware about this. Yours, Linus Walleij