On Wed, 25 Oct 2017, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Wed, Oct 25, 2017 at 4:16 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: >> Quoting Kees Cook (2017-10-25 15:05:13) >>> On Wed, Oct 25, 2017 at 3:11 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: >>> > Quoting Chris Wilson (2017-10-25 11:24:19) >>> >> Quoting Chris Wilson (2017-10-24 17:17:09) >>> >> > Quoting Kees Cook (2017-10-24 16:13:44) >>> >> > > In preparation for unconditionally passing the struct timer_list pointer to >>> >> > > all timer callbacks, switch to using the new timer_setup() and from_timer() >>> >> > > to pass the timer pointer explicitly. >>> >> > > >>> >> > > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> >>> >> > > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> >>> >> > > Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> >>> >> > > Cc: David Airlie <airlied@xxxxxxxx> >>> >> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> >>> >> > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >>> >> > > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx >>> >> > > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx >>> >> > > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> >>> >> > >>> >> > Thank you for saving me from having to do this myself, >>> >> > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >>> >> >>> >> I've a small batch of selftests patches queued, so added this one and >>> >> will push to drm-intel-next-queued shortly. >>> > >>> > Oh dear, major faux pas. There is no timer_setup_on_stack yet. >>> >>> Argh. Right, sorry. That's only in -next. Since this is mainly a >>> mechanical change, should I carry this in the timer tree, or wait >>> until the merge window for it to go via i915? >> >> Jani has the final word, but my understanding is that there will be no >> more from i915 towards the 4.15 merge. Hmm, the origin of this timer, >> >> commit 214707fc2ce08d09982bc4fe4b7a1c1f010e82be >> Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> Date: Thu Oct 12 13:57:25 2017 +0100 >> >> drm/i915/selftests: Wrap a timer into a i915_sw_fence >> >> did make it into 4.15, so it would have been better to put into a >> separate tree for the 4.15 merge window anyway. In hindsight, yes this >> probably wants to be carried in the timer tree to be applied after i915. >> (I guess there will be a few other stragglers that need to be converted >> at the end of the merge window anyway.) > > Yeah, it's going to be messy, but I'll manage. I'll be carrying a lot > of other stuff as well. Avoiding conflicts will be the trick. Wheee. > :) Acked-by: Jani Nikula <jani.nikula@xxxxxxxxx> for merging via timer tree. Otherwise we'll need to wait for the changes to hit Linus' tree, then get backmerges to our tree, and it's v4.16 before you know it. ;) -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
