1. 25 3月, 2015 2 次提交
  2. 20 2月, 2015 1 次提交
  3. 19 2月, 2015 2 次提交
  4. 18 2月, 2015 12 次提交
    • P
      ARM: mm: Remove Kconfig symbol CACHE_PL310 · d88d6cfc
      Paul Bolle 提交于
      Commit 20e783e3 ("ARM: 8296/1: cache-l2x0: clean up aurora cache
      handling") removed the only user of the Kconfig symbol CACHE_PL310.
      Setting CACHE_PL310 is now pointless. Remove its Kconfig entry, and one
      select of this symbol.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      d88d6cfc
    • A
      ARM: rockchip: force built-in regulator support for PM · d1bef995
      Arnd Bergmann 提交于
      The rockchips suspend/resume code requires regulators to work,
      and gives a compile-time error if they are not available:
      
      arch/arm/mach-rockchip/built-in.o: In function `rk3288_suspend_finish':
      :(.text+0x146): undefined reference to `regulator_suspend_finish'
      arch/arm/mach-rockchip/built-in.o: In function `rk3288_suspend_prepare':
      :(.text+0x18e): undefined reference to `regulator_suspend_prepare'
      
      To solve this, we now enable regulators whenever they are needed,
      which is what we do on a lot of other platforms as well.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      d1bef995
    • A
      ARM: mvebu: build armada375-smp code conditionally · 16523518
      Arnd Bergmann 提交于
      mvebu_armada375_smp_wa_init is only used on armada 375 but is defined
      for all mvebu machines. As it calls a function that is only provided
      sometimes, this can result in a link error:
      
      arch/arm/mach-mvebu/built-in.o: In function `mvebu_armada375_smp_wa_init':
      :(.text+0x228): undefined reference to `mvebu_setup_boot_addr_wa'
      
      To solve this, we can just change the existing #ifdef around the
      function to also check for Armada375 SMP platforms.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 305969fb ("ARM: mvebu: use the common function for Armada 375 SMP workaround")
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      16523518
    • A
      ARM: sti: always enable RESET_CONTROLLER · 1fd01aa2
      Arnd Bergmann 提交于
      A lot of the sti device drivers require reset controller support,
      but do not all have individual 'depends on RESET_CONTROLLER'
      statements. Using 'select' here once avoids a lot of build errors
      resulting from this.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
      Acked-by: NPatrice Chotard <patrice.chotard@st.com>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@gmail.com>
      1fd01aa2
    • A
      ARM: rockchip: make rockchip_suspend_init conditional · c8823e7a
      Arnd Bergmann 提交于
      If CONFIG_PM_SLEEP is disabled, we get a build error for rockchips:
      
      arch/arm/mach-rockchip/built-in.o: In function `rockchip_dt_init':
      :(.init.text+0x1c): undefined reference to `rockchip_suspend_init'
      
      This adds an inline alternative for that case.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
      Cc: linux-rockchip@lists.infradead.org
      c8823e7a
    • A
      ARM: ixp4xx: fix {in,out}s{bwl} data types · 1aeb3c5c
      Arnd Bergmann 提交于
      Most platforms use void pointer arguments in these functions, but
      ixp4xx does not, which triggers lots of warnings in device drivers like:
      
      net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr':
      net/ethernet/8390/ne2k-pci.c:503:3: warning: passing argument 2 of 'insw' from incompatible pointer type
         insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1);
         ^
      In file included from include/asm/io.h:214:0,
                       from /git/arm-soc/include/linux/io.h:22,
                       from /git/arm-soc/include/linux/pci.h:31,
                       from net/ethernet/8390/ne2k-pci.c:48:
      mach-ixp4xx/include/mach/io.h:316:91: note: expected 'u16 *' but argument is of type 'struct e8390_pkt_hdr *'
       static inline void insw(u32 io_addr, u16 *vaddr, u32 count)
      
      Fixing the drivers seems hopeless, so this changes the ixp4xx code
      to do the same as the others to avoid the warnings.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NKrzysztof Halasa <khalasa@piap.pl>
      Cc: Imre Kaloz <kaloz@openwrt.org>
      1aeb3c5c
    • A
      ARM: prima2: do not select SMP_ON_UP · d76f733d
      Arnd Bergmann 提交于
      The new Atlas7 platform implicitly selects 'CONFIG_SMP_ON_UP',
      which leads to problems if we enable building the platform without
      MMU, as that combination is not allowed and causes a link error:
      
      arch/arm/kernel/built-in.o: In function `c_show':
      :(.text+0x1872): undefined reference to `smp_on_up'
      :(.text+0x1876): undefined reference to `smp_on_up'
      arch/arm/kernel/built-in.o: In function `arch_irq_work_raise':
      :(.text+0x3d48): undefined reference to `smp_on_up'
      :(.text+0x3d4c): undefined reference to `smp_on_up'
      arch/arm/kernel/built-in.o: In function `smp_setup_processor_id':
      :(.init.text+0x180): undefined reference to `smp_on_up'
      
      This removes the 'select' statement.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 4cba0585 ("ARM: sirf: add Atlas7 machine support")
      Acked-by: NBarry Song <Baohua.Song@csr.com>
      Cc: Zhiwu Song <Zhiwu.Song@csr.com>
      d76f733d
    • A
      ARM: at91: fix pm declarations · a91c5824
      Arnd Bergmann 提交于
      In a recent rearrangement of the at91 pm initialization code, a broken
      set of declarations was added for the !CONFIG_PM-case, leading to
      this link error:
      
      arch/arm/mach-at91/board-dt-sama5.o: In function `at91_rm9200_pm_init':
      arch/arm/mach-at91/generic.h:40: multiple definition of `at91_rm9200_pm_init'
      arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:40: first defined here
      arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9260_pm_init':
      arch/arm/mach-at91/generic.h:41: multiple definition of `at91_sam9260_pm_init'
      arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:41: first defined here
      arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9g45_pm_init':
      arch/arm/mach-at91/generic.h:42: multiple definition of `at91_sam9g45_pm_init'
      arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:42: first defined here
      
      This adds the missing 'static inline' to the declarations to avoid
      creating a copy of the functions in each file that includes the
      header.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 4db0ba22 ("ARM: at91: pm: prepare for multiplatform")
      Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
      a91c5824
    • A
      ARM: davinci: multi-soc kernels require AUTO_ZRELADDR · 99bd667a
      Arnd Bergmann 提交于
      The davinci DA8xx and DMx families have incompatible zreladdr
      settings, and attempting to build a kernel with both enabled
      results in an error unless AUTO_ZRELADDR is set:
      
      multiple zreladdrs: 0xc0008000 0x80008000
      This needs CONFIG_AUTO_ZRELADDR to be set
      
      This patch changes Kconfig to make the two families mutually
      exclusive when this is unset.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSekhar Nori <nsekhar@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      99bd667a
    • A
      ARM: davinci: davinci_cfg_reg cannot be init · 31612d64
      Arnd Bergmann 提交于
      davinci_cfg_reg gets called from a lot of locations that
      might get called after the init section has been discarded,
      so the function itself must not be marked __init either.
      
      The kernel build currently warns about this with lots of
      messages like:
      
      WARNING: vmlinux.o(.text.unlikely+0x24c): Section mismatch in reference from the function dm365evm_mmc_configure() to the function .init.text:davinci_cfg_reg()
      The function dm365evm_mmc_configure() references
      the function __init davinci_cfg_reg().
      This is often because dm365evm_mmc_configure lacks a __init
      annotation or the annotation of davinci_cfg_reg is wrong.
      
      This removes the extraneous __init_or_module annotation.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSekhar Nori <nsekhar@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      31612d64
    • A
      ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile · ff34cae5
      Arnd Bergmann 提交于
      A recent cleanup rearranged the Kconfig file for mach-bcm and
      accidentally dropped the dependency on ARCH_MULTI_V7, which
      makes it possible to now build the two mobile SoC platforms
      on an ARMv6-only kernel, resulting in a log of Kconfig
      warnings like
      
      warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
      
      and which of course cannot work on any machine.
      
      This puts back the dependencies as before.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 64e74aa7 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NScott Branden <sbranden@broadcom.com>
      ff34cae5
    • A
      ARM: vexpress: use ARM_CPU_SUSPEND if needed · 95fcedb0
      Arnd Bergmann 提交于
      The vexpress tc2 power management code calls mcpm_loopback, which
      is only available if ARM_CPU_SUSPEND is enabled, otherwise we
      get a link error:
      
      arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
      arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
      
      This explicitly selects ARM_CPU_SUSPEND like other platforms that
      need it.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 3592d7e0 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      95fcedb0
  5. 17 2月, 2015 3 次提交
    • A
      arm: dts: zynq: update isl9305 compatible string to use isil vendor prefix · b4770fe5
      Arnaud Ebalard 提交于
      "isil" and "isl" prefixes are used at various locations inside the kernel
      to reference Intersil corporation.  This patch is part of a series fixing
      those locations were "isl" is used in compatible strings to use the now
      expected "isil" prefix instead (NASDAQ symbol for Intersil and most used
      version).
      
      Note: isl9305 is an I2C device so the patch does not in fact currently
      depend on the introduction of "isil"-based compatible string in isl9305
      driver (provided by another patch) because I2C core does not check the
      prefix yet.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Uwe Kleine-Knig <uwe@kleine-koenig.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Darshana Padmadas <darshanapadmadas@gmail.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b4770fe5
    • R
      ARM: dts: add I2C device nodes for Broadcom Cygnus · b51c05a3
      Ray Jui 提交于
      Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
      them disabled there. Individual I2C devices can be enabled in board
      specific dts file when I2C slave devices are enabled in the future
      Signed-off-by: NRay Jui <rjui@broadcom.com>
      Reviewed-by: NScott Branden <sbranden@broadcom.com>
      Reviewed-by: NKevin Cernekee <cernekee@chromium.org>
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      b51c05a3
    • F
      ARM: dts: BCM63xx: fix L2 cache properties · 9df11828
      Florian Fainelli 提交于
      The L2 cache properties were completely off with respect to what the
      hardware is configured for. Fix the cache-size, cache-line-size and
      cache-sets to reflect the L2 cache controller we have: 512KB, 16 ways
      and 32 bytes per cache-line.
      
      Fixes: 46d4bca0 ("ARM: BCM63XX: add BCM63138 minimal Device Tree")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      9df11828
  6. 14 2月, 2015 4 次提交
    • G
      ARM: mvebu: enable Armada 38x RTC driver in mvebu_v7_defconfig · a3b30e72
      Gregory CLEMENT 提交于
      Now that the Armada 38x RTC driver has been pushed, let's enable it in
      mvebu_v7_defconfig.
      Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Arnaud Ebalard <arno@natisbad.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: Boris BREZILLON <boris.brezillon@free-electrons.com>
      Cc: Lior Amsalem <alior@marvell.com>
      Cc: Tawfik Bayouk <tawfik@marvell.com>
      Cc: Nadav Haklai <nadavh@marvell.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a3b30e72
    • G
      ARM: mvebu: add Device Tree description of RTC on Armada 38x · a73c7305
      Gregory CLEMENT 提交于
      The Marvell Armada 38x SoCs contains an RTC which differs from the RTC
      used in the other mvebu SoCs until now.  This commit adds the Device Tree
      description of this interface at the SoC level.
      Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Arnaud Ebalard <arno@natisbad.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: Boris BREZILLON <boris.brezillon@free-electrons.com>
      Cc: Lior Amsalem <alior@marvell.com>
      Cc: Tawfik Bayouk <tawfik@marvell.com>
      Cc: Nadav Haklai <nadavh@marvell.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a73c7305
    • A
      ARM: mvebu: ISL12057 rtc chip can now wake up RN102, RN102 and RN2120 · 1a67e256
      Arnaud Ebalard 提交于
      Now that alarm support for ISL12057 chip is available w/ the specific
      "isil,irq2-can-wakeup-machine" property, let's use that feature of the
      driver dedicated to NETGEAR ReadyNAS 102, 104 and 2120 specific routing of
      RTC Alarm IRQ#2 pin; on those devices, this pin is not connected to the
      SoC but to a PMIC, which allows the device to be powered up when RTC alarm
      rings.
      
      For that to work, the chip needs to be explicitly marked as a device
      wakeup source using this "isil,irq2-can-wakeup-machine" boolean property.
      This makes 'wakealarm' sysfs entry available to configure the alarm.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Peter Huewe <peter.huewe@infineon.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Darshana Padmadas <darshanapadmadas@gmail.com>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1a67e256
    • A
      mm: vmalloc: pass additional vm_flags to __vmalloc_node_range() · cb9e3c29
      Andrey Ryabinin 提交于
      For instrumenting global variables KASan will shadow memory backing memory
      for modules.  So on module loading we will need to allocate memory for
      shadow and map it at address in shadow that corresponds to the address
      allocated in module_alloc().
      
      __vmalloc_node_range() could be used for this purpose, except it puts a
      guard hole after allocated area.  Guard hole in shadow memory should be a
      problem because at some future point we might need to have a shadow memory
      at address occupied by guard hole.  So we could fail to allocate shadow
      for module_alloc().
      
      Now we have VM_NO_GUARD flag disabling guard page, so we need to pass into
      __vmalloc_node_range().  Add new parameter 'vm_flags' to
      __vmalloc_node_range() function.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: NAndrey Konovalov <adech.fo@gmail.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cb9e3c29
  7. 13 2月, 2015 2 次提交
    • A
      all arches, signal: move restart_block to struct task_struct · f56141e3
      Andy Lutomirski 提交于
      If an attacker can cause a controlled kernel stack overflow, overwriting
      the restart block is a very juicy exploit target.  This is because the
      restart_block is held in the same memory allocation as the kernel stack.
      
      Moving the restart block to struct task_struct prevents this exploit by
      making the restart_block harder to locate.
      
      Note that there are other fields in thread_info that are also easy
      targets, at least on some architectures.
      
      It's also a decent simplification, since the restart code is more or less
      identical on all architectures.
      
      [james.hogan@imgtec.com: metag: align thread_info::supervisor_stack]
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NRichard Weinberger <richard@nod.at>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Tested-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f56141e3
    • M
      mm: convert p[te|md]_mknonnuma and remaining page table manipulations · 4d942466
      Mel Gorman 提交于
      With PROT_NONE, the traditional page table manipulation functions are
      sufficient.
      
      [andre.przywara@arm.com: fix compiler warning in pmdp_invalidate()]
      [akpm@linux-foundation.org: fix build with STRICT_MM_TYPECHECKS]
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NAneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Tested-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Kirill Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d942466
  8. 12 2月, 2015 4 次提交
    • K
      mm: fix false-positive warning on exit due mm_nr_pmds(mm) · b30fe6c7
      Kirill A. Shutemov 提交于
      The problem is that we check nr_ptes/nr_pmds in exit_mmap() which happens
      *before* pgd_free().  And if an arch does pte/pmd allocation in
      pgd_alloc() and frees them in pgd_free() we see offset in counters by the
      time of the checks.
      
      We tried to workaround this by offsetting expected counter value according
      to FIRST_USER_ADDRESS for both nr_pte and nr_pmd in exit_mmap().  But it
      doesn't work in some cases:
      
      1. ARM with LPAE enabled also has non-zero USER_PGTABLES_CEILING, but
         upper addresses occupied with huge pmd entries, so the trick with
         offsetting expected counter value will get really ugly: we will have
         to apply it nr_pmds, but not nr_ptes.
      
      2. Metag has non-zero FIRST_USER_ADDRESS, but doesn't do allocation
         pte/pmd page tables allocation in pgd_alloc(), just setup a pgd entry
         which is allocated at boot and shared accross all processes.
      
      The proposal is to move the check to check_mm() which happens *after*
      pgd_free() and do proper accounting during pgd_alloc() and pgd_free()
      which would bring counters to zero if nothing leaked.
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: NTyler Baker <tyler.baker@linaro.org>
      Tested-by: NTyler Baker <tyler.baker@linaro.org>
      Tested-by: NNishanth Menon <nm@ti.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b30fe6c7
    • K
      arm: define __PAGETABLE_PMD_FOLDED for !LPAE · 8aa76875
      Kirill A. Shutemov 提交于
      ARM uses custom implementation of PMD folding in 2-level page table case.
      Generic code expects to see __PAGETABLE_PMD_FOLDED to be defined if PMD is
      folded, but ARM doesn't do this.  Let's fix it.
      
      Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc().  It
      also fixes problems with recently-introduced pmd accounting on ARM without
      LPAE.
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: NNishanth Menon <nm@ti.com>
      Reported-by: NSimon Horman <horms@verge.net.au>
      Tested-by: NSimon Horman <horms+renesas@verge.net.au>
      Tested-by: NFabio Estevam <festevam@gmail.com>
      Tested-by: NFelipe Balbi <balbi@ti.com>
      Tested-by: NNishanth Menon <nm@ti.com>
      Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8aa76875
    • K
      mm: make FIRST_USER_ADDRESS unsigned long on all archs · d016bf7e
      Kirill A. Shutemov 提交于
      LKP has triggered a compiler warning after my recent patch "mm: account
      pmd page tables to the process":
      
          mm/mmap.c: In function 'exit_mmap':
       >> mm/mmap.c:2857:2: warning: right shift count >= width of type [enabled by default]
      
      The code:
      
       > 2857                WARN_ON(mm_nr_pmds(mm) >
         2858                                round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
      
      In this, on tile, we have FIRST_USER_ADDRESS defined as 0.  round_up() has
      the same type -- int.  PUD_SHIFT.
      
      I think the best way to fix it is to define FIRST_USER_ADDRESS as unsigned
      long.  On every arch for consistency.
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d016bf7e
    • N
      mm/hugetlb: reduce arch dependent code around follow_huge_* · 61f77eda
      Naoya Horiguchi 提交于
      Currently we have many duplicates in definitions around
      follow_huge_addr(), follow_huge_pmd(), and follow_huge_pud(), so this
      patch tries to remove the m.  The basic idea is to put the default
      implementation for these functions in mm/hugetlb.c as weak symbols
      (regardless of CONFIG_ARCH_WANT_GENERAL_HUGETL B), and to implement
      arch-specific code only when the arch needs it.
      
      For follow_huge_addr(), only powerpc and ia64 have their own
      implementation, and in all other architectures this function just returns
      ERR_PTR(-EINVAL).  So this patch sets returning ERR_PTR(-EINVAL) as
      default.
      
      As for follow_huge_(pmd|pud)(), if (pmd|pud)_huge() is implemented to
      always return 0 in your architecture (like in ia64 or sparc,) it's never
      called (the callsite is optimized away) no matter how implemented it is.
      So in such architectures, we don't need arch-specific implementation.
      
      In some architecture (like mips, s390 and tile,) their current
      arch-specific follow_huge_(pmd|pud)() are effectively identical with the
      common code, so this patch lets these architecture use the common code.
      
      One exception is metag, where pmd_huge() could return non-zero but it
      expects follow_huge_pmd() to always return NULL.  This means that we need
      arch-specific implementation which returns NULL.  This behavior looks
      strange to me (because non-zero pmd_huge() implies that the architecture
      supports PMD-based hugepage, so follow_huge_pmd() can/should return some
      relevant value,) but that's beyond this cleanup patch, so let's keep it.
      
      Justification of non-trivial changes:
      - in s390, follow_huge_pmd() checks !MACHINE_HAS_HPAGE at first, and this
        patch removes the check. This is OK because we can assume MACHINE_HAS_HPAGE
        is true when follow_huge_pmd() can be called (note that pmd_huge() has
        the same check and always returns 0 for !MACHINE_HAS_HPAGE.)
      - in s390 and mips, we use HPAGE_MASK instead of PMD_MASK as done in common
        code. This patch forces these archs use PMD_MASK, but it's OK because
        they are identical in both archs.
        In s390, both of HPAGE_SHIFT and PMD_SHIFT are 20.
        In mips, HPAGE_SHIFT is defined as (PAGE_SHIFT + PAGE_SHIFT - 3) and
        PMD_SHIFT is define as (PAGE_SHIFT + PAGE_SHIFT + PTE_ORDER - 3), but
        PTE_ORDER is always 0, so these are identical.
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: NHugh Dickins <hughd@google.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Luiz Capitulino <lcapitulino@redhat.com>
      Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: Steve Capper <steve.capper@linaro.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      61f77eda
  9. 11 2月, 2015 1 次提交
  10. 10 2月, 2015 4 次提交
  11. 09 2月, 2015 2 次提交
  12. 07 2月, 2015 2 次提交
    • A
      ARM: 8297/1: cache-l2x0: optimize aurora range operations · 1d889679
      Arnd Bergmann 提交于
      The aurora_inv_range(), aurora_clean_range() and aurora_flush_range()
      functions are highly redundant, both in source and in object code, and
      they are harder to understand than necessary.
      
      By moving the range loop into the aurora_pa_range() function, they
      become trivial wrappers, and the object code start looking like what
      one would expect for an optimal implementation.
      
      Further optimization may be possible by using the per-CPU "virtual"
      registers to avoid the spinlocks in most cases.
      
       (on Armada 370 RD and Armada XP GP, boot tested, plus a little bit of
       DMA traffic by reading data from a SD card)
      Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1d889679
    • A
      ARM: 8296/1: cache-l2x0: clean up aurora cache handling · 20e783e3
      Arnd Bergmann 提交于
      The aurora cache controller is the only remaining user of a couple
      of functions in this file and are completely unused when that is
      disabled, leading to build warnings:
      
      arch/arm/mm/cache-l2x0.c:167:13: warning: 'l2x0_cache_sync' defined but not used [-Wunused-function]
      arch/arm/mm/cache-l2x0.c:184:13: warning: 'l2x0_flush_all' defined but not used [-Wunused-function]
      arch/arm/mm/cache-l2x0.c:194:13: warning: 'l2x0_disable' defined but not used [-Wunused-function]
      
      With the knowledge that the code is now aurora-specific, we can
      simplify it noticeably:
      
      - The pl310 errata workarounds are not needed on aurora and can be removed
      - As confirmed by Thomas Petazzoni from the data sheet, the cache_wait()
        macro is never needed.
      - No need to hold the lock across atomic cache sync
      - We can load the l2x0_base into a local variable across operations
      
      There should be no functional change in this patch, but readability
      and the generated object code improves, along with avoiding the
      warnings.
      
       (on Armada 370 RD and Armada XP GP, boot tested, plus a little bit of
       DMA traffic by reading data from a SD card)
      Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      20e783e3
  13. 06 2月, 2015 1 次提交
    • P
      kvm: add halt_poll_ns module parameter · f7819512
      Paolo Bonzini 提交于
      This patch introduces a new module parameter for the KVM module; when it
      is present, KVM attempts a bit of polling on every HLT before scheduling
      itself out via kvm_vcpu_block.
      
      This parameter helps a lot for latency-bound workloads---in particular
      I tested it with O_DSYNC writes with a battery-backed disk in the host.
      In this case, writes are fast (because the data doesn't have to go all
      the way to the platters) but they cannot be merged by either the host or
      the guest.  KVM's performance here is usually around 30% of bare metal,
      or 50% if you use cache=directsync or cache=writethrough (these
      parameters avoid that the guest sends pointless flush requests, and
      at the same time they are not slow because of the battery-backed cache).
      The bad performance happens because on every halt the host CPU decides
      to halt itself too.  When the interrupt comes, the vCPU thread is then
      migrated to a new physical CPU, and in general the latency is horrible
      because the vCPU thread has to be scheduled back in.
      
      With this patch performance reaches 60-65% of bare metal and, more
      important, 99% of what you get if you use idle=poll in the guest.  This
      means that the tunable gets rid of this particular bottleneck, and more
      work can be done to improve performance in the kernel or QEMU.
      
      Of course there is some price to pay; every time an otherwise idle vCPUs
      is interrupted by an interrupt, it will poll unnecessarily and thus
      impose a little load on the host.  The above results were obtained with
      a mostly random value of the parameter (500000), and the load was around
      1.5-2.5% CPU usage on one of the host's core for each idle guest vCPU.
      
      The patch also adds a new stat, /sys/kernel/debug/kvm/halt_successful_poll,
      that can be used to tune the parameter.  It counts how many HLT
      instructions received an interrupt during the polling period; each
      successful poll avoids that Linux schedules the VCPU thread out and back
      in, and may also avoid a likely trip to C1 and back for the physical CPU.
      
      While the VM is idle, a Linux 4 VCPU VM halts around 10 times per second.
      Of these halts, almost all are failed polls.  During the benchmark,
      instead, basically all halts end within the polling period, except a more
      or less constant stream of 50 per second coming from vCPUs that are not
      running the benchmark.  The wasted time is thus very low.  Things may
      be slightly different for Windows VMs, which have a ~10 ms timer tick.
      
      The effect is also visible on Marcelo's recently-introduced latency
      test for the TSC deadline timer.  Though of course a non-RT kernel has
      awful latency bounds, the latency of the timer is around 8000-10000 clock
      cycles compared to 20000-120000 without setting halt_poll_ns.  For the TSC
      deadline timer, thus, the effect is both a smaller average latency and
      a smaller variance.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      f7819512