On Mon, 2011-01-10 at 16:08 -0500, Alan Stern wrote: > On Mon, 10 Jan 2011, Dan Williams wrote: > > > Hi, > > > > Upon booting 2.6.37 for the first time any open(2) request for the TTY > > port of my Pantech UML290 (new Verizon LTE dongle) returned EAGAIN. > > (lsusb for the device at the bottom) This did not happen with 2.6.36. > > > > The USB interface in question is #2, the QCDM DIAG port of the device. > > The other ports are standard CDC-ACM for minimal AT commands, and > > vendor-specific ports for RmNet (Qualcomm pseudo-ethernet protocol), > > another proprietary control protocol, and a GPS port. > > > > The callpath below is what I believe is happening to return EAGAIN to > > open() of the DIAG tty: > > > > tty_open > > tty_init_dev > > tty_driver_install_tty > > driver->ops->install > > serial_install > > usb_autopm_get_interface (returns -EAGAIN) > > Did you verified that it really does return -EAGAIN? Yes, I have; that call in serial_install() in drivers/usb/serial/usb-serial.c is definitely returning EAGAIN, which is how I composed the above call stack. > > pm_runtime_get_sync > > __pm_runtime_resume > > rpm_resume > > > > rpm_resume() executes this code: > > > > else if (dev->power.disable_depth > 0) > > retval = -EAGAIN; > > > > which I think is the culprit, since not much else below > > usb_autopm_get_interface() returns EAGAIN. > > Here's /sys/class/tty/ttyUSB0/power: > > That's the wrong directory. You need to look in > /sys/class/tty/ttyUSB0/device/../../power (the device's directory) and > /sys/class/tty/ttyUSB0/device/../power (the interface's directory). 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, 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? > > [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 > > > > which seems to corroborate that disable_depth > 0 for this device. > > No, it's meaningless because that's a class device directory, not the > directory for the real device. > > > The > > hunk in question is from: > > > > 1bfee5bc Alan Stern 2010-09-25 > > Linus has asked people to include the commit name in parenthesis along > with the hash value; otherwise there's no easy way to tell what the > commit is. > > However I looked it up, and it's not obvious how it relates to your > problem. Maybe things will become clearer when we see the power info > for the real device. > > > Does anyone have ideas how to debug further? Clearly for this device > > pm_runtime_enable() isn't getting called, and thus rpm_resume() is > > bailing out early. Perhaps the device doesn't actually support > > autosuspend or something, but that shouldn't cause open(2) to fail... > > Do other USB serial devices that don't support autosuspend work with > > 2.6.37? > > It's not a question of what the device supports; it's a question of > what the software is doing. > > 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. We do have devices that expose DIAG ports already driven by 'option' (Huawei EC168C for example), but adding the IDs for the DIAG interfaces for devices not primarily driven by option was vetoed long ago, thus I proposed qcaux. 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
