1. 15 12月, 2016 1 次提交
  2. 13 12月, 2016 3 次提交
  3. 09 12月, 2016 1 次提交
  4. 08 12月, 2016 3 次提交
    • J
      arm/xen: Use alloc_percpu rather than __alloc_percpu · 24d5373d
      Julien Grall 提交于
      The function xen_guest_init is using __alloc_percpu with an alignment
      which are not power of two.
      
      However, the percpu allocator never supported alignments which are not power
      of two and has always behaved incorectly in thise case.
      
      Commit 3ca45a46 "percpu: ensure requested alignment is power of two"
      introduced a check which trigger a warning [1] when booting linux-next
      on Xen. But in reality this bug was always present.
      
      This can be fixed by replacing the call to __alloc_percpu with
      alloc_percpu. The latter will use an alignment which are a power of two.
      
      [1]
      
      [    0.023921] illegal size (48) or align (48) for percpu allocation
      [    0.024167] ------------[ cut here ]------------
      [    0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
      [    0.024584] Modules linked in:
      [    0.024708]
      [    0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
      4.9.0-rc7-next-20161128 #473
      [    0.025012] Hardware name: Foundation-v8A (DT)
      [    0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
      [    0.025351] PC is at pcpu_alloc+0x88/0x6c0
      [    0.025490] LR is at pcpu_alloc+0x88/0x6c0
      [    0.025624] pc : [<ffff00000818e678>] lr : [<ffff00000818e678>]
      pstate: 60000045
      [    0.025830] sp : ffff80003d847cd0
      [    0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
      [    0.026147] x27: 0000000000000000 x26: 0000000000000000
      [    0.026348] x25: 0000000000000000 x24: 0000000000000000
      [    0.026549] x23: 0000000000000000 x22: 00000000024000c0
      [    0.026752] x21: ffff000008e97000 x20: 0000000000000000
      [    0.026953] x19: 0000000000000030 x18: 0000000000000010
      [    0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
      [    0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
      [    0.027573] x13: ffff000008f79c4d x12: 0000000000000041
      [    0.027782] x11: 0000000000000006 x10: 0000000000000042
      [    0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
      [    0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
      [    0.028419] x5 : 0000000000000005 x4 : 0000000000000000
      [    0.028628] x3 : 0000000000000000 x2 : 000000000000017f
      [    0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
      [    0.029056]
      [    0.029152] ---[ end trace 0000000000000000 ]---
      [    0.029297] Call trace:
      [    0.029403] Exception stack(0xffff80003d847b00 to
                                     0xffff80003d847c30)
      [    0.029621] 7b00: 0000000000000030 0001000000000000
      ffff80003d847cd0 ffff00000818e678
      [    0.029901] 7b20: 0000000000000002 0000000000000004
      ffff000008f7c060 0000000000000035
      [    0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
      ffff80003d847bf0 ffff000008101778
      [    0.030402] 7b60: 0000000000000030 0000000000000000
      ffff000008e97000 00000000024000c0
      [    0.030647] 7b80: 0000000000000000 0000000000000000
      0000000000000000 0000000000000000
      [    0.030895] 7ba0: 0000000000000035 ffff80003d870000
      000000000000017f 0000000000000000
      [    0.031144] 7bc0: 0000000000000000 0000000000000005
      ffff000008f79c84 6120757063726570
      [    0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
      0000000000000042 0000000000000006
      [    0.031643] 7c00: 0000000000000041 ffff000008f79c4d
      ffff000088f79c3f 0000000000000006
      [    0.031877] 7c20: 00000000deadbeef 0000000000000a3f
      [    0.032051] [<ffff00000818e678>] pcpu_alloc+0x88/0x6c0
      [    0.032229] [<ffff00000818ece8>] __alloc_percpu+0x18/0x20
      [    0.032409] [<ffff000008d9606c>] xen_guest_init+0x174/0x2f4
      [    0.032591] [<ffff0000080830f8>] do_one_initcall+0x38/0x130
      [    0.032783] [<ffff000008d90c34>] kernel_init_freeable+0xe0/0x248
      [    0.032995] [<ffff00000899a890>] kernel_init+0x10/0x100
      [    0.033172] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
      Reported-by: NWei Chen <wei.chen@arm.com>
      Link: https://lkml.org/lkml/2016/11/28/669Signed-off-by: NJulien Grall <julien.grall@arm.com>
      Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
      Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
      Cc: stable@vger.kernel.org
      24d5373d
    • S
      ARM: dts: imx7d: fix LCDIF clock assignment · 4b707fa0
      Stefan Agner 提交于
      The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them
      separately:
      
      Clock      Clock Root              Description
      apb_clk    MAIN_AXI_CLK_ROOT       AXI clock
      pix_clk    LCDIF_PIXEL_CLK_ROOT    Pixel clock
      ipg_clk_s  MAIN_AXI_CLK_ROOT       Peripheral access clock
      
      All of them are switched by a single gate, which is part of the
      IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for
      the AXI bus clock (clock-name "axi") makes sure the gate gets
      enabled when accessing registers.
      
      There seem to be no separate AXI display clock, and the clock is
      optional. Hence remove the dummy clock.
      
      This fixes kernel freezes when starting the X-Server (which
      disables/re-enables the display controller).
      
      Fixes: e8ed73f6 ("ARM: dts: imx7d: add lcdif support")
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
      Acked-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      4b707fa0
    • J
      dts: sun8i-h3: correct UART3 pin definitions · 4367c1d8
      Jorik Jonker 提交于
      In a previous commit, I made a copy/paste error in the pinmux
      definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
      care of that. I have tested this commit on Orange Pi PC and Orange Pi
      Plus, and it works for these boards.
      
      Fixes: e3d11d3c ("dts: sun8i-h3: add pinmux definitions for
      UART2-3")
      Signed-off-by: NJorik Jonker <jorik@kippendief.biz>
      Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      4367c1d8
  5. 07 12月, 2016 3 次提交
  6. 06 12月, 2016 1 次提交
  7. 03 12月, 2016 1 次提交
  8. 01 12月, 2016 1 次提交
  9. 30 11月, 2016 3 次提交
  10. 29 11月, 2016 3 次提交
  11. 28 11月, 2016 2 次提交
  12. 26 11月, 2016 2 次提交
  13. 23 11月, 2016 4 次提交
  14. 22 11月, 2016 1 次提交
  15. 21 11月, 2016 1 次提交
    • L
      mfd: qcom-pm8xxx: Clean up PM8XXX namespace · 40a3a0f2
      Linus Walleij 提交于
      The Kconfig and file naming for the PM8xxx driver is totally
      confusing:
      
      - Kconfig options MFD_PM8XXX and MFD_PM8921_CORE, some in-kernel
        users depending on or selecting either at random.
      - A driver file named pm8921-core.c even if it is indeed
        used by the whole PM8xxx family of chips.
      - An irqchip named pm8xxx since it was (I guess) realized that
        the driver was generic for all pm8xxx PMICs.
      
      As I may want to add support for PM8901 this is starting to get
      really messy. Fix this situation by:
      
      - Remove the MFD_PM8921_CORE symbol and rely solely on MFD_PM8XXX
        and convert all users, including LEDs Kconfig and ARM defconfigs
        for qcom and multi_v7 to use that single symbol.
      - Renaming the driver to qcom-pm8xxx.c to fit along the two
        other qcom* prefixed drivers.
      - Rename functions withing the driver from 8921 to 8xxx to
        indicate it is generic.
      - Just drop the =m config from the pxa_defconfig, I have no clue
        why it is even there, it is not a Qualcomm platform. (Possibly
        older Kconfig noise from saveconfig.)
      
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: NAndy Gross <andy.gross@linaro.org>
      Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      40a3a0f2
  16. 18 11月, 2016 1 次提交
  17. 17 11月, 2016 4 次提交
  18. 16 11月, 2016 2 次提交
    • C
      locking/core, arch: Remove cpu_relax_lowlatency() · 5bd0b85b
      Christian Borntraeger 提交于
      As there are no users left, we can remove cpu_relax_lowlatency()
      implementations from every architecture.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Cc: <linux-arch@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1477386195-32736-6-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5bd0b85b
    • C
      locking/core: Introduce cpu_relax_yield() · 79ab11cd
      Christian Borntraeger 提交于
      For spinning loops people do often use barrier() or cpu_relax().
      For most architectures cpu_relax and barrier are the same, but on
      some architectures cpu_relax can add some latency.
      For example on power,sparc64 and arc, cpu_relax can shift the CPU
      towards other hardware threads in an SMT environment.
      On s390 cpu_relax does even more, it uses an hypercall to the
      hypervisor to give up the timeslice.
      In contrast to the SMT yielding this can result in larger latencies.
      In some places this latency is unwanted, so another variant
      "cpu_relax_lowlatency" was introduced. Before this is used in more
      and more places, lets revert the logic and provide a cpu_relax_yield
      that can be called in places where yielding is more important than
      latency. By default this is the same as cpu_relax on all architectures.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1477386195-32736-2-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      79ab11cd
  19. 15 11月, 2016 3 次提交
    • M
      ARM: 8628/1: dma-mapping: preallocate DMA-debug hash tables in core_initcall · 256ff1cf
      Marek Szyprowski 提交于
      fs_initcall is definitely too late to initialize DMA-debug hash tables,
      because some drivers might get probed and use DMA mapping framework
      already in core_initcall. Late initialization of DMA-debug results in
      false warning about accessing memory, that was not allocated, like this
      one:
      ------------[ cut here ]------------
      WARNING: CPU: 5 PID: 1 at lib/dma-debug.c:1104 check_unmap+0xa1c/0xe50
      exynos-sysmmu 10a60000.sysmmu: DMA-API: device driver tries to free DMA memory it has not allocated [device
      address=0x000000006ebd0000] [size=16384 bytes]
      Modules linked in:
      CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc5-00028-g39dde3d-dirty #44
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [<c0119dd4>] (unwind_backtrace) from [<c01122bc>] (show_stack+0x20/0x24)
      [<c01122bc>] (show_stack) from [<c062714c>] (dump_stack+0x84/0xa0)
      [<c062714c>] (dump_stack) from [<c0132560>] (__warn+0x14c/0x180)
      [<c0132560>] (__warn) from [<c01325dc>] (warn_slowpath_fmt+0x48/0x50)
      [<c01325dc>] (warn_slowpath_fmt) from [<c06814f8>] (check_unmap+0xa1c/0xe50)
      [<c06814f8>] (check_unmap) from [<c06819c4>] (debug_dma_unmap_page+0x98/0xc8)
      [<c06819c4>] (debug_dma_unmap_page) from [<c076c3e8>] (exynos_iommu_domain_free+0x158/0x380)
      [<c076c3e8>] (exynos_iommu_domain_free) from [<c0764a30>] (iommu_domain_free+0x34/0x60)
      [<c0764a30>] (iommu_domain_free) from [<c011f168>] (release_iommu_mapping+0x30/0xb8)
      [<c011f168>] (release_iommu_mapping) from [<c011f23c>] (arm_iommu_release_mapping+0x4c/0x50)
      [<c011f23c>] (arm_iommu_release_mapping) from [<c0b061ac>] (s5p_mfc_probe+0x640/0x80c)
      [<c0b061ac>] (s5p_mfc_probe) from [<c07e6750>] (platform_drv_probe+0x70/0x148)
      [<c07e6750>] (platform_drv_probe) from [<c07e25c0>] (driver_probe_device+0x12c/0x6b0)
      [<c07e25c0>] (driver_probe_device) from [<c07e2c6c>] (__driver_attach+0x128/0x17c)
      [<c07e2c6c>] (__driver_attach) from [<c07df74c>] (bus_for_each_dev+0x88/0xc8)
      [<c07df74c>] (bus_for_each_dev) from [<c07e1b6c>] (driver_attach+0x34/0x58)
      [<c07e1b6c>] (driver_attach) from [<c07e1350>] (bus_add_driver+0x18c/0x32c)
      [<c07e1350>] (bus_add_driver) from [<c07e4198>] (driver_register+0x98/0x148)
      [<c07e4198>] (driver_register) from [<c07e5cb0>] (__platform_driver_register+0x58/0x74)
      [<c07e5cb0>] (__platform_driver_register) from [<c174cb30>] (s5p_mfc_driver_init+0x1c/0x20)
      [<c174cb30>] (s5p_mfc_driver_init) from [<c0102690>] (do_one_initcall+0x64/0x258)
      [<c0102690>] (do_one_initcall) from [<c17014c0>] (kernel_init_freeable+0x3d0/0x4d0)
      [<c17014c0>] (kernel_init_freeable) from [<c116eeb4>] (kernel_init+0x18/0x134)
      [<c116eeb4>] (kernel_init) from [<c010bbd8>] (ret_from_fork+0x14/0x3c)
      ---[ end trace dc54c54bd3581296 ]---
      
      This patch moves initialization of DMA-debug to core_initcall. This is
      safe from the initialization perspective. dma_debug_do_init() internally calls
      debugfs functions and debugfs also gets initialised at core_initcall(), and
      that is earlier than arch code in the link order, so it will get initialized
      just before the DMA-debug.
      Reported-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      256ff1cf
    • N
      ARM: 8624/1: proc-v7m.S: fix init section name · 544457fa
      Nicolas Pitre 提交于
      There is no .text.init sections.
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      544457fa
    • R
      ARM: fix backtrace · 24c66dfd
      Russell King 提交于
      Recent kernels have changed their behaviour to be more inconsistent
      when handling printk continuations.  With todays kernels, the output
      looks sane on the console, but dmesg splits individual printk()s which
      do not have the KERN_CONT prefix into separate lines.
      
      Since the assembly code is not trivial to add the KERN_CONT, and we
      ideally want to avoid using KERN_CONT (as multiple printk()s can race
      between different threads), convert the assembly dumping the register
      values to C code, and have the C code build the output a line at a
      time before dumping to the console.
      
      This avoids the KERN_CONT issue, and also avoids situations where the
      output is intermixed with other console activity.
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      24c66dfd