On Thu, 05 Oct 2017, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Oct 5, 2017 at 6:45 AM, Joonas Lahtinen
> <joonas.lahti...@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.vet...@intel.com>
>>> Cc: Jani Nikula <jani.nik...@linux.intel.com>
>>> Cc: David Airlie <airl...@linux.ie>
>>> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
>>> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
>>> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
>>> Cc: Oscar Mateo <oscar.ma...@intel.com>
>>> Cc: intel-...@lists.freedesktop.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: Thomas Gleixner <t...@linutronix.de>
>>> Signed-off-by: Kees Cook <keesc...@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.lahti...@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.
We'll pick this when we have -rc3.
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
