Linux 7.2 trims RISC-V boot overhead and adds Eswin support
4 RISC-V changes in Linux 7.2 cut boot overhead, add Eswin SoC support by default, and clean up kernel code paths.

Linux 7.2 brings RISC-V boot tweaks, default Eswin support, and cleanup fixes.
Linux 7.2 folds in a small set of RISC-V updates that matter to board owners and kernel tinkerers, including default Eswin SoC support and a startup tweak tied to ftrace.
1. Default Eswin SoC support
Get the latest AI news in your inbox
Weekly picks of model releases, tools, and deep dives — no spam, unsubscribe anytime.
No spam. Unsubscribe at any time.
The biggest user-facing change is that the RISC-V defconfig now enables Eswin SoC support by default. That matters for boards built around Eswin silicon, especially the SiFive HiFive Premier P550, because the default kernel config is more likely to boot with the right support already in place.

In practice, this reduces the chance that a developer or distro maintainer has to patch the config just to get a common board into a working state. It is a modest change on paper, but it removes one more setup step from the path to a usable kernel build.
- Applies to the default RISC-V kernel configuration
- Aims to cover the SiFive HiFive Premier P550
- Also helps other boards using an Eswin SoC
2. Lower startup overhead in ftrace init
Linux 7.2 also enables HAVE_BUILDTIME_MCOUNT_SORT on RISC-V, which lets the build sort the __mcount_loc section at link time. The result is less work during ftrace initialization and a smaller kernel startup cost.
This is the kind of change that does not alter features, but it can trim overhead in a path that runs on every boot. For developers who watch boot time, tracing setup, or early kernel behavior, that makes it a practical improvement rather than just a compiler flag.
- Build-time sorting happens at link time
- Targets the
__mcount_locsection - Reduces work in the ftrace init path
3. Kernel code clean-ups
Beyond the boot-related work, the RISC-V pull for Linux 7.2 includes a set of code clean-ups. These are the quieter changes that keep architecture support easier to maintain over time, even if they do not show up as a headline feature.

Clean-ups also matter because RISC-V support is still growing across many boards and SoCs. Smaller maintenance passes can make future changes easier to review, easier to merge, and less likely to carry old complexity forward.
- General architecture code clean-ups
- Maintenance work with no user-facing toggle
- Helps keep the port easier to extend
4. Cacheinfo memory leak fix
One of the concrete bug fixes in this batch addresses a potential memory leak in the cacheinfo code. That kind of fix is easy to miss in daily use, but it matters for stability and for keeping long-running systems from wasting memory in edge cases.
For kernel developers, these fixes are part of the steady work that keeps an architecture port usable across more hardware. For users, the value is simple: fewer bugs in core code paths and fewer surprises once the system has been up for a while.
RISC-V Linux 7.2 updates include:
- Eswin SoC support enabled by default
- HAVE_BUILDTIME_MCOUNT_SORT enabled
- cacheinfo memory leak fix
- additional clean-ups and fixes5. A stronger default for new RISC-V builds
Taken together, the changes point in one direction: the default RISC-V kernel configuration is becoming more practical for real boards. Eswin support improves out-of-the-box coverage, while the startup tweak and bug fixes smooth out early boot and core kernel behavior.
That matters most for people building kernels for hardware bring-up, distro integration, or embedded deployments. The less hand-editing required in defconfig, the easier it is to get from source tree to a booting system.
- Better default coverage for common boards
- Less manual config work for maintainers
- Small performance and stability gains
How to decide
If you own a SiFive HiFive Premier P550 or another Eswin-based RISC-V board, this is the most directly useful part of the Linux 7.2 work. If you care more about boot behavior and tracing overhead, the build-time mcount sorting change is the one to watch.
If you are tracking RISC-V upstreaming in general, the broader message is that the architecture keeps getting more default-friendly, with small fixes landing alongside platform support.
// Related Articles