On Thu, 05 Oct 2017, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> On Thu, Oct 5, 2017 at 6:45 AM, Joonas Lahtinen
> <joonas.lahtinen@xxxxxxxxxxxxxxx> 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@xxxxxxxxx>
>>> Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>
>>> Cc: David Airlie <airlied@xxxxxxxx>
>>> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
>>> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
>>> Cc: Oscar Mateo <oscar.mateo@xxxxxxxxx>
>>> Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx
>>> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
>>> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>>> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
>>
>> <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@xxxxxxxxxxxxxxx>
>
> 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.
We'll pick this when we have -rc3.
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
