I agree entirely. If you try to get a patch to be accepted, be prepared to explain exactly what it does bit by bit to people whose entire job it is to make sure that the kernel quality does not degrade.
Having read through the email exchanges linked elsewhere in this thread, I don't think the issue is with having to explain what changes do. There appears to be 2 main conflicts in the thread. One is a reviewer who appears to not be taking a large picture view of the patches. It appears multiple points of concern for them are addressed, answered or given relevant context either just a few lines up or down, or in a different part of the file. The frustration here appears to be not that things have to be explained, but that little to no effort was put into understanding it at all. This I think was compounded by the fact that the reviewer appeared to reject multiple suggested revisions while not providing any context for what they're actually looking for, and when the reviewer did make a suggestion, their suggestions apparently weren't even valid C code.
The second conflict appears to have occurred around a dispute over the logical organization of the changes, and how they would be called and where the code would live. In this case, it appears the Asahi people organized it in a way that made sense based on their understanding of the hardware in question, the current structure of the code, and in a way that other parts were already laid out. A different reviewer objected to this layout, noting that while they had indeed followed the model of some other code, that was wrong and apparently shouldn't have been there in the first place. Again there appears to have been an amount of back and forth that was ultimately a series of rejections on proposed alternates without any real explanation of what they were looking for and why they thought given the hardware design, this layout didn't make sense. This argument included a directive from the reviewer to just do it "proper" without (to my reading) any real guidance to what "proper" would look like given nature of what is being submitted.
While I appreciate that reviewers don't necessarily have all the context and will be asking questions, sometimes on stuff that is answered within the file, I would certainly expect them to not return a review that is almost entirely answered by context within the file. I would equally expect that if they are going to suggest I do something a different way, that suggestion should be valid code, or at least pseudo code that can be made valid. I would honestly also expect a review to include some feedback on what the reviewer would like when the disagreements are about logical organization or coding choices that fall outside the documented code style requirements.
I do not need respect in my linux kernel, I need it to work without failure. The linux kernel is perhaps the most important software project ever. It makes sense to have different rules.
If you can't, quit.