On Fri, Dec 21, 2012 at 07:00:58AM -0800, 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. > > > > And this isn't always true from all automotive systems, some that I talk > > > to in that industry do need this, as they are not allowed to drain a lot > > > of power all the time (think about when running on a car battery), and > > > their power budget is quite low. > > > > Correct, CONFIG_USB_SUSPEND can let the user choose if they want > > USB runtime PM or not, you know different users may have different > > requirements. > > I don't know anyone that doesn't want USB runtime suspend, that's the > issue here. > > > > > - For embedded system, we have may SoCs, and USB low power mode > > > > is the most challenge job when we bring up new USB module, usually, > > > > our develop sequence like: basic USB functions --> USB function after > > > > System suspend/resume --> USB Runtime PM. We usually disable USB > > > > runtime PM at first. > > > > > > 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. > > 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.)
Thanks, greg. I will share it to other Freescale guys, hope we can work better with community in near future. > > 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. > > Good luck, > > greg k-h > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
