On Mon, 2011-01-10 at 17:20 -0500, Alan Stern wrote: > On Mon, 10 Jan 2011, Dan Williams wrote: > > > Ah, good to know. > > > > [dcbw@dcbw ~]$ cd -P /sys/class/tty/ttyUSB0/device/../../power > > [dcbw@dcbw power]$ ls > > active_duration connected_duration runtime_active_kids runtime_suspended_time wakeup_active_count wakeup_max_time_ms > > async control runtime_active_time runtime_usage wakeup_count wakeup_total_time_ms > > autosuspend level runtime_enabled wakeup wakeup_hit_count > > autosuspend_delay_ms persist runtime_status wakeup_active wakeup_last_time_ms > > [dcbw@dcbw power]$ cat runtime_enabled > > forbidden > > [dcbw@dcbw power]$ cat runtime_status > > active > > [dcbw@dcbw power]$ cd -P /sys/class/tty/ttyUSB0/device/../power > > [dcbw@dcbw power]$ ls > > async runtime_active_kids runtime_status wakeup wakeup_count wakeup_max_time_ms > > autosuspend_delay_ms runtime_active_time runtime_suspended_time wakeup_active wakeup_hit_count wakeup_total_time_ms > > control runtime_enabled runtime_usage wakeup_active_count wakeup_last_time_ms > > [dcbw@dcbw power]$ cat runtime_enabled > > disabled > > [dcbw@dcbw power]$ cat runtime_status > > unsupported > > > > so yeah, that invalidates my original hypothesis about disable_depth; > > what does the new info mean then? For the device itself, 'forbidden' > > means disable_depth == 0, > > And it implies that usage_count > 0. > > > but runtime_status == RPM_ACTIVE. For the > > interface of course the results mean disabled_depth > 0. But since I > > assume the tty is pulling from the *interface*, not the device, we still > > get EAGAIN... or? > > That could indeed be it. USB serial drivers _should_ support > autosuspend... > > > > What serial driver is getting bound to your interface? Is it cdc-acm? > > > > qcaux, which is a thin shim driver over usbserial, much like moto_modem. > > It's basically a driver to expose the Qualcomm DIAG protocol ports on > > devices that present a CDC-ACM interface (for standard AT commands) and > > then a separate Qualcomm DIAG interface. Thus more than one driver gets > > bound to the device; CDC-ACM for the actual CDC-ACM interface, and qcaux > > for the DIAG interface, and possibly another driver for other protocols > > the device may support on the other interfaces. > > ... but maybe something's wrong with qcaux. I'll have a look at it > tomorrow. qcaux.c does not have: #ifdef CONFIG_PM .suspend = usb_serial_suspend, .resume = usb_serial_resume, .supports_autosuspend = 1, #endif but that shouldn't mean that open() fails, I hope. If the driver doesn't support autosuspend, things should still work... Regardless, adding that hunk to qcaux causes things to magically work again. What's the criteria for drivers to set supports_autosuspend = 1? Should everything that uses usb_serial_probe() be audited with an eye towards adding that block? Dan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
