[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87354sij2i.fsf@minerva.mail-host-address-is-not-set>
Date: Sat, 22 Apr 2023 07:26:13 +0200
From: Javier Martinez Canillas <javierm@...hat.com>
To: Maxime Ripard <maxime@...no.tech>, Emma Anholt <emma@...olt.net>,
Maxime Ripard <mripard@...nel.org>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>
Cc: Hans Verkuil <hverkuil@...all.nl>,
Maxime Ripard <maxime@...no.tech>,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
Dave Stevenson <dave.stevenson@...pberrypi.com>
Subject: Re: [PATCH v3 1/9] drm/vc4: Switch to container_of_const
Maxime Ripard <maxime@...no.tech> writes:
Hello Maxime,
> container_of_const() allows to preserve the pointer constness and is
> thus more flexible than inline functions.
>
> Let's switch all our instances of container_of() to
> container_of_const().
>
> Signed-off-by: Maxime Ripard <maxime@...no.tech>
> ---
[...]
> -static inline struct vc4_dpi *
> -to_vc4_dpi(struct drm_encoder *encoder)
> -{
> - return container_of(encoder, struct vc4_dpi, encoder.base);
> -}
> +#define to_vc4_dpi(_encoder) \
> + container_of_const(_encoder, struct vc4_dpi, encoder.base)
>
A disadvantage of this approach though is that the type checking is lost.
Since you already had these, I would probably had changed them to return
a const pointer and just replace container_of() for container_of_const().
But I see that there are a lot of patches from Greg all over the kernel
that do exactly this, dropping static inline functions in favor of using
container_of_const() directly. So it seems the convention is what you do.
Reviewed-by: Javier Martinez Canillas <javierm@...hat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Powered by blists - more mailing lists