On Fri, 21 Dec 2012, Greg KH wrote: > On Fri, Dec 21, 2012 at 01:21:18PM +0800, Peter Chen wrote: > > On Thu, Dec 20, 2012 at 08:55:33PM -0800, Greg KH wrote: > > > On Fri, Dec 21, 2012 at 12:28:38PM +0800, Peter Chen wrote: > > > > On Tue, Dec 18, 2012 at 11:11:15AM -0500, Alan Stern wrote: > > > > > I suggest that we remove the CONFIG_USB_SUSPEND option, starting in > > > > > 3.9. Practically everyone enables it, and the amount of code it > > > > > protects is fairly small (just portions of usbcore, nothing in the > > > > > drivers). > > > > > > > > > > Basically, if people don't want their kernels to save power then they > > > > > should turn off CONFIG_PM. > > > > > > > > > > Objections, anyone? > > > > Sorry, I may not agree with this due to below reasons: > > > > > > > > - Some customers wants system PM, but do not want usb runtime power > > > > management, such as Car Navigation System. They want system > > > > responds fast after user press power on key, but they don't care > > > > usb power during runtime. > > > > > > What is "fast"? And you can always explicitly keep the device away by > > > writing to the proper sysfs file, right? > > I mean system suspend/resume. > > That's totally different and is not relevant here. Actually it is slightly relevant. When CONFIG_USB_SUSPEND is enabled, during system suspend we go through the whole USB device tree and explicitly suspend each device (and we do the opposite during system resume). Without CONFIG_USB_SUSPEND, only the root hubs are suspended explicitly -- this is what the USB spec calls a "global" suspend. It doesn't work for USB-3 buses, but I assume Peter is referring only to USB-2. Even though the suspend and resume activities are carried out in multiple threads in parallel, it seems reasonable that a "global" approach would take less time. In theory we should be able to use "global" approach for system sleeps even with CONFIG_USB_SUSPEND enabled. I trust this would answer Peter's objection. > > > So you need to get this working properly for your devices, what's wrong > > > with that? :) > > > > Yes, we can debug that but it needs some efforts. Maybe for alpha release > > we only add basic USB function, for beta release we will add usb suspend/resume > > function. Then, at next release, we will add USB runtime PM. > > I just want to say keep CONFIG_USB_SUSPEND can give users more choices > > no matter debug, development or final product procedure. This ought to be irrelevant, because you can effectively turn off runtime PM in userspace whenever you need to. Or you can turn it off by default for all USB devices by making a one-line change to the kernel source (initialize usb_autosuspend_delay to -1 in drivers/usb/core/usb.c). > That really is only your issue, and one that might force your company to > actually work better with the Linux kernel community in order to get > your hardware working properly upstream (hint, Freescale has a horrible > reputation here, I personally always advise people to use other hardware > because of it.) > > We don't have "alpha" and the like type of releases. If this option > goes away, it still doesn't affect your ability to actually support USB > suspend in a better way, but it becomes more obvious that you don't, > which I think is a good thing. Without commenting on Freescale's degree of community support, it still seems clear that there is essentially no real advantage to disabling CONFIG_USB_SUSPEND -- or at least, there won't be after we add support for "global" USB suspend and resume during system sleep. Alan Stern -- 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
