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.) 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 -- 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
