Re: Wake usb-serial device and disable autosuspend after probing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux