“58602c1681bdfa1a0deaa5574b8a72d6e30c0e97”上不存在“README.md”
- 11 9月, 2012 2 次提交
-
-
由 Daniel Vetter 提交于
This has been added in commit de9a35ab Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jun 5 11:03:40 2012 +0200 drm/i915: assert that the IBX port transcoder select w/a is implemented Unfortunately I've failed to notice that these checks are not just called for the port that is about to be disabled, but for all (which makes sense for an assert ...), and the WARN missfired when disabling another pipe than the one with the dp port. Hence also check whether the port is actually disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54688Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Currently we've only frobbed this bit at irq_init time, but did not restore it at resume time. Move it to the gen3 clock gating function to fix this. Notice while reading through code. Cc: stable@vger.kernel.org (for 3.5 only) Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 9月, 2012 3 次提交
-
-
由 Jean Delvare 提交于
If kernel is compiled with CONFIG_PROVE_LOCKING the validator raises an error when a multiplexer is removed via sysfs and sub-clients are connected to it. This is a false positive. Documentation/lockdep-design.txt recommends to handle this via calls to mutex_lock_nested(). Based on an earlier fix from Michael Lawnick. Note that the extra code resolves to nothing unless CONFIG_DEBUG_LOCK_ALLOC=y. Signed-off-by: NJean Delvare <khali@linux-fr.org> Cc: Michael Lawnick <ml.lawnick@gmx.de>
-
由 Axel Lin 提交于
This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI select I2C_DESIGNWARE_CORE. Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as built-in or module, we also need to export the functions in i2c-designware-core. This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y: LD drivers/i2c/busses/built-in.o drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int': i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init': i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl': i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr': i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer': i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled': i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel': i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg': i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable': i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param': i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable': i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func': i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int': i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int' drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here make[3]: *** [drivers/i2c/busses/built-in.o] Error 1 make[2]: *** [drivers/i2c/busses] Error 2 make[1]: *** [drivers/i2c] Error 2 make: *** [drivers] Error 2 Signed-off-by: NAxel Lin <axel.lin@gmail.com> Signed-off-by: NJean Delvare <khali@linux-fr.org> Tested-by: NJiri Slaby <jslaby@suse.cz> Cc: stable@vger.kernel.org [3.2+]
-
由 James Ralston 提交于
Add the SMBus Device IDs for the Intel Lynx Point-LP PCH. Signed-off-by: NJames Ralston <james.d.ralston@intel.com> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
- 09 9月, 2012 1 次提交
-
-
由 Alexander Shishkin 提交于
This thing is killing lockdep. Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> [Jani: move the init next to the other spin lock inits] Signed-off-by: NJani Nikula <jani.nikula@intel.com> Acked-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 9月, 2012 4 次提交
-
-
由 Andres Freund 提交于
c1dcad2d added a new driver configured by HID_LENOVO_TPKBD but made the hid_have_special_driver entry non-optional which lead to a recognized but non-working device if the new driver wasn't configured (which is the correct default). Signed-off-by: NAndres Freund <andres@anarazel.de> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Dave Airlie 提交于
This will cause udev to load vmwgfx instead of waiting for X to do it. Reviewed-by: NJakob Bornecrantz <jakob@vmware.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This makes things easier for distros where we'd like to have fbcon enabled all the time. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ben Collins 提交于
In 3.6-rc3, without this patch, the following error occurs with a modular build: ERROR: "gen_split_key" [drivers/crypto/caam/caamhash.ko] undefined! ERROR: "gen_split_key" [drivers/crypto/caam/caamalg.ko] undefined! Signed-off-by: NBen Collins <ben.c@servergy.com> Cc: Yuan Kang <Yuan.Kang@freescale.com> Acked-by: NKim Phillips <kim.phillips@freescale.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 06 9月, 2012 3 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
When we do FLR and save PCI config we did it in the wrong order. The end result was that if a PCI device was unbind from its driver, then binded to xen-pciback, and then back to its driver we would get: > lspci -s 04:00.0 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 13:42:12 # 4 :~/ > echo "0000:04:00.0" > /sys/bus/pci/drivers/pciback/unbind > modprobe e1000e e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k e1000e: Copyright(c) 1999 - 2012 Intel Corporation. e1000e 0000:04:00.0: Disabling ASPM L0s L1 e1000e 0000:04:00.0: enabling device (0000 -> 0002) xen: registering gsi 48 triggering 0 polarity 1 Already setup the GSI :48 e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode e1000e: probe of 0000:04:00.0 failed with error -2 This fixes it by first saving the PCI configuration space, then doing the FLR. Reported-by: NRen, Yongjie <yongjie.ren@intel.com> Reported-and-Tested-by: NTobias Geiger <tobias.geiger@vido.info> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: stable@vger.kernel.org
-
由 Alan Cox 提交于
Allocate a structure not a pointer to it ! Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Keith Packard 提交于
Most of the DRM drivers appear to be missing the .compat_ioctl file operation entry necessary for 32-bit application compatibility. This patch uses drm_compat_ioctl for all drivers which don't have their own, and which are using drm_ioctl for .unlocked_ioctl. This leaves drivers/gpu/drm/psb/psb_drv.c unchanged; it has a custom .unlocked_ioctl and will presumably need a custom .compat_ioctl as well. Signed-off-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NDave Airlie <airlied@gmail.com>
-
- 05 9月, 2012 12 次提交
-
-
由 Ronny Hegewald 提交于
When running 32-bit pvops-dom0 and a driver tries to allocate a coherent DMA-memory the xen swiotlb-implementation returned memory beyond 4GB. The underlaying reason is that if the supplied driver passes in a DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff) our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits. By using the dma_alloc_coherent_mask function - it does the proper casting and we get 0xfffffffff. This caused not working sound on a system with 4 GB and a 64-bit compatible sound-card with sets the DMA-mask to 64bit. On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent DMA-memory is always allocated inside the 32-bit address-range by calling dma_alloc_coherent_mask. This patch adds the same functionality to xen swiotlb and is a rebase of the original patch from Ronny Hegewald which never got upstream b/c the underlaying reason was not understood until now. The original email with the original patch is in: http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html the original thread from where the discussion started is in: http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.htmlSigned-off-by: NRonny Hegewald <ronny.hegewald@online.de> Signed-off-by: NStefano Panella <stefano.panella@citrix.com> Acked-By: NDavid Vrabel <david.vrabel@citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: stable@vger.kernel.org
-
由 Paul Walmsley 提交于
After commit 26b88520 ("mmc: omap_hsmmc: remove private DMA API implementation"), the Nokia N800 here stopped booting: [ 2.086181] Waiting for root device /dev/mmcblk0p1... [ 2.324066] Unhandled fault: imprecise external abort (0x406) at 0x00000000 [ 2.331451] Internal error: : 406 [#1] ARM [ 2.335784] Modules linked in: [ 2.339050] CPU: 0 Not tainted (3.6.0-rc3 #60) [ 2.344146] PC is at default_idle+0x28/0x30 [ 2.348602] LR is at trace_hardirqs_on_caller+0x15c/0x1b0 ... This turned out to be due to memory corruption caused by long-broken PIO code in drivers/mmc/host/omap.c. (Previously, this driver had been using DMA; but the above commit caused the MMC driver to fall back to PIO mode with an unmodified Kconfig.) The PIO code, added with the rest of the driver in commit 730c9b7e ("[MMC] Add OMAP MMC host driver"), confused bytes with 16-bit words. This bug caused memory located after the PIO transfer buffer to be corrupted with transfers larger than 32 bytes. The driver also did not increment the buffer pointer after the transfer occurred. This bug resulted in data corruption during any transfer larger than 64 bytes. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Reviewed-by: NFelipe Balbi <balbi@ti.com> Tested-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ian Chen 提交于
For several MoviNAND eMMC parts, there are known issues with secure erase and secure trim. For these specific MoviNAND devices, we skip these operations. Specifically, there is a bug in the eMMC firmware that causes unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE enabled. References: http://forum.xda-developers.com/showthread.php?t=1644364 https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkBSigned-off-by: NIan Chen <ian.cy.chen@samsung.com> Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Cc: stable <stable@vger.kernel.org> [3.0+] Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Doug Anderson 提交于
The documentation for the dw_mmc part says that the low power mode should normally only be set for MMC and SD memory and should be turned off for SDIO cards that need interrupts detected. The best place I could find to do this is when the SDIO interrupt was first enabled. I rely on the fact that dw_mci_setup_bus() will be called when it's time to reenable. Signed-off-by: NDoug Anderson <dianders@chromium.org> Acked-by: NSeungwon Jeon <tgih.jun@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Seungwon Jeon 提交于
Data transfer will be continued until all the bytes are transmitted, even if data crc error occurs during a multiple-block data transfer. This means RXDR/TXDR interrupts will occurs until data transfer is terminated. Early setting of host->sg to NULL prevents going into xxx_data_pio functions, hence permanent unhandled RXDR/TXDR interrupts occurs. And checking error interrupt status in the xxx_data_pio functions is no need because dw_mci_interrupt does do the same. This patch also removes it. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Acked-by: NWill Newton <will.newton@imgtec.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Seungwon Jeon 提交于
Datasheet of SYNOPSYS mentions that DTO(Data Transfer Over) interrupt will be raised even if some error interrupts, however it is actually found that DTO does not occur. SYNOPSYS has confirmed this issue. Current implementation defers the call of tasklet_schedule until DTO when the error interrupts is happened. This patch fixes error handling. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Acked-by: NWill Newton <will.newton@imgtec.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Seungwon Jeon 提交于
RINTSTS status includes masked interrupts as well as unmasked. data_status and cmd_status are set by value of RINTSTS in interrupt handler and tasklet finally uses it to decide whether error is happened or not. In addition, MINTSTS status is used for setting data_status in PIO. Masked error interrupt will not be handled and that status can be considered non-error case. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Reviewed By: Girish K S <girish.shivananjappa@linaro.org> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Acked-by: NWill Newton <will.newton@imgtec.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ludovic Desroches 提交于
Even if the datasheet says that the not busy flag has to be used only for write operations, it's false except for version lesser than v2xx. Not waiting on the not busy flag for read operations can cause the controller to hang-up during the initialization of some SD cards with DMA after the first CMD6 -- the next command is sent too early. Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com> Cc: stable <stable@vger.kernel.org> [3.5, 3.6] Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Shawn Guo 提交于
Since commit 30832ab5 ("mmc: sdhci: Always pass clock request value zero to set_clock host op") was merged, esdhc_set_clock starts hitting "if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated. This causes SDHCI card-detection function being broken. Fix the regression by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation. Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Lauri Hintsala 提交于
Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_enable_sdio_irq. Backtrace: [ 65.470000] ============================================= [ 65.470000] [ INFO: possible recursive locking detected ] [ 65.470000] 3.5.0-rc5 #2 Not tainted [ 65.470000] --------------------------------------------- [ 65.470000] ksdioirqd/mmc0/73 is trying to acquire lock: [ 65.470000] (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] but task is already holding lock: [ 65.470000] (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] other info that might help us debug this: [ 65.470000] Possible unsafe locking scenario: [ 65.470000] [ 65.470000] CPU0 [ 65.470000] ---- [ 65.470000] lock(&(&host->lock)->rlock#2); [ 65.470000] lock(&(&host->lock)->rlock#2); [ 65.470000] [ 65.470000] *** DEADLOCK *** [ 65.470000] [ 65.470000] May be due to missing lock nesting notation [ 65.470000] [ 65.470000] 1 lock held by ksdioirqd/mmc0/73: [ 65.470000] #0: (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc] [ 65.470000] [ 65.470000] stack backtrace: [ 65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) [ 65.470000] [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) from [<c005d3f8>] (lock_acquire+0xa0/0x108) [ 65.470000] [<c005d3f8>] (lock_acquire+0xa0/0x108) from [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) [ 65.470000] [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) [ 65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) [ 65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) [ 65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98) [ 65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8) [ 65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73 [ 65.470000] lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0 [ 65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) [ 65.470000] [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) from [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) [ 65.470000] [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) [ 65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) [ 65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) [ 65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98) [ 65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8) Reported-by: NAttila Kinali <attila@kinali.ch> Signed-off-by: NLauri Hintsala <lauri.hintsala@bluegiga.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Lauri Hintsala 提交于
Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler. Backtrace: [ 79.660000] ============================================= [ 79.660000] [ INFO: possible recursive locking detected ] [ 79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted [ 79.660000] --------------------------------------------- [ 79.660000] swapper/0 is trying to acquire lock: [ 79.660000] (&(&host->lock)->rlock#2){-.....}, at: [<c026ea3c>] mxs_mmc_enable_sdio_irq+0x18/0xd4 [ 79.660000] [ 79.660000] but task is already holding lock: [ 79.660000] (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8 [ 79.660000] [ 79.660000] other info that might help us debug this: [ 79.660000] Possible unsafe locking scenario: [ 79.660000] [ 79.660000] CPU0 [ 79.660000] ---- [ 79.660000] lock(&(&host->lock)->rlock#2); [ 79.660000] lock(&(&host->lock)->rlock#2); [ 79.660000] [ 79.660000] *** DEADLOCK *** [ 79.660000] [ 79.660000] May be due to missing lock nesting notation [ 79.660000] [ 79.660000] 1 lock held by swapper/0: [ 79.660000] #0: (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8 [ 79.660000] [ 79.660000] stack backtrace: [ 79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) [ 79.660000] [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) from [<c005fea0>] (lock_acquire+0xe0/0xf8) [ 79.660000] [<c005fea0>] (lock_acquire+0xe0/0xf8) from [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) [ 79.660000] [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) [ 79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) [ 79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) [ 79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c) [ 79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110) [ 79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50) [ 79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84) [ 79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60) [ 79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40) [ 79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc) [ 79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8) [ 79.660000] BUG: spinlock lockup on CPU#0, swapper/0 [ 79.660000] lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [ 79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) [ 79.660000] [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) from [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) [ 79.660000] [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) [ 79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) [ 79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) [ 79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c) [ 79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110) [ 79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50) [ 79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84) [ 79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60) [ 79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40) [ 79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc) [ 79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8) Signed-off-by: NLauri Hintsala <lauri.hintsala@bluegiga.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Sonic Zhang 提交于
Descriptor array structure has been moved into blackfin dma.h head file. This patch fix below error: drivers/mmc/host/bfin_sdh.c:52:8: error: redefinition of 'struct dma_desc_array' make[4]: *** [drivers/mmc/host/bfin_sdh.o] Error 1 Signed-off-by: NSonic Zhang <sonic.zhang@analog.com> Signed-off-by: NBob Liu <lliubbo@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 04 9月, 2012 2 次提交
-
-
由 Artem Bityutskiy 提交于
UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened only when we were doing auto-format, so many systems were unaffected. However, there are still many users affected. It is strange, but the system did not crash and nothing bad happened when the SLUB memory allocator was used. However, in case of SLOB we observed an crash right away. This problem was introduced in 2.6.39 by commit "6c1e875c UBI: add slab cache for ubi_scan_leb objects" A note for stable trees: Because variable were renamed, this won't cleanly apply to older kernels. Changing names like this should help: 1. ai -> si 2. aeb_slab_cache -> seb_slab_cache 3. new_aeb -> new_seb Reported-by: NRichard Genoud <richard.genoud@gmail.com> Tested-by: NRichard Genoud <richard.genoud@gmail.com> Tested-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: stable@vger.kernel.org [v2.6.39+] Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
-
由 Jani Nikula 提交于
Previously intel_panel_setup_backlight() would create a sysfs backlight interface with max brightness of 1 if it was unable to figure out the max backlight brightness. This rendered the backlight interface useless. Do not create a dysfunctional backlight interface to begin with. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Tested-by: NDavid Woodhouse <David.Woodhouse@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 03 9月, 2012 3 次提交
-
-
由 Jani Nikula 提交于
Avoid constant wakeups caused by noisy irq lines when we don't even care about the irq. This should be particularly useful for i945g/gm where the hotplug has been disabled: commit 768b107e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri May 4 11:29:56 2012 +0200 drm/i915: disable sdvo hotplug on i945g/gm v2: While at it, remove the bogus hotplug_active read, and do not mask hotplug_active[0] before checking whether the irq is needed, per discussion with Daniel on IRC. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442Tested-by: NDominik Köppl <dominik@devwork.org> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Dave Airlie 提交于
In order to setup the i2c channel, we power up the panel via ironlake_edp_panel_vdd_on, however it requires intel_dp->panel_power_up_delay to be initialised, which hasn't been setup yet. So move things around so we set the panel power up values first then init the i2c stuff. This is one step to fixing the eDP panel in the MBP from uninitialised state. Signed-off-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Dave Airlie 提交于
This was never an error, drop to a debug print. Reported-by: Keven Lachance Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 02 9月, 2012 3 次提交
-
-
由 Henrik Rydberg 提交于
Going through the motions of printing the debug message information takes a long time; using the keyboard can lead to a 160 us irqsoff latency. This patch skips hid_dump_input() when there are no open handles, which brings latency down to 100 us. Signed-off-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Bjørn Mork 提交于
Gobi devices are composite, needing both the qcserial and qmi_wwan drivers to support all functions. Re-syncing the list of supported devices with qcserial. Cc: Aleksander Morgado <aleksander@lanedo.com> Cc: Thomas Tuttle <ttuttle@chromium.org> Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NDavid S. Miller <davem@tempietto.lan>
-
由 Dan Carpenter 提交于
The intent was to set 4 bytes of data so that's why the sp_len is set to 4 on the next line. The cast to u_long pointer clears 8 bytes on 64 bit arches. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@tempietto.lan>
-
- 01 9月, 2012 7 次提交
-
-
由 Axel Lin 提交于
This driver can be built as a module, set the missing owner field of struct gpio_chip to prevent removal of modules exporting active GPIOs. Signed-off-by: NAxel Lin <axel.lin@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Axel Lin 提交于
irq_alloc_descs() returns negative error code on failure. Signed-off-by: NAxel Lin <axel.lin@gmail.com> Acked-by: NMagnus Damm <damm@opensource.se> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Axel Lin 提交于
Make GPIO_MC9S08DZ60 depend on I2C=y, this fixes below build error: LD init/built-in.o drivers/built-in.o: In function `mc9s08dz60_get_value': clk-fixed-factor.c:(.text+0x7214): undefined reference to `i2c_smbus_read_byte_data' drivers/built-in.o: In function `mc9s08dz60_set': clk-fixed-factor.c:(.text+0x727c): undefined reference to `i2c_smbus_read_byte_data' clk-fixed-factor.c:(.text+0x72bc): undefined reference to `i2c_smbus_write_byte_data' drivers/built-in.o: In function `mc9s08dz60_i2c_driver_init': clk-fixed-factor.c:(.init.text+0x290): undefined reference to `i2c_register_driver' drivers/built-in.o: In function `mc9s08dz60_i2c_driver_exit': clk-fixed-factor.c:(.exit.text+0x2c): undefined reference to `i2c_del_driver' make: *** [vmlinux] Error 1 Signed-off-by: NAxel Lin <axel.lin@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Bin Liu 提交于
davinci mdio device is not unregistered from mdiobus when removing the module, which causes BUG_ON() when free the device from mdiobus. Calling mdiobus_unregister() before mdiobus_free() fixes the issue. Signed-off-by: NBin Liu <b-liu@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Aleksander Morgado 提交于
Foxconn-branded Novatel E396, Gobi3k modem. Cc: Dan Williams <dcbw@redhat.com> Cc: Bjørn Mork <bjorn@mork.no> Cc: Ben Chan <benchan@google.com> Signed-off-by: NAleksander Morgado <aleksander@lanedo.com> Acked-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Oliver Neukum 提交于
A usbnet device can share a multifunction device with a storage device. If the storage device is autoresumed the usbnet devices also needs to be autoresumed. Allocating memory with GFP_KERNEL can deadlock in this case. This should go back into all kernels that have commit 65841fd5 That is 3.5 Signed-off-by: NOliver Neukum <oneukum@suse.de> CC: stable@kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jaccon Bastiaansen 提交于
The RxCFG register of the CS89x0 could be configured incorrectly (because of misplaced parentheses), resulting in the disabling of packet reception. Signed-off-by: NJaccon Bastiaansen <jaccon.bastiaansen@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-