> Remember that "usb_device" suspend is managed only by usbcore, > and drivers themselves connect to a "usb_interface" of which > several generally exist. > > Don't even _think_ of usb_suspend_device() as anything more than > an internal "helper" routine. Yes, called by the "generic" suspend > routine that understands the difference between the two types of > usb devie nodes: usb_device, usb_interface.
Ok, that's what I was finally getting at by reading the core. I wasn't sure if a driver coult actually take over the whole devie or not. >You did miss a few things here. Yup, I'm getting it. > No, there's a missing "autosuspend" mechanism. That's what would > suspend USB devices after all of their interfaces are suspended > (possibly because they have no driver) ... as part of runtime PM, > rather than as part of system-wide sleep state transitions. Ok. How difficult would that be to implement ? I may give that a try at one point. Typically suspending interfaces for devices with all interfaces explicitely suspended by the driver. I'm not sure about devices with no driver attached as we don't know if the device actually supports the suspend state, and that would thus possibly break further driver loading or userland drivers if the device crashes. > > - If a device wants to suspend itself > > That concept is nonsense. A driver may choose to suspend its device. That's what I meant. > And for USB, the drivers are bound to usb_interface objects, not to > usb_device objects. So drivers suspend usb_interface->dev ... and > usbcore is then responsible for suspending usb_device->dev, not the > driver for one of the device's interfaces. Yup, got it. > There are a couple exceptions, notably anything calling usb_reset_device() > (for DFU firmware updates or for usb-storage fault recovery), but we're > trying to steer drivers away from such exceptions. Ok. Well back in the MacOS days, I remember we could explicitly bind drivers to interfaces or whole device. It made sense for some proprietary drivers (that is not class drivers typically) to bind to the whole devive, typically for things like firmware uploads & forced disconnects/reconnects. > The driver could call that on the device object inside its usb_interface. > That ought to work. But it won't suspend the parent usb_device yet, > because there isn't an autosuspend framework yet. Suspending the parent device when all interfaces are suspended could be implemented "by itself" without going all the way to a full featured autosuspend framework that walks all the way up the tree, no ? That is at least going up one level to the devive, which itself goes to the hub already. That would provide significant power saving in the most common cases (suspending entire hubs when they have nothing connected or all childs suspended would be what an autosuspend framework would bring in addition I suppose). > You missed some of those, as well as the missing "autosuspend" logic. > Since that logic is missing, it's especially easy to overlook. ;) Yes, well, since I was thinking about drivers at the device and not interface level, autosuspend triggered by the driver for one port wouldn't have needed any special logic. In fact, if today, my USB device driver suspends all its interfaces and then suspends its parent device all by itself, it will acheive the desired result though it's not necessarily clean :) > I'd say it differently: For now don't try that at all. Because in addition > to an autosuspend mechanism being missing, so is autoresume. Well, what I'm describing is entirely under control of the driver, thus the driver would just issue the right resume call as soon as it gets a request or an open port in the case of a serial driver ... Ben. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
