summaryrefslogtreecommitdiff
path: root/arch/arm/mm
AgeCommit message (Collapse)Author
2018-06-21arm: fix build issue caused by spectre/meltdown patchMarcel Ziswiler
Currently building fails as follows due to an erroneous + sign in front of an #endif in arch/arm/mm/fsr-3level.c: In file included from /home/user/linux-3.10/arch/arm/mm/fault.c:554:0: /home/user/linux-3.10/arch/arm/mm/fsr-3level.c:68:0: error: unterminated #else make[2]: *** [/home/user/linux-3.10/scripts/Makefile.build:308: arch/arm/mm/fault.o] Error 1 This fixes commit de3110548b04 ("arm: Invalidate BTB on prefetch abort outside of user mapping on Cortex A8, A9, A12 and A17"). Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
2018-04-28arm: Add BTB invalidation on switch_mm for Cortex-A9, A12 and A17Marc Zyngier
** Not yet queued for inclusion in mainline ** In order to avoid aliasing attacks against the branch predictor, some implementations require to invalidate the BTB when switching from one user context to another. For this, we reuse the existing implementation for Cortex-A8, and apply it to A9, A12 and A17. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Change-Id: Ibbd99465a5dcf5eda6a29dd23a55f9b21b280e65 Reviewed-on: https://git-master.nvidia.com/r/1704129 GVS: Gerrit_Virtual_Submit Reviewed-by: Bibek Basu <bbasu@nvidia.com> Tested-by: Bibek Basu <bbasu@nvidia.com>
2018-04-28arm: Invalidate icache on prefetch abort outside of user mapping on Cortex-A15Marc Zyngier
** Not yet queued for inclusion in mainline ** In order to prevent aliasing attacks on the branch predictor, invalidate the icache on Cortex-A15, which has the side effect of invalidating the BTB. This requires ACTLR[0] to be set to 1 (secure operation). Change-Id: I4bb8e3ec05853d739bebd8fb3c61657e252808c0 Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Jeetesh Burman <jburman@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1698400 GVS: Gerrit_Virtual_Submit Reviewed-by: Bibek Basu <bbasu@nvidia.com> Tested-by: Bibek Basu <bbasu@nvidia.com>
2018-04-28arm: Invalidate BTB on prefetch abort outside of user mapping on Cortex A8, ↵Marc Zyngier
A9, A12 and A17 ** Not yet queued for inclusion in mainline ** In order to prevent aliasing attacks on the branch predictor, invalidate the BTB on CPUs that are known to be affected when taking a prefetch abort on a address that is outside of a user task limit. __ACCESS_CP15 and __ACCESS_CP15_64 added from below link: https://patchwork.kernel.org/patch/9234399/ Change-Id: Ib8c9807f5e787437e66b83ea0305d75cce4bbbdf Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Jeetesh Burman <jburman@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1698399 GVS: Gerrit_Virtual_Submit Reviewed-by: Bibek Basu <bbasu@nvidia.com> Tested-by: Bibek Basu <bbasu@nvidia.com>
2018-04-28arm: Add icache invalidation on switch_mm for Cortex-A15Marc Zyngier
** Not yet queued for inclusion in mainline ** In order to avoid aliasing attacks against the branch predictor, Cortex-A15 require to invalidate the BTB when switching from one user context to another. The only way to do so on this CPU is to perform an ICIALLU, having set ACTLR[0] to 1 from secure mode. Change-Id: Ib0083803d75a4399b8225193349a4b490d1776a1 Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Jeetesh Burman <jburman@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1698398 GVS: Gerrit_Virtual_Submit Reviewed-by: Bibek Basu <bbasu@nvidia.com> Tested-by: Bibek Basu <bbasu@nvidia.com>
2018-01-19mm: larger stack guard gap, between vmasSri Krishna chowdary
commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream. Stack guard page is a useful feature to reduce a risk of stack smashing into a different mapping. We have been using a single page gap which is sufficient to prevent having stack adjacent to a different mapping. But this seems to be insufficient in the light of the stack usage in userspace. E.g. glibc uses as large as 64kB alloca() in many commonly used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX] which is 256kB or stack strings with MAX_ARG_STRLEN. This will become especially dangerous for suid binaries and the default no limit for the stack size limit because those applications can be tricked to consume a large portion of the stack and a single glibc call could jump over the guard page. These attacks are not theoretical, unfortunatelly. Make those attacks less probable by increasing the stack guard gap to 1MB (on systems with 4k pages; but make it depend on the page size because systems with larger base pages might cap stack allocations in the PAGE_SIZE units) which should cover larger alloca() and VLA stack allocations. It is obviously not a full fix because the problem is somehow inherent, but it should reduce attack space a lot. One could argue that the gap size should be configurable from userspace, but that can be done later when somebody finds that the new 1MB is wrong for some special case applications. For now, add a kernel command line option (stack_guard_gap) to specify the stack gap size (in page units). Implementation wise, first delete all the old code for stack guard page: because although we could get away with accounting one extra page in a stack vma, accounting a larger gap can break userspace - case in point, a program run with "ulimit -S -v 20000" failed when the 1MB gap was counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK and strict non-overcommit mode. Instead of keeping gap inside the stack vma, maintain the stack guard gap as a gap between vmas: using vm_start_gap() in place of vm_start (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few places which need to respect the gap - mainly arch_get_unmapped_area(), and and the vma tree's subtree_gap support for that. Bug 1946430 Change-Id: I9a66aabc34b687996fb971e01bb0ef30a3d4de7d Original-patch-by: Oleg Nesterov <oleg@redhat.com> Original-patch-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Tested-by: Helge Deller <deller@gmx.de> # parisc Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [wt: backport to 4.11: adjust context] [wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide] [wt: backport to 4.4: adjust context ; drop ppc hugetlb_radix changes] Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sri Krishna chowdary <schowdary@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1509390 GVS: Gerrit_Virtual_Submit Tested-by: Bibek Basu <bbasu@nvidia.com> Reviewed-by: Bibek Basu <bbasu@nvidia.com>
2015-05-14arm: mm: Add v7_clean_kern_cache_louisKrishna Reddy
This allows perform L1 cache clean alone. Bug 200077334 Change-Id: I7a6106ed53755df33e09e3fa32a9e2524eb98649 Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: http://git-master/r/742252 GVS: Gerrit_Virtual_Submit Reviewed-by: Bibek Basu <bbasu@nvidia.com>
2014-06-05Merge branch 'linux-3.10.40' into rel-21Ishan Mittal
Bug 200004122 Conflicts: drivers/cpufreq/cpufreq.c drivers/regulator/core.c sound/soc/codecs/max98090.c Change-Id: I9418a05ad5c56b2e902249218bac2fa594d99f56 Signed-off-by: Ishan Mittal <imittal@nvidia.com>
2014-05-16mm: allow >2GB virtual space for legacy mmapKrishna Reddy
Bug 1380691 Legacy mmap layout has virtual space starts from TASK_UNMAPPED_BASE. This prevents some apps/games requiring >2GB memory to run correctly. This patch allows allocating lower virtual memory in case legacy mmap space is running out. Change-Id: Ied470e5f7811c461a1ad94cc7ff5b0babda382bf Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Signed-off-by: Li Li <lli5@nvidia.com> Reviewed-on: http://git-master/r/394408 (cherry picked from commit 899c0048c97307a460764a1d4032819091279bd1) Reviewed-on: http://git-master/r/410327
2014-05-13ARM: 7840/1: LPAE: don't reject mapping /dev/mem above 4GBSergey Dyasly
commit 3159f372354e8e1f5dee714663d705dd2c7e0759 upstream. With LPAE enabled, physical address space is larger than 4GB. Allow mapping any part of it via /dev/mem by using PHYS_MASK to determine valid range. PHYS_MASK covers 40 bits with LPAE enabled and 32 bits otherwise. Reported-by: Vassili Karpov <av1474@comtv.ru> Signed-off-by: Sergey Dyasly <dserrg@gmail.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: hujianyang <hujianyang@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-06ARM: 7728/1: mm: Use phys_addr_t properly for ioremap functionsLaura Abbott
commit 9b97173e785a54c5df0aa23d1e1f680f61e36e43 upstream. Several of the ioremap functions use unsigned long in places resulting in truncation if physical addresses greater than 4G are passed in. Change the types of the functions and the callers accordingly. Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Wang Nan <wangnan0@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-06ARM: 7954/1: mm: remove remaining domain support from ARMv6Will Deacon
commit b6ccb9803e90c16b212cf4ed62913a7591e79a39 upstream. CPU_32v6 currently selects CPU_USE_DOMAINS if CPU_V6 and MMU. This is because ARM 1136 r0pX CPUs lack the v6k extensions, and therefore do not have hardware thread registers. The lack of these registers requires the kernel to update the vectors page at each context switch in order to write a new TLS pointer. This write must be done via the userspace mapping, since aliasing caches can lead to expensive flushing when using kmap. Finally, this requires the vectors page to be mapped r/w for kernel and r/o for user, which has implications for things like put_user which must trigger CoW appropriately when targetting user pages. The upshot of all this is that a v6/v7 kernel makes use of domains to segregate kernel and user memory accesses. This has the nasty side-effect of making device mappings executable, which has been observed to cause subtle bugs on recent cores (e.g. Cortex-A15 performing a speculative instruction fetch from the GIC and acking an interrupt in the process). This patch solves this problem by removing the remaining domain support from ARMv6. A new memory type is added specifically for the vectors page which allows that page (and only that page) to be mapped as user r/o, kernel r/w. All other user r/o pages are mapped also as kernel r/o. Patch co-developed with Russell King. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-04-30ARM: 7941/2: Fix incorrect FDT initrd parameter overrideBen Peddell
Commit 65939301acdb (arm: set initrd_start/initrd_end for fdt scan) caused the FDT initrd_start and initrd_end to override the phys_initrd_start and phys_initrd_size set by the initrd= kernel parameter. With this patch initrd_start and initrd_end will be overridden if phys_initrd_start and phys_initrd_size are set by the kernel initrd= parameter. Fixes: 65939301acdb (arm: set initrd_start/initrd_end for fdt scan) (cherry picked from commit 4c235cb9e35407bdb4a2debeef4dc8721e8f91f2) Conflicts: arch/arm/mm/init.c Change-Id: Ie88bf6e12b69dc99bfd7f40c5d9c09ab6fbe65c1 Signed-off-by: Ben Peddell <klightspeed@killerwolves.net> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-04-30of: remove early_init_dt_setup_initrd_archRob Herring
All arches do essentially the same thing now for early_init_dt_setup_initrd_arch, so it can now be removed. Conflicts: arch/arm/mm/init.c arch/c6x/kernel/devicetree.c arch/powerpc/kernel/prom.c (cherry picked from commit 29eb45a9ab4839a1e9cef2bcf369b918c9c4fcad) Acked-by: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Mark Salter <msalter@redhat.com> Cc: Aurelien Jacquiot <a-jacquiot@ti.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Jonas Bonn <jonas@southpole.se> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Acked-by: Grant Likely <grant.likely@linaro.org> Change-Id: I84b59cec16fa7e96fa8ff3de04aa959f7039a7a9 Signed-off-by: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Ishan Mittal <imittal@nvidia.com>
2014-04-30of: Specify initrd location using 64-bitSantosh Shilimkar
On some PAE architectures, the entire range of physical memory could reside outside the 32-bit limit. These systems need the ability to specify the initrd location using 64-bit numbers. This patch globally modifies the early_init_dt_setup_initrd_arch() function to use 64-bit numbers instead of the current unsigned long. There has been quite a bit of debate about whether to use u64 or phys_addr_t. It was concluded to stick to u64 to be consistent with rest of the device tree code. As summarized by Geert, "The address to load the initrd is decided by the bootloader/user and set at that point later in time. The dtb should not be tied to the kernel you are booting" More details on the discussion can be found here: https://lkml.org/lkml/2013/6/20/690 https://lkml.org/lkml/2012/9/13/544 (cherry picked from commit 374d5c9964c10373ba39bbe934f4262eb87d7114) Change-Id: Iab36378e1de4e6c2cb07a3b88aeb5ff4afbe535b Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Rob Herring <rob.herring@calxeda.com> Acked-by: Vineet Gupta <vgupta@synopsys.com> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
2014-04-23arm: dma-mapping: fix wrong print sizeHiroshi Doyu
Please refer to "Documentation/printk-formats.txt". Change-Id: I3b14a2dfbe98edce0c09fcef6d5609299c59e64a Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/394698 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> Tested-by: Krishna Reddy <vdumpa@nvidia.com>
2014-04-23arm: dma-mapping: fix wrong end addressHiroshi Doyu
The end address shouldn't overwrap the next start address. Change-Id: I48f95f43b79b9e678908a2a6f0562347d671fcad Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/394697 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> Tested-by: Krishna Reddy <vdumpa@nvidia.com>
2014-04-04arm: dma-mapping: fix incorrect phys address in trace messageKrishna Reddy
Fix incorrect phys address printed in trace message in arm_coherent_iommu_unmap_page(). iommu_iova_to_phys() is called after unmap iova in arm_coherent_iommu_unmap_page(). This causes invalid phys address printed in trace message. Change-Id: I94acbfc9ef6f25c765ed3057b474596c8f12c6dc Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: http://git-master/r/391952 GVS: Gerrit_Virtual_Submit Reviewed-by: Alex Waterman <alexw@nvidia.com>
2014-04-04arm: dma-mapping: add missing trace print in unmap_pageKrishna Reddy
Add missing trace print in arm_iommu_unmap_page. Change-Id: I77914350aadccb0688b02658185e26652d4fdf2b Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: http://git-master/r/391951 GVS: Gerrit_Virtual_Submit Reviewed-by: Alex Waterman <alexw@nvidia.com>
2014-04-04arm: dma-mapping: pass correct args to trace_dma_map_pageKrishna Reddy
Change-Id: Id97ea4af04323f4a4c18597a4dba0423c3061a27 Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: http://git-master/r/391950 GVS: Gerrit_Virtual_Submit Reviewed-by: Alex Waterman <alexw@nvidia.com>
2014-04-03ARM: 7963/1: mm: report both sections from PMDKees Cook
On 2-level page table systems, the PMD has 2 section entries. Report these, otherwise ARM_PTDUMP will miss reporting permission changes on odd section boundaries. Change-Id: I76d40f4b6451abdcdc5e0a4f5e341ec5be2898e1 Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Steve Capper <steve.capper@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/391334 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
2014-04-03ARM: add support to dump the kernel page tablesRussell King
This patch allows the kernel page tables to be dumped via a debugfs file, allowing kernel developers to check the layout of the kernel page tables and the verify the various permissions and type settings. Change-Id: Ic7447182c8e5dc18a17338d7cb8abef983b1303e Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/391319 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
2014-04-03ARM: mm: Transparent huge page support for LPAE systems.Catalin Marinas
The patch adds support for THP (transparent huge pages) to LPAE systems. When this feature is enabled, the kernel tries to map anonymous pages as 2MB sections where possible. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> [steve.capper@linaro.org: symbolic constants used, value of PMD_SECT_SPLITTING adjusted, tlbflush.h included in pgtable.h, added PROT_NONE support.] Signed-off-by: Steve Capper <steve.capper@linaro.org> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Conflicts: arch/arm/Kconfig arch/arm/include/asm/pgtable-3level.h Change-Id: Iaf6bd59ffdc56249914691063f3931cc0422230d Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/391318 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
2014-04-03ARM: 7781/1: mmu: Add debug_ll_io_init() mappings to early mappingsStephen Boyd
Failure to add the mapping created in debug_ll_io_init() can lead to the BUG_ON() triggering in lib/ioremap.c:27 if the static virtual address decided for the debug_ll mapping overlaps with another mapping that is created later. This happens because the generic ioremap code has no idea there is a mapping there and it tries to place a mapping in the same location and blows up when it sees that there is a pte already present. kernel BUG at lib/ioremap.c:27! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc2-00042-g2af0c67-dirty #316 task: ef088000 ti: ef082000 task.ti: ef082000 PC is at ioremap_page_range+0x16c/0x198 LR is at ioremap_page_range+0xf0/0x198 pc : [<c04cb874>] lr : [<c04cb7f8>] psr: 20000113 sp : ef083e78 ip : af140000 fp : ef083ebc r10: ef7fc100 r9 : ef7fc104 r8 : 000af174 r7 : 00000647 r6 : beffffff r5 : f004c000 r4 : f0040000 r3 : af173417 r2 : 16440653 r1 : af173e07 r0 : ef7fc8fc Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: 8020406a DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xef082238) Stack: (0xef083e78 to 0xef084000) 3e60: 00040000 ef083eec 3e80: bf134000 f004bfff c0207c00 f004c000 c02fc120 f000c000 c15e7800 00040000 3ea0: ef083eec 00000647 c098ba9c c0953544 ef083edc ef083ec0 c021b82c c04cb714 3ec0: c09cdc50 00000040 ef0f1e00 ef1003c0 ef083f14 ef083ee0 c09535bc c021b7bc 3ee0: c0953544 c04d0c6c c094e2cc c1600be4 c07440c4 c09a6888 00000002 c0a15f00 3f00: ef082000 00000000 ef083f54 ef083f18 c0208728 c0953550 00000002 c1600bfc 3f20: c08e3fac c0839918 ef083f54 c1600b80 c09a6888 c0a15f00 0000008b c094e2cc 3f40: c098ba9c c098bab8 ef083f94 ef083f58 c094ea0c c020865c 00000002 00000002 3f60: c094e2cc 00000000 c025b674 00000000 c06ff860 00000000 00000000 00000000 3f80: 00000000 00000000 ef083fac ef083f98 c06ff878 c094e910 00000000 00000000 3fa0: 00000000 ef083fb0 c020efe8 c06ff86c 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 c0595108 [<c04cb874>] (ioremap_page_range+0x16c/0x198) from [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4) [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4) from [<c09535bc>] (atomic_pool_init+0x78/0x128) [<c09535bc>] (atomic_pool_init+0x78/0x128) from [<c0208728>] (do_one_initcall+0xd8/0x198) [<c0208728>] (do_one_initcall+0xd8/0x198) from [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0) [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0) from [<c06ff878>] (kernel_init+0x18/0xf4) [<c06ff878>] (kernel_init+0x18/0xf4) from [<c020efe8>] (ret_from_fork+0x14/0x20) Code: e50b0040 ebf54b2f e51b0040 eaffffee (e7f001f2) Fix it by telling generic layers about the static mapping via iotable_init(). This also has the nice side effect of letting you see the mapping in procfs' vmallocinfo file. Cc: Rob Herring <rob.herring@calxeda.com> Cc: Stephen Warren <swarren@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Conflicts: arch/arm/mm/mmu.c Change-Id: Iebc142fd4fbd47a7bdbb4f67786d35aef4ece508 Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/391317 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
2014-04-02ARM: dma-mapping: add device_is_iommuable()Hiroshi Doyu
A helper function to check if a device is iommuable or not. Bug 1490400 Change-Id: I65b803e57ad19e32214df8fde054a4f68535a74b Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/390156 Reviewed-by: Sri Krishna Chowdary <schowdary@nvidia.com>
2014-03-13Merge branch 'linux-3.10.33' into dev-kernel-3.10Deepak Nibade
Bug 1456092 Change-Id: Ic563f451abb08754fea0e2bbf0ce065ca2e6e770 Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
2014-03-13Merge branch 'linux-3.10.33' into dev-kernel-3.10Deepak Nibade
Bug 1456092 Change-Id: I3021247ec68a3c2dddd9e98cde13d70a45191d53 Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
2014-03-11ARM: Export LoUIS flushAntti P Miettinen
Export flushing to LoUIS. Change-Id: If9e3b7119dd4dbe7bdcf6caee5e1632e77b2c288 Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com> Reviewed-on: http://git-master/r/379551 Reviewed-by: Juha Tukkinen <jtukkinen@nvidia.com>
2014-03-10Revert "[ARM] mm: add memory type for inner-writeback"Krishna Reddy
This reverts commit b6e576d7370f64b78f828af495b1a21ffb56f887. Change-Id: I872c3c06e7c8a5986ba5aed57fa9cd7ec7fa2f88 Reviewed-on: http://git-master/r/354411 Reviewed-by: Bo Yan <byan@nvidia.com> Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> Tested-by: Krishna Reddy <vdumpa@nvidia.com>
2014-03-06ARM: 7953/1: mm: ensure TLB invalidation is complete before enabling MMUWill Deacon
commit bae0ca2bc550d1ec6a118fb8f2696f18c4da3d8e upstream. During __v{6,7}_setup, we invalidate the TLBs since we are about to enable the MMU on return to head.S. Unfortunately, without a subsequent dsb instruction, the invalidation is not guaranteed to have completed by the time we write to the sctlr, potentially exposing us to junk/stale translations cached in the TLB. This patch reworks the init functions so that the dsb used to ensure completion of cache/predictor maintenance is also used to ensure completion of the TLB invalidation. Reported-by: Albin Tonnerre <Albin.Tonnerre@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-06ARM: dma-mapping: fix GFP_ATOMIC macro usageMarek Szyprowski
commit 10c8562f932d89c030083e15f9279971ed637136 upstream. GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an atomic allocation, the code must test __GFP_WAIT flag presence. This patch fixes the issue introduced in v3.6-rc5 Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-03arm: mm: remove change_page_attr supportKrishna Reddy
It only supports cortex-a9 page table format and no longer in use from cortex-A15 based SOC's. Change-Id: Ic81eccab81b12dbf04e8ac13458f2560c4cd2328 Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: http://git-master/r/375705 Reviewed-by: Alex Waterman <alexw@nvidia.com> Reviewed-by: Hiroshi Doyu <hdoyu@nvidia.com>
2014-02-09Revert "ARM: tegra: trustzone: Single kernel to work in both secure and ↵Varun Wadekar
non-secure mode." This reverts commit 7f93a0dddf39f372c064f772f9af6903e91aaacf as the t132ref builds break with the following errors - <android>/kernel/drivers/platform/tegra/../../../arch/arm/mach-tegra/reset.c:45: undefined reference to `is_secure_mode' <android>/kernel/drivers/platform/tegra/../../../arch/arm/mach-tegra/reset.c:57: undefined reference to `is_secure_mode' <android>/kernel/drivers/platform/tegra/../../../arch/arm/mach-tegra/reset.c:58: undefined reference to `tegra_generic_smc' Change-Id: I4e44c2ffba4e1c013213e543b67f2d49a928b764 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Reviewed-on: http://git-master/r/365347
2014-02-09arch: arm: mm: dynamic check for secure/non-secure mode.Nitin Sehgal
- Replace compile time flag with runtime selection. - Same kernel should work in secure and non secure mode bug 1411345 Change-Id: I7b20121623aa432eaefe00f47115908595590f16 Signed-off-by: Nitin Sehgal <nsehgal@nvidia.com> Reviewed-on: http://git-master/r/362897 Reviewed-by: Varun Wadekar <vwadekar@nvidia.com> Tested-by: Varun Wadekar <vwadekar@nvidia.com>
2014-02-09ARM: tegra: trustzone: Single kernel to work in both secure and non-secure mode.Nitin Sehgal
- Remove CONFIG_TEGRA_USE_SECURE_KERNEL config option - Use DBGDSCR.NS bit to dynamically get secure/non-secure mode - Replace ifdefs with dynamic code. - Keep CONFIG_TRUSTED_LITTLE_KERNEL to enable secure os bug 1411345 Change-Id: I75ddfed7a35fcb30e2772bb43057ae022bcf09b3 Signed-off-by: Nitin Sehgal <nsehgal@nvidia.com> Reviewed-on: http://git-master/r/353155 Reviewed-by: Varun Wadekar <vwadekar@nvidia.com> Tested-by: Varun Wadekar <vwadekar@nvidia.com>
2013-12-19Merge "Merge tag 'v3.10.24' into HEAD" into dev-kernel-3.10Bharat Nihalani
2013-12-19ARM: dma-mapping: exclude DMA32, HIGHMEM for meta dataHiroshi Doyu
slab allocator doens't acceppt DMA32, HIGHMEM gfp flags, and the passed gfp param is for a buffer usage, not for meta data, page porter array. Drop DMA32, HIGHMEM for meta data allocation. Bug 1414172 Bug 1427490 Change-Id: Ie894c110ada185aed04d5fc41a46fa1de4bd9670 Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/346947 GVS: Gerrit_Virtual_Submit
2013-12-16Merge tag 'v3.10.24' into HEADAjay Nandakumar
This is the 3.10.24 stable release Change-Id: Ibd2734f93d44385ab86867272a1359158635133b
2013-12-12ARM: dma-mapping: alloc highmem w/o GFP_DMA*Hiroshi Doyu
There's a case that a client wants to avoid highmem explicitly. For example some PM code lets firmware access to pages during suspend/resume when IOMMU is off. This allows a client to specify a type of pages{GPF_DMA,GFP_DMA32} to not contradicting to GFP_HIGHMEM. This would be valid if AArch64 selects ZONE_DMA(32). Bug 1414172 Change-Id: I3c97262f9388094dae12a350420a3d184d1e7144 Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/343645 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> Tested-by: Krishna Reddy <vdumpa@nvidia.com>
2013-12-11ARM: fix booting low-vectors machinesRussell King
commit d8aa712c30148ba26fd89a5dc14de95d4c375184 upstream. Commit f6f91b0d9fd9 (ARM: allow kuser helpers to be removed from the vector page) required two pages for the vectors code. Although the code setting up the initial page tables was updated, the code which allocates page tables for new processes wasn't, neither was the code which tears down the mappings. Fix this. Fixes: f6f91b0d9fd9 ("ARM: allow kuser helpers to be removed from the vector page") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-12-11ARM: dma-mapping: Use %pa for {dma,phys}_addr_tHiroshi Doyu
The data size varis depending on LPAE, 32 or 64. Modified to support both without any build warnings. Change-Id: Iacb8cbbffdab9f7148a62315e011c9a3a74d9030 Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/339861 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
2013-12-04ARM: 7876/1: clear Thumb-2 IT state on exception handlingMarc Zyngier
commit e16b31bf47738f4498d7ce632e12d7d2a6a2492a upstream. The exception handling code fails to clear the IT state, potentially leading to incorrect execution of the fixup if the size of the IT block is more than one. Let fixup_exception do the IT sanitizing if a fixup has been found, and restore CPSR from the stack when returning from a data abort. Cc: Will Deacon <will.deacon@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-28arm: dma-mapping: support DMA_ATTR_ALLOC_EXACT_SIZEVandana Salve
This new attribute can handle allocation & release of memory of exact sizes by making call to attr version of dma_alloc_from_coherent/dma_release_from_coherent bug 1380639 Change-Id: I2af8c8131ff552ae5e0ac3a628139318b3395a73 Signed-off-by: Vandana Salve <vsalve@nvidia.com> Reviewed-on: http://git-master/r/334000 Reviewed-by: Hiroshi Doyu <hdoyu@nvidia.com> Tested-by: Hiroshi Doyu <hdoyu@nvidia.com>
2013-11-11Revert "Revert "arm: mm: cpa: remove APIs no longer used""Alex Waterman
This reverts commit e7f14c6091b152d0f4da8d5470ca987f5deecce6. Change-Id: I76d651932f7e57b92b24e380dbbd5cca00268ba3 Signed-off-by: Alex Waterman <alexw@nvidia.com> Reviewed-on: http://git-master/r/329040 GVS: Gerrit_Virtual_Submit Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
2013-11-07Revert "arm: mm: cpa: remove APIs no longer used"Krishna Reddy
This reverts commit 98ecd24717543e80280adfdbf4957e8f54e46a3a. Change-Id: I2a8b9aeba150b3f8b7ad00258bf659421683f5b4 Reviewed-on: http://git-master/r/328095 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> Tested-by: Krishna Reddy <vdumpa@nvidia.com>
2013-11-07arm: mm: cpa: remove APIs no longer usedAlex Waterman
Remove the unused APIs in the CPA code. Bug 1393434 Change-Id: I5b2fa8cbf77b79f108699fa2588754b182a24ec7 Signed-off-by: Alex Waterman <alexw@nvidia.com> Reviewed-on: http://git-master/r/327287 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
2013-11-06arm: mm: cpa: Only call update_page_count() with CPAAlex Waterman
If CPA is disabled this function call is not necessary. The ifdef is inside the if block since it prevents the compiler from complaining about an unused variable. Bug 1393434 Change-Id: If76bbf11f4751a25236a6ebe8b87e354a219b571 Signed-off-by: Alex Waterman <alexw@nvidia.com> Reviewed-on: http://git-master/r/326337 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
2013-10-03ARM: config: mutual exclusive CPA & LPAEBibek Basu
Make CONFIG_CPA and CONFIG_ARM_LPAE mutually exclusive. Bug 1374612 Change-Id: I1ec2dbe316a52633d19d122d42e18103a838c960 Signed-off-by: Bibek Basu <bbasu@nvidia.com> Reviewed-on: http://git-master/r/279798 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Kiran Adduri <kadduri@nvidia.com> Reviewed-by: Matt Craighead <mcraighead@nvidia.com> Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-by: Adeel Raza <araza@nvidia.com> Tested-by: Adeel Raza <araza@nvidia.com> Reviewed-by: Alexander Van Brunt <avanbrunt@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com> (cherry picked from commit 8b550aba000043ff10d9127a082c9faa7e85fcad) Signed-off-by: Ajay Nandakumar <anandakumarm@nvidia.com>
2013-10-02arm: mm: fix mm merge conflictAdeel Raza
Bug 1379902 Change-Id: I7e9419dbe2ea2386cee27343f419a8c2d383c706 Signed-off-by: Adeel Raza <araza@nvidia.com> Reviewed-on: http://git-master/r/280487 Reviewed-by: Automatic_Commit_Validation_User Reviewed-by: Alexander Van Brunt <avanbrunt@nvidia.com>
2013-10-01ARM: mm: Invalid pte for DEBUG_PAGEALLOCHiroshi Doyu
Invalid pte temporary for debug instead of using read-only page. This could oops at illegal read too. Bug 1365298 Change-Id: Ibe3f0f969cb1b1c16cd9fda26d029d8179f2c3b4 Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> Reviewed-on: http://git-master/r/278900 Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> (cherry picked from commit f2a12070ed983b4f2fce1610c59fb86bfc8a57b9) Signed-off-by: Ajay Nandakumar <anandakumarm@nvidia.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-12 00:18:14 +0000