On Wed, Mar 18, 2026 at 5:03 PM Mathieu Poirier <[email protected]> wrote:
> I have made this point clear before: modeling legacy protocols in > mainline doesn't scale. Mainline uses a single generic protocol, and > yes, it means breaking legacy protocols. This is the cost of moving > to a mainline kernel. If people want to use the legacy firmware, they > must stick with a legacy kernel. I mostly agree with this stance. But it is under the assumption that the contributor is coming from the same legal body that can define and change the firmware in question. For example: the mainline Linux kernel supports a whole slew of funky Apple rpmsg-like protocols. c.f. drivers/soc/apple/rtkit.c We cannot go and tell the Asahi contributors to change the Apple firmware to use rpmsg like everyone else, because they are not Apple, they just want to run Linux on someone else's hardware. In this case, the contributor is coming from the same legal body as the one doing the firmware. I know and sympathize with the fact that sometimes working inside a company to make changes happen can be as hard as working on the outside, and internal structures can be as resistant to pressure change as Microsoft, or Apple. Additionally they hit the contributor on the head with "just get this done, now, fast". So it is pretty important in this situation that it is NXP that we address. The contributor is just a representative of that legal body in this case. If someone *outside* of NXP, say an OpenWrt hobbyist contributor was pushing the same patches based on code drops and reverse engineering, the response would be *different*. In a way the situation is a bit icky. As the Linux community we often see all contributions as personal, individual. And the discussion here is that of standards committee, which we are not. So if we are addressing NXP, then we need to be explicit about that, and careful not to put their representative in the crosshairs. It's unfair, he's just the messenger. Yours, Linus Walleij
