"Completely garbage!" Linus blasts the Linux MMC code update: It can't even compile, and no testing was done at all.

As is well known, Linus Torvalds, the father of Linux, who has always had a fiery temper and is straightforward, has strict requirements for code quality. Especially for the code to be merged into the Linux kernel, there is no room for the slightest flaw or perfunctory.

However, during the development process of the Linux 7.0 kernel, a batch of planned MMC-related code modifications directly hit the nail on the head. Linus successively criticized them as "complete garbage" and "untested junk" and mercilessly rejected them all. As a result, a series of optimizations for the MMC subsystem originally prepared for Linux 7.0 were completely excluded from this version.

What is MMC?

The Linux MMC (MultiMediaCard) subsystem is a driver framework in the kernel responsible for managing the MMC, SD, and SDIO bus protocols. It not only drives storage devices such as eMMC and SD cards but also drives non-storage peripherals connected through the SDIO interface, such as Wi-Fi modules and Bluetooth adapters. The storage and wireless communication components in mobile phones, embedded devices, development boards, and even some server devices may rely on this mechanism.

It is responsible for underlying tasks such as device initialization, protocol processing, and read/write scheduling. Although ordinary users rarely directly interact with this layer, in the actual system operation, it is an indispensable part of the storage stack.

Linus Rejects MMC Code Modifications in Linux 7.0

This time, the subsystem maintainers originally planned to upgrade the Linux MMC, which actually included some quite interesting changes, such as:

Adding device ID support for the NXP IW61x WiFi chip connected via SDIO;

Adding support for identifying production dates after 2025;

Optimizing the secure erase and TRIM operations for some Kingston eMMC;

Cleaning up the DW_MMC code;

Adding support for the MediaTek MT8189 in the mtk-sd driver and updating multiple SHDCI drivers.

From a functional perspective, these changes are not radical and are more like a regular iteration.

The problem lies in the code itself and the process.

According to the long-established convention in the kernel community, before submitting a pull request to Linus for subsystem updates, they should first be integrated and tested in the linux-next repository. The role of linux-next is to detect cross-subsystem conflicts, compilation issues, and integration errors before merging into the mainline.

However, when the MMC update reached Linus, there were still a bunch of problems.

At the beginning of the email, Linus directly scolded: "These changes are complete garbage and can't even pass the compilation. It seems that they have never been in linux-next and no build tests have been done."

Immediately afterwards, he seemed to be patiently telling the subsystem contributors step by step what was wrong with this code:

When CONFIG_MULTIPLEXER=m, we will build this core.o file:

• obj-$(CONFIG_MULTIPLEXER) += mux-core.o

But in include/linux/mux/consumer.h, you wrote:

• #ifdef CONFIG_MULTIPLEXER

This condition will not hold here (because what is actually defined is CONFIG_MULTIPLEXER_MODULE), which will result in a series of errors like the following:

• drivers/mux/core.c:312:14: error: redefinition of ‘mux_control_states’

Because the placeholder wrapper function has already been defined in the mux/consumer.h header file.

In other words, that commit ad314348ceb4 ("mux: Add helper functions for getting optional and selected mux-state") is complete, untested garbage.

Linus's "Code" Obsession with Purity

Actually, those familiar with the Linux community know that Linus has always had strict requirements for code quality, and this operation is actually not surprising at all. As the most widely used open-source kernel globally, Linux can be found in servers, mobile phones, and embedded devices. The stability and reliability of the kernel code are directly related to the normal operation of countless devices.

The linux-next testing phase is the "first security check" for the kernel code, which can detect compilation and compatibility issues in advance and prevent problematic code from entering the official version. This batch of MMC code not only skipped the security check but also came with a bunch of errors, obviously touching Linus's bottom line.

Regarding this, Linus's attitude is also very clear:

"I don't want to see you send any more 'fixed' pull requests. This is completely unacceptable, and I won't pull anything from you during this merge window.

Don't send me untested garbage code that hasn't been in linux-next and can't even pass the most basic checks.

You can try again in the 7.1 cycle - provided that it has really been in linux-next and has been properly tested."

Looking back, similar "last-minute braking" events occur in each version cycle of the Linux kernel. To the outside world, it seems like a "scolding"; to those who have long been involved in kernel development, it is more like a routine process correction.

Open collaboration does not mean relaxing standards. It is this insistence on process and quality that has kept the Linux mainline relatively stable during decades of high-frequency iterations.

References:

https://www.phoronix.com/news/Linux-7.0-No-MMC-Changes

https://lore.kernel.org/lkml/CAHk-=wgnRQiKqWVrO_uF1btYM