Dave Airlie <airlied@xxxxxxxxx> writes: > 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. Thank you for tracking these and making sure the reverts happen!
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
