A brand new hot off the press Linux kernel 7.1 has been released bringing with it all the latest new and improved hardware support.
From the release announcement
So it's only Sunday morning back home, but it's Sunday afternoon where I am right now, so I'm doing the 7.1 release at the regular time - just not in the regular timezone.
This obviously means that the merge window opens tomorrow, but I'll be in yet another timezone by then, so timing will all be a bit irregular. Normally I try to front-load the merge window and do as much as possible the first few days - this time I'm not sure that will work out with my laptop and a couple of long flights without internet, but I've made sure that I have fetched the early pull requests (thank you - you know who you are), so I will be able to do some of it off-line.
Anyway, possible slight hiccups in the merge window aside, the news today is 7.1. Below is the shortlog for the last week - nothing particularly interesting or scary stands out, which is as it should be. It's mostly various smaller driver updates (gpu, networking, sound, misc) with some networking and trace tooling fixes. And random minor changes elsewhere.
Please do keep testing despite the release, and apologies in advance if my merge window latency is going to be a bit random the next few days. I briefly considered just extending the release for a week, but decided it wasn't really worth it. I may come to regret that decision,
Linus
Unlike other open source projects you don't get some nice highlights with new kernel releases, this is mainly due to the insanely vast size of it, so we all have to sleuth over what we can gather from all the code requests sent in. You can see all the changes in the full technical changelog.
Some highlights of what we found:
- A brand new NTFS driver, but it's not the default (yet).
- A Steam Deck OLED audio fix.
- Improvements to the Intel Xe driver for handling memory pressure.
- More older AMD GPUs switched over to the modern AMDGPU driver.
- Improved support for the Lenovo Legion Go / Lenovo Legion Go S and Lenovo Legion Go 2.
- Improved support for the GPD Win 5.
- Better support for various Lenovo Yoga devices.
- The AMD P-State performance scaler gained some new tricks like support for Dynamic EPP (Energy Performance Preference) to swap laptops between performance profiles if plugged in or on battery power.
- A new macsmc-power driver for Apple Silicon - providing battery and AC status monitoring via the SMC (System Management Controller).
You can see some more via LWN #1 / LWN #2.
Article taken from GamingOnLinux.com.
See more from me
You can also find comments for this article on social media: 
Dmitri Seletski 12 hours ago
It is stuck on 3GHz at all times, or goes above under load. When lowest step on CPU is actually 600MHz.
Latest UEFI and all.
Passive is a way to go for me.
Quoting: artikI'm really suprised how the kernel team now put many efforts in gaming, especially handled console. That's so cool.I've been recently watching some interviews from the kernels devs and learned that only 3 (iirc) people are actually employed by the Linux Foundation to work on the kernel, and everybody else is employed by some random corporation or whatever to selfishly work on the stuff they're actually interested in. Also that there is generally no plan and no direction to how kernel happens to evolve over time. So I'm guessing there is probably no particular intent to improve gaming from the kernel team, it's just that somebody out there happens to be doing that.
Quoting: rustynailSo I'm guessing there is probably no particular intent to improve gaming from the kernel team, it's just that somebody out there happens to be doing that.Quite possibly somebody who works for Valve . . .
From the link:
commit f52bbb00deaaa137271217e158537151f6c792b6
Author: Mika Kahola <[email protected]>
Date: Thu Mar 12 08:06:37 2026 +0000
drm/i915/lt_phy: Refactor LT PHY PLL handling to use explicit PLL state
The LT PHY implementation currently pulls PLL and port_clock
information directly from the CRTC state. This ties the PHY
programming logic too tightly to the CRTC state and makes it
harder to clearly express the PHY’s own PLL configuration.
Introduce an explicit "struct intel_lt_phy_pll_state" argument
for the PHY functions and update callers accordingly.
No functional change is intended — this is a preparatory cleanup for
to bring LT PHY PLL handling as part of PLL framework.
v2: DP, HDMI 2.0, and HDMI FRL modes are port of the VDR configuration 0
register. These modes are defined by bits 2:0. Decode these to
differentiate DP and HDMI modes when programming PLL's. (Imre, Suraj)
v3: Pass port_clock as argument instead of recalculating it (Suraj)
v4: Fix checkpatch warning of line length exceeding 100 columns
BSpec: 744921
Signed-off-by: Mika Kahola <[email protected]>
Reviewed-by: Suraj Kandpal <[email protected]>
Patreon
PayPal