- 09 Jun, 2012 2 commits
-
-
Lars-Peter Clausen authored
commit 59516b07 upstream. The microblaze architecture does not provide a native GPIO API implementation nor requires GPIOLIB, but still selects GENERIC_GPIO by default. As a result the following build error occurs, if GPIOLIB is not selected: include/asm-generic/gpio.h: In function 'gpio_get_value_cansleep': include/asm-generic/gpio.h:218: error: implicit declaration of function '__gpio_get_value' include/asm-generic/gpio.h: In function 'gpio_set_value_cansleep': include/asm-generic/gpio.h:224: error: implicit declaration of function '__gpio_set_value' This patch addresses the issue by not selecting GENERIC_GPIO by default. This causes the GPIO API to be stubbed out if no implementation is provided. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Tested-by:
Michal Simek <monstr@monstr.eu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Boaz Harrosh authored
commit 6abe4a87 upstream. If at exofs_fill_super() we had an early termination do to any error, like an IO error while reading the super-block. We would crash inside exofs_free_sbi(). This is because sbi->oc.numdevs was set to 1, before we actually have a device table at all. Fix it by moving the sbi->oc.numdevs = 1 to after the allocation of the device table. Reported-by:
Johannes Schild <JSchild@gmx.de> Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
- 01 Jun, 2012 38 commits
-
-
Greg Kroah-Hartman authored
-
Laxman Dewangan authored
commit c889e91d upstream. The notification of the transfer complete by calling complete() should be done after clearing all interrupt status. This avoids the race condition of misconfigure the i2c controller in multi-core environment. Signed-off-by:
Laxman Dewangan <ldewangan@nvidia.com> Acked-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
-
Marcus Folkesson authored
commit 9868a060 upstream. The freed IRQ is not necessary the one requested in probe. Even if it was, with two or more i2c-controllers it will fails anyway. Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by:
-
Andi Kleen authored
commit a129a7c8 upstream. When running on 32bit the mce handler could misinterpret vm86 mode as ring 0. This can affect whether it does recovery or not; it was possible to panic when recovery was actually possible. Fix this by always forcing vm86 to look like ring 3. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Stephen Warren authored
commit 1dfebb42 upstream. Cardhu's eMMC controller is on sdhci@78000600, not sdhci@78000400. Fix the typo. This roughly doubles the IO performance, since the support-8bit property actually takes effect. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Dima Zavin authored
commit 435a7ef5 upstream. We can't be holding the mmap_sem while calling flush_cache_user_range because the flush can fault. If we fault on a user address, the page fault handler will try to take mmap_sem again. Since both places acquire the read lock, most of the time it succeeds. However, if another thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in between the call to flush_cache_user_range and the fault, the down_read in do_page_fault will deadlock. [will: removed drop of vma parameter as already queued by rmk (7365/1)] Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Dima Zavin <dima@android.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Dima Zavin authored
commit 4542b6a0 upstream. vma isn't used and flush_cache_user_range isn't a standard macro that is used on several archs with the same prototype. In fact only unicore32 has a macro with the same name (with an identical implementation and no in-tree users). This is a part of a patch proposed by Dima Zavin (with Message-id: 1272439931-12795-1-git-send-email-dima@android.com) that didn't get accepted. Cc: Dima Zavin <dima@android.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Dan Carpenter authored
commit fefe1ed1 upstream. fault_reason - 0x20 == ARRAY_SIZE(irq_remap_fault_reasons) is one past the end of the array. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Joerg Roedel <joerg.roedel@amd.com> Cc: Youquan Song <youquan.song@intel.com> Cc: walter harms <wharms@bfs.de> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Link: http://lkml.kernel.org/r/20120513170938.GA4280@elgon.mountainSigned-off-by:
Ingo Molnar <mingo@kernel.org> [bwh: Backported to 3.2: s/irq_remap_fault_reasons/intr_remap_fault_reasons/] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
David Woodhouse authored
commit e2ad23d0 upstream. Add device info into list before doing context mapping, because device info will be used by iommu_enable_dev_iotlb(). Without it, ATS won't get enabled as it should be. ATS, while a dubious decision from a security point of view, can be very important for performance. Signed-off-by:
Xudong Hao <xudong.hao@intel.com> Signed-off-by:
Xiantao Zhang <xiantao.zhang@intel.com> Acked-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Chris Metcalf authored
commit 9f1d62be upstream. This is because __builtin_clz(0) returns 64 for the "undefined" case of 0, since the builtin just does a right-shift 32 and "clz" instruction. So, use the alpha approach of casting to u32 and using __builtin_clzll(). Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Ming Lei authored
commit db35f83e upstream. The flag of IRQF_ONESHOT should be passed to request_threaded_irq, otherwise the following failure message should be dumped because hardware handler is defined as NULL: [ 3.383483] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 368 [ 3.392730] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 The patch fixes one kernel hang bug which is caused by mmc card probe failure and root device can't be brought up. Signed-off-by:
Ming Lei <ming.lei@canonical.com> Acked-by:
Venkatraman S <svenkatr@ti.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Guennadi Liakhovetski authored
commit 0e9f480b upstream. Do not oops, even if mmc_cd_gpio_free() is mistakenly called on a driver cleanup path, even though a previous call to mmc_cd_gpio_request() failed. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> [stable@: please apply to 3.3-stable] Signed-off-by:
-
Nicolas Pitre authored
commit bbbc4c4d upstream. Commit 06e8935f ("optimized SDIO IRQ handling for single irq") introduced some spurious calls to SDIO function interrupt handlers, such as when the SDIO IRQ thread is started, or the safety check performed upon a system resume. Let's add a flag to perform the optimization only when a real interrupt is signaled by the host driver and we know there is no point confirming it. Reported-by:
Sujit Reddy Thumma <sthumma@codeaurora.org> Signed-off-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
-
Tony Luck authored
commit 875e2664 upstream. Linus pointed out that there was no value is checking whether m->ip was zero - because zero is a legimate value. If we have a reliable (or faked in the VM86 case) "m->cs" we can use it to tell whether we were in user mode or kernelwhen the machine check hit. Reported-by:
Linus Torvalds <torvalds@linuxfoundation.org> Signed-off-by:
-
H. Peter Anvin authored
commit ea17e741 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.auReported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
H. Peter Anvin authored
commit fd952815 upstream. As noted in checkin: a3e854d9 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:
-
Jarkko Sakkinen authored
commit b2d668da 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.comSigned-off-by:
-
Laurent Pinchart authored
commit 31c5f0c5 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:
-
Michael Krufky authored
commit 4d1b58b8 upstream. Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Dave Airlie authored
commit c284815d 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:
-
Stefano Stabellini authored
commit 68c2c39a 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:
-
Dan Carpenter authored
commit 201a52be 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:
-
Herton Ronaldo Krzesinski authored
commit 067aa481 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 5039a869, "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:
-
Thomas Gleixner authored
commit d6de85e8 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:
-
Daniel Vetter authored
commit a9dcf84b upstream. ... we need it later on in the function to clean up pipe <-> plane associations. This regression has been introduced in commit f47166d2 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:
-
Ben Widawsky authored
commit a1e969e0 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:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Chris Wilson authored
commit 9adab8b5 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:
-
Larry Finger authored
commit 8f4b2038 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:
-
Alan Cox authored
commit 7beff62e upstream. Reported-by:
Guillaume Clément <guillaume@baobob.org> Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Andiry Xu authored
commit c3e751e4 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 65580b43 "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:
-
Oliver Neukum authored
commit f8a9e72d 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 c29eea62 "xhci: Implement HS/FS/LS bandwidth checking." and commit 839c817c "xhci: Implement HS/FS/LS bandwidth checking." Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Sarah Sharp authored
commit 1530bbc6 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 f5182b41 "xhci: Disable MSI for some Fresco Logic hosts." That commit was marked for stable kernels as old as 2.6.36. Signed-off-by:
Sergio Correia <lists@uece.net> Tested-by:
-
Sarah Sharp authored
commit 33b2831a 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 913a8a34 "USB: xhci: Change how xHCI commands are handled." Signed-off-by:
-
Hans de Goede authored
commit 9c745995 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 04e51901 "USB: xHCI: Isochronous transfer implementation". Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Sarah Sharp authored
commit 51c9e6c7 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 69e848c2 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by:
Eric Anholt <eric.anholt@intel.com> Reported-by:
David Bein <d.bein@f5.com> Signed-off-by:
-
Andiry Xu authored
commit f370b996 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 879d38e6 "USB: fix race between root-hub suspend and remote wakeup". Signed-off-by:
Andiry Xu <andiry.xu@amd.com> Signed-off-by:
-
Sarah Sharp authored
commit 1c12443a 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 69e848c2 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by:
-
Steffen Müller authored
commit 166cb70e upstream. Tested-by:
Steffen Müller <steffen.mueller@radio-frei.de> Signed-off-by:
Stefan Seyfried <seife+kernel@b1-systems.com> Signed-off-by:
-
