On Fri, Jan 11, 2019 at 10:13:28AM +0000, Karoly Pados wrote: > As the next step I'm going to prepare a patch to fix this buggy > interaction with PM. Assuming GPIO pin state is not lost in suspend > (I'll test this explicitly later), which of the following two ways is > the preferred solution?
> - Call autopm_get in gpio_request and autopm_put in gpio_free, kind of > like how the existing code calls autopm_get in port open, or... > - Sandwich all gpio-related code (get, set, _*multiple, > direction_input, etc.) between pairs of autopm_get and autopm_put. The second, more fine-grained option is preferred. No need to keep the device resumed if all you want to do is set a pin state and leave it at that, for example. Looks like you may get away with only adding calls to ftdi_set_cbus_pins() and ftdi_read_cbus_pins(). Would be good to keep the fix minimal so we can backport it to stable too. > If pin state is lost in suspend, then obviously I'll have to go with > the first solution. Right, but then we'd have bigger problems with restoring the state on resume. It'd be good to confirm this isn't the case. Thanks, Johan
