In the Linux 7.3 development cycle, the char/misc changes merged this week tell two different stories. The first is predictable: the usual IIO driver churn and updates to the Google Binder drivers. The second is more revealing: the kernel keeps removing dated hardware drivers, the latest being an old IBM driver joining the insecure SGI drivers already slated for removal. Behind the cleanup there is a new pressure: the surplus of bug reports and patches generated by LLMs.

The point is not only that those drivers are obsolete or have no active users on the mainline kernel. It is that the cost of maintaining them is changing. Every dead driver that remains in the tree becomes a target for low-quality automated fixes, forcing maintainers to spend time separating useful contributions from noise. In this context, removal becomes rational: less unmaintained code, less surface to review, fewer spurious reports to handle.

For those managing on-premise infrastructure with long lifecycles, this is a structural signal. Mainline support is not a static guarantee: it is a process with shifting attention thresholds. If a company still runs machines with IBM or SGI drivers from that generation, removal from the mainline kernel means it will have to maintain out-of-tree patches, pay for extended support, or migrate earlier than planned. In every case TCO rises, and staying on dated hardware becomes more expensive.

There is also a matter of trust. LLM-generated patches are not necessarily wrong; many are plausible but trivial, others require context that a model does not have. For maintainers of obsolete drivers, the volume of weak contributions is a hidden cost that does not appear in any changelog. The second-order effect is that the selection of code to maintain no longer depends only on technical usefulness, but also on the amount of noise that code attracts. Drivers with few users and many automated reports become the first candidates for removal.

Who gains? Maintainers, who reduce review workload; vendors of newer hardware, who see obsolescence accelerate; and those who rely only on modern components. Who loses? Operators of laboratories, industrial plants, or research centers with legacy equipment, and communities maintaining niche kernel variants. The structural message is that generative automation applied to software maintenance can paradoxically increase human work instead of reducing it, because triage cost outweighs the benefit of quantity.

For those planning on-premise deployments with five- or ten-year horizons, this episode is a reminder that system software is not a one-time cost. It is a continuous maintenance commitment, and decisions about which hardware and kernel to adopt should also be evaluated based on the likelihood that upstream support will survive obsolescence. AI-RADAR offers on /llm-onpremise an analytical framework to compare trade-offs between autonomous maintenance and dependence on upstream channels, without reducing everything to short-term convenience.