Ok, sorry it was my bad, I had the usb_autopm_get_interface in the wrong place: there was an even earlier call to usb_control_msg, which is why things didn't work. 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. If pin state is lost in suspend, then obviously I'll have to go with the first solution. Karoly January 11, 2019 9:12 AM, "Johan Hovold" <johan@xxxxxxxxxx> wrote: > On Thu, Jan 10, 2019 at 11:21:03PM +0000, Karoly Pados wrote: > >> Hello, >> >> It was observed that the GPIOs of the ftdi_sio driver cannot be used >> when the device was put into autosuspend earlier (usb_control_msg returns >> -EHOSTUNREACH). Quick workaround for users is to disable autosuspend only >> for this affected device, which reportedly fixes the problem. >> However, as the original contributor of this GPIO functionality, my goal >> is creating patch that automatically wakes the device and disables auto- >> suspend when (and only when) the user requests a GPIO line, thereby making >> sure that the GPIOs will be usable (which the user has already declared >> a demand for by requesting a line). >> >> Unfortunately, nothing I try in the kernel works. usb_autopm_get_interface() >> is called successfully (returns 0), but the device still goes into suspend >> (or does not wake if already suspended, dunno). I also tried >> usb_disable_autosuspend() but same results. >> >> So my question is: how can I wake a suspended usb-serial device and >> prevent it from going into autosuspend again (after probing ended)? >> AFAICT usb_autopm_get_interface() should do exactly this, but as I said >> above, for some reason it doesn't have the expected effect. > > You're right that usb_autopm_get_interface() prevents the device from > being runtime suspended. An ftdi device is never suspended while it's > port it open, but we do need to add appropriate usb_autopm calls also to > the gpio callbacks to handle this generally as you point out. > > Have you tried adding such calls to the gpio callbacks (e.g. get and put > around the control messages)? > > I don't think we should prevent suspend completely whenever there are > requested gpios unless really necessary (e.g. the pins loose state > during suspend). But the means to do so would be the same (i.e. acquire > a runtime pm reference in request() and drop it in free()). > > Not sure what to make of the report that usb_autopm_get_interface() > isn't working for you as expected. What is the runtime pm status of the > USB device as reported through sysfs before and after calling > autopm_get() from a gpio request callback for example? > > Johan
