Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.6 2012-06-22T18:37:13+00:00 2012-06-22T18:37:13+00:00 Alan Stern stern@rowland.harvard.edu 2012-06-13T15:20:19+00:00 urn:sha1:12ad741b1c60c341bf85a90c828b6fa1df47dba5 commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b upstream. This patch (as1558) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. A similar patch has already been applied as commit 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during suspend on ASUS computers). The patch supersedes that one and reverts it. There are two differences: The old patch added the flag at the USB level; this patch adds it at the PCI level. The old patch applied to all chipsets with the same vendor, subsystem vendor, and product IDs; this patch makes an exception for a known-good system (based on DMI information). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-05-15T17:41:42+00:00 Ming Lei tom.leiming@gmail.com 2012-04-26T03:33:46+00:00 urn:sha1:5b6e9bcdeb65634b4ad604eb4536404bbfc62cfa Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid recursive locking in usbnet_stop()) fixes the recursive locking problem by releasing the skb queue lock before unlink, but may cause skb traversing races: - after URB is unlinked and the queue lock is released, the refered skb and skb->next may be moved to done queue, even be released - in skb_queue_walk_safe, the next skb is still obtained by next pointer of the last skb - so maybe trigger oops or other problems This patch extends the usage of entry->state to describe 'start_unlink' state, so always holding the queue(rx/tx) lock to change the state if the referd skb is in rx or tx queue because we need to know if the refered urb has been started unlinking in unlink_urbs. The other part of this patch is based on Huajun's patch: always traverse from head of the tx/rx queue to get skb which is to be unlinked but not been started unlinking. Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Cc: Oliver Neukum <oneukum@suse.de> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net> 2012-04-24T20:55:43+00:00 Alan Stern stern@rowland.harvard.edu 2012-04-24T18:07:22+00:00 urn:sha1:151b61284776be2d6f02d48c23c3625678960b97 This patch (as1545) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. This fixes Bugzilla #42728. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Steven Rostedt <rostedt@goodmis.org> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Oleksij Rempel (fishor) <bug-track@fisher-privat.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-04-16T15:35:33+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2012-04-16T15:35:33+00:00 urn:sha1:edffaa031e50f913f0272516b39dd1cad7aa4aea usb: fixes for v3.4-rc cycle Here are the fixes I have queued for v3.4-rc cycle so far. It includes fixes on many of the gadget drivers and a few of the UDC controller drivers. For musb we have a fix for a kernel oops when unloading omap2430.ko glue layer, proper error checking for pm_runtime_*, fix for the ULPI transfer block, and a bug fix in musb_cleanup_urb routine. For s3c-hsotg we have mostly FIFO-related fixes (proper TX FIFO allocation, TX FIFO corruption fix in DMA mode) but also a couple of minor fixes (fixing maximum packet size for ep0 and fix for big transfers with DMA). For the dwc3 driver we have a memory leak fix, a very important fix for USB30CV with SetFeature tests and the hability to handle ep0 requests bigger than wMaxPacketSize. On top of that there's a bunch of gadget driver minor fixes adding proper section annotations, and fixing up the sysfs interface for doing device-initiated connect/disconnect and so on. All patches have been pending on the mailing list for quite a while and look good for your for-linus branch. 2012-04-10T16:11:48+00:00 Grazvydas Ignotas notasas@gmail.com 2012-03-21T14:35:52+00:00 urn:sha1:bf070bc14178f1458e7eccd76316ac24f76f1890 musb can be suspended at the time some other driver wants to do ulpi transfers using usb_phy_io_* functions, and that can cause data abort, as it happened with isp1704_charger: http://article.gmane.org/gmane.linux.kernel/1226122 Add pm_runtime to ulpi functions to rectify this. This also adds io_dev to usb_phy so that pm_runtime_* functions can be used. Cc: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Felipe Balbi <balbi@ti.com> 2012-04-09T22:36:20+00:00 Alan Stern stern@rowland.harvard.edu 2012-03-28T20:10:49+00:00 urn:sha1:891a3b1fddb24b4b53426685bd0390bb74c9b5b3 This patch (as1536) fixes a bug in the USB serial core. Unloading and reloading a serial driver while a serial device is plugged in causes errors because of the code in usb_serial_disconnect() that tries to make sure the port_remove method is called. With the new order of driver registration introduced in the 3.4 kernel, this is definitely not the right thing to do (if indeed it ever was). The patch removes that whole section code, along with the mechanism for keeping track of each port's registration state, which is no longer needed. The driver core can handle all that stuff for us. Note: This has been tested only with one or two USB serial drivers. In theory, other drivers might still run into trouble. But if they do, it will be the fault of the drivers, not of this patch -- that is, the drivers will need to be fixed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-03-15T19:42:07+00:00 Hauke Mehrtens hauke@hauke-m.de 2012-03-13T00:04:48+00:00 urn:sha1:7a7a4a592f42d9abf3b6cc40620b3f79fef49246 This adds a generic driver for platform devices. It works like the PCI driver and is based on it. This is for devices which do not have an own bus but their EHCI controller works like a PCI controller. It will be used for the Broadcom bcma and ssb USB EHCI controller. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-03-15T19:41:58+00:00 Hauke Mehrtens hauke@hauke-m.de 2012-03-13T00:04:47+00:00 urn:sha1:fa3364b5a2d79b0c94a912b371c92bd3d06bc8fb This adds a generic driver for platform devices. It works like the PCI driver and is based on it. This is for devices which do not have an own bus but their OHCI controller works like a PCI controller. It will be used for the Broadcom bcma and ssb USB OHCI controller. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-03-12T16:31:24+00:00 Andiry Xu andiry.xu@amd.com 2011-12-12T08:45:28+00:00 urn:sha1:f99298bfa7c42da8d27c2b42050941471c0866ab The latest released errata for USB2.0 ECN LPM adds new fields to USB2.0 extension descriptor, defines two BESL values for device: baseline BESL and deep BESL. Baseline BESL value communicates a nominal power savings design point and the deep BESL value communicates a significant power savings design point. If device indicates BESL value, driver will use a value count in both host BESL and device BESL. Use baseline BESL value as default. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Tested-by: Jason Fan <jcfan@qca.qualcomm.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> 2012-03-10T00:38:14+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2012-03-10T00:38:14+00:00 urn:sha1:b790f5d1260b4c962bd066cd34ae982943c27fe1 Now that module_driver() can handle varargs, use it instead of rolling our own version. Cc: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>