kernel/git/stable/linux.git/arch/mips/mm, branch linux-4.4.y

MIPS: c-r4k: Fix section mismatch for loongson2_sc_init

2021-03-03T15:44:16+00:00

[ Upstream commit c58734eee6a2151ba033c0dcb31902c89e310374 ] When building with clang, the following section mismatch warning occurs: WARNING: modpost: vmlinux.o(.text+0x24490): Section mismatch in reference from the function r4k_cache_init() to the function .init.text:loongson2_sc_init() This should have been fixed with commit ad4fddef5f23 ("mips: fix Section mismatch in reference") but it was missed. Remove the improper __init annotation like that commit did. Fixes: 078a55fc824c ("MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code") Link: https://github.com/ClangBuiltLinux/linux/issues/787 Signed-off-by: Nathan Chancellor Reviewed-by: Huacai Chen Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

MIPS: RM7000: Double locking bug in rm7k_tc_disable()

2020-05-10T08:25:46+00:00

commit 58a7e1c140f3ad61646bc0cd9a1f6a9cafc0b225 upstream. We obviously intended to enable IRQs again at the end. Fixes: 745aef5df1e2 ('MIPS: RM7000: Add support for tertiary cache') Signed-off-by: Dan Carpenter Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: kernel-janitors@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13815/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

MIPS: Fix HTW config on XPA kernel without LPA enabled

2020-05-10T08:25:42+00:00

commit 14bc241443e126c62fcbf571b7d4c79740debc58 upstream. The hardware page table walker (HTW) configuration is broken on XPA kernels where XPA couldn't be enabled (either nohtw or the hardware doesn't support it). This is because the PWSize.PTEW field (PTE width) was only set to 8 bytes (an extra shift of 1) in config_htw_params() if PageGrain.ELPA (enable large physical addressing) is set. On an XPA kernel though the size of PTEs is fixed at 8 bytes regardless of whether XPA could actually be enabled. Fix the initialisation of this field based on sizeof(pte_t) instead. Fixes: c5b367835cfc ("MIPS: Add support for XPA.") Signed-off-by: James Hogan Cc: Steven J. Hill Cc: Paul Burton Cc: Paul Gortmaker Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13113/ Signed-off-by: Paul Burton Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

MIPS: BMIPS: local_r4k___flush_cache_all needs to blast S-cache

2020-05-10T08:25:41+00:00

commit f675843ddfdfdf467d08cc922201614a149e439e upstream. local_r4k___flush_cache_all() is missing a special check for BMIPS5000 processors, we need to blast the S-cache, just like other MTI processors since we have an inclusive cache. We also need an additional __sync() to make sure this is completed. Fixes: d74b0172e4e2c ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by: Florian Fainelli Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13012/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

MIPS: BMIPS: Clear MIPS_CACHE_ALIASES earlier

2020-05-10T08:25:41+00:00

commit 73c4ca047f440c79f545bc6133e3033f754cd239 upstream. BMIPS5000 and BMIPS5200 processor have no D cache aliases, and this is properly handled by the per-CPU override added at the end of r4k_cache_init(), the problem is that the output of probe_pcache() disagrees with that, since this is too late: Primary instruction cache 32kB, VIPT, 4-way, linesize 64 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes With the change moved earlier, we now have a consistent output with the settings we are intending to have: Primary instruction cache 32kB, VIPT, 4-way, linesize 64 bytes. Primary data cache 32kB, 4-way, VIPT, no aliases, linesize 32 bytes Fixes: d74b0172e4e2c ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by: Florian Fainelli Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13011/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

MIPS: BMIPS: BMIPS5000 has I cache filing from D cache

2020-05-10T08:25:41+00:00

commit c130d2fd3d59fbd5d269f7d5827bd4ed1d94aec6 upstream. BMIPS5000 and BMIPS52000 processors have their I-cache filling from the D-cache. Since BMIPS_GENERIC does not provide (yet) a cpu-feature-overrides.h file, this was not set anywhere, so make sure the R4K cache detection takes care of that. Fixes: d74b0172e4e2c ("MIPS: BMIPS: Add special cache handling in c-r4k.c") Signed-off-by: Florian Fainelli Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13010/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

mm: replace get_user_pages_unlocked() write/force parameters with gup_flags

2018-12-17T20:55:16+00:00

commit c164154f66f0c9b02673f07aa4f044f1d9c70274 upstream. This removes the 'write' and 'force' use from get_user_pages_unlocked() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes Reviewed-by: Jan Kara Acked-by: Michal Hocko Signed-off-by: Linus Torvalds [bwh: Backported to 4.4: - Also update calls from process_vm_rw_single_vec() and async_pf_execute() - Adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

MIPS: WARN_ON invalid DMA cache maintenance, not BUG_ON

2018-09-19T20:48:59+00:00

[ Upstream commit d4da0e97baea8768b3d66ccef3967bebd50dfc3b ] If a driver causes DMA cache maintenance with a zero length then we currently BUG and kill the kernel. As this is a scenario that we may well be able to recover from, WARN & return in the condition instead. Signed-off-by: Paul Burton Acked-by: Florian Fainelli Patchwork: https://patchwork.linux-mips.org/patch/14623/ Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

MIPS: Fix ioremap() RAM check

2018-07-17T09:31:42+00:00

commit 523402fa9101090c91d2033b7ebdfdcf65880488 upstream. We currently attempt to check whether a physical address range provided to __ioremap() may be in use by the page allocator by examining the value of PageReserved for each page in the region - lowmem pages not marked reserved are presumed to be in use by the page allocator, and requests to ioremap them fail. The way we check this has been broken since commit 92923ca3aace ("mm: meminit: only set page reserved in the memblock region"), because memblock will typically not have any knowledge of non-RAM pages and therefore those pages will not have the PageReserved flag set. Thus when we attempt to ioremap a region outside of RAM we incorrectly fail believing that the region is RAM that may be in use. In most cases ioremap() on MIPS will take a fast-path to use the unmapped kseg1 or xkphys virtual address spaces and never hit this path, so the only way to hit it is for a MIPS32 system to attempt to ioremap() an address range in lowmem with flags other than _CACHE_UNCACHED. Perhaps the most straightforward way to do this is using ioremap_uncached_accelerated(), which is how the problem was discovered. Fix this by making use of walk_system_ram_range() to test the address range provided to __ioremap() against only RAM pages, rather than all lowmem pages. This means that if we have a lowmem I/O region, which is very common for MIPS systems, we're free to ioremap() address ranges within it. A nice bonus is that the test is no longer limited to lowmem. The approach here matches the way x86 performed the same test after commit c81c8a1eeede ("x86, ioremap: Speed up check for RAM pages") until x86 moved towards a slightly more complicated check using walk_mem_res() for unrelated reasons with commit 0e4c12b45aa8 ("x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages"). Signed-off-by: Paul Burton Reported-by: Serge Semin Tested-by: Serge Semin Fixes: 92923ca3aace ("mm: meminit: only set page reserved in the memblock region") Cc: James Hogan Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org # v4.2+ Patchwork: https://patchwork.linux-mips.org/patch/19786/ Signed-off-by: Greg Kroah-Hartman

MIPS: mm: fixed mappings: correct initialisation

2018-04-13T17:50:19+00:00

[ Upstream commit 71eb989ab5a110df8bcbb9609bacde73feacbedd ] fixrange_init operates at PMD-granularity and expects the addresses to be PMD-size aligned, but currently that might not be the case for PKMAP_BASE unless it is defined properly, so ensure a correct alignment is used before passing the address to fixrange_init. fixed mappings: only align the start address that is passed to fixrange_init rather than the value before adding the size, as we may end up with uninitialised upper part of the range. Signed-off-by: Marcin Nowakowski Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15948/ Signed-off-by: Ralf Baechle Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman