linux/kernel/git/baikal/linux.git, branch mips/eva

mips: spaces: Convert CAC_BASE to being pre-defined

2026-08-05T22:51:52+00:00

The macro defines the base address of the kernel directly mapped cacheable region. It normally matches to the (C)KSEG0/XKPHYS regions. But EVA (Enhanced Virtual Addressing) feature changes that since KSEG0 is no longer a static region. Basically the EVA mapping can be any but normally it just implies the KSEG0 extending downward. In order to have that reflected in the CAC_BASE macro let's make it optionally pre-defined by the platform-specific space.h header-file on MIPS32 in the same way as it can be done on MIPS64 CPUs. Signed-off-by: Serge Semin

mips: relocatable: Take vmlinux base address into account

2026-08-05T22:51:52+00:00

The Linux kernel can be built to run anywhere within the valid virtual address space. In case of the legacy MIPS memory mapping it's indeed based in the KSEG0 region. So the kernel relocation to 0x81000000 should be fine in the most of the cases. But if the kernel is built for EVA mapping with extended KSEG0 (XKSEG) and the platform has no traditional KSEG0 aliasing, then the default 0x81000000 address won't be suitable since at least it will lack having the directly mapped uncached region where the exception handlers reside. Let's fix that by defaulting the relocated kernel base address to being with respect to the platform-specific VMLINUX_LOAD_ADDRESS. In all of the currently supported platforms it's 0x80100000. So the commit won't change much for them. But if the kernel is built for EVA and placed out of the legacy KSEG0 region, it will be taken into account in the default relocation address. Signed-off-by: Serge Semin

mips: Drop EVA and XPA mutual exclusivity

2026-08-05T22:51:52+00:00

There is absolutely no reason to have these features being mutually exclusive. XPA stands for EXtended Physical Addressing and is dedicated for having more than 4G physical memory available on MIPS32 platforms. EVA stands for Enhanced Virtual Addressing and it's purpose to make the CPU virtual address configurable primarily to overcome the 512M lowmem constraint and have up to 3G directly addressable memory in kernel. The MIPS-arch implementation of the Linux kernel currently doesn't have anything that makes these features not working together. Moreover it has been tested on a MIPS32 P5600 CPU-based platform with 8GB memory available. The system works just fine. Let's drop the XPA-EVA anti-dependency then. Fixes: c5b367835cfc ("MIPS: Add support for XPA.") Signed-off-by: Serge Semin

mips: Drop EVA and HIGHMEM mutual exclusivity

2026-08-05T22:51:51+00:00

There is absolutely no reason to have these features being mutually exclusive. EVA stands for Enhanced Virtual Addressing and it's purpose to make the CPU virtual address space configurable primarily to overcome the 512M lowmem constraint and have up to 3G directly addressable memory in kernel. But that doesn't mean that EVA has no mapped memory support. It has and is normally enabled at the same virtual address space as on the legacy memory segments. That makes HIGHMEM and EVA configs being incorrectly anti-dependent. Let's drop the dependency then. The change has been tested on a MIPS32 P5600 CPU-based platform with 8GB memory available. The system works just fine. Fixes: a6e18781c5b8 ("MIPS: Kconfig: Add Kconfig symbols for EVA support") Signed-off-by: Serge Semin

mips: Permit up to KSEG2 direct virtual addressing on EVA

2026-08-05T22:51:51+00:00

Indeed the kernel won't work correctly without the MAP_BASE region. It's defined above the KSEG2/KSEG3 legacy regions and above the CFG0/CFG1 EVA virtual segments on all the currently EVA-capable CPUs (Malta and Baikal-T1). Thus at least on this stage it's incorrect to omit the upper limit in the __debug_virt_addr_valid() method in the EVA kernel. Let's fix that. Fixes: 8a2b456665d1 ("MIPS: Fixed __debug_virt_addr_valid()") Signed-off-by: Serge Semin

mips: mm: Re-map uncached address on DMA-noncoherent EVA

2026-08-05T22:50:35+00:00

EVA mapping provides a way to completely re-define the kernel virtual address space map. But normally it implies just the cached lowmem region extending. That's what done on the Malta and Baikal-T1 CPUs with EVA feature enabled. In the meantime the directly mapped uncached region is still limited to be less than 512M including the IO-memory sub-space. So in order to support the DMA-coherent memory allocated from all the low-memory space even on the EVA kernel let's use the KSEG2/KSEG3 regions to uncached-remap the requested address via MMU. Note the arch_dma_set_uncached() caller antagonist implies to call the vunmap() method (like it's done in dma_direct_alloc()/dma_direct_free() pair). Fixes: c9fede2afc00 ("MIPS: malta: spaces.h: Add spaces.h file for Malta (EVA)") Signed-off-by: Serge Semin

mips: CPS: Fix secondary CPU failed to boot on EVA

2026-08-05T22:49:05+00:00

EVA-based memory mapping can be any but normally the segments have the KSEG0 extended downwards (like on Malta and Baikal-T1). In these cases it will be fatal to jump over the absolute address, i.e. to use l*r instructions, before the EVA mapping is deployed since kernel may reside at a range not suitably remapped yet. So let's move the eva_init code execution to be done before jumping to the actual kernel address. The same order can be found on the core 0 initial boot up assembler code. Fixes: 6521d9a436a6 ("MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores") Signed-off-by: Serge Semin

Linux 7.0

2026-04-12T20:48:06+00:00

Merge tag 'edac_urgent_for_7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras

2026-04-12T18:56:07+00:00

Pull EDAC fix from Borislav Petkov: - Fix the error path ordering when the driver-private descriptor allocation fails * tag 'edac_urgent_for_7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/mc: Fix error path ordering in edac_mc_alloc()

Merge tag 'wq-for-7.0-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

2026-04-12T17:42:40+00:00

Pull workqueue fix from Tejun Heo: "This is a fix for a stall which triggers on ordered workqueues when there are multiple inactive work items during workqueue property changes through sysfs, which doesn't happen that frequently. While really late, the fix is very low risk as it just repeats an operation which is already being performed: - Fix incomplete activation of multiple inactive works when unplugging a pool_workqueue, where the pending_pwqs list wasn't being updated for subsequent works" * tag 'wq-for-7.0-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Add pool_workqueue to pending_pwqs list when unplugging multiple inactive works