summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2010-08-02drm/i915: Hold the spinlock whilst resetting unpin_work along error pathChris Wilson1-8/+12
commit 468f0b44ce4b002ca7d9260f802a341854752c02 upstream. Delay taking the mutex until we need to and ensure that we hold the spinlock when resetting unpin_work on the error path. Also defer the debugging print messages until after we have released the spinlock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02drm/i915: don't queue flips during a flip pending eventJesse Barnes1-0/+11
commit 83f7fd055eb3f1e843803cd906179d309553967b upstream. Hardware will set the flip pending ISR bit as soon as it receives the flip instruction, and (supposedly) clear it once the flip completes (e.g. at the next vblank). If we try to send down a flip instruction while the ISR bit is set, the hardware can become very confused, and we may never receive the corresponding flip pending interrupt, effectively hanging the chip. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02drm/i915: gen3 page flipping fixesJesse Barnes6-9/+46
commit 1afe3e9d4335bf3bc5615e37243dc8fef65dac8f upstream. Gen3 chips have slightly different flip commands, and also contain a bit that indicates whether a "flip pending" interrupt means the flip has been queued or has been completed. So implement support for the gen3 flip command, and make sure we use the flip pending interrupt correctly depending on the value of ECOSKPD bit 0. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: musb: tusb6010: fix compile error with n8x0_defconfigFelipe Balbi1-13/+0
commit 2b795ea00c2bbb077a1199a4d729c8ac03a6bded upstream. Drop the unnecessary empty stubs in tusb6010.c and avoid a compile error when building kernel for n8x0. Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: FTDI: Add support for the RT System VX-7 radio programming cableCorey Minyard2-0/+7
commit fcc6cb789c77ffee31710eec64efeb25f2124f7a upstream. RT Systems has put out bunch of ham radio cables based on the FT232RL chip. Each cable type has a unique PID, this adds one for the Yaesu VX-7 radios. Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: add quirk for Broadcom BT dongleOliver Neukum1-0/+3
commit 63ab71deae67b031045bb28bf8cff45180089f8f upstream. This device needs to be reset when resuming Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: xhci: Set Mult field in endpoint context correctly.Sarah Sharp1-2/+3
commit c30c791c946a14a03e87819eced562ed28711961 upstream. The bmAttributes field of the SuperSpeed Endpoint Companion Descriptor has different meanings, depending on the endpoint type. If the endpoint is isochronous, the bmAttributes field is the maximum number of packets within a service interval that this endpoint supports. If the endpoint is bulk, it's the number of stream IDs this endpoint supports. Only set the Mult field of the xHCI endpoint context using the bmAttributes field if the endpoint is isochronous, and the device is a SuperSpeed device. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: sisusbvga: Fix for USB 3.0Oliver Neukum1-2/+3
commit 20a12f007feee1cfa761b431047271d1141d8031 upstream. Super speed is also fast enough to let sisusbvga operate. Therefor expand the checks. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: adds Artisman USB dongle to list of quirky devicesPaul Mortier1-0/+4
commit 47f19c0eedb377ad1ee8114f464d001ec5f96a69 upstream. When an attempt is made to read the interface strings of the Artisman Watchdog USB dongle (idVendor:idProduct 04b4:0526) an error is written to the dmesg log (uhci_result_common: failed with status 440000) and the dongle resets itself, resulting in a disconnect/reconnect loop. Adding the dongle to the list of devices in quirks.c, with the same quirk Alan Stern's previous patch for the Saitek Cyborg Gold 3D joystick, stops the device from resetting and allows it to be used with no problems. Signed-off-by: Paul Mortier <mortier@btinternet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: Fix USB3.0 Port Speed Downgrade after port resetSarah Sharp1-0/+2
commit 809cd1cb80d7dffe75dc94bc94ef2aab3dadc86a upstream. Without this fix, a USB 3.0 port is downgraded to full speed after a port reset of a configured device. The USB 3.0 terminations will be disabled permanently, and USB 3.0 devices will always enumerate as full speed devices, until the host controller is unplugged (if it is an ExpressCard) or the computer is rebooted. Fajun Chen traced this traced the speed downgrade issue to the port reset and the interpretation of port status in USB hub driver code. The hub code was not testing for the port being a SuperSpeed port, and it fell through to the else case of Full Speed. The following patch adds SuperSpeed mapping from the port status, and fixes the speed downgrade issue. Reported-by: Fajun Chen <fajun.chen@seagate.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: option: Add support for AMOI Skypephone S2Dennis Jansen1-0/+2
commit 7595931c986f50b1e197ce7b881563e36a7d041e upstream. usbserial: Add AMOI Skypephone S2 support. This patch adds support for the AMOI Skypephone S2 to the usbserial module. Tested-by: Dennis Jansen <Dennis.Jansen@web.de> Signed-off-by: Dennis Jansen <Dennis.Jansen@web.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: ftdi_sio: support for Signalyzer tools based on FTDI chipsColin Leitner2-0/+17
commit 77dbd74e16b566e9d5eeb4be18ae3ee7d5902bd3 upstream. ftdi_sio: support for Signalyzer tools based on FTDI chips This patch adds support for the Xverve Signalyzers. Signed-off-by: Colin Leitner <colin.leitner@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: Add PID for Sierra 250U to drivers/usb/serial/sierra.caugust huber1-0/+1
commit 9d72c81d657340e54a260a3b621f4a9f5b33829c upstream. Add VID/PID for Sierra Wireless 250U USB dongle to sierra.c Allows use of 3G radio only Signed-off-by: August Huber <gus@pbx.org> Cc: Elina Pasheva <epasheva@sierrawireless.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: option: add support for 1da5:4518Ömer Sezgin Ugurlu1-0/+2
commit 646d90e2b925578abef5c45853e0b166b6a450bf upstream. Signed-off-by: Omer Sezgin Ugurlu <omer.ugurlu@a-kent.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: MUSB: make non-OMAP platforms build with CONFIG_PM=ySergei Shtylyov1-2/+4
commit 9297688a9257d73956d4bba484d9dd331ca72c25 upstream. Attempt to build MUSB driver with CONFIG_PM=y (e.g. in the OTG mode) on DaVinci results in these link errors: drivers/built-in.o: In function `musb_restore_context': led-triggers.c:(.text+0x714d8): undefined reference to `musb_platform_restore_context' drivers/built-in.o: In function `musb_save_context': led-triggers.c:(.text+0x71788): undefined reference to `musb_platform_save_context' This turned out to be caused by commit 9957dd97ec5e98dd334f87ade1d9a0b24d1f86eb (usb: musb: Fix compile error for omaps for musb_hdrc). Revert it, taking into account the rename of CONFIG_ARCH_OMAP34XX into CONFIG_ARCH_OMAP3 (which that commit fixed in a completely inappropriate way) and the recent addition of OMAP4 support. Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com> Acked-by: Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: musb_core: make disconnect and suspend interrupts work againSergei Shtylyov1-5/+1
commit 7d9645fdca444d53907b22a4b73e3967efe09781 upstream. Commit 1c25fda4a09e8229800979986ef399401053b46e (usb: musb: handle irqs in the order dictated by programming guide) forgot to get rid of the old 'STAGE0_MASK' filter for calling musb_stage0_irq(), so now disconnect and suspend interrupts are effectively ignored... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com> Acked-by: Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: obey the sysfs power/wakeup settingAlan Stern1-10/+3
commit 48826626263d4a61d06fd8c5805da31f925aefa0 upstream. This patch (as1403) is a partial reversion of an earlier change (commit 5f677f1d45b2bf08085bbba7394392dfa586fa8e "USB: fix remote wakeup settings during system sleep"). After hearing from a user, I realized that remote wakeup should be enabled during system sleep whenever userspace allows it, and not only if a driver requests it too. Indeed, there could be a device with no driver, that does nothing but generate a wakeup request when the user presses a button. Such a device should be allowed to do its job. The problem fixed by the earlier patch -- device generating a wakeup request for no reason, causing system suspend to abort -- was also addressed by a later patch ("USB: don't enable remote wakeup by default", accepted but not yet merged into mainline). The device won't be able to generate the bogus wakeup requests because it will be disabled for remote wakeup by default. Hence this reversion will not re-introduce any old problems. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: ehci-mxc: bail out on transceiver problemsWolfram Sang1-3/+10
commit 4c9715de52b9b6256bf1e9510917111a47b0c176 upstream. The old code registered the hcd even if there were no transceivers detected, leading to oopses like this if we try to probe a non-existant ULPI: [ 2.730000] mxc-ehci mxc-ehci.0: unable to init transceiver [ 2.740000] timeout polling for ULPI device [ 2.740000] timeout polling for ULPI device [ 2.750000] mxc-ehci mxc-ehci.0: unable to enable vbus on transceiver [ 2.750000] mxc-ehci mxc-ehci.0: Freescale On-Chip EHCI Host Controller [ 2.760000] mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 2 [ 2.770000] Unhandled fault: external abort on non-linefetch (0x808) at 0xc4876184 [ 2.770000] Internal error: : 808 [#1] PREEMPT [ 2.770000] last sysfs file: [ 2.770000] Modules linked in: [ 2.770000] CPU: 0 Not tainted (2.6.33.5 #5) [ 2.770000] PC is at ehci_hub_control+0x4d4/0x8f8 [ 2.770000] LR is at ehci_mxc_setup+0xbc/0xdc [ 2.770000] pc : [<c0196dfc>] lr : [<c019bc8c>] psr: 00000093 [ 2.770000] sp : c3815e40 ip : 00000001 fp : 60000013 [ 2.770000] r10: c4876184 r9 : 00000000 r8 : c3814000 [ 2.770000] r7 : c391d2cc r6 : 00000001 r5 : 00000001 r4 : 00000000 [ 2.770000] r3 : 80000000 r2 : 00000007 r1 : 80000000 r0 : c4876184 [ 2.770000] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 2.770000] Control: 0005317f Table: a0004000 DAC: 00000017 [ 2.770000] Process swapper (pid: 1, stack limit = 0xc3814270) ... Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Cc: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Daniel Mack <daniel@caiaq.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02usb: musb: Fix a bug by making suspend interrupt available in device modeMaulik Mankad1-1/+2
commit 2bb14cbf04ded4b9e394a6ba9e4f06b82fbac8b2 upstream. As a part of aligning the ISR code for MUSB with the specs, the ISR code was re-written. See Commit 1c25fda4a09e8229800979986ef399401053b46e (usb: musb: handle irqs in the order dictated by programming guide) With this the suspend interrupt came accidently under CONFIG_USB_MUSB_HDRC_HCD. The fix brings suspend interrupt handling outside CONFIG_USB_MUSB_HDRC_HCD. Signed-off-by: Maulik Mankad <x0082077@ti.com> Cc: David Brownell <david-b@pacbell.net> Acked-by: Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: g_serial: fix tty cleanup on unloadJon Povey1-0/+1
commit b23097b793081358a6d943263c91bae4c955c4e3 upstream. Call put_tty_driver() in cleanup function, to fix Oops when trying to open gadget serial char device after module unload. Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: g_serial: don't set low_latency flagJon Povey1-13/+2
commit 44a0c0190b500ee6bcfc0976fe540f65dee2cd67 upstream. No longer set low_latency flag as it causes this warning backtrace: WARNING: at kernel/mutex.c:207 __mutex_lock_slowpath+0x6c/0x288() Fix associated locking and wakeups. Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk> Cc: Maulik Mankad <x0082077@ti.com> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02USB: don't enable remote wakeup by defaultAlan Stern1-1/+0
commit 7aba8d014341341590ecb64050b7a026642a62eb upstream. This patch (as1364) avoids enabling remote wakeup by default on all non-root-hub USB devices. Individual drivers or userspace will have to enable it wherever it is needed, such as for keyboards or network interfaces. Note: This affects only system sleep, not autosuspend. External hubs will continue to relay wakeup requests received from downstream through their upstream port, even when remote wakeup is not enabled for the hub itself. Disabling remote wakeup on a hub merely prevents it from generating wakeup requests in response to connect, disconnect, and overcurrent events. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02x86, i8259: Only register sysdev if we have a real 8259 PICAdam Lackorzynski1-10/+15
commit 087b255a2b43f417af83cb44e0bb02507f36b7fe upstream. My platform makes use of the null_legacy_pic choice and oopses when doing a shutdown as the shutdown code goes through all the registered sysdevs and calls their shutdown method which in my case poke on a non-existing i8259. Imho the i8259 specific sysdev should only be registered if the i8259 is actually there. Do not register the sysdev function when the null_legacy_pic is used so that the i8259 resume, suspend and shutdown functions are not called. Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de> LKML-Reference: <201007202218.o6KMIJ3m020955@imap1.linux-foundation.org> Cc: Jacob Pan <jacob.jun.pan@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02x86: kprobes: fix swapped segment registers in kretprobeRoland McGrath1-1/+1
commit a197479848a2f1a2a5c07cffa6c31ab5e8c82797 upstream. In commit f007ea26, the order of the %es and %ds segment registers got accidentally swapped, so synthesized 'struct pt_regs' frames have the two values inverted. It's almost sure that these values never matter, and that they also never differ. But wrong is wrong. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02x86, pci, mrst: Add extra sanity check in walking the PCI extended cap chainJacob Pan1-3/+4
commit f82c3d71d6fd2e6a3e3416f09099e29087e39abf upstream. The fixed bar capability structure is searched in PCI extended configuration space. We need to make sure there is a valid capability ID to begin with otherwise, the search code may stuck in a infinite loop which results in boot hang. This patch adds additional check for cap ID 0, which is also invalid, and indicates end of chain. End of chain is supposed to have all fields zero, but that doesn't seem to always be the case in the field. Suggested-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <1279306706-27087-1-git-send-email-jacob.jun.pan@linux.intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02x86: Do not try to disable hpet if it hasn't been initialized beforeStefano Stabellini1-1/+1
commit ff4878089e1eaeac79d57878ad4ea32910fb4037 upstream. hpet_disable is called unconditionally on machine reboot if hpet support is compiled in the kernel. hpet_disable only checks if the machine is hpet capable but doesn't make sure that hpet has been initialized. [ tglx: Made it a one liner and removed the redundant hpet_address check ] Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Venkatesh Pallipadi <venki@google.com> LKML-Reference: <alpine.DEB.2.00.1007211726240.22235@kaball-desktop> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ARM: 6226/1: fix kprobe bug in ldr instruction emulationNicolas Pitre1-2/+3
commit 0ebe25f90cd99bb1bcf622ec8a841421d48380d6 upstream. From: Bin Yang <bin.yang@marvell.com> Signed-off-by: Bin Yang <bin.yang@marvell.com> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ARM: 6212/1: atomic ops: add memory constraints to inline asmWill Deacon1-66/+66
commit 398aa66827155ef52bab58bebd24597d90968929 upstream. Currently, the 32-bit and 64-bit atomic operations on ARM do not include memory constraints in the inline assembly blocks. In the case of barrier-less operations [for example, atomic_add], this means that the compiler may constant fold values which have actually been modified by a call to an atomic operation. This issue can be observed in the atomic64_test routine in <kernel root>/lib/atomic64_test.c: 00000000 <test_atomic64>: 0: e1a0c00d mov ip, sp 4: e92dd830 push {r4, r5, fp, ip, lr, pc} 8: e24cb004 sub fp, ip, #4 c: e24dd008 sub sp, sp, #8 10: e24b3014 sub r3, fp, #20 14: e30d000d movw r0, #53261 ; 0xd00d 18: e3011337 movw r1, #4919 ; 0x1337 1c: e34c0001 movt r0, #49153 ; 0xc001 20: e34a1aa3 movt r1, #43683 ; 0xaaa3 24: e16300f8 strd r0, [r3, #-8]! 28: e30c0afe movw r0, #51966 ; 0xcafe 2c: e30b1eef movw r1, #48879 ; 0xbeef 30: e34d0eaf movt r0, #57007 ; 0xdeaf 34: e34d1ead movt r1, #57005 ; 0xdead 38: e1b34f9f ldrexd r4, [r3] 3c: e1a34f90 strexd r4, r0, [r3] 40: e3340000 teq r4, #0 44: 1afffffb bne 38 <test_atomic64+0x38> 48: e59f0004 ldr r0, [pc, #4] ; 54 <test_atomic64+0x54> 4c: e3a0101e mov r1, #30 50: ebfffffe bl 0 <__bug> 54: 00000000 .word 0x00000000 The atomic64_set (0x38-0x44) writes to the atomic64_t, but the compiler doesn't see this, assumes the test condition is always false and generates an unconditional branch to __bug. The rest of the test is optimised away. This patch adds suitable memory constraints to the atomic operations on ARM to ensure that the compiler is informed of the correct data hazards. We have to use the "Qo" constraints to avoid hitting the GCC anomaly described at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492 , where the compiler makes assumptions about the writeback in the addressing mode used by the inline assembly. These constraints forbid the use of auto{inc,dec} addressing modes, so it doesn't matter if we don't use the operand exactly once. Reviewed-by: Nicolas Pitre <nicolas.pitre@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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ARM: 6211/1: atomic ops: fix register constraints for atomic64_add_unlessWill Deacon1-1/+1
commit 068de8d1be48a04b92fd97f76bb7e113b7be82a8 upstream. The atomic64_add_unless function compares an atomic variable with a given value and, if they are not equal, adds another given value to the atomic variable. The function returns zero if the addition did not occur and non-zero otherwise. On ARM, the return value is initialised to 1 in C code. Inline assembly code then performs the atomic64_add_unless operation, setting the return value to 0 iff the addition does not occur. This means that when the addition *does* occur, the value of ret must be preserved across the inline assembly and therefore requires a "+r" constraint rather than the current one of "=&r". Thanks to Nicolas Pitre for helping to spot this. Reviewed-by: Nicolas Pitre <nicolas.pitre@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: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ARM: 6201/1: RealView: Do not use outer_sync() on ARM11MPCore boards with L220Catalin Marinas2-0/+10
commit 2503a5ecd86c002506001eba432c524ea009fe7f upstream. RealView boards with certain revisions of the L220 cache controller (ARM11* processors only) may have issues (hardware deadlock) with the recent changes to the mb() barrier implementation (DSB followed by an L2 cache sync). The patch redefines the RealView ARM11MPCore mandatory barriers without the outer_sync() call. Tested-by: Linus Walleij <linus.walleij@stericsson.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02Input: twl40300-keypad - fix handling of "all ground" rowsDmitry Torokhov2-9/+25
commit 3fea60261e73dbf4a51130d40cafcc8465b0f2c3 upstream. The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c) defines a key map for the matrix keypad keyboard. The hardware seems to use all of the 8 rows and 8 columns of the keypad, although not all possible locations are used. The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys are defined with a row and column number between 0 and 7, except KEY(0xff, 2, KEY_F9), KEY(0xff, 4, KEY_F10), KEY(0xff, 5, KEY_F11), which represent keycodes that should be emitted when entire row is connected to the ground. since the driver handles this case as if we had an extra column in the key matrix. Unfortunately we do not allocate enough space and end up owerwriting some random memory. Reported-and-tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02Input: i8042 - add Gigabyte Spring Peak to dmi_noloop_tableKamal Mostafa1-0/+7
commit 3e1bbc8d5018a05c0793c8a32b777a1396eb4414 upstream. Gigabyte "Spring Peak" notebook indicates wrong chassis-type, tripping up i8042 and breaking the touchpad. Add this model to i8042_dmi_noloop_table[] to resolve. BugLink: https://bugs.launchpad.net/bugs/580664 Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02IPoIB: Fix world-writable child interface control sysfs attributesOr Gerlitz1-2/+2
commit 7a52b34b07122ff5f45258d47f260f8a525518f0 upstream. Sumeet Lahorani <sumeet.lahorani@oracle.com> reported that the IPoIB child entries are world-writable; however we don't want ordinary users to be able to create and destroy child interfaces, so fix them to be writable only by root. Signed-off-by: Or Gerlitz <ogerlitz@voltaire.com> Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02x86: Fix x2apic preenabled system with kexecYinghai Lu1-1/+1
commit fd19dce7ac07973f700b0f13fb7f94b951414a4c upstream. Found one x2apic system kexec loop test failed when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip) first kernel can kexec second kernel, but second kernel can not kexec third one. it can be duplicated on another system with BIOS preenabled x2apic. First kernel can not kexec second kernel. It turns out, when kernel boot with pre-enabled x2apic, it will not execute disable_local_APIC on shutdown path. when init_apic_mappings() is called in setup_arch, it will skip setting of apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic()) Then later, disable_local_APIC() will bail out early because !apic_phys. So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys. another solution could be updating init_apic_mappings() to set apic_phys even for preenabled x2apic system. Actually even for x2apic system, that lapic address is mapped already in early stage. BTW: is there any x2apic preenabled system with apicid of boot cpu > 255? Signed-off-by: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4C3EB22B.3000701@kernel.org> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02Input: gamecon - reference correct pad in gc_psx_command()Dmitry Torokhov1-1/+1
commit c25f7b763cc35a249232ce612a36a811b0e263f9 upstream. Otherwise we won't see any events from the gamepad. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16408 Reported-and-tested-by: Eugene Yudin <eugene.yudin@gmail.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02Input: gamecon - reference correct input device in NES modeDmitry Torokhov1-2/+1
commit 7b5d3312fbfbb21d2fc7de94e0db66cfdf8b0055 upstream. We moved input devices from 'struct gc' to individial pads (struct gc-pad), but gc_nes_process_packet() was still trying to use old ones and crashing. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02x86,nobootmem: make alloc_bootmem_node fall back to other node when 32bit ↵Yinghai Lu2-4/+23
numa is used commit b8ab9f82025adea77864115da73e70026fa4f540 upstream. Borislav Petkov reported his 32bit numa system has problem: [ 0.000000] Reserving total of 4c00 pages for numa KVA remap [ 0.000000] kva_start_pfn ~ 32800 max_low_pfn ~ 375fe [ 0.000000] max_pfn = 238000 [ 0.000000] 8202MB HIGHMEM available. [ 0.000000] 885MB LOWMEM available. [ 0.000000] mapped low ram: 0 - 375fe000 [ 0.000000] low ram: 0 - 375fe000 [ 0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 1000 1000 => 34e7000 [ 0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 200 40 => 34c9d80 [ 0.000000] alloc (nid=0 100000 - 7ee00000) (1000000 - ffffffffffffffff) 180 40 => 34e6140 [ 0.000000] alloc (nid=1 80000000 - c7e60000) (1000000 - ffffffffffffffff) 240 40 => 80000000 [ 0.000000] BUG: unable to handle kernel paging request at 40000000 [ 0.000000] IP: [<c2c8cff1>] __alloc_memory_core_early+0x147/0x1d6 [ 0.000000] *pdpt = 0000000000000000 *pde = f000ff53f000ff00 ... [ 0.000000] Call Trace: [ 0.000000] [<c2c8b4f8>] ? __alloc_bootmem_node+0x216/0x22f [ 0.000000] [<c2c90c9b>] ? sparse_early_usemaps_alloc_node+0x5a/0x10b [ 0.000000] [<c2c9149e>] ? sparse_init+0x1dc/0x499 [ 0.000000] [<c2c79118>] ? paging_init+0x168/0x1df [ 0.000000] [<c2c780ff>] ? native_pagetable_setup_start+0xef/0x1bb looks like it allocates too much high address for bootmem. Try to cut limit with get_max_mapped() Reported-by: Borislav Petkov <borislav.petkov@amd.com> Tested-by: Conny Seidel <conny.seidel@amd.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Mel Gorman <mel@csn.ul.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ASoC: Remove duplicate AUX definition from WM8776Mark Brown1-1/+0
commit 3c0709396df0869786f83e4b2d2d687c70ee886d upstream. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02edac: mpc85xx: fix MPC85xx dependencyAnton Vorontsov1-1/+1
commit 1cd8521e7d77def75fdb1cb35ecd135385e4be4f upstream. Since commit 5753c082f66eca5be81f6bda85c1718c5eea6ada ("powerpc/85xx: Kconfig cleanup"), there is no MPC85xx Kconfig symbol anymore, so the driver became non-selectable. This patch fixes the issue by switching to PPC_85xx symbol. Signed-off-by: Anton Vorontsov <avorontsov@mvista.com> Cc: Doug Thompson <dougthompson@xmission.com> Cc: Peter Tyser <ptyser@xes-inc.com> Cc: Dave Jiang <djiang@mvista.com> Cc: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02virtio: fix oops on OOMMichael S. Tsirkin1-2/+3
commit 1fe9b6fef11771461e69ecd1bc8935a1c7c90cb5 upstream. virtio ring was changed to return an error code on OOM, but one caller was missed and still checks for vq->vring.num. The fix is just to check for <0 error code. Long term it might make sense to change goto add_head to just return an error on oom instead, but let's apply a minimal fix for 2.6.35. Reported-by: Chris Mason <chris.mason@oracle.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Tested-by: Chris Mason <chris.mason@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02virtio_net: fix oom handling on txRusty Russell1-8/+13
commit 58eba97d0774c69b1cf3e5a8ac74419409d1abbf upstream. virtio net will never try to overflow the TX ring, so the only reason add_buf may fail is out of memory. Thus, we can not stop the device until some request completes - there's no guarantee anything at all is outstanding. Make the error message clearer as well: error here does not indicate queue full. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02sdhci-s3c: add missing remove functionMarek Szyprowski1-0/+20
commit 9d51a6b2487724e8713cd2794cf09ffeee5f6932 upstream. System will crash sooner or later once the memory with the code of the s3c-sdhci.ko module is reused for something else. I really have no idea how the lack of remove function went unnoticed into the mainline code. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02kmemleak: Add support for NO_BOOTMEM configurationsCatalin Marinas2-0/+11
commit 9078370c0d2cfe4a905aa34f398bbb0d65921a2b upstream. With commits 08677214 and 59be5a8e, alloc_bootmem()/free_bootmem() and friends use the early_res functions for memory management when NO_BOOTMEM is enabled. This patch adds the kmemleak calls in the corresponding code paths for bootmem allocations. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02powerpc/cpm1: Fix build with various CONFIG_*_UCODE_PATCH combinationsAnton Vorontsov1-0/+5
commit 2069a6ae19a34d96cc9cb284eb645b165138e03f upstream. Warnings are treated as errors for arch/powerpc code, so build fails with CONFIG_I2C_SPI_UCODE_PATCH=y: CC arch/powerpc/sysdev/micropatch.o cc1: warnings being treated as errors arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch': arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp' make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1 And with CONFIG_USB_SOF_UCODE_PATCH=y: CC arch/powerpc/sysdev/micropatch.o cc1: warnings being treated as errors arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch': arch/powerpc/sysdev/micropatch.c:629: warning: unused variable 'spp' arch/powerpc/sysdev/micropatch.c:628: warning: unused variable 'iip' make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1 This patch fixes these issues by introducing proper #ifdefs. Signed-off-by: Anton Vorontsov <avorontsov@mvista.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02powerpc/cpm: Reintroduce global spi_pram struct (fixes build issue)Anton Vorontsov3-25/+28
commit 56825c88ff438f4dbb51a44591cc29e707fe783a upstream. spi_t was removed in commit 644b2a680ccc51a9ec4d6beb12e9d47d2dee98e2 ("powerpc/cpm: Remove SPI defines and spi structs"), the commit assumed that spi_t isn't used anywhere outside of the spi_mpc8xxx driver. But it appears that the struct is needed for micropatch code. So, let's reintroduce the struct. Fixes the following build issue: CC arch/powerpc/sysdev/micropatch.o micropatch.c: In function 'cpm_load_patch': micropatch.c:629: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token micropatch.c:629: error: 'spp' undeclared (first use in this function) micropatch.c:629: error: (Each undeclared identifier is reported only once micropatch.c:629: error: for each function it appears in.) Reported-by: LEROY Christophe <christophe.leroy@c-s.fr> Reported-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02powerpc: Fix logic error in fixup_irqsJohannes Berg1-1/+4
commit 3cd8519248e9e17d982c6fab0f1a89bca6feb49a upstream. When SPARSE_IRQ is set, irq_to_desc() can return NULL. While the code here has a check for NULL, it's not really correct. Fix it by separating the check for it. This fixes CPU hot unplug for me. Reported-by: Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ethtool: Fix potential kernel buffer overflow in ETHTOOL_GRXCLSRLALLBen Hutchings1-2/+3
commit db048b69037e7fa6a7d9e95a1271a50dc08ae233 upstream. On a 32-bit machine, info.rule_cnt >= 0x40000000 leads to integer overflow and the buffer may be smaller than needed. Since ETHTOOL_GRXCLSRLALL is unprivileged, this can presumably be used for at least denial of service. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ata_generic: implement ATA_GEN_* flags and force enable DMA on MBP 7,1Tejun Heo1-7/+19
commit 1529c69adce1e95f7ae72f0441590c226bbac7fc upstream. IDE mode of MCP89 on MBP 7,1 doesn't set DMA enable bits in the BMDMA status register. Make the following changes to work around the problem. * Instead of using hard coded 1 in id->driver_data as class code match, use ATA_GEN_CLASS_MATCH and carry the matched id in host->private_data. * Instead of matching PCI_VENDOR_ID_CENATEK, use ATA_GEN_FORCE_DMA flag in id instead. * Add ATA_GEN_FORCE_DMA to the id entry of MBP 7,1. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Peer Chen <pchen@nvidia.com> Reported-by: Anders Østhus <grapz666@gmail.com> Reported-by: Andreas Graf <andreas_graf@csgraf.de> Reported-by: Benoit Gschwind <gschwind@gnu-log.net> Reported-by: Damien Cassou <damien.cassou@gmail.com> Reported-by: tixetsal@juno.com Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02ahci,ata_generic: let ata_generic handle new MBP w/ MCP89Tejun Heo3-0/+17
commit c6353b4520788e34098bbf61c73fb9618ca7fdd6 upstream. For yet unknown reason, MCP89 on MBP 7,1 doesn't work w/ ahci under linux but the controller doesn't require explicit mode setting and works fine with ata_generic. Make ahci ignore the controller on MBP 7,1 and let ata_generic take it for now. Reported in bko#15923. https://bugzilla.kernel.org/show_bug.cgi?id=15923 NVIDIA is investigating why ahci mode doesn't work. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Peer Chen <pchen@nvidia.com> Reported-by: Anders Østhus <grapz666@gmail.com> Reported-by: Andreas Graf <andreas_graf@csgraf.de> Reported-by: Benoit Gschwind <gschwind@gnu-log.net> Reported-by: Damien Cassou <damien.cassou@gmail.com> Reported-by: tixetsal@juno.com Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-02rtc: fix ds1388 time corruptionJoakim Tjernlund1-2/+2
commit 96fc3a45ea073136566f3c2676cad52f8b39a7df upstream. The ds1307 driver misreads the ds1388 registers when checking for 12 or 24 hour mode. Instead of checking the hour register it reads the minute register. Therefore the driver thinks minutes >= 40 has the 12HR bit set and resets the minute register by zeroing the high bits. This results in minutes are reset to 0-9, jumping back in time 40 or 50 minutes. The time jump is also written back to the RTC. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Cc: Wan ZongShun <mcuos.com@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-15 05:58:51 +0300