1. 19 Sep, 2012 40 commits
    • Ben Hutchings's avatar
      sfc: Fix maximum number of TSO segments and minimum TX queue size · 68cb695c
      Ben Hutchings authored
      [ Upstream commit 7e6d06f0 ]
      
      Currently an skb requiring TSO may not fit within a minimum-size TX
      queue.  The TX queue selected for the skb may stall and trigger the TX
      watchdog repeatedly (since the problem skb will be retried after the
      TX reset).  This issue is designated as CVE-2012-3412.
      
      Set the maximum number of TSO segments for our devices to 100.  This
      should make no difference to behaviour unless the actual MSS is less
      than about 700.  Increase the minimum TX queue size accordingly to
      allow for 2 worst-case skbs, so that there will definitely be space
      to add an skb after we wake a queue.
      
      To avoid invalidating existing configurations, change
      efx_ethtool_set_ringparam() to fix up values that are too small rather
      than returning -EINVAL.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      68cb695c
    • Ben Hutchings's avatar
      net: Allow driver to limit number of GSO segments per skb · 99ea81ed
      Ben Hutchings authored
      [ Upstream commit 30b678d8 ]
      
      A peer (or local user) may cause TCP to use a nominal MSS of as little
      as 88 (actual MSS of 76 with timestamps).  Given that we have a
      sufficiently prodigious local sender and the peer ACKs quickly enough,
      it is nevertheless possible to grow the window for such a connection
      to the point that we will try to send just under 64K at once.  This
      results in a single skb that expands to 861 segments.
      
      In some drivers with TSO support, such an skb will require hundreds of
      DMA descriptors; a substantial fraction of a TX ring or even more than
      a full ring.  The TX queue selected for the skb may stall and trigger
      the TX watchdog repeatedly (since the problem skb will be retried
      after the TX reset).  This particularly affects sfc, for which the
      issue is designated as CVE-2012-3412.
      
      Therefore:
      1. Add the field net_device::gso_max_segs holding the device-specific
         limit.
      2. In netif_skb_features(), if the number of segments is too high then
         mask out GSO features to force fall back to software GSO.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      99ea81ed
    • Axel Lin's avatar
      i2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y · bc63e39c
      Axel Lin authored
      commit e68bb91b upstream.
      
      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: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Tested-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bc63e39c
    • Dave Airlie's avatar
      drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot · beb30ae4
      Dave Airlie authored
      commit c4903429 upstream.
      
      This will cause udev to load vmwgfx instead of waiting for X
      to do it.
      Reviewed-by: default avatarJakob Bornecrantz <jakob@vmware.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      beb30ae4
    • Pavel Shilovsky's avatar
      CIFS: Fix error handling in cifs_push_mandatory_locks · 06335856
      Pavel Shilovsky authored
      commit e2f2886a upstream.
      Signed-off-by: default avatarPavel Shilovsky <pshilovsky@etersoft.ru>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      06335856
    • Dave Jones's avatar
      Remove user-triggerable BUG from mpol_to_str · 9600be78
      Dave Jones authored
      commit 80de7c31 upstream.
      
      Trivially triggerable, found by trinity:
      
        kernel BUG at mm/mempolicy.c:2546!
        Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670)
        Call Trace:
          show_numa_map+0xd5/0x450
          show_pid_numa_map+0x13/0x20
          traverse+0xf2/0x230
          seq_read+0x34b/0x3e0
          vfs_read+0xac/0x180
          sys_pread64+0xa2/0xc0
          system_call_fastpath+0x1a/0x1f
        RIP: mpol_to_str+0x156/0x360
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9600be78
    • Ronny Hegewald's avatar
      xen: Use correct masking in xen_swiotlb_alloc_coherent. · 7c013154
      Ronny Hegewald authored
      commit b5031ed1 upstream.
      
      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: default avatarRonny Hegewald <ronny.hegewald@online.de>
      Signed-off-by: default avatarStefano Panella <stefano.panella@citrix.com>
      Acked-By: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7c013154
    • Jan Kara's avatar
      udf: Fix data corruption for files in ICB · 0658632e
      Jan Kara authored
      commit 9c2fc0de upstream.
      
      When a file is stored in ICB (inode), we overwrite part of the file, and
      the page containing file's data is not in page cache, we end up corrupting
      file's data by overwriting them with zeros. The problem is we use
      simple_write_begin() which simply zeroes parts of the page which are not
      written to. The problem has been introduced by be021ee4 (udf: convert to
      new aops).
      
      Fix the problem by providing a ->write_begin function which makes the page
      properly uptodate.
      Reported-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0658632e
    • Paul Mackerras's avatar
      powerpc: Make sure IPI handlers see data written by IPI senders · 241ee90a
      Paul Mackerras authored
      commit 9fb1b36c upstream.
      
      We have been observing hangs, both of KVM guest vcpu tasks and more
      generally, where a process that is woken doesn't properly wake up and
      continue to run, but instead sticks in TASK_WAKING state.  This
      happens because the update of rq->wake_list in ttwu_queue_remote()
      is not ordered with the update of ipi_message in
      smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
      scheduler_ipi() is not ordered with the reading of ipi_message in
      smp_ipi_demux().  Thus it is possible for the IPI receiver not to see
      the updated rq->wake_list and therefore conclude that there is nothing
      for it to do.
      
      In order to make sure that anything done before smp_send_reschedule()
      is ordered before anything done in the resulting call to scheduler_ipi(),
      this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
      The barrier in smp_muxed_message_pass() is a full barrier to ensure that
      there is a full ordering between the smp_send_reschedule() caller and
      scheduler_ipi().  In smp_ipi_demux(), we use xchg() rather than
      xchg_local() because xchg() includes release and acquire barriers.
      Using xchg() rather than xchg_local() makes sense given that
      ipi_message is not just accessed locally.
      
      This moves the barrier between setting the message and calling the
      cause_ipi() function into the individual cause_ipi implementations.
      Most of them -- those that used outb, out_8 or similar -- already had
      a full barrier because out_8 etc. include a sync before the MMIO
      store.  This adds an explicit barrier in the two remaining cases.
      
      These changes made no measurable difference to the speed of IPIs as
      measured using a simple ping-pong latency test across two CPUs on
      different cores of a POWER7 machine.
      
      The analysis of the reason why processes were not waking up properly
      is due to Milton Miller.
      Reported-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      241ee90a
    • Anton Blanchard's avatar
      powerpc/xics: Harden xics hypervisor backend · 4d676c89
      Anton Blanchard authored
      commit 3ce21cdf upstream.
      
      During kdump stress testing I sometimes see the kdump kernel panic
      with:
      
        Interrupt 0x306 (real) is invalid, disabling it.
        Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306
      
      Instead of panicing print the error message, dump the stack the first
      time it happens and continue on. Add some more information to the
      debug messages as well.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4d676c89
    • Anton Blanchard's avatar
      powerpc: Restore correct DSCR in context switch · 33b29c62
      Anton Blanchard authored
      commit 71433285 upstream.
      
      During a context switch we always restore the per thread DSCR value.
      If we aren't doing explicit DSCR management
      (ie thread.dscr_inherit == 0) and the default DSCR changed while
      the process has been sleeping we end up with the wrong value.
      
      Check thread.dscr_inherit and select the default DSCR or per thread
      DSCR as required.
      
      This was found with the following test case, when running with
      more threads than CPUs (ie forcing context switching):
      
      http://ozlabs.org/~anton/junkcode/dscr_default_test.c
      
      With the four patches applied I can run a combination of all
      test cases successfully at the same time:
      
      http://ozlabs.org/~anton/junkcode/dscr_default_test.c
      http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
      http://ozlabs.org/~anton/junkcode/dscr_inherit_test.cSigned-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      33b29c62
    • Anton Blanchard's avatar
      powerpc: Fix DSCR inheritance in copy_thread() · ea186239
      Anton Blanchard authored
      commit 1021cb26 upstream.
      
      If the default DSCR is non zero we set thread.dscr_inherit in
      copy_thread() meaning the new thread and all its children will ignore
      future updates to the default DSCR. This is not intended and is
      a change in behaviour that a number of our users have hit.
      
      We just need to inherit thread.dscr and thread.dscr_inherit from
      the parent which ends up being much simpler.
      
      This was found with the following test case:
      
      http://ozlabs.org/~anton/junkcode/dscr_default_test.cSigned-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ea186239
    • Anton Blanchard's avatar
      powerpc: Keep thread.dscr and thread.dscr_inherit in sync · 5f31a641
      Anton Blanchard authored
      commit 00ca0de0 upstream.
      
      When we update the DSCR either via emulation of mtspr(DSCR) or via
      a change to dscr_default in sysfs we don't update thread.dscr.
      We will eventually update it at context switch time but there is
      a period where thread.dscr is incorrect.
      
      If we fork at this point we will copy the old value of thread.dscr
      into the child. To avoid this, always keep thread.dscr in sync with
      reality.
      
      This issue was found with the following testcase:
      
      http://ozlabs.org/~anton/junkcode/dscr_inherit_test.cSigned-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5f31a641
    • Anton Blanchard's avatar
      powerpc: Update DSCR on all CPUs when writing sysfs dscr_default · b32fef3b
      Anton Blanchard authored
      commit 1b6ca2a6 upstream.
      
      Writing to dscr_default in sysfs doesn't actually change the DSCR -
      we rely on a context switch on each CPU to do the work. There is no
      guarantee we will get a context switch in a reasonable amount of time
      so fire off an IPI to force an immediate change.
      
      This issue was found with the following test case:
      
      http://ozlabs.org/~anton/junkcode/dscr_explicit_test.cSigned-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b32fef3b
    • Ian Chen's avatar
      mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption. · 3b75588b
      Ian Chen authored
      commit 3550ccdb upstream.
      
      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: default avatarIan Chen <ian.cy.chen@samsung.com>
      Reviewed-by: default avatarNamjae Jeon <linkinjeon@gmail.com>
      Acked-by: default avatarJaehoon Chung <jh80.chung@samsung.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3b75588b
    • Shawn Guo's avatar
      mmc: sdhci-esdhc: break out early if clock is 0 · a0d9ef18
      Shawn Guo authored
      commit 74f330bc upstream.
      
      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: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a0d9ef18
    • Lauri Hintsala's avatar
      mmc: mxs-mmc: fix deadlock caused by recursion loop · 3a0ae8e1
      Lauri Hintsala authored
      commit fc108d24 upstream.
      
      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: default avatarAttila Kinali <attila@kinali.ch>
      Signed-off-by: default avatarLauri Hintsala <lauri.hintsala@bluegiga.com>
      Acked-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      [bwh: Backported to 3.2:
       - Adjust context
       - HW_SSP_STATUS is a simple rather than function-like macro]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3a0ae8e1
    • Lauri Hintsala's avatar
      mmc: mxs-mmc: fix deadlock in SDIO IRQ case · 2fa07abb
      Lauri Hintsala authored
      commit 1af36b2a upstream.
      
      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: default avatarLauri Hintsala <lauri.hintsala@bluegiga.com>
      Acked-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2fa07abb
    • Miklos Szeredi's avatar
      fuse: fix retrieve length · 68b7b07e
      Miklos Szeredi authored
      commit c9e67d48 upstream.
      
      In some cases fuse_retrieve() would return a short byte count if offset was
      non-zero.  The data returned was correct, though.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      68b7b07e
    • Artem Bityutskiy's avatar
      UBI: fix a horrible memory deallocation bug · 7b07c2bc
      Artem Bityutskiy authored
      commit 78b495c3 upstream.
      
      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: default avatarRichard Genoud <richard.genoud@gmail.com>
      Tested-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Tested-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      [bwh: Backported to 3.2: aeb_slab_cache was actually named scan_leb_slab]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7b07c2bc
    • Jan Kara's avatar
      ext3: Fix fdatasync() for files with only i_size changes · 33c5063f
      Jan Kara authored
      commit 156bddd8 upstream.
      
      Code tracking when transaction needs to be committed on fdatasync(2) forgets
      to handle a situation when only inode's i_size is changed. Thus in such
      situations fdatasync(2) doesn't force transaction with new i_size to disk
      and that can result in wrong i_size after a crash.
      
      Fix the issue by updating inode's i_datasync_tid whenever its size is
      updated.
      Reported-by: default avatarKristian Nielsen <knielsen@knielsen-hq.org>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      33c5063f
    • Bruce Allan's avatar
      e1000e: DoS while TSO enabled caused by link partner with small MSS · 78e96c14
      Bruce Allan authored
      commit d821a4c4 upstream.
      
      With a low enough MSS on the link partner and TSO enabled locally, the
      networking stack can periodically send a very large (e.g.  64KB) TCP
      message for which the driver will attempt to use more Tx descriptors than
      are available by default in the Tx ring.  This is due to a workaround in
      the code that imposes a limit of only 4 MSS-sized segments per descriptor
      which appears to be a carry-over from the older e1000 driver and may be
      applicable only to some older PCI or PCIx parts which are not supported in
      e1000e.  When the driver gets a message that is too large to fit across the
      configured number of Tx descriptors, it stops the upper stack from queueing
      any more and gets stuck in this state.  After a timeout, the upper stack
      assumes the adapter is hung and calls the driver to reset it.
      
      Remove the unnecessary limitation of using up to only 4 MSS-sized segments
      per Tx descriptor, and put in a hard failure test to catch when attempting
      to check for message sizes larger than would fit in the whole Tx ring.
      Refactor the remaining logic that limits the size of data per Tx descriptor
      from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
      Tx packet buffer as described in the hardware specification.
      
      Also, fix the logic in the check for space in the Tx ring for the next
      largest possible packet after the current one has been successfully queued
      for transmit, and use the appropriate defines for default ring sizes in
      e1000_probe instead of magic values.
      
      This issue goes back to the introduction of e1000e in 2.6.24 when it was
      split off from e1000.
      Reported-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2:
       - Adjust context
       - Adjust for use of net_device vs e1000_ring parameter]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      78e96c14
    • Paul Menzel's avatar
      drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S · 307937c6
      Paul Menzel authored
      commit 6f33814b upstream.
      
      Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
      vertical stripes in the top half.
      
      In commit bc42aabc [2]
      
              commit bc42aabc
              Author: Adam Jackson <ajax@redhat.com>
              Date:   Wed May 23 16:26:54 2012 -0400
      
                  drm/edid/quirks: ViewSonic VA2026w
      
      Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
      is also needed for this ASUS monitor.
      
      All log files and output from `xrandr` is included in the referenced
      Bugzilla report #17629.
      
      Please note that this monitor only has a VGA (D-Sub) connector [1].
      
      [1] http://www.asus.com/Display/LCD_Monitors/VW222S/
      [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629Signed-off-by: default avatarPaul Menzel <paulepanter@users.sourceforge.net>
      Cc: <dri-devel@lists.freedesktop.org>
      Cc: Adam Jackson <ajax@redhat.com>
      Cc: Ian Pilcher <arequipeno@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      307937c6
    • Adam Jackson's avatar
      drm/edid/quirks: ViewSonic VA2026w · 84a53fbe
      Adam Jackson authored
      commit bc42aabc upstream.
      
      Entirely new class of fail for this one.  The detailed timings are for
      normal CVT but the monitor really wanted CVT-R.
      
      Bugzilla: http://bugzilla.redhat/com/516471Signed-off-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      84a53fbe
    • Jerome Glisse's avatar
      drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740 · 07137a22
      Jerome Glisse authored
      commit 4a2b6662 upstream.
      
      It seems some of those IGP dislike non dma32 page despite what
      documentation says. Fix regression since we allowed non dma32
      pages. It seems it only affect some revision of those IGP chips
      as we don't know which one just force dma32 for all of them.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=785375Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      07137a22
    • Alex Deucher's avatar
      drm/radeon/atom: rework DIG modesetting on DCE3+ · fb7094d5
      Alex Deucher authored
      commit 8d1af57a upstream.
      
      The ordering is important and the current drm code
      wasn't cutting it for modern DIG encoders.  We need
      to have information about crtc before setting up
      the encoders so I've shifted the ordering a bit.
      Probably we'll need a full rework akin to danvet's
      recent intel patchs.  This patch fixes numerous
      issues with DP bridge chips and makes link training
      much more reliable.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      [bwh: Backported to 3.2: drop DCE6 cases]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      fb7094d5
    • Alex Deucher's avatar
      drm/radeon: don't disable plls that are in use by other crtcs · bcee0e63
      Alex Deucher authored
      commit 4e58591c upstream.
      
      Some plls are shared for DP.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      [bwh: Backported to 3.2: add the dev and rdev variables, previously added
       upstream to support DCE6.1 which isn't supported in this version]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bcee0e63
    • Alan Stern's avatar
      HID: add NOGET quirk for Eaton Ellipse MAX UPS · cedfdede
      Alan Stern authored
      commit 67ddbb3e upstream.
      
      This patch (as1603) adds a NOGET quirk for the Eaton Ellipse MAX UPS
      device.  (The USB IDs were already present in hid-ids.h, apparently
      under a different name.)
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarLaurent Bigonville <l.bigonville@edpnet.be>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cedfdede
    • Aaron Tian's avatar
      HID: multitouch: support PixArt optical touch screen · f41bb272
      Aaron Tian authored
      commit b7ea95ff upstream.
      
      This patch modifies hid-multitouch driver for supporting PixArt optical touch
      screen.  Because of the device does not have to set initial report, we apply
      "HID_QUIRK_NO_INIT_REPORTS" quirk and add the device into hid_blacklist[]
      Signed-off-by: default avatarAaron Tian <aaron_tian@pixart.com.tw>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f41bb272
    • Jakob Bornecrantz's avatar
      drm: Check for invalid cursor flags · cb4c3c50
      Jakob Bornecrantz authored
      commit 7c4eaca4 upstream.
      Signed-off-by: default avatarJakob Bornecrantz <jakob@vmware.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cb4c3c50
    • Jesse Barnes's avatar
      drm: remove some potentially dangerous DRM_ERRORs · 770ba238
      Jesse Barnes authored
      commit acb4b992 upstream.
      
      Each of these error messages can be caused by a broken or malicious
      userspace wanting to spam the dmesg with useless info.  They're really
      not worthy of DRM_DEBUG statements either; those are generally only
      useful during bringup of new hardware or versions, and ought to be
      removed before going upstream anyway.
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: default avatarAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      [bwh: Backported to 3.2: s/r\./r->/ in drm_mode_addfb()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      770ba238
    • Arnd Bergmann's avatar
      ARM: imx: select CPU_FREQ_TABLE when needed · c09ccfb9
      Arnd Bergmann authored
      commit f637c4c9 upstream.
      
      The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
      so it needs to select that code to be built. This problem has
      apparently existed since the i.MX cpufreq code was first merged
      in v2.6.37.
      
      Building IMX without CPU_FREQ_TABLE results in:
      
      arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
      arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
      arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
      arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
      arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
      arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
      arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
      arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
      arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Yong Shen <yong.shen@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c09ccfb9
    • Konrad Rzeszutek Wilk's avatar
      xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M. · aaee3116
      Konrad Rzeszutek Wilk authored
      commit c96aae1f upstream.
      
      When we are finished with return PFNs to the hypervisor, then
      populate it back, and also mark the E820 MMIO and E820 gaps
      as IDENTITY_FRAMEs, we then call P2M to set areas that can
      be used for ballooning. We were off by one, and ended up
      over-writting a P2M entry that most likely was an IDENTITY_FRAME.
      For example:
      
      1-1 mapping on 40000->40200
      1-1 mapping on bc558->bc5ac
      1-1 mapping on bc5b4->bc8c5
      1-1 mapping on bc8c6->bcb7c
      1-1 mapping on bcd00->100000
      Released 614 pages of unused memory
      Set 277889 page(s) to 1-1 mapping
      Populating 40200-40466 pfn range: 614 pages added
      
      => here we set from 40466 up to bc559 P2M tree to be
      INVALID_P2M_ENTRY. We should have done it up to bc558.
      
      The end result is that if anybody is trying to construct
      a PTE for PFN bc558 they end up with ~PAGE_PRESENT.
      Reported-by-and-Tested-by: default avatarAndre Przywara <andre.przywara@amd.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      aaee3116
    • Shawn Guo's avatar
      ARM: dts: imx51-babbage: fix esdhc cd/wp properties · a3aaee9f
      Shawn Guo authored
      commit a46d2619 upstream.
      
      The binding doc and dts use properties "fsl,{cd,wp}-internal" while
      esdhc driver uses "fsl,{cd,wp}-controller".  Fix binding doc and dts
      to get them match driver code.
      Reported-by: default avatarChris Ball <cjb@laptop.org>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Acked-by: default avatarChris Ball <cjb@laptop.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a3aaee9f
    • Shawn Guo's avatar
      ARM: imx6: spin the cpu until hardware takes it down · 63aa21ef
      Shawn Guo authored
      commit c944b0b9 upstream.
      
      Though commit 602bf409 (ARM: imx6: exit coherency when shutting down
      a cpu) improves the stability of imx6q cpu hotplug a lot, there are
      still hangs seen with a more stressful hotplug testing.
      
      It's expected that once imx_enable_cpu(cpu, false) is called, the cpu
      will be taken down by hardware immediately, and the code after that
      will not get any chance to execute.  However, this is not always the
      case from the testing.  The cpu could possibly be alive for a few
      cycles before hardware actually takes it down.  So rather than letting
      cpu execute some code that could cause a hang in these cycles, let's
      make the cpu spin there and wait for hardware to take it down.
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      63aa21ef
    • Grazvydas Ignotas's avatar
      OMAPFB: fix framebuffer console colors · 3fd4e8f0
      Grazvydas Ignotas authored
      commit c1c52848 upstream.
      
      omapfb does not currently set pseudo palette correctly for color depths
      above 16bpp, making red text invisible, command like
        echo -e '\e[0;31mRED' > /dev/tty1
      will display nothing on framebuffer console in 24bpp mode.
      This is because temporary variable is declared incorrectly, fix it.
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3fd4e8f0
    • Xu, Anhua's avatar
      drm/i915: fix wrong order of parameters in port checking functions · 9ec66214
      Xu, Anhua authored
      commit b70ad586 upstream.
      
      Wrong order of parameters passed-in when calling hdmi/adpa
      /lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
      
      This bug was indroduced by
      
      commit 1519b995
      Author: Keith Packard <keithp@keithp.com>
      Date:   Sat Aug 6 10:35:34 2011 -0700
      
          drm/i915: Fix PCH port pipe select in CPT disable paths
      
      The reachable tag for this commit is v3.1-rc1-3-g1519b995Signed-off-by: default avatarAnhua Xu <anhua.xu@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44876Tested-by: default avatarDaniel Schroeder <sec@dschroeder.info>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9ec66214
    • Adam Jackson's avatar
      caac2653
    • Luca Tettamanti's avatar
      hwmon: (asus_atk0110) Add quirk for Asus M5A78L · e5748ee0
      Luca Tettamanti authored
      commit 43ca6cb2 upstream.
      
      The old interface is bugged and reads the wrong sensor when retrieving
      the reading for the chassis fan (it reads the CPU sensor); the new
      interface works fine.
      Reported-by: default avatarGöran Uddeborg <goeran@uddeborg.se>
      Tested-by: default avatarGöran Uddeborg <goeran@uddeborg.se>
      Signed-off-by: default avatarLuca Tettamanti <kronos.it@gmail.com>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e5748ee0
    • James Bottomley's avatar
      Fix 'Device not ready' issue on mpt2sas · 31155dab
      James Bottomley authored
      commit 14216561 upstream.
      
      This is a particularly nasty SCSI ATA Translation Layer (SATL) problem.
      
      SAT-2 says (section 8.12.2)
      
              if the device is in the stopped state as the result of
              processing a START STOP UNIT command (see 9.11), then the SATL
              shall terminate the TEST UNIT READY command with CHECK CONDITION
              status with the sense key set to NOT READY and the additional
              sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND
              REQUIRED;
      
      mpt2sas internal SATL seems to implement this.  The result is very confusing
      standby behaviour (using hdparm -y).  If you suspend a drive and then send
      another command, usually it wakes up.  However, if the next command is a TEST
      UNIT READY, the SATL sees that the drive is suspended and proceeds to follow
      the SATL rules for this, returning NOT READY to all subsequent commands.  This
      means that the ordering of TEST UNIT READY is crucial: if you send TUR and
      then a command, you get a NOT READY to both back.  If you send a command and
      then a TUR, you get GOOD status because the preceeding command woke the drive.
      
      This bit us badly because
      
      commit 85ef06d1
      Author: Tejun Heo <tj@kernel.org>
      Date:   Fri Jul 1 16:17:47 2011 +0200
      
          block: flush MEDIA_CHANGE from drivers on close(2)
      
      Changed our ordering on TEST UNIT READY commands meaning that SATA drives
      connected to an mpt2sas now suspend and refuse to wake (because the mpt2sas
      SATL sees the suspend *before* the drives get awoken by the next ATA command)
      resulting in lots of failed commands.
      
      The standard is completely nuts forcing this inconsistent behaviour, but we
      have to work around it.
      
      The fix for this is twofold:
      
         1. Set the allow_restart flag so we wake the drive when we see it has been
            suspended
      
         2. Return all TEST UNIT READY status directly to the mid layer without any
            further error handling which prevents us causing error handling which
            may offline the device just because of a media check TUR.
      Reported-by: default avatarMatthias Prager <linux@matthiasprager.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      31155dab