1. 28 5月, 2014 2 次提交
    • S
      powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode · 011e4b02
      Srivatsa S. Bhat 提交于
      If we try to perform a kexec when the machine is in ST (Single-Threaded) mode
      (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we
      get the following messages during boot:
      
      [    0.089866] POWER8 performance monitor hardware support registered
      [    0.089985] power8-pmu: PMAO restore workaround active.
      [    5.095419] Processor 1 is stuck.
      [   10.097933] Processor 2 is stuck.
      [   15.100480] Processor 3 is stuck.
      [   20.102982] Processor 4 is stuck.
      [   25.105489] Processor 5 is stuck.
      [   30.108005] Processor 6 is stuck.
      [   35.110518] Processor 7 is stuck.
      [   40.113369] Processor 9 is stuck.
      [   45.115879] Processor 10 is stuck.
      [   50.118389] Processor 11 is stuck.
      [   55.120904] Processor 12 is stuck.
      [   60.123425] Processor 13 is stuck.
      [   65.125970] Processor 14 is stuck.
      [   70.128495] Processor 15 is stuck.
      [   75.131316] Processor 17 is stuck.
      
      Note that only the sibling threads are stuck, while the primary threads (0, 8,
      16 etc) boot just fine. Looking closer at the previous step of kexec, we observe
      that kexec tries to wakeup (bring online) the sibling threads of all the cores,
      before performing kexec:
      
      [ 9464.131231] Starting new kernel
      [ 9464.148507] kexec: Waking offline cpu 1.
      [ 9464.148552] kexec: Waking offline cpu 2.
      [ 9464.148600] kexec: Waking offline cpu 3.
      [ 9464.148636] kexec: Waking offline cpu 4.
      [ 9464.148671] kexec: Waking offline cpu 5.
      [ 9464.148708] kexec: Waking offline cpu 6.
      [ 9464.148743] kexec: Waking offline cpu 7.
      [ 9464.148779] kexec: Waking offline cpu 9.
      [ 9464.148815] kexec: Waking offline cpu 10.
      [ 9464.148851] kexec: Waking offline cpu 11.
      [ 9464.148887] kexec: Waking offline cpu 12.
      [ 9464.148922] kexec: Waking offline cpu 13.
      [ 9464.148958] kexec: Waking offline cpu 14.
      [ 9464.148994] kexec: Waking offline cpu 15.
      [ 9464.149030] kexec: Waking offline cpu 17.
      
      Instrumenting this piece of code revealed that the cpu_up() operation actually
      fails with -EBUSY. Thus, only the primary threads of all the cores are online
      during kexec, and hence this is a sure-shot receipe for disaster, as explained
      in commit e8e5c215 (powerpc/kexec: Fix orphaned offline CPUs across kexec),
      as well as in the comment above wake_offline_cpus().
      
      It turns out that cpu_up() was returning -EBUSY because the variable
      'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was done
      by migrate_to_reboot_cpu() inside kernel_kexec().
      
      Now, migrate_to_reboot_cpu() was originally written with the assumption that
      any further code will not need to perform CPU hotplug, since we are anyway in
      the reboot path. However, kexec is clearly not such a case, since we depend on
      onlining CPUs, atleast on powerpc.
      
      So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the
      kexec path, to fix this regression in kexec on powerpc.
      
      Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we
      can catch such issues more easily in the future.
      
      Fixes: c97102ba (kexec: migrate to reboot cpu)
      Cc: stable@vger.kernel.org
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      011e4b02
    • G
      powerpc: Fix 64 bit builds with binutils 2.24 · 7998eb3d
      Guenter Roeck 提交于
      With binutils 2.24, various 64 bit builds fail with relocation errors
      such as
      
      arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
      	(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI
      	against symbol `interrupt_base_book3e' defined in .text section
      	in arch/powerpc/kernel/built-in.o
      arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
      	(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI
      	against symbol `interrupt_end_book3e' defined in .text section
      	in arch/powerpc/kernel/built-in.o
      
      The assembler maintainer says:
      
       I changed the ABI, something that had to be done but unfortunately
       happens to break the booke kernel code.  When building up a 64-bit
       value with lis, ori, shl, oris, ori or similar sequences, you now
       should use @high and @higha in place of @h and @ha.  @h and @ha
       (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA)
       now report overflow if the value is out of 32-bit signed range.
       ie. @h and @ha assume you're building a 32-bit value. This is needed
       to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h
       and @toc@ha expressions, and for consistency I did the same for all
       other @h and @ha relocs.
      
      Replacing @h with @high in one strategic location fixes the relocation
      errors. This has to be done conditionally since the assembler either
      supports @h or @high but not both.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7998eb3d
  2. 24 5月, 2014 2 次提交
  3. 23 5月, 2014 1 次提交
  4. 22 5月, 2014 3 次提交
  5. 20 5月, 2014 7 次提交
  6. 18 5月, 2014 1 次提交
  7. 17 5月, 2014 3 次提交
    • T
      ARM: OMAP2+: Fix DMA hang after off-idle · 9ce2482f
      Tony Lindgren 提交于
      Commit 6ddeb6d8 (dmaengine: omap-dma: move IRQ handling to omap-dma)
      added support for handling interrupts in the omap dmaengine driver
      instead of the legacy driver. Because of different handling for
      interrupts this however caused omap3 to hang eventually after hitting
      off-idle.
      
      Any of the virtual 32 DMA channels can be assigned to any of the
      four DMA interrupts. So commit 6ddeb6d8 made the omap dmaengine
      driver to use the second DMA interrupt while keeping the legacy code
      still using the first DMA interrupt.
      
      This means we need to save and restore both IRQENABLE_L1 in addition
      to IRQENABLE_L0. As there is a chance that the DSP might be using
      IRQENABLE_L2 or IRQENABLE_L3 lines, let's not touch those until
      this has been confirmed. Let's just add a comment to the code for
      now.
      
      Fixes: 6ddeb6d8 (dmaengine: omap-dma: move IRQ handling to omap-dma)
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      9ce2482f
    • R
      ARM: OMAP2+: nand: Fix NAND on OMAP2 and OMAP3 boards · 5005e0b7
      Roger Quadros 提交于
      Commit c66d0391 broke NAND for non-DT boot on all OMAP2 and OMAP3
      boards using board_nand_init(). Following error is seen at boot
      
      [    0.154998]  (null): Unsupported NAND ECC scheme selected
      
      For OMAP2 and OMAP3 platforms, the ecc_opt parameter in platform data
      must be set to OMAP_ECC_HAM1_CODE_HW to work properly.
      
      Tested on omap3-beagle c4.
      
      Fixes: c66d0391 (mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes)
      Cc: stable@vger.kernel.org # v3.12+
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      5005e0b7
    • M
      arm64: fix pud_huge() for 2-level pagetables · 4797ec2d
      Mark Salter 提交于
      The following happens when trying to run a kvm guest on a kernel
      configured for 64k pages. This doesn't happen with 4k pages:
      
        BUG: failure at include/linux/mm.h:297/put_page_testzero()!
        Kernel panic - not syncing: BUG!
        CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF            3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
        Call trace:
        [<fffffe0000096034>] dump_backtrace+0x0/0x16c
        [<fffffe00000961b4>] show_stack+0x14/0x1c
        [<fffffe000066e648>] dump_stack+0x84/0xb0
        [<fffffe0000668678>] panic+0xf4/0x220
        [<fffffe000018ec78>] free_reserved_area+0x0/0x110
        [<fffffe000018edd8>] free_pages+0x50/0x88
        [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
        [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
        [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
        [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c
        [<fffffe00001edc1c>] __fput+0xb0/0x288
        [<fffffe00001ede4c>] ____fput+0xc/0x14
        [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c
        [<fffffe0000095c14>] do_notify_resume+0x54/0x58
      
      In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
      on the stage2 pgd which leads to the BUG in put_page_testzero(). This
      happens because a pud_huge() test in unmap_range() returns true when it
      should always be false with 2-level pages tables used by 64k pages.
      This patch removes support for huge puds if 2-level pagetables are
      being used.
      Signed-off-by: NMark Salter <msalter@redhat.com>
      [catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: <stable@vger.kernel.org> # v3.11+
      4797ec2d
  8. 16 5月, 2014 4 次提交
    • L
      mips: dts: Fix missing device_type="memory" property in memory nodes · dfc44f80
      Leif Lindholm 提交于
      A few platforms lack a 'device_type = "memory"' for their memory
      nodes, relying on an old ppc quirk in order to discover its memory.
      Add the missing data so that all parsing code can find memory nodes
      correctly.
      Signed-off-by: NLeif Lindholm <leif.lindholm@linaro.org>
      Cc: linux-mips@linux-mips.org
      Cc: devicetree@vger.kernel.org
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org>
      Acked-by: NJohn Crispin <blogic@openwrt.org>
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      dfc44f80
    • L
      arm: dts: Fix missing device_type="memory" for ste-ccu8540 · bfaed5ab
      Leif Lindholm 提交于
      The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
      its memory node, relying on an old ppc quirk in order to discover its
      memory. Fix the data so that all parsing code can handle it correctly.
      Signed-off-by: NLeif Lindholm <leif.lindholm@linaro.org>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: devicetree@vger.kernel.org
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      bfaed5ab
    • J
      parisc: Improve LWS-CAS performance · c776cd89
      John David Anglin 提交于
      The attached change significantly improves the performance of the LWS-CAS code
      in syscall.S.
      This allows a number of packages to build (e.g., zeromq3, gtest and libxs)
      that previously failed because slow LWS-CAS performance under contention. In
      particular, interrupts taken while the lock was taken degraded performance
      significantly.
      
      The change does the following:
      
      1) Disables interrupts around the CAS operation, and
      2) Changes the loads and stores to use the ordered completer, "o", on
      PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is
      accepted on both PA 1.X and 2.0.
      
      The use of ordered loads and stores probably makes no difference on all
      existing hardware, but it seemed pedantically correct. In particular, the CAS
      operation must complete before LDCW lock is released. As written before, a
      processor could reorder the operations.
      
      I don't believe the period interrupts are disabled is long enough to
      significantly increase interrupt latency. For example, the TLB insert code is
      longer. Worst case is a memory fault in the CAS operation.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 3.13+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      c776cd89
    • H
      parisc: ratelimit userspace segfault printing · fef47e2a
      Helge Deller 提交于
      Ratelimit printing of userspace segfaults and make it runtime
      configurable via the /proc/sys/debug/exception-trace variable. This
      should resolve syslog from growing way too fast and thus prevents
      possible system service attacks.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # 3.13+
      fef47e2a
  9. 15 5月, 2014 13 次提交
    • L
      x86-64, modify_ldt: Make support for 16-bit segments a runtime option · fa81511b
      Linus Torvalds 提交于
      Checkin:
      
      b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
      
      disabled 16-bit segments on 64-bit kernels due to an information
      leak.  However, it does seem that people are genuinely using Wine to
      run old 16-bit Windows programs on Linux.
      
      A proper fix for this ("espfix64") is coming in the upcoming merge
      window, but as a temporary fix, create a sysctl to allow the
      administrator to re-enable support for 16-bit segments.
      
      It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
      you hit this issue and care about your old Windows program more than
      you care about a kernel stack address information leak, you can do
      
         echo 1 > /proc/sys/abi/ldt16
      
      as root (add it to your startup scripts), and you should be ok.
      
      The sysctl table is only added if you have COMPAT support enabled on
      x86-64, but I assume anybody who runs old windows binaries very much
      does that ;)
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
      Cc: <stable@vger.kernel.org>
      fa81511b
    • J
      metag: Remove _STK_LIM_MAX override · c70458f5
      James Hogan 提交于
      Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to
      256MB, apparently in an attempt to prevent setup_arg_pages's
      STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is
      far too large for Meta's limited virtual address space and hits a BUG_ON
      (stack_top is usually 0x3ffff000).
      
      However the commit "metag: Reduce maximum stack size to 256MB" reduces
      the absolute stack size limit to a safe value for metag. This allows the
      default _STK_LIM_MAX override to be removed, bringing the default
      behaviour in line with all other architectures. Parisc in particular
      recently removed their override of _STK_LIMT_MAX in commit e0d8898d
      (parisc: remove _STK_LIM_MAX override) since it subtly affects stack
      allocation semantics in userland. Meta's uapi/asm/resource.h can now be
      removed and switch to using generic-y.
      Suggested-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Cc: John David Anglin <dave.anglin@bell.net>
      c70458f5
    • H
      parisc,metag: Do not hardcode maximum userspace stack size · 042d27ac
      Helge Deller 提交于
      This patch affects only architectures where the stack grows upwards
      (currently parisc and metag only). On those do not hardcode the maximum
      initial stack size to 1GB for 32-bit processes, but make it configurable
      via a config option.
      
      The main problem with the hardcoded stack size is, that we have two
      memory regions which grow upwards: stack and heap. To keep most of the
      memory available for heap in a flexmap memory layout, it makes no sense
      to hard allocate up to 1GB of the memory for stack which can't be used
      as heap then.
      
      This patch makes the stack size for 32-bit processes configurable and
      uses 80MB as default value which has been in use during the last few
      years on parisc and which hasn't showed any problems yet.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: linux-parisc@vger.kernel.org
      Cc: linux-metag@vger.kernel.org
      Cc: John David Anglin <dave.anglin@bell.net>
      042d27ac
    • J
      metag: Reduce maximum stack size to 256MB · d71f290b
      James Hogan 提交于
      Specify the maximum stack size for arches where the stack grows upward
      (parisc and metag) in asm/processor.h rather than hard coding in
      fs/exec.c so that metag can specify a smaller value of 256MB rather than
      1GB.
      
      This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased
      beyond a safe value by root. E.g. when starting a process after running
      "ulimit -H -s unlimited" it will then attempt to use a stack size of the
      maximum 1GB which is far too big for metag's limited user virtual
      address space (stack_top is usually 0x3ffff000):
      
      BUG: failure at fs/exec.c:589/shift_arg_pages()!
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: linux-parisc@vger.kernel.org
      Cc: linux-metag@vger.kernel.org
      Cc: John David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # only needed for >= v3.9 (arch/metag)
      d71f290b
    • M
      metag: fix memory barriers · 2425ce84
      Mikulas Patocka 提交于
      Volatile access doesn't really imply the compiler barrier. Volatile access
      is only ordered with respect to other volatile accesses, it isn't ordered
      with respect to general memory accesses. Gcc may reorder memory accesses
      around volatile access, as we can see in this simple example (if we
      compile it with optimization, both increments of *b will be collapsed to
      just one):
      
      void fn(volatile int *a, long *b)
      {
      	(*b)++;
      	*a = 10;
      	(*b)++;
      }
      
      Consequently, we need the compiler barrier after a write to the volatile
      variable, to make sure that the compiler doesn't reorder the volatile
      write with something else.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      2425ce84
    • H
      net: filter: s390: fix JIT address randomization · e84d2f8d
      Heiko Carstens 提交于
      This is the s390 variant of Alexei's JIT bug fix.
      (patch description below stolen from Alexei's patch)
      
      bpf_alloc_binary() adds 128 bytes of room to JITed program image
      and rounds it up to the nearest page size. If image size is close
      to page size (like 4000), it is rounded to two pages:
      round_up(4000 + 4 + 128) == 8192
      then 'hole' is computed as 8192 - (4000 + 4) = 4188
      If prandom_u32() % hole selects a number >= PAGE_SIZE - sizeof(*header)
      then kernel will crash during bpf_jit_free():
      
      kernel BUG at arch/x86/mm/pageattr.c:887!
      Call Trace:
       [<ffffffff81037285>] change_page_attr_set_clr+0x135/0x460
       [<ffffffff81694cc0>] ? _raw_spin_unlock_irq+0x30/0x50
       [<ffffffff810378ff>] set_memory_rw+0x2f/0x40
       [<ffffffffa01a0d8d>] bpf_jit_free_deferred+0x2d/0x60
       [<ffffffff8106bf98>] process_one_work+0x1d8/0x6a0
       [<ffffffff8106bf38>] ? process_one_work+0x178/0x6a0
       [<ffffffff8106c90c>] worker_thread+0x11c/0x370
      
      since bpf_jit_free() does:
        unsigned long addr = (unsigned long)fp->bpf_func & PAGE_MASK;
        struct bpf_binary_header *header = (void *)addr;
      to compute start address of 'bpf_binary_header'
      and header->pages will pass junk to:
        set_memory_rw(addr, header->pages);
      
      Fix it by making sure that &header->image[prandom_u32() % hole] and &header
      are in the same page.
      
      Fixes: aa2d2c73 ("s390/bpf,jit: address randomize and write protect jit code")
      Reported-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: <stable@vger.kernel.org> # v3.11+
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e84d2f8d
    • A
      ARM: dts: Remove g2d_pd node for exynos5420 · 702b691e
      Arun Kumar K 提交于
      G2D power domain also controls the CMU block of G2D. Since
      clock registers can be accessed anytime for viewing
      clk_summary, it can cause a system crash if g2d power domain
      is disabled.
      Signed-off-by: NArun Kumar K <arun.kk@samsung.com>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      702b691e
    • T
      ARM: dts: Remove mau_pd node for exynos5420 · c5b817e4
      Tushar Behera 提交于
      MAU powerdomain provides clocks for Audio sub-system block.
      This block comprises of the I2S audio controller, audio DMA
      blocks and Audio sub-system clock registers.
      
      Right now, there is no way to hook up power-domains with
      clock providers.  During late boot when this power-domain
      gets disabled, we get following external abort.
      
      Unhandled fault: imprecise external abort (0x1406) at 0x00000000
      Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
      Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
      Tested-by: NDoug Anderson <dianders@chromium.org>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      c5b817e4
    • S
      ARM: exynos_defconfig: enable HS-I2C to fix for mmc partition mount · a8f1d088
      Sachin Kamat 提交于
      High speed I2C is used on Exynos5 based SoCs. Enable it.
      
      The MMC partition for Root filesystem cannot be mounted
      without this enabling HS-I2C and regulators on many boards
      are connected HS-I2C bus so the regulators don't come by
      default without this.
      
      Actually, we are not able to get arndale-octa board to boot
      and mount an MMC partition without this change.
      Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
      Tested-by: NJavi Merino <javi.merino@arm.com>
      [kgene.kim@samsung.com: modified description]
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      a8f1d088
    • S
      ARM: dts: disable MDMA1 node for exynos5420 · e6015c1f
      Seungwon Jeon 提交于
      This change places MDMA1 in disabled node for Exynos5420.
      If MDMA1 region is configured with secure mode, it makes
      the boot failure with the following on smdk5420 board.
      ("Unhandled fault: imprecise external abort (0x1406) at 0x00000000")
      Thus, arndale-octa board don't need to do the same thing anymore.
      Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Tested-by: NJavi Merino <javi.merino@arm.com>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      e6015c1f
    • K
      ARM: EXYNOS: fix the secondary CPU boot of exynos4212 · 989ff3fd
      Kyungmin Park 提交于
      This patch fixes the offset of CPU boot address and changes
      the parameter of smc call for SMC_CMD_CPU1BOOT command on
      exynos4212.
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
      Reviewed-by: NTomasz Figa <t.figa@samsung.com>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      989ff3fd
    • P
      ARM: omap5: hwmod_data: Correct IDLEMODE for McPDM · 0f9e19ad
      Peter Ujfalusi 提交于
      McPDM need to be configured to NO_IDLE mode when it is in used otherwise
      vital clocks will be gated which results 'slow motion' audio playback.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0f9e19ad
    • S
      MIPS: mm: Fix broken microMIPS kernel regression. · 7bb39409
      Steven J. Hill 提交于
      Commit f4ae17aa [MIPS: mm: Use scratch for
      PGD when !CONFIG_MIPS_PGD_C0_CONTEXT] broke microMIPS kernel builds. This
      patch refactors that code similar to what was done for the 'clear_page'
      and 'copy_page' functions.
      Signed-off-by: NSteven J. Hill <Steven.Hill@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6744/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      7bb39409
  10. 14 5月, 2014 3 次提交
  11. 13 5月, 2014 1 次提交
反馈
建议
客服 返回
顶部