Linux 7.1 MMC Changes Finally Land After Linus Called the 7.0 Submission "Complete Garbage"

February 2026. The Linux 7.0 merge window is open. The MMC subsystem maintainer sends Linus a pull request with new hardware support, eMMC optimizations, Qualcomm driver additions, and a handful of other improvements. Linus looks at it, attempts to build it, and it does not compile.

His response: "complete garbage" and "untested crap."

He pulled nothing from that request. The entire MMC subsystem sat out Linux 7.0 as a result. Not a single line merged.

Fast forward to the Linux 7.1 merge window, which opened after Linux 7.0 shipped on April 12, 2026. The MMC maintainer sent the pull request again -- this time with the original 7.0 changes included, properly tested, passing linux-next CI, building correctly. Linus merged it on Wednesday without commentary.

That silence is the review.

What Actually Happened in February

The Linux kernel development process runs through linux-next, a staging tree that pulls from dozens of subsystem trees before anything reaches Linus. CI systems continuously build from linux-next. Compilation failures surface there before they ever reach Linus's inbox. The entire point of the process is that Linus should not be the person who discovers that your code does not compile.

The MMC maintainer bypassed that process and sent a pull request directly to Linus from a branch that had not gone through linux-next. The code did not build as a module.

The response from the kernel community on the Phoronix forums was direct: "The absolute bare minimum test is always compilation. Doesn't matter if it's as a module or an in-kernel code. Anybody can write bad code or make mistakes, but if the patch doesn't compile, it is absolute trash and not to be accepted."

The maintainer acknowledged the issue and took responsibility. One commenter offered a more measured read: "Linus is being a bit dramatic. It didn't compile as a module, but worked otherwise." That is true and also misses the point. The process exists for a reason. Skipping linux-next is how you get compilation failures landing on Linus's desk.

For Linux 7.1, the maintainer ran everything through linux-next. The pull request compiled. It got merged. The drama ended.

The Actual Technical Changes That Landed

The Linux 7.1 MMC pull request landed on April 16, 2026. Here is what changed:

New NXP WiFi chip IDs over SDIO

The MMC subsystem handles MultiMediaCard and Secure Digital interfaces, which includes SDIO -- the variant used to connect WiFi and Bluetooth chips to host systems. New device IDs for NXP WiFi chips over SDIO land in this cycle, expanding the range of NXP hardware that Linux can initialize correctly on embedded and mobile platforms without out-of-tree patches.

MMC manufacturing date support beyond 2025

This is quiet but worth noting. The MMC specification stores manufacturing date information in a limited field inside the device's CSD register. Some implementations encoded dates in a way that hit a ceiling around 2025. Linux 7.1 extends the handling for MMC manufacturing data to support devices manufactured after that boundary. This matters for embedded systems and industrial hardware built this year and forward, where the manufacturing date embedded in the eMMC chip would otherwise be misread.

Kingston eMMC secure erase from 10 minutes to 2 seconds

This is the headline improvement in this cycle. On some Kingston eMMC devices, the existing secure erase and TRIM implementation was inefficient. A 1GB secure erase took approximately 10 minutes. The optimized implementation brings that to about 2 seconds.

The gap is a 300x improvement. For systems that run secure erase as part of deployment or end-of-life workflows -- factory reset operations, drive provisioning, secure decommissioning -- this changes what is practical. A 10-minute erase cycle on a fleet of devices is a logistics problem. A 2-second cycle is not.

The change works by taking advantage of hardware-accelerated erase commands that Kingston eMMCs support but the previous driver code was not using correctly. The optimization is device-specific: other eMMC vendors require different approaches.

Qualcomm hardware in SDHCI-MSM

The SDHCI-MSM driver handles Qualcomm's Snapdragon SD/eMMC controllers. Linux 7.1 adds support for additional Qualcomm hardware variants in this driver. Qualcomm's Snapdragon chipsets power a large share of Android devices and embedded Arm platforms. Broader SDHCI-MSM coverage means fewer devices requiring manual device tree patches for storage controller initialization.

Aspeed AST2700 in sdhci-of-aspeed

Aspeed chips turn up in server baseboard management controllers (BMCs) -- the embedded systems that handle out-of-band server management, power control, and health monitoring on datacenter hardware. The AST2700 is Aspeed's current-generation BMC SoC. Adding its SDHCI support to the mainline kernel means server operators and BMC firmware developers get upstream eMMC support for AST2700-based boards without carrying downstream patches.

SpacemiT K1 in sdhci-of-k1

The SpacemiT K1 is a RISC-V SoC targeting embedded and edge computing. SDHCI support in mainline Linux means the K1 gets a standard storage controller driver path rather than relying on vendor-specific trees.

Why the MMC Subsystem Matters More Than It Sounds

MMC and eMMC are the storage technology inside nearly every embedded Linux system: routers, industrial controllers, automotive systems, IoT devices, single-board computers. Your Raspberry Pi boots from eMMC or an SD card. Your car's infotainment runs Linux on eMMC. The BMC in a datacenter server is an Aspeed chip with eMMC storage.

SDIO is the interface for WiFi and Bluetooth modules on those same embedded platforms. Getting device IDs right means your NXP WiFi chip initializes correctly during boot instead of requiring a manual module parameter or a downstream patch.

The kernel subsystem that handles these components is unglamorous. It does not generate benchmark numbers or headline features. But when it works, the entire embedded Linux ecosystem benefits. When it stalls – as it did during Linux 7.0 because of a process failure – hardware support gaps accumulate for an entire cycle.

The Process Lesson

The Linux kernel review process is not bureaucracy for its own sake. linux-next exists specifically to catch failures before they waste Linus's time and before they delay a release cycle. The MMC submission for 7.0 failed the absolute minimum bar: it did not compile. That failure reached Linus because the maintainer bypassed the system that should have caught it first.

Linus's reaction was harsh. It was also the correct response to code that does not build landing in a pull request. The kernel does not have the luxury of merging broken code and fixing it later on a six-week release schedule with thousands of dependent subsystems.

The 7.1 submission went through linux-next. It compiled. Linus merged it without a word. That is what the process looks like when it works.