History log of /linux-master/arch/xtensa/mm/Makefile
Revision Date Author Comments
# a8f0c31f 10-Dec-2019 Max Filippov <jcmvbkbc@gmail.com>

xtensa: noMMU: allow handling protection faults

Many xtensa CPU cores without full MMU still have memory protection
features capable of raising exceptions for invalid instruction
fetches/data access. Allow handling such exceptions. This improves
behavior of processes that pass invalid memory pointers to syscalls in
noMMU configs: in case of exception the kernel instead of killing the
process is now able to return -EINVAL from a syscall.

Introduce CONFIG_PFAULT that controls whether protection fault code is
enabled and register handlers for common memory protection exceptions
when it is enabled.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# ec8f24b7 19-May-2019 Thomas Gleixner <tglx@linutronix.de>

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# c633544a 03-Dec-2017 Max Filippov <jcmvbkbc@gmail.com>

xtensa: add support for KASAN

Cover kernel addresses above 0x90000000 by the shadow map. Enable
HAVE_ARCH_KASAN when MMU is enabled. Provide kasan_early_init that fills
shadow map with writable copies of kasan_zero_page. Call
kasan_early_init right after mmu initialization in the setup_arch.
Provide kasan_init that allocates proper shadow map pages from the
memblock and puts these pages into the shadow map for addresses from
VMALLOC area to the end of KSEG. Call kasan_init right after memblock
initialization. Don't use KASAN for the boot code, MMU and KASAN
initialization and page fault handler. Make kernel stack size 4 times
larger when KASAN is enabled to avoid stack overflows.
GCC 7.3, 8 or newer is required to build the xtensa kernel with KASAN.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 5bb8def5 10-Dec-2015 Max Filippov <jcmvbkbc@gmail.com>

xtensa: support ioremap for memory outside KIO region

Map physical memory outside KIO region into the vmalloc area.
Unmap it with vunmap.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# b6cee17b 21-Sep-2014 Max Filippov <jcmvbkbc@gmail.com>

xtensa: nommu: don't build most of the cache flushing code

Most cache flushing code is only relevant for MMU. Don't build it for
nommu configuration.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# 65559100 03-Feb-2014 Max Filippov <jcmvbkbc@gmail.com>

xtensa: add HIGHMEM support

Introduce fixmap area just below the vmalloc region. Use it for atomic
mapping of high memory pages.
High memory on cores with cache aliasing is not supported and is still
to be implemented. Fail build for such configurations for now.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>


# e5083a63 04-Mar-2009 Johannes Weiner <jw@emlix.com>

xtensa: nommu support

Add support for !CONFIG_MMU setups.

Signed-off-by: Johannes Weiner <jw@emlix.com>
Signed-off-by: Chris Zankel <chris@zankel.net>


# d3883ece 10-Nov-2007 Adrian Bunk <bunk@kernel.org>

Remove references to "make dep"

"make dep" is no longer required in kernel 2.6, but was still mentioned
in some places.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>


# 6656920b 22-Aug-2007 Chris Zankel <chris@zankel.net>

[XTENSA] Add support for cache-aliasing

Add support for processors that have cache-aliasing issues, such as
the Stretch S5000 processor. Cache-aliasing means that the size of
the cache (for one way) is larger than the page size, thus, a page
can end up in several places in cache depending on the virtual to
physical translation. The method used here is to map a user page
temporarily through the auto-refill way 0 and of of the DTLB.
We probably will want to revisit this issue and use a better
approach with kmap/kunmap.

Signed-off-by: Chris Zankel <chris@zankel.net>


# 3f65ce4d 23-Jun-2005 Chris Zankel <czankel@tensilica.com>

[PATCH] xtensa: Architecture support for Tensilica Xtensa Part 5

The attached patches provides part 5 of an architecture implementation for the
Tensilica Xtensa CPU series.

Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>