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 5 次提交
  12. 26 11月, 2016 3 次提交
  13. 23 11月, 2016 7 次提交
  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. 20 11月, 2016 1 次提交
    • K
      ARM: davinci: PM: fix build when da850 not compiled in · f7715b29
      Kevin Hilman 提交于
      Currently, suspend/resume support is only available on da850 platforms,
      and the platform PM code has dependencies on da850 functions.  However,
      CONFIG_SUSPEND might be enabled even when da850 support is not, causing
      build failure:
      
      arch/arm/mach-davinci/built-in.o: In function `davinci_pm_init':
      pm_domain.c:(.init.text+0x1fb8): undefined reference to `da8xx_get_mem_ctlr'
      pm_domain.c:(.init.text+0x20b0): undefined reference to `da8xx_syscfg1_base'
      
      Fix this by only building the PM core when da850 is enabled.
      Reported-by: NSekhar Nori <nsekhar@ti.com>
      Fixes: aa9aa1ec ("ARM: davinci: PM: rework init, remove platform device")
      Signed-off-by: NKevin Hilman <khilman@baylibre.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      f7715b29
  17. 19 11月, 2016 1 次提交
  18. 18 11月, 2016 1 次提交