> > Add a new, weird and wonderful driver for the equally weird Apple > > PMU HW. Although the PMU itself is functional, we don't know much > > about the events yet, so this can be considered as yet another > > random number generator... > > It's really frustrating that Apple built this rather than the architected PMU, > because we've generally pushed back on IMPLEMENTATION DEFINED junk in this > area, and supporting this makes it harder to push back on other vendors going > the same route, which I'm not keen on. That, and the usual state of IMP-DEF > stuff making this stupidly painful to reason about. Rules can be a bit stricter for vendors than for ragtag reverse-engineers. The kernel community can push back on vendor's choices because vendors have the power to choose otherwise. But reverse engineers' hands are sometimes forced by bad vendor decisions; rejecting the driver means mainline can never support the hardware. I believe there's precedent for distinguishing these cases, at least in the graphics subsystem. I don't know if this applies to this driver. I only wish to offer a rebuttal to a future vendor trying to mainline something questionable with the defence "Asahi Linux / Nouveau / ... did it, so we can too". (This will be relevant to the Apple M1 display controller driver, which would be a hard NAK if submitted by Apple...)
