[PATCH] drm/i915: Convert timers to use timer_setup()
Kees Cook
keescook at chromium.org
Thu Oct 5 17:35:37 UTC 2017
On Thu, Oct 5, 2017 at 6:45 AM, Joonas Lahtinen
<joonas.lahtinen at linux.intel.com> wrote:
> On Wed, 2017-10-04 at 17:54 -0700, Kees Cook wrote:
>> 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: Daniel Vetter <daniel.vetter at intel.com>
>> Cc: Jani Nikula <jani.nikula at linux.intel.com>
>> Cc: David Airlie <airlied at linux.ie>
>> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>> Cc: Oscar Mateo <oscar.mateo at intel.com>
>> Cc: intel-gfx at lists.freedesktop.org
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Signed-off-by: Kees Cook <keescook at chromium.org>
>
> <SNIP>
>
>> @@ -32,9 +32,9 @@ static struct mock_request *first_request(struct mock_engine *engine)
>> link);
>> }
>>
>> -static void hw_delay_complete(unsigned long data)
>> +static void hw_delay_complete(struct timer_list *t)
>> {
>> - struct mock_engine *engine = (typeof(engine))data;
>> + struct mock_engine *engine = from_timer(engine, t, hw_delay);
>
> The order is bit strange to me, it's not same as with container_of, but
> I guess GCC will complain for getting it wrong. It's also slightly
> different doing the typeof for you, so I guess it makes sense, so:
Yeah, this seemed to be the least bad of several options. Other things
ended up being either very long, named unlike anything else already in
the kernel, etc.
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
Thanks!
> Do you expect for us to merge or are you looking to merge all timer
> changes from single tree?
If you have -rc3 in your tree already, please take this into your
tree. If you prefer the timer tree to carry it, that can happen too.
tglx suggested to me that it was better for maintainers to carry the
changes.
-Kees
--
Kees Cook
Pixel Security
More information about the dri-devel
mailing list