From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DD7E1FB3; Wed, 6 Aug 2025 08:16:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754468220; cv=none; b=WMGSlCIoh2/1YRIVrUF4Y/3KghnUoIPT2idOOE0XrFCZNbFEKkd+cXtwp6WOvGoudMEAOSMRPNApywMe4RSrnu+xr8034CQPfCNk+TKhS3IvM+1IR+Abc0Ad9Fx4tgWABGUzG0h7di2Xfl/IJ3f6mp3nKcY4JhOzzBhxKnyKak8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754468220; c=relaxed/simple; bh=mSezG6NRkxDtJlYf/ZFsHjMGCJmUaCUPnrgkbL+HJRE=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=RTXgsgHZ1CuANGhJNBsFqVrWzfv86fjk9NEgUHPbakFNa6NnuSZnDQ6BogoIEG0M+fK2HRAvB564Pqj3s91C4sdO09lStQ9+XvvErS8BlGKhHy394ngx6LiRuCLQnfNzFyYx1Bn1xJxfy/Nv5OoTrJjUiqqNkpBlAEGxkzODrXs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mBlcnILQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mBlcnILQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 657BBC4CEE7; Wed, 6 Aug 2025 08:16:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754468219; bh=mSezG6NRkxDtJlYf/ZFsHjMGCJmUaCUPnrgkbL+HJRE=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=mBlcnILQJQ8itwowSPTjPYWtbmq0X3J4O4tViHMM3acfOo0gkxWlN1i8bih8TRk/D QEK88TYFCCAgRdFf8N2vcHquOSOUzegVf8WhW/Lsok7t83wbntVOKbt/9YhJ0whgx3 5Pw9TjucRRgCke06GxlfRg3jM6WSnxmB2mHB5KAF2EmEO8hgceOt4Z1OmiUmUg2AaV FwUr0faqAjE7o5R8MImS6WtgvVuPDjdbXIJiJkaVw/SZsYXDBQgOf6d9ctuBZbPmCU dj5qL0frPJSAHC86jkv/ZZcGOlf7y8hBVfvg5g40mjFEZISVqZUlox2uPFHVojc+hd jTKUIqp5zZJRg== Message-ID: <49e753f4-f626-49ae-bf23-d2aecfcc6282@kernel.org> Date: Wed, 6 Aug 2025 10:16:37 +0200 Precedence: bulk X-Mailing-List: linux-renesas-soc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Hans Verkuil Subject: Re: [PATCH 11/65] media: Replace file->private_data access with custom functions To: Jacopo Mondi , Mauro Carvalho Chehab , Devarsh Thakkar , Benoit Parrot , Hans Verkuil , Mike Isely , Laurent Pinchart , Hans de Goede , Parthiban Veerasooran , Christian Gromm , Greg Kroah-Hartman , Alex Shi , Yanteng Si , Dongliang Mu , Jonathan Corbet , Tomasz Figa , Marek Szyprowski , Andy Walls , Michael Tretter , Pengutronix Kernel Team , Bin Liu , Matthias Brugger , AngeloGioacchino Del Regno , Dmitry Osipenko , Thierry Reding , Jonathan Hunter , Mirela Rabulea , Shawn Guo , Sascha Hauer , Fabio Estevam , Kieran Bingham , Michal Simek , Ming Qian , Zhou Peng , Xavier Roumegue , Philipp Zabel , Vikash Garodia , Dikshita Agarwal , Abhinav Kumar , Bryan O'Donoghue , Sylwester Nawrocki , Jernej Skrabec , Chen-Yu Tsai , Samuel Holland , Daniel Almeida , Neil Armstrong , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Nas Chung , Jackson Lee , Minghsiu Tsai , Houlong Wei , Andrew-CT Chen , Tiffany Lin , Yunfei Dong , Geert Uytterhoeven , Magnus Damm , Mikhail Ulyanov , Jacob Chen , Ezequiel Garcia , Heiko Stuebner , Detlev Casanova , Krzysztof Kozlowski , Alim Akhtar , Sylwester Nawrocki , =?UTF-8?Q?=C5=81ukasz_Stelmach?= , Andrzej Pietrasiewicz , Jacek Anaszewski , Andrzej Hajda , Fabien Dessenne , Hugues Fruchet , Jean-Christophe Trotin , Maxime Coquelin , Alexandre Torgue , Nicolas Dufresne , Benjamin Gaignard , Steve Longerbeam , Maxime Ripard , Paul Kocialkowski , =?UTF-8?Q?Niklas_S=C3=B6derlund?= , Robert Foss , Todor Tomov , Vladimir Zapolskiy , Corentin Labbe , Sakari Ailus , Bingbu Cao , Tianshu Qiu , Stanislaw Gruszka Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org, imx@lists.linux.dev, linux-renesas-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-usb@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, mjpeg-users@lists.sourceforge.net References: <20250802-media-private-data-v1-0-eb140ddd6a9d@ideasonboard.com> <20250802-media-private-data-v1-11-eb140ddd6a9d@ideasonboard.com> Content-Language: en-US, nl In-Reply-To: <20250802-media-private-data-v1-11-eb140ddd6a9d@ideasonboard.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02/08/2025 11:22, Jacopo Mondi wrote: > From: Laurent Pinchart > > Accessing file->private_data manually to retrieve the v4l2_fh pointer is > error-prone, as the field is a void * and will happily cast implicitly > to any pointer type. > > Replace all remaining locations that read the v4l2_fh pointer directly > from file->private_data and cast it to driver-specific file handle > structures with driver-specific functions that use file_to_v4l2_fh() and > perform the same cast. > > No functional change is intended, this only paves the way to remove > direct accesses to file->private_data and make V4L2 drivers safer. > Other accesses to the field will be addressed separately. > > Signed-off-by: Laurent Pinchart > Signed-off-by: Jacopo Mondi > --- > drivers/media/pci/ivtv/ivtv-driver.h | 5 ++++ > drivers/media/pci/ivtv/ivtv-fileops.c | 10 +++---- > drivers/media/pci/ivtv/ivtv-ioctl.c | 8 +++--- > drivers/media/platform/allegro-dvt/allegro-core.c | 7 ++++- > drivers/media/platform/amlogic/meson-ge2d/ge2d.c | 8 ++++-- > .../media/platform/chips-media/coda/coda-common.c | 7 ++++- > .../platform/chips-media/wave5/wave5-helper.c | 2 +- > .../media/platform/chips-media/wave5/wave5-vpu.h | 5 ++++ > drivers/media/platform/m2m-deinterlace.c | 7 ++++- > .../media/platform/mediatek/jpeg/mtk_jpeg_core.c | 7 ++++- > drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c | 7 ++++- > .../media/platform/mediatek/mdp3/mtk-mdp3-m2m.c | 7 ++++- > .../mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c | 2 +- > .../mediatek/vcodec/decoder/mtk_vcodec_dec_drv.h | 5 ++++ > .../mediatek/vcodec/encoder/mtk_vcodec_enc_drv.c | 2 +- > .../mediatek/vcodec/encoder/mtk_vcodec_enc_drv.h | 5 ++++ > drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c | 7 ++++- > drivers/media/platform/nxp/imx8-isi/imx8-isi-m2m.c | 7 ++++- > drivers/media/platform/nxp/mx2_emmaprp.c | 7 ++++- > drivers/media/platform/renesas/rcar_fdp1.c | 7 ++++- > drivers/media/platform/renesas/rcar_jpu.c | 7 ++++- > drivers/media/platform/rockchip/rga/rga.c | 3 +-- > drivers/media/platform/rockchip/rga/rga.h | 5 ++++ > drivers/media/platform/rockchip/rkvdec/rkvdec.c | 2 +- > drivers/media/platform/rockchip/rkvdec/rkvdec.h | 5 ++++ > .../media/platform/samsung/exynos-gsc/gsc-core.h | 6 +++++ > .../media/platform/samsung/exynos-gsc/gsc-m2m.c | 6 ++--- > .../media/platform/samsung/exynos4-is/fimc-core.h | 5 ++++ > .../media/platform/samsung/exynos4-is/fimc-m2m.c | 2 +- > drivers/media/platform/samsung/s5p-g2d/g2d.c | 7 +++-- > .../media/platform/samsung/s5p-jpeg/jpeg-core.c | 9 +++++-- > drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 6 ++--- > .../platform/samsung/s5p-mfc/s5p_mfc_common.h | 6 +++++ > drivers/media/platform/st/sti/bdisp/bdisp-v4l2.c | 7 ++++- > drivers/media/platform/st/sti/delta/delta-v4l2.c | 26 +++++++++++------- > drivers/media/platform/st/sti/hva/hva-v4l2.c | 31 ++++++++++++---------- > drivers/media/platform/st/sti/hva/hva.h | 2 -- > drivers/media/platform/st/stm32/dma2d/dma2d.c | 7 +++-- > drivers/media/platform/sunxi/sun8i-di/sun8i-di.c | 3 +-- > .../platform/sunxi/sun8i-rotate/sun8i_rotate.c | 3 +-- > drivers/media/platform/ti/omap3isp/ispvideo.c | 4 +-- > drivers/media/platform/ti/omap3isp/ispvideo.h | 6 +++++ > drivers/media/platform/verisilicon/hantro.h | 5 ++++ > drivers/media/platform/verisilicon/hantro_drv.c | 3 +-- > drivers/staging/media/imx/imx-media-csc-scaler.c | 7 ++++- > drivers/staging/media/meson/vdec/vdec.c | 24 ++++++----------- > drivers/staging/media/meson/vdec/vdec.h | 5 ++++ > drivers/staging/media/sunxi/cedrus/cedrus.c | 3 +-- > drivers/staging/media/sunxi/cedrus/cedrus.h | 5 ++++ > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 5 ---- > 50 files changed, 237 insertions(+), 100 deletions(-) > > diff --git a/drivers/media/pci/ivtv/ivtv-driver.h b/drivers/media/pci/ivtv/ivtv-driver.h > index a6ffa99e16bc64a5b7d3e48c1ab32b49a7989242..cad548b28e360ecfe2bcb9fcb5d12cd8823c3727 100644 > --- a/drivers/media/pci/ivtv/ivtv-driver.h > +++ b/drivers/media/pci/ivtv/ivtv-driver.h > @@ -388,6 +388,11 @@ static inline struct ivtv_open_id *fh2id(struct v4l2_fh *fh) > return container_of(fh, struct ivtv_open_id, fh); > } > > +static inline struct ivtv_open_id *file2id(struct file *filp) > +{ > + return container_of(file_to_v4l2_fh(filp), struct ivtv_open_id, fh); Why not write: return fh2id(file_to_v4l2_fh(filp)); Same for all other drivers that do this. I prefer to have the contained_of() in just one place. > +} > + > struct yuv_frame_info > { > u32 update; > diff --git a/drivers/media/platform/allegro-dvt/allegro-core.c b/drivers/media/platform/allegro-dvt/allegro-core.c > index 1f134e08923a528cc676f825da68951c97ac2f25..74977f3ae4844022c04de877f31b4fc6aaac0749 100644 > --- a/drivers/media/platform/allegro-dvt/allegro-core.c > +++ b/drivers/media/platform/allegro-dvt/allegro-core.c > @@ -302,6 +302,11 @@ struct allegro_channel { > unsigned int error; > }; > > +static inline struct allegro_channel *file_to_channel(struct file *filp) > +{ > + return container_of(file_to_v4l2_fh(filp), struct allegro_channel, fh); > +} > + > static inline int > allegro_channel_get_i_frame_qp(struct allegro_channel *channel) > { > @@ -3229,7 +3234,7 @@ static int allegro_open(struct file *file) > > static int allegro_release(struct file *file) > { > - struct allegro_channel *channel = fh_to_channel(file->private_data); > + struct allegro_channel *channel = file_to_channel(file); So a file_to_channel inline function was added, but it is used in just one place. I would prefer to just drop the inline function and instead write: struct allegro_channel *channel = fh_to_channel(file_to_v4l2_fh(file)); If this is needed in two or more places, then the extra inline makes sense, but it is a fairly common pattern that it is only needed in the release function. Adding a new inline just for that seems overkill to me. > > v4l2_m2m_ctx_release(channel->fh.m2m_ctx); > Regards, Hans