summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-06-01x86, relocs: Add jiffies and jiffies_64 to the relative whitelistH. Peter Anvin1-0/+1
commit ea17e7414bc62e8d3bde8d08e3df1d921c518c17 upstream. The symbol jiffies is created in the linker script as an alias to jiffies_64. Unfortunately this is done outside any section, and apparently GNU ld 2.21 doesn't carry the section with it, so we end up with an absolute symbol and therefore a broken kernel. Add jiffies and jiffies_64 to the whitelist. The most disturbing bit with this discovery is that it shows that we have had multiple linker bugs in this area crossing multiple generations, and have been silently building bad kernels for some time. Link: http://lkml.kernel.org/r/20120524171604.0d98284f3affc643e9714470@canb.auug.org.au Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01x86-32, relocs: Whitelist more symbols for ld bug workaroundH. Peter Anvin1-0/+11
commit fd952815307f0f272bf49fd364a7fd2f9992bc42 upstream. As noted in checkin: a3e854d95 x86, relocs: Workaround for binutils 2.22.52.0.1 section bug ld version 2.22.52.0.[12] can incorrectly promote relative symbols to absolute, if the output section they appear in is otherwise empty. Since checkin: 6520fe55 x86, realmode: 16-bit real-mode code support for relocs tool we actually check for this and error out rather than silently creating a kernel which will malfunction if relocated. Ingo found a configuration in which __start_builtin_fw triggered the warning. Go through the linker script sources and look for more symbols that could plausibly get bogusly promoted to absolute, and add them to the whitelist. In general, if the following error triggers: Invalid absolute R_386_32 relocation: <symbol> ... then we should verify that <symbol> is really meant to be relocated, and add it and any related symbols manually to the S_REL regexp. Please note that 6520fe55 does not introduce the error, only the check for the error -- without 6520fe55 this version of ld will simply produce a corrupt kernel if CONFIG_RELOCATABLE is set on x86-32. Reported-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01x86, relocs: Build clean fixJarkko Sakkinen1-0/+1
commit b2d668da9307c4c163dd603d2bb3cadb10f9fd37 upstream. relocs was not cleaned up when "make clean" is issued. This patch fixes the issue. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com> Link: http://lkml.kernel.org/r/1337622684-6834-1-git-send-email-jarkko.sakkinen@intel.com Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01media: uvcvideo: Fix ENUMINPUT handlingLaurent Pinchart1-1/+1
commit 31c5f0c5e25ed71eeced170f113bb590f2f1f6f3 upstream. Properly validate the user-supplied index against the number of inputs. The code used the pin local variable instead of the index by mistake. Reported-by: Jozef Vesely <vesely@gjh.sk> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01smsusb: add autodetection support for USB ID 2040:c0a0Michael Krufky1-0/+2
commit 4d1b58b84472d1d300a66e1c5fd765b21e74ba15 upstream. Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01nouveau: nouveau_set_bo_placement takes TTM flagsDave Airlie1-1/+1
commit c284815debba2f14ee2fd07b1b4cc972ab116110 upstream. This seems to be wrong to me, spotted while thinking about dma-buf. Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01xen: do not map the same GSI twice in PVHVM guests.Stefano Stabellini3-2/+10
commit 68c2c39a76b094e9b2773e5846424ea674bf2c46 upstream. PV on HVM guests map GSIs into event channels. At restore time the event channels are resumed by restore_pirqs. Device drivers might try to register the same GSI again through ACPI at restore time, but the GSI has already been mapped and bound by restore_pirqs. This patch detects these situations and avoids mapping the same GSI multiple times. Without this patch we get: (XEN) irq.c:2235: dom4: pirq 23 or emuirq 28 already mapped and waste a pirq. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01hvc_xen: NULL dereference on allocation failureDan Carpenter1-2/+2
commit 201a52bea928687b7557728b176ac4f8a37d5cbd upstream. If kzalloc() returns a NULL here, we pass a NULL to xencons_disconnect_backend() which will cause an Oops. Also I removed the __GFP_ZERO while I was at it since kzalloc() implies __GFP_ZERO. Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01spi/spi-fsl-spi: reference correct pdata in fsl_spi_cs_controlHerton Ronaldo Krzesinski1-1/+1
commit 067aa4815a9bc12a569d8a06afef50ba5773afbf upstream. Commit 178db7d3, "spi: Fix device unregistration when unregistering the bus master", changed spi device initialization of dev.parent pointer to be the master's device pointer instead of his parent. This introduced a bug in spi-fsl-spi, since its usage of spi device pointer was not updated accordingly. This was later fixed by commit 5039a86, "spi/mpc83xx: fix NULL pdata dereference bug", but it missed another spot on fsl_spi_cs_control function where we also need to update usage of spi device pointer. This change address that. Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01gpio: mpc8xxx: Prevent NULL pointer deref in demux handlerThomas Gleixner1-1/+2
commit d6de85e85edcc38c9edcde45a0a568818fcddc13 upstream. commit cfadd838(powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO driver) added an unconditional call of chip->irq_eoi() to the demux handler. This leads to a NULL pointer derefernce on MPC512x platforms which use this driver as well. Make it conditional. Reported-by: Thomas Wucher <thwucher@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Felix Radensky <felix@embedded-sol.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01drm/i915: don't clobber the pipe param in sanitize_modesettingDaniel Vetter1-2/+3
commit a9dcf84b14ef4e9a609910367576995e6f32f3dc upstream. ... we need it later on in the function to clean up pipe <-> plane associations. This regression has been introduced in commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Mar 22 15:00:50 2012 +0000 drm/i915: Sanitize BIOS debugging bits from PIPECONF Spotted by staring at debug output of an (as it turns out) totally unrelated bug. v2: I've totally failed to do the s/pipe/i/ correctly, spotted by Chris Wilson. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01drm/i915: [GEN7] Use HW scheduler for fixed function shadersBen Widawsky2-0/+29
commit a1e969e0332de7a430e62822cee8f2ec8d83cd7c upstream. This originally started as a patch from Bernard as a way of simply setting the VS scheduler. After submitting the RFC patch, we decided to also modify the DS scheduler. To be most explicit, I've made the patch explicitly set all scheduler modes, and included the defines for other modes (in case someone feels frisky later). The rest of the story gets a bit weird. The first version of the patch showed an almost unbelievable performance improvement. Since rebasing my branch it appears the performance improvement has gone, unfortunately. But setting these bits seem to be the right thing to do given that the docs describe corruption that can occur with the default settings. In summary, I am seeing no more perf improvements (or regressions) in my limited testing, but we believe this should be set to prevent rendering corruption, therefore cc stable. v1: Clear bit 4 also (Ken + Eugeni) Do a full clear + set of the bits we want (Me). Cc: Bernard Kilarski <bernard.r.kilarski@intel.com> Reviewed-by (RFC): Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01drm/i915: Avoid a double-read of PCH_IIR during interrupt handlingChris Wilson1-6/+3
commit 9adab8b5a7fde248504f484e197589f3e3c922e2 upstream. Currently the code re-reads PCH_IIR during the hotplug interrupt processing. Not only is this a wasted read, but introduces a potential for handling a spurious interrupt as we then may not clear all the interrupts processed (since the re-read IIR may contains more interrupts asserted than we clear using the result of the original read). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01b43legacy: Fix error due to MMIO access with SSB unpoweredLarry Finger1-2/+0
commit 8f4b20388fa77226a3605627a33a23f90d559e50 upstream. There is a dummy read of a PCI MMIO register that occurs before the SSB bus has been powered, which is an error. This bug has not been seen earlier, but was apparently exposed when udev was updated to version 182. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01gma500: Fix Poulsbo suspend/resume crash on devices with SDVO portsAlan Cox1-2/+4
commit 7beff62ee39d3ccf088bb77f61a63037f714d235 upstream. Reported-by: Guillaume Clément <guillaume@baobob.org> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01usbcore: enable USB2 LPM if port suspend failsAndiry Xu1-0/+4
commit c3e751e4f4754793bb52bd5ae30e9cc027edbb12 upstream. USB2 LPM is disabled when device begin to suspend and enabled after device is resumed. That's because USB spec does not define the transition from U1/U2 state to U3 state. If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM is disabled in this situation. Enable USB2 LPM if port suspend fails. This patch should be backported to kernels as old as 3.2, that contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2 hardware LPM". Signed-off-by: Andiry Xu <andiry.xu@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: fix resource leak in xhci power loss pathOliver Neukum1-0/+26
commit f8a9e72d125f4e00ec529ba67b674321a1f3bf31 upstream. Some more data structures must be freed and counters reset if an XHCI controller has lost power. The failure to do so renders some chips inoperative after a certain number of S4 cycles. This patch should be backported to kernels as old as 3.2, that contain the commits c29eea621900f18287d50519f72cb9113746d75a "xhci: Implement HS/FS/LS bandwidth checking." and commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Implement HS/FS/LS bandwidth checking." Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01xhci: Add new short TX quirk for Fresco Logic host.Sarah Sharp3-3/+19
commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 upstream. Sergio reported that when he recorded audio from a USB headset mic plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded "robotic". When plugged into the USB 2.0 port under EHCI on the same laptop, the audio sounded fine. The device is: Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset The problem was tracked down to the Fresco Logic xHCI host controller not correctly reporting short transfers on isochronous IN endpoints. The driver would submit a 96 byte transfer, the device would only send 88 or 90 bytes, and the xHCI host would report the transfer had a "successful" completion code, with an untransferred buffer length of 8 or 6 bytes. The successful completion code and non-zero untransferred length is a contradiction. The xHCI host is supposed to only mark a transfer as successful if all the bytes are transferred. Otherwise, the transfer should be marked with a short packet completion code. Without the EHCI bus trace, we wouldn't know whether the xHCI driver should trust the completion code or the untransferred length. With it, we know to trust the untransferred length. Add a new xHCI quirk for the Fresco Logic host controller. If a transfer is reported as successful, but the untransferred length is non-zero, print a warning. For the Fresco Logic host, change the completion code to COMP_SHORT_TX and process the transfer like a short transfer. This should be backported to stable kernels that contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts." That commit was marked for stable kernels as old as 2.6.36. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Sergio Correia <lists@uece.net> Tested-by: Sergio Correia <lists@uece.net> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01xhci: Reset reserved command ring TRBs on cleanup.Sarah Sharp1-0/+1
commit 33b2831ac870d50cc8e01c317b07fb1e69c13fe1 upstream. When the xHCI driver needs to clean up memory (perhaps due to a failed register restore on resume from S3 or resume from S4), it needs to reset the number of reserved TRBs on the command ring to zero. Otherwise, several resume cycles (about 30) with a UAS device attached will continually increment the number of reserved TRBs, until all command submissions fail because there isn't enough room on the command ring. This patch should be backported to kernels as old as 2.6.32, that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d "USB: xhci: Change how xHCI commands are handled." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01usb-xhci: Handle COMP_TX_ERR for isoc tdsHans de Goede1-0/+1
commit 9c745995ae5c4ff787f34a359de908facc11ee00 upstream. While testing unplugging an UVC HD webcam with usb-redirection (so through usbdevfs), my userspace usb-redir code was getting a value of -1 in iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt is not a valid value. The source of this -1 is the default case in xhci-ring.c:process_isoc_td() adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR in this case, so this patch adds handling for that completion code to process_isoc_td(). This was observed and tested with the following xhci controller: 1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can do, but since I cannot come up with anything better I've left that as is. This patch should be backported to kernels as old as 2.6.36, which contain the commit 04e51901dd44f40a5a385ced897f6bca87d5f40a "USB: xHCI: Isochronous transfer implementation". Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=nSarah Sharp1-0/+14
commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 upstream. If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system with an Intel Panther Point chipset, the PCI quirks code or the EHCI driver will switch the ports over to the xHCI host, but the xHCI driver will never load. The ports will be powered off and seem "dead" to the user. Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is either compiled in, or compiled as a module. This patch should be backported to stable kernels as old as 3.0, that contain commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Eric Anholt <eric.anholt@intel.com> Reported-by: David Bein <d.bein@f5.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01xHCI: keep track of ports being resumed and indicate in hub_status_dataAndiry Xu4-12/+25
commit f370b9968a220a3d79d870dd7dee674cc0ff3d10 upstream. This commit adds a bit-array to xhci bus_state for keeping track of which ports are undergoing a resume transition. If any of the bits are set when xhci_hub_status_data() is called, the routine will return a non-zero value even if no ports have any status changes pending. This will allow usbcore to handle races between root-hub suspend and port wakeup. This patch should be backported to kernels as old as 3.4, that contain the commit 879d38e6bc36d73b0ac40ec9b0d839fda9fa8b1a "USB: fix race between root-hub suspend and remote wakeup". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01xhci: Add Lynx Point to list of Intel switchable hosts.Sarah Sharp2-2/+20
commit 1c12443ab8eba71a658fae4572147e56d1f84f66 upstream. The upcoming Intel Lynx Point chipset includes an xHCI host controller that can have ports switched from the EHCI host controller, just like the Intel Panther Point xHCI host. This time, ports from both EHCI hosts can be switched to the xHCI host controller. The PCI config registers to do the port switching are in the exact same place in the xHCI PCI configuration registers, with the same semantics. Hooray for shipping patches for next-gen hardware before the current gen hardware is even available for purchase! This patch should be backported to stable kernels as old as 3.0, that contain commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01usb: add USB_QUIRK_RESET_RESUME for M-Audio 88esSteffen Müller1-0/+3
commit 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 upstream. Tested-by: Steffen Müller <steffen.mueller@radio-frei.de> Signed-off-by: Steffen Müller <steffen.mueller@radio-frei.de> Signed-off-by: Stefan Seyfried <seife+kernel@b1-systems.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01usb: gadget: fsl_udc_core: dTD's next dtd pointer need to be updated once ↵Peter Chen1-0/+2
written commit 4d0947dec4db1224354e2f6f00ae22ce38e62a43 upstream. dTD's next dtd pointer need to be updated once CPU writes it, or this request may not be handled by controller, then host will get NAK from device forever. This problem occurs when there is a request is handling, we need to add a new request to dTD list, if this new request is added before the current one is finished, the new request is intended to added as next dtd pointer at current dTD, but without wmb(), the dTD's next dtd pointer may not be updated when the controller reads it. In that case, the controller will still get Terminate Bit is 1 at dTD's next dtd pointer, that means there is no next request, then this new request is missed by controller. Signed-off-by: Peter Chen <peter.chen@freescale.com> Acked-by: Li Yang <leoli@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: serial: ti_usb_3410_5052: Add support for the FRI2 serial consoleDarren Hart2-2/+5
commit 975dc33b82cb887d75a29b1e3835c8eb063a8e99 upstream. The Kontron M2M development board, also known as the Fish River Island II, has an optional daughter card providing access to the PCH_UART (EG20T) via a ti_usb_3410_5052 uart to usb chip. http://us.kontron.com/products/systems+and+platforms/m2m/m2m+smart+services+developer+kit.html Signed-off-by: Darren Hart <dvhart@linux.intel.com> CC: Al Borchers <alborchers@steinerpoint.com> CC: Peter Berger <pberger@brimson.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: Remove races in devio.cHuajun Li1-8/+25
commit 4e09dcf20f7b5358615514c2ec8584b248ab8874 upstream. There exist races in devio.c, below is one case, and there are similar races in destroy_async() and proc_unlinkurb(). Remove these races. cancel_bulk_urbs() async_completed() ------------------- ----------------------- spin_unlock(&ps->lock); list_move_tail(&as->asynclist, &ps->async_completed); wake_up(&ps->wait); Lead to free_async() be triggered, then urb and 'as' will be freed. usb_unlink_urb(as->urb); ===> refer to the freed 'as' Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oncaphillis <oncaphillis@snafu.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: ohci-at91: add a reset function to fix race conditionNicolas Ferre1-1/+10
commit 07e4e556eff4938eb2edf2591de3aa7d7fb82b52 upstream. A possible race condition appears because we are not initializing the ohci->regs before calling usb_hcd_request_irqs(). We move the call to ohci_init() in hcd->driver->reset() instead of hcd->driver->start() to fix this. This was experienced when we share the same IRQ line between OHCI and EHCI controllers. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Tested-by: Christian Eggers <christian.eggers@kathrein.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: gpio_vbus: provide an appropriate debounce intervalShinya Kuribayashi1-4/+4
commit 934ccec4da14dc0586dfe08b36166364bdd2181b upstream. In commit c2344f13b59e007d782a3e591ebc551bc583a8b7 (USB: gpio_vbus: add delayed vbus_session calls, 2009-01-24), usb_gadget_vbus_connect() and ...disconnect() were extracted from the interrupt handler, so to allow vbus_session handlers to deal with msleep() calls. This patch takes the approach one step further. USB2.0 specification (7.1.7.3 Connect and Disconnect Signaling) says that the USB system software (shall) provide a debounce interval with a minimum duration of 100 ms, which ensures that the electrical and mechanical connection is stable before software attempts to reset the attached device. Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: EHCI: OMAP: Finish ehci omap phy reset cycle before adding hcd.Russ Dill1-9/+9
commit 3aa2ae74ba630ec9b98736d64aea8e4cb490861d upstream. 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0f) created a regression with Beagleboard xM if booting the kernel after running 'usb start' under u-boot. Finishing the reset before calling 'usb_add_hcd' fixes the regression. This is most likely due to usb_add_hcd calling the driver's reset and init functions which expect the hardware to be up and running. Signed-off-by: Russ Dill <Russ.Dill@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: ehci-platform: remove update_deviceHauke Mehrtens1-2/+0
commit 8377c94f627f7943da9a7eefdb21fd2e9e7ec629 upstream. The update_device callback is not needed and the function used here is from the pci ehci driver. Without this patch we get a compile error if ehci-platform is compiled without ehci-pci. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01usb: usbtest: two super speed fixes for usbtestPaul Zimmerman1-5/+12
commit 6a23ccd216b6a8ba2c67a9f9d8969b4431ad2920 upstream. bMaxPacketSize0 field for super speed is a power of 2, not a count. The size itself is always 512. Max packet size for a super speed bulk endpoint is 1024, so allocate the urb size in halt_simple() accordingly. Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: ffs-test: fix length argument of out function callMatthias Fend1-1/+1
commit eb9c5836384cd2a276254df6254ed71117983626 upstream. The out functions should only handle actual available data instead of the complete buffer. Otherwise for example the ep0_consume function will report ghost events since it tries to decode the complete buffer - which may contain partly invalid data. Signed-off-by: Matthias Fend <matthias.fend@wolfvision.net> Acked-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01usb-storage: unusual_devs entry for Yarvik PMP400 MP4 playerAlan Stern1-0/+7
commit df767b71e5816692134d59c0c17e0f77cd73333d upstream. This patch (as1553) adds an unusual_dev entrie for the Yarvik PMP400 MP4 music player. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Jesse Feddema <jdfeddema@gmail.com> Tested-by: Jesse Feddema <jdfeddema@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01usb-serial: ftdi_sio: fix oops during autosuspendAlan Stern1-2/+7
commit 5cbe61c5aff0a8ada691eb8b07dbfb55c303f640 upstream. This patch (as1550) fixes a bug in the usb-serial core that affects the ftdi_sio driver and most likely others as well. The core implements suspend and resume routines, but it doesn't store pointers to those routines in the usb_driver structures that it registers, even though it does set those drivers' supports_autosuspend flag. The end result is that when one of these devices is autosuspended, we try to call through a NULL pointer. The patch fixes the problem by setting the suspend and resume method pointers to the appropriate routines in the USB serial core, along with the supports_autosuspend field, in each driver as it is registered. This should be back-ported to all the stable kernels that have the new usb_serial_register_drivers() interface. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Frank Schäfer <schaefer.frank@gmx.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: ftdi-sio: add support for Physik Instrumente E-861Éric Piel2-0/+9
commit b69cc672052540e8efb1368420f10d7d4d8b8a3d upstream. This adds VID/PID for the PI E-861. Without it, I had to do: modprobe -q ftdi-sio product=0x1008 vendor=0x1a72 http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610 Signed-off-by: Éric Piel <piel@delmic.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01tty: Allow uart_register/unregister/registerAlan Cox1-0/+1
commit 1e66cded334e6cea596c72f6f650eec351b1e959 upstream. This is legitimate but because we don't clear the drv->state pointer in the unregister code causes a bogus BUG(). Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880 Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-018250_pci: fix pch uart matchingArnaud Patard1-0/+18
commit aaa10eb1d0034eccc096f583fe308f0921617598 upstream. The rules used to make 8250_pci "ignore" the PCH uarts are lacking pci subids entries, preventing it to match and thus is breaking serial port support for theses systems. This has been tested on a nanoETXexpress-TT, which has a specifici uart clock. Tested-by: Erwan Velu <Erwan.Velu@zodiacaerospace.com> [stable@: please apply to 3.0-stable, 3.2-stable and 3.3-stable] Signed-off-by: Arnaud Patard <apatard@hupstream.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-018250.c: less than 2400 baud fix.Christian Melki1-4/+5
commit f9a9111b540fd67db5dab332f4b83d86c90e27b1 upstream. We noticed that we were loosing data at speed less than 2400 baud. It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr reg. The input code still fills the buffer with 64 bytes if I remember correctly and thus data is lost. Our fix was to remove whiping of the fcr content and just add the TRIGGER_1 which we want for latency. I can't see why this would not work on less than 2400 always, for all uarts ... Otherwise one would have to make sure the filling of the fifo re-checks the current state of available fifo size (urrk). Signed-off-by: Christian Melki <christian.melki@ericsson.se> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01Add missing call to uart_update_timeout()Lothar Waßmann1-0/+2
commit 8b979f7c6bf13a57e7b6002f1175312a44773960 upstream. This patch fixes a problem reported here: http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auart Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01md: using GFP_NOIO to allocate bio for flush requestShaohua Li1-1/+1
commit b5e1b8cee7ad58a15d2fa79bcd7946acb592602d upstream. A flush request is usually issued in transaction commit code path, so using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. This is suitable for any -stable kernel to which it applies as it avoids a possible deadlock. Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01mm: mempolicy: Let vma_merge and vma_split handle vma->vm_policy linkagesMel Gorman1-24/+17
commit 05f144a0d5c2207a0349348127f996e104ad7404 upstream. Dave Jones' system call fuzz testing tool "trinity" triggered the following bug error with slab debugging enabled ============================================================================= BUG numa_policy (Not tainted): Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff880146498250-0xffff880146498250. First byte 0x6a instead of 0x6b INFO: Allocated in mpol_new+0xa3/0x140 age=46310 cpu=6 pid=32154 __slab_alloc+0x3d3/0x445 kmem_cache_alloc+0x29d/0x2b0 mpol_new+0xa3/0x140 sys_mbind+0x142/0x620 system_call_fastpath+0x16/0x1b INFO: Freed in __mpol_put+0x27/0x30 age=46268 cpu=6 pid=32154 __slab_free+0x2e/0x1de kmem_cache_free+0x25a/0x260 __mpol_put+0x27/0x30 remove_vma+0x68/0x90 exit_mmap+0x118/0x140 mmput+0x73/0x110 exit_mm+0x108/0x130 do_exit+0x162/0xb90 do_group_exit+0x4f/0xc0 sys_exit_group+0x17/0x20 system_call_fastpath+0x16/0x1b INFO: Slab 0xffffea0005192600 objects=27 used=27 fp=0x (null) flags=0x20000000004080 INFO: Object 0xffff880146498250 @offset=592 fp=0xffff88014649b9d0 This implied a reference counting bug and the problem happened during mbind(). mbind() applies a new memory policy to a range and uses mbind_range() to merge existing VMAs or split them as necessary. In the event of splits, mpol_dup() will allocate a new struct mempolicy and maintain existing reference counts whose rules are documented in Documentation/vm/numa_memory_policy.txt . The problem occurs with shared memory policies. The vm_op->set_policy increments the reference count if necessary and split_vma() and vma_merge() have already handled the existing reference counts. However, policy_vma() screws it up by replacing an existing vma->vm_policy with one that potentially has the wrong reference count leading to a premature free. This patch removes the damage caused by policy_vma(). With this patch applied Dave's trinity tool runs an mbind test for 5 minutes without error. /proc/slabinfo reported that there are no numa_policy or shared_policy_node objects allocated after the test completed and the shared memory region was deleted. Signed-off-by: Mel Gorman <mgorman@suse.de> Cc: Dave Jones <davej@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Stephen Wilson <wilsons@start.ca> Cc: Christoph Lameter <cl@linux.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01workqueue: skip nr_running sanity check in worker_enter_idle() if trustee is ↵Tejun Heo1-2/+7
active commit 544ecf310f0e7f51fa057ac2a295fc1b3b35a9d3 upstream. worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running isn't zero when every worker is idle. This can trigger spuriously while a cpu is going down due to the way trustee sets %WORKER_ROGUE and zaps nr_running. It first sets %WORKER_ROGUE on all workers without updating nr_running, releases gcwq->lock, schedules, regrabs gcwq->lock and then zaps nr_running. If the last running worker enters idle inbetween, it would see stale nr_running which hasn't been zapped yet and trigger the WARN_ON_ONCE(). Fix it by performing the sanity check iff the trustee is idle. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: cdc-wdm: remove from device list on disconnectBjørn Mork1-3/+9
commit 6286d85e8efdb59252d1ceb99a56fa6b0b11526c upstream. Prevents dereferencing an invalid struct usb_interface pointer. Always delete entry from device list whether or not the rest of the device state cleanup is postponed. The device list uses desc->intf as key, and wdm_open will dereference this key while searching for a matching device. A device should not appear in the list unless probe() has succeeded and disconnect() has not finished. Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: cdc-wdm: cannot use dev_printk when device is goneBjørn Mork1-5/+10
commit 6b0b79d38806481c1c8fffa7c5842f3c83679a42 upstream. We cannot dereference a removed USB interface for dev_printk. Use pr_debug instead where necessary. Flush errors are expected if device is unplugged and are therefore best ingored at this point. Move the kill_urbs() call in wdm_release with dev_dbg() for the non disconnect, as we know it has already been called if WDM_DISCONNECTING is set. This does not actually fix anything, but keeps the code more consistent. Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: cdc-wdm: poll must return POLLHUP if device is goneBjørn Mork1-1/+1
commit 616b6937e348ef2b4c6ea5fef2cd3c441145efb0 upstream. Else the poll will be restarted indefinitely in a tight loop, preventing final device cleanup. Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: cdc-wdm: fix memory leakOliver Neukum1-0/+2
commit 2f338c8a1904e2e7aa5a8bd12fb0cf2422d17da4 upstream. cleanup() is not called if the last close() comes after disconnect(). That leads to a memory leak. Rectified by checking for an earlier disconnect() in release() Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01USB: cdc-wdm: sanitize error returnsOliver Neukum1-1/+1
commit 24a85bae5da2b43fed423859c09c5a81ab359473 upstream. wdm_flush() returns unsanitized USB error codes. They must be cleaned up to before being anded to user space Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01docs: update HOWTO for 2.6.x -> 3.x versioningKees Cook1-16/+16
commit 591bfc6bf9e5e25e464fd4c87d64afd5135667c4 upstream. The HOWTO document needed updating for the new kernel versioning. The git URI for -next was updated as well. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-06-01persistent_ram: Fix buffer size clamping during writesAnton Vorontsov1-18/+1
commit 484dd30e016eb425b0de871357fff2c9bb93be45 upstream. This is a longstanding bug, almost unnoticeable when calling persistent_ram_write() for small buffers. But when called for large data buffers, the write routine behaves incorrectly, as the size may never update: instead of clamping the size to the maximum buffer size, buffer_size_add_clamp() returns an error (which is never checked by the write routine, btw). To fix this, we now use buffer_size_add() that actually clamps the size to the max value. Also remove buffer_size_add_clamp(), it is no longer needed. Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org> Acked-by: Colin Cross <ccross@android.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>