Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 25 11月, 2015 1 次提交
    • A
      ARM/arm64: KVM: test properly for a PTE's uncachedness · e6fab544
      由 Ard Biesheuvel 提交于 
      The open coded tests for checking whether a PTE maps a page as
uncached use a flawed '(pte_val(xxx) & CONST) != CONST' pattern,
which is not guaranteed to work since the type of a mapping is
not a set of mutually exclusive bits

For HYP mappings, the type is an index into the MAIR table (i.e, the
index itself does not contain any information whatsoever about the
type of the mapping), and for stage-2 mappings it is a bit field where
normal memory and device types are defined as follows:

    #define MT_S2_NORMAL            0xf
    #define MT_S2_DEVICE_nGnRE      0x1

I.e., masking *and* comparing with the latter matches on the former,
and we have been getting lucky merely because the S2 device mappings
also have the PTE_UXN bit set, or we would misidentify memory mappings
as device mappings.

Since the unmap_range() code path (which contains one instance of the
flawed test) is used both for HYP mappings and stage-2 mappings, and
considering the difference between the two, it is non-trivial to fix
this by rewriting the tests in place, as it would involve passing
down the type of mapping through all the functions.

However, since HYP mappings and stage-2 mappings both deal with host
physical addresses, we can simply check whether the mapping is backed
by memory that is managed by the host kernel, and only perform the
D-cache maintenance if this is the case.

Cc: stable@vger.kernel.org
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: NPavel Fedin <p.fedin@samsung.com>
Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      e6fab544
  3. 18 11月, 2015 1 次提交
    • P
      ARM: dts: imx27.dtsi: change the clock information for usb · facf47ee
      由 Peter Chen 提交于 
      For imx27, it needs three clocks to let the controller work,
the old code is wrong, and usbmisc has not included clock handling
code any more. Without this patch, it will cause below data
abort when accessing usbmisc registers.

usbcore: registered new interface driver usb-storage
Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600
pgd = c0004000
[f4424600] *pgd=10000452(bad)
Internal error: : 8 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-next-20150701-dirty #3089
Hardware name: Freescale i.MX27 (Device Tree Support)
task: c7832b60 ti: c783e000 task.ti: c783e000
PC is at usbmisc_imx27_init+0x4c/0xbc
LR is at usbmisc_imx27_init+0x40/0xbc
pc : [<c03cb5c0>]    lr : [<c03cb5b4>]    psr: 60000093
sp : c783fe08  ip : 00000000  fp : 00000000
r10: c0576434  r9 : 0000009c  r8 : c7a773a0
r7 : 01000000  r6 : 60000013  r5 : c7a776f0  r4 : c7a773f0
r3 : f4424600  r2 : 00000000  r1 : 00000001  r0 : 00000001
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005317f  Table: a0004000  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc783e190)
Stack: (0xc783fe08 to 0xc7840000)
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Reported-by: NFabio Estevam <fabio.estevam@freescale.com>
Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
Cc: <stable@vger.kernel.org> #v4.1+
Acked-by: NShawn Guo <shawnguo@kernel.org>
      facf47ee
  5. 17 11月, 2015 1 次提交
  7. 10 11月, 2015 1 次提交
  9. 07 11月, 2015 2 次提交
    • M
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      由 Mel Gorman 提交于 
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts.  They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve".  __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".

Over time, callers had a requirement to not block when fallback options
were available.  Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.

This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative.  High priority users continue to use
__GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.

This patch then converts a number of sites

o __GFP_ATOMIC is used by callers that are high priority and have memory
  pools for those requests. GFP_ATOMIC uses this flag.

o Callers that have a limited mempool to guarantee forward progress clear
  __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
  into this category where kswapd will still be woken but atomic reserves
  are not used as there is a one-entry mempool to guarantee progress.

o Callers that are checking if they are non-blocking should use the
  helper gfpflags_allow_blocking() where possible. This is because
  checking for __GFP_WAIT as was done historically now can trigger false
  positives. Some exceptions like dm-crypt.c exist where the code intent
  is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
  flag manipulations.

o Callers that built their own GFP flags instead of starting with GFP_KERNEL
  and friends now also need to specify __GFP_KSWAPD_RECLAIM.

The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.

The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL.  They may
now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.
Signed-off-by: NMel Gorman <mgorman@techsingularity.net>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Acked-by: NMichal Hocko <mhocko@suse.com>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
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>
      d0164adc
    • S
      Revert "ARM: dts: twl4030: Add iio properties for bci subnode" · 829a7da0
      由 Sebastian Reichel 提交于 
      This reverts commit af19161a,
which breaks the omap3 device tree build due to a wrong reference.

I accidently queued this change via the power supply subsystem while
telling Marek at the same time, that it should go through Tony.
Following that I did miss Stephen's messages about the build failure in
linux-next and since he switched to merging an older snapshot nobody
else noticed the problem in my tree. I didn't notice myself, since I
did not build any device tree files assuming none have changed by me.
Signed-off-by: NSebastian Reichel <sre@kernel.org>
Reported-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
      829a7da0
  11. 06 11月, 2015 1 次提交
    • A
      uaccess: reimplement probe_kernel_address() using probe_kernel_read() · 0ab32b6f
      由 Andrew Morton 提交于 
      probe_kernel_address() is basically the same as the (later added)
probe_kernel_read().

The return value on EFAULT is a bit different: probe_kernel_address()
returns number-of-bytes-not-copied whereas probe_kernel_read() returns
-EFAULT.  All callers have been checked, none cared.

probe_kernel_read() can be overridden by the architecture whereas
probe_kernel_address() cannot.  parisc, blackfin and um do this, to insert
additional checking.  Hence this patch possibly fixes obscure bugs,
although there are only two probe_kernel_address() callsites outside
arch/.

My first attempt involved removing probe_kernel_address() entirely and
converting all callsites to use probe_kernel_read() directly, but that got
tiresome.

This patch shrinks mm/slab_common.o by 218 bytes.  For a single
probe_kernel_address() callsite.

Cc: Steven Miao <realmz6@gmail.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ab32b6f
  13. 03 11月, 2015 4 次提交
  15. 02 11月, 2015 2 次提交
  17. 31 10月, 2015 2 次提交
  19. 29 10月, 2015 1 次提交
  21. 28 10月, 2015 2 次提交
  23. 27 10月, 2015 5 次提交
    • P
      ARM: DTS: am437x: Use the new DT bindings for the eDMA3 · e3faf2b8
      由 Peter Ujfalusi 提交于 
      Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      e3faf2b8
    • P
      ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 · d871cd2e
      由 Peter Ujfalusi 提交于 
      Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      d871cd2e
    • M
      ARM: dts: uniphier: add outer cache controller nodes · 7c62f299
      由 Masahiro Yamada 提交于 
      Add L2 cache controller nodes for all the UniPhier SoC DTSI.
Also, add an L3 cache controller node for PH1-Pro5 DTSI.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      7c62f299
    • M
      ARM: uniphier: rework SMP operations to use trampoline code · b1e4006a
      由 Masahiro Yamada 提交于 
      The complexity of the boot sequence of UniPhier SoC family is
a PITA due to the following hardware limitations:

[1] No dedicated on-chip SRAM
SoCs in general have small SRAM, on which a tiny firmware or a boot
loader can run before SDRAM is initialized.  As UniPhier SoCs do not
have any dedicated SRAM accessible from CPUs, the locked outer cache
is used instead.  Due to the ARM specification, to have access to
the outer cache, the MMU must be enabled.  This is done for all CPU
cores by the program hard-wired in the boot ROM.  The boot ROM code
loads a small amount of program (this is usually SPL of U-Boot) from
a non-volatile device onto the locked outer cache, and the primary
CPU jumps to it.  The secondary CPUs stay in the boot ROM until they
are kicked by the primary CPU.

[2] CPUs can not directly jump to SDRAM address space
As mentioned above, the MMU is enable for all the CPUs with the page
table hard-wired in the boot ROM.  Unfortunately, the page table only
has minimal sets of valid sections; all the sections of SDRAM address
space are zero-filled.  That means all the CPUs, including secondary
ones, can not jump directly to SDRAM address space.  So, the primary
CPU must bring up secondary CPUs to accessible address mapped onto
the outer cache, then again kick them to SDRAM address space.

Before this commit, this complex task was done with help of a boot
loader (U-Boot); U-Boot SPL brings up the secondary CPUs to the entry
of U-Boot SPL and they stay there until they are kicked by Linux.
This is not nice because a boot loader must put the secondary CPUs
into a certain state expected by the kernel.  It makes difficult to
port another boot loader because the boot loader and the kernel must
work in sync to wake up the secondary CPUs.

This commit reworks the SMP operations so that they do not rely on
particular boot loader implementation; the SMP operations (platsmp.c)
put trampoline code (headsmp.S) on a locked way of the outer cache.
The secondary CPUs jump from the boot ROM to secondary_entry via the
trampoline code.  The boot loader no longer needs to take care of SMP.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      b1e4006a
    • M
      ARM: uniphier: add outer cache support · e7ecbc05
      由 Masahiro Yamada 提交于 
      This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      e7ecbc05
  25. 26 10月, 2015 7 次提交
  27. 24 10月, 2015 10 次提交