The announced rule protects a contribution area used for learning. Its scope and testing exception need to be read directly rather than expanded into a policy for all Linux code.
What the maintainer wrote
In his August 3 message, Greg Kroah-Hartman says he will reject LLM-generated drivers/staging patches. He describes staging as a place for newcomers to learn. His exception concerns valid security issues: the submitter must test on the driver’s actual hardware, describe the test and defend the fix. An automated report or successful compilation alone does not meet that condition.
The message does not establish a kernel-wide prohibition. Nor should its warning about undisclosed tool use be treated as a scientific claim that authorship can always be detected from prose.
A useful report connects cause and observation
The diagram separates a suspected issue from evidence that an affected device can reach it, then from evidence that a patch corrects it. These are distinct steps. A model can suggest a suspicious path without demonstrating that the path is reachable under the driver’s actual constraints.
For example, a claim about an invalid device response needs more than a generic statement about unchecked lengths. The report should identify what supplies the length, which earlier checks apply, and how the affected hardware exercises the path. A proposed fix must preserve valid responses as well as reject invalid ones.
This article describes the evidence required; it does not provide an exploit or claim a vulnerability in a particular staging driver.
Compilation is one observation among several
Keep the kernel revision and configuration, device identity, reproducible trigger and observed before/after behaviour together. A patch that compiles may still change timing, break a legitimate device response or leave the original failure intact. Conversely, a test that never reaches the relevant path cannot demonstrate a fix.
For newcomers working on ordinary cleanups, the rule’s practical implication is to choose a small change you can explain and follow the subsystem’s contribution process. The purpose of the exercise includes learning why the code works and how to respond to review. A large generated cleanup removes that learning step rather than complete it.
September 8: correct announcement to August 3, scope to drivers/staging, narrow exception to validated security issues; remove claims of reliable AI detection and universal kernel policy.