Greg Kroah-Hartman posted a new rule to the kernel mailing list on August 4: drivers/staging will no longer accept patches generated by large language models. The reasoning is not that the patches are bad. It is that staging exists primarily so new contributors can learn how kernel development works, the easy cleanups are the curriculum, and automated tools have been consuming that curriculum faster than humans can reach it. One narrow exception survives, and it comes with a requirement that is hard to fake.
The short answer
Kroah-Hartman announced that drivers/staging will reject LLM generated patches. The stated reason is purpose rather than quality: staging exists primarily so new kernel developers can learn the contribution process, and the easy cleanups are the material they learn on. One exception remains, for patches fixing a genuine defect, and it requires the submitter to have tested on the real hardware and to describe how. Undisclosed tool use is addressed directly in the post: it is very obvious, and not saying so gains nothing.
There is a version of this story that is about machines writing code, and it is the less interesting version. The rule Greg Kroah-Hartman posted on August 4 is really about what a subsystem is for, and it is one of the clearest statements anyone in kernel land has made about that.
The rule itself is short. Patches generated by large language models will not be accepted into drivers/staging. Not because they are wrong, though a share of them are, but because of what staging is.
Staging is a classroom, and the mess is the lesson
drivers/staging holds drivers that are not yet good enough for the main kernel tree. That is its entire definition. The code has style violations, uses deprecated interfaces, handles errors sloppily, and the distance between where it is and where mainline expects it to be is not an accident to be cleaned up as fast as possible.
That distance is a supply of small, well defined, genuinely useful tasks. Fix the indentation. Move this driver off an API that was deprecated three releases ago. Make this error path actually free what it allocated. Kroah-Hartman describes these as the low hanging fruit, and they are how a large share of today's kernel developers learned the workflow: find something small, write the patch, send it, get told what you did wrong, send it again, watch it merge.
An automated tool can strip that fruit from the tree in an afternoon. If it does, a newcomer arriving next month finds a subsystem with nothing left they can safely attempt, and the on ramp that made them a kernel developer is gone. That is the loss the rule is protecting against, and it is a strange one to explain to anyone who thinks of a patch queue as a backlog to be minimised.
The exception has teeth
One category still gets through: patches that fix a real defect. The condition is that the submitter must have tested the fix on the actual hardware the driver targets, and must describe how they tested it.
That condition is doing the real work, and it was well chosen. Producing a patch that looks correct for a driver you have never run is easy and getting easier. Producing a credible account of having exercised it on the device is not, because it requires owning or having access to hardware that in staging is frequently obscure. The requirement converts a claim into something checkable.
Kroah-Hartman has also put a number on why the bar sits there rather than at plausibility: roughly a third of machine identified issues in this area turn out to be incorrect or actively harmful. When the false positive rate is that high, review is not a cheap filter. Testing is.
On not mentioning it
The post closes off the obvious workaround. Kroah-Hartman wrote that it is very obvious when people submit LLM generated patches, and that nobody should think that simply not disclosing it will let them get away with anything.
Coming from a maintainer who has handled an extraordinary volume of kernel patches over two decades, that is a claim worth believing. Machine generated submissions carry recognisable signatures: the phrasing of commit messages, the shape of the changelog, which cleanups get bundled together and which never do. The trade being offered to anyone tempted is a bad one, since the reward is credit for a patch that was low value by design and the risk is a maintainer's opinion of you.
What this does and does not mean
Keep the scope straight, because this is where the story will get distorted.
The rule covers drivers/staging. It does not cover the rest of the kernel, where the broader conversation about disclosing and documenting tool assisted contributions is still running and has not concluded. This is one maintainer applying a rule that fits one subsystem's unusual purpose, not a kernel wide position.
It is also worth noticing what kind of argument won here. The case against was not that the output is unreliable, which would invite a rebuttal about better models. It was that the subsystem produces something other than code, and that the something is scarce. That argument does not get weaker as tools improve. It gets stronger.
Sources and further reading
- Linux's staging area to now reject LLM generated patches, except for real security fixes, Phoronix, August 4, 2026
- Toward a policy for machine learning tools in kernel development, LWN.net
- Kernel documentation: the staging tree and how to contribute to it
- A new kernel tree: linux-staging, LWN.net, on the original purpose of the subsystem
Frequently asked questions
Does this ban AI assistance across the whole Linux kernel?
No, and the scope limit is the most misreported part of this. The rule applies to drivers/staging and nothing else. Outside that subsystem, kernel policy on machine generated contributions is what it was before, and the broader discussion about how to document and disclose tool assistance in kernel development is still ongoing rather than settled. What Kroah-Hartman did was carve out one subsystem with an unusual purpose and apply a rule that fits that purpose. Reading it as a kernel wide prohibition gets both the letter and the intent wrong.
Why single out staging rather than any other subsystem?
Because staging is the only part of the tree whose code quality problems are deliberate. drivers/staging holds drivers that are not yet good enough for the main tree, and the gap between their current state and mainline standards is the point. That gap is a supply of small, tractable, genuinely useful tasks: coding style fixes, deprecated API migrations, error handling cleanups. Those tasks are how a large share of kernel developers learned the workflow, from first patch through review to merge. An automated tool can clear that backlog quickly, and if it does, the ladder that newcomers climb is gone. Kroah-Hartman put it directly: staging exists primarily as a place for new kernel developers to learn how to get involved.
What exactly is the exception?
Patches that fix a real defect can still be accepted, but the submitter has to have tested the fix on the actual hardware the driver targets, and has to describe how they did it in the submission. That requirement does most of the work. A tool can produce a plausible looking patch for a driver nobody has hardware for; it cannot produce a credible account of having run it on the device. Kroah-Hartman has noted that a substantial share of machine identified issues in this area, roughly a third, turn out to be wrong or actively harmful, which is why the bar is testing rather than argument.
Can I just not mention that I used a tool?
Kroah-Hartman addressed that possibility in the post and did not leave it ambiguous: it is very obvious when people submit LLM generated patches, so nobody should assume that omitting the disclosure gets them anything. That is worth taking at face value from someone who has processed an enormous volume of kernel patches. Machine generated submissions have recognisable tells in phrasing, in commit message structure, and in which cleanups get grouped together. The practical consequence is that undisclosed use is a reputational risk with a maintainer you would rather have on your side, in exchange for a patch that was low value by definition.
What should I do if I wanted to contribute to staging?
Do it the slow way, because in this subsystem the slow way is the entire product. Pick a driver, read it properly, run checkpatch on it, find something genuinely wrong, and write the fix yourself. If you own the hardware the driver targets, that is a significant advantage and you should say so. The thing you are optimising for is not the patch, it is learning the submission and review loop with a maintainer who is unusually willing to teach it. Using a tool to skip that step means you spent the opportunity and kept none of the benefit.