Linux sound subsystem maintainer Takashi Iwai of SUSE began the Linux 7.4 sound pull request by noting that "the AI flood continues" with there continuing to be a lot of new patches coming as a result of AI/LLM agents devising patches as well as uncovering new kernel bugs.
Takashi went on to explain that it was another busy cycle with changes in the sound subsystem from lots of core code hardening to new platforms and codecs as well. The core ALSA code has been hardened against some race conditions, there's a buffer leak fix in the compression offload code, race fixes in the JACK code, and other race conditions and more typical C bug fixes. The OSS sequencer emulation code has also been marked as deprecated for Linux 7.4.
On the hardware side, the Linux 7.4 sound updates include support for compressed audio playback on SOF IPC4 with Intel Tigerlake and newer. There is also AMD ACP 7.0/7.F sound IP support with SoundWire and the PDM controller. The new AMD ACP 7.0/7.F IP appears for upcoming Ryzen Zen 6 platforms.
There are also quirks for many different Intel/AMD laptops from the likes of Lenovo, ASUS, HP, AAcer, HONOR, MSI, and others.
New codec drivers are for the ESS ES9039Q2M, Nuvoton NAU83G60 amplifier, Senary SN624x SoundWire SDCA codec.
Also new is the Qualcomm QAIF driver for their Shikra platform.
More details on the many sound changes for Linux 7.4 via this pull ( https://lore.kernel.org/lkml/87ecdgc246.wl-tiwai@suse.de/ ).
I haven't attempted to verify the truth or expose the fiction of Torvalds' patch and vacation thing - it doesn't feel worth anywhere near the effort it would take to get to the bottom of - but I have certainly read it parroted more than twice...
In response to that, I'll continue to repeat the fact that Torvalds the human issued a bad patch to Dirty COW which he himself described as sloppy (in so many words), and that involved race conditions that went undetected in the production kernel for years and years before anyone ever attempted to have an LLM write code.
It's not that Torvalds is bad, he's human - these things happen. They also happen with greater frequency when using LLMs, but in both cases: using due care and good practices dramatically reduces the liklihood of such problems getting out to the field. The LLM tools speed things up, in the creation of code, in the creation of bugs in the code, and in the finding and fixing of bugs in the code. How you choose to use it should be your own responsibility.
A lot of the sloppy human coders didn't have the perseverence to make anything that would compile cleanly, let alone pass basic "smell tests," until they got LLM tools - that's not the tools' fault, but it is the maintainers' problem. Ignoring/attempting (with inevitable futility) to block the tools because they can be used poorly is... ridiculously bad logic.