fix for CRTC mutex corruption
Daniel Vetter
daniel at ffwll.ch
Tue Oct 29 21:11:35 CET 2013
On Tue, Oct 29, 2013 at 8:22 PM, Ilija Hadzic
<ihadzic at research.bell-labs.com> wrote:
>
>>> The actual fix is implemented in patch #6; preceding
>>> 5 patches are necessary prerequisites.
>>
>>
>> Hm, I don't really see why patches 1,2&4 are required. If we reorder them
>> to the end of the series as follow-up cleanups then we'd only need to
>> backport 3 patches. Which is imo reasonable.
>
>
> 1 and 2 could indeed be left out, but the end-result will look really ugly
> (e.g., x and y restoration will come from save_set.x and save_set.y, while
> frame buffer restoration will come from old_fb (and IMO, it's always better
> to first cleanup the code that one is about to touch and then make
> functional changes).
>
> Patch 4, however, is required because of saving and restoration of 'enabled'
> flag, but it could be split in two: the required part that restores the
> enabled flag that restores only the the 'enabled' flag and the cleanup part
> that eliminates unecessary restoration of hwmode field
Oh right, I've forgotten that between the review and writing the mail
;-) I guess we could try to bend the stable rules a bit and just
submit all 6. It's a regression fix after all, and at least personally
I prefer the most minimal backports to avoid diverging between
upstream and stable kernel branches.
But I guess that's Dave's call to make.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel
mailing list