I've been looking a bit at 5.0 for a few things recently, and I've noticed it shipped with a bunch of regressions, that I'm trying to smash. udl driver regression due to gem unlocked cleanup udl driver unload regression due to other unplug changes i915 + atomic x.org modesetting driver break i915 eDP faster/stronger/wider patch fallout virtio-gpu prime removal broke DRI3 Now in some of the cases here a revert has had to be argued for by me, and in some cases a revert hasn't happened as quickly as I'd like. But one thing I've seen in a couple of cases is regression nitpicking, which isn't acceptable to Linus and hence to me either. if the sequence happens: kernel A does something apply patch X kernel A+X doesn't do the same thing then patch X is broken and needs to be reverted - no matter what patch X fixes - no matter if the fault patch X uncovers is somewhere in userspace or in magic other lands, - no matter if patch X revert regresses something patch X fixes. I do not want to hear excuses that this patch isn't at fault, or it's the other userspace problem, it's your problem to engineer around that, wait 5 years, new CONFIG options, detecting the buggy userspace, whatever, you are engineering something, go engineer it. For anyone interested I've reverted the i915 atomic fbdev fix, the virtio-gpu prime removal, i915 team already did the eDP reverts, and I did two fixes for udl. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
