Message ID | 20220204121514.2762676-5-alexander.stein@ew.tq-group.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1nFxVB-004Lpx-Rg; Fri, 04 Feb 2022 12:15:46 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358659AbiBDMPn (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Fri, 4 Feb 2022 07:15:43 -0500 Received: from mx1.tq-group.com ([93.104.207.81]:57007 "EHLO mx1.tq-group.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238672AbiBDMPe (ORCPT <rfc822;linux-media@vger.kernel.org>); Fri, 4 Feb 2022 07:15:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1643976934; x=1675512934; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=w/GuNznqndIUcAdDbJ2FxtN8SD25HIguOxBaARlAb1E=; b=ETZatjqwt/qlZvhTaY3bT2RVIvrFY6KeTMWp6aU1kDDQCBHjKpY+/eGS FFcf3fO6F94jDk4HJix2ZukOzoZ2EEIaA+39MaqH/ahiUMtVMxyLMtAAR HfiswdJ9qt555Umf8cZpVIoiYlwLwVkgXcdlPSm689DpvPeO9xqIyHFB/ +Ad7Fv/crexWMsY88cy/716A2BlugsqMZ2OYnLA6XemnsvcT0EWhPZjYU JQuO9RhZtOvfGBeErZ34Xo85YxkkfKC4qhq7GM8hUU0Q9Bi91bUKNJJh6 yn5YEyclHoeofzSldBTELONAUf/fyfM8SPTMXy+PkRsb/Ps4OqIFX4QiL Q==; X-IronPort-AV: E=Sophos;i="5.88,342,1635199200"; d="scan'208";a="21903443" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 04 Feb 2022 13:15:30 +0100 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Fri, 04 Feb 2022 13:15:30 +0100 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Fri, 04 Feb 2022 13:15:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1643976930; x=1675512930; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=w/GuNznqndIUcAdDbJ2FxtN8SD25HIguOxBaARlAb1E=; b=CvwyRAB+K8AiIManazXd7kpO5CcK37/S9oqyR8ayntBF4BeHtHhiOW40 El4mYVm2ttbqNLzcKBFyMjEamqX20DfD1HlikHdXJfygFiRlNjH/R0LRL wO74OboqI8YJKgYD8pOQhjDczptuvAB6t+2Ozy17Xa1kVO3/6RbjdoKPc WZ/NDjaT2KFqGDEdkDLNB8a/kBQm9Mu8clP+Dq5fwDxwpgrv2MSKY36Ho xoSjFpc5nW6B+PKMmxS9blBAlgjqfHXSbuyFaDWtCsQscVzeObkR/jTwP lPJvoxJ4+Y9DcYqUQ99Iytye+qc52ScavL3YVF5Ago3wGc1o8PkzlMOyt Q==; X-IronPort-AV: E=Sophos;i="5.88,342,1635199200"; d="scan'208";a="21903430" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 04 Feb 2022 13:15:25 +0100 Received: from steina-w.tq-net.de (unknown [10.123.49.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by vtuxmail01.tq-net.de (Postfix) with ESMTPSA id 43F63280065; Fri, 4 Feb 2022 13:15:25 +0100 (CET) From: Alexander Stein <alexander.stein@ew.tq-group.com> To: Steve Longerbeam <slongerbeam@gmail.com>, Philipp Zabel <p.zabel@pengutronix.de>, Mauro Carvalho Chehab <mchehab@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Rui Miguel Silva <rmfrfs@gmail.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> Cc: linux-media@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Alexander Stein <alexander.stein@ew.tq-group.com> Subject: [PATCH 4/8] media: imx: Fail conversion if pixel format not supported Date: Fri, 4 Feb 2022 13:15:10 +0100 Message-Id: <20220204121514.2762676-5-alexander.stein@ew.tq-group.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220204121514.2762676-1-alexander.stein@ew.tq-group.com> References: <20220204121514.2762676-1-alexander.stein@ew.tq-group.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -7.4 (-------) X-LSpam-Report: No, score=-7.4 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_HI=-5 autolearn=ham autolearn_force=no |
Series |
imx7/imx8mm media / csi patches
|
|
Commit Message
Alexander Stein
Feb. 4, 2022, 12:15 p.m. UTC
From: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> imx_media_find_mbus_format has NULL as a valid return value, therefore the caller should take it into account. Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> --- drivers/staging/media/imx/imx-media-utils.c | 3 +++ 1 file changed, 3 insertions(+)
Comments
Hi Alexander and Dorota, Thank you for the patch. On Fri, Feb 04, 2022 at 01:15:10PM +0100, Alexander Stein wrote: > From: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> > > imx_media_find_mbus_format has NULL as a valid return value, > therefore the caller should take it into account. > > Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > --- > drivers/staging/media/imx/imx-media-utils.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/staging/media/imx/imx-media-utils.c b/drivers/staging/media/imx/imx-media-utils.c > index 32aaa2e81bea..e0a256a08c3b 100644 > --- a/drivers/staging/media/imx/imx-media-utils.c > +++ b/drivers/staging/media/imx/imx-media-utils.c > @@ -544,6 +544,9 @@ static int imx56_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix, > cc = imx_media_find_mbus_format(code, PIXFMT_SEL_YUV); The code passed to the function comes from the previous line: imx_media_enum_mbus_formats(&code, 0, PIXFMT_SEL_YUV); As far as I can tell, this is guaranteed to return a code that will result in imx_media_find_mbus_format() returning a non-NULL pointer. > } > > + if (!cc) > + return -EINVAL; > + > /* Round up width for minimum burst size */ > width = round_up(mbus->width, 8); >
Hi Laurent, On Sat, 5 Feb 2022 06:07:37 +0200 Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Alexander and Dorota, > > Thank you for the patch. > > On Fri, Feb 04, 2022 at 01:15:10PM +0100, Alexander Stein wrote: > > From: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> > > > > imx_media_find_mbus_format has NULL as a valid return value, > > therefore the caller should take it into account. > > > > Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> > > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > > --- > > drivers/staging/media/imx/imx-media-utils.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/staging/media/imx/imx-media-utils.c b/drivers/staging/media/imx/imx-media-utils.c > > index 32aaa2e81bea..e0a256a08c3b 100644 > > --- a/drivers/staging/media/imx/imx-media-utils.c > > +++ b/drivers/staging/media/imx/imx-media-utils.c > > @@ -544,6 +544,9 @@ static int imx56_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix, > > cc = imx_media_find_mbus_format(code, PIXFMT_SEL_YUV); > > The code passed to the function comes from the previous line: > > imx_media_enum_mbus_formats(&code, 0, PIXFMT_SEL_YUV); > > As far as I can tell, this is guaranteed to return a code that will > result in imx_media_find_mbus_format() returning a non-NULL pointer. > While I am not well-versed in the implicit code style of the kernel, I decided to leave it in because it makes the code more locally legible. With a check here, even a non-functional one, there's no need to understand the internals of `imx_media_find_mbus_format` that are only implicit. That makes the code less surprising when interested only in the outer function. The other advantage of a check is becoming robust against future changes to `imx_media_find_mbus_format` itself. I don't have a strong preference about keeping or leaving this patch, but if this check was there in the first place, I wouldn't have spent time trying to figure out whether there's a bug here. Cheers, Dorota > > } > > > > + if (!cc) > > + return -EINVAL; > > + > > /* Round up width for minimum burst size */ > > width = round_up(mbus->width, 8); > > >
Hi Laurent and Dorota, Am Samstag, 5. Februar 2022, 08:51:51 CET schrieb Dorota Czaplejewicz: > * PGP Signed by an unknown key > > Hi Laurent, > > On Sat, 5 Feb 2022 06:07:37 +0200 > > Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Alexander and Dorota, > > > > Thank you for the patch. > > > > On Fri, Feb 04, 2022 at 01:15:10PM +0100, Alexander Stein wrote: > > > From: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> > > > > > > imx_media_find_mbus_format has NULL as a valid return value, > > > therefore the caller should take it into account. > > > > > > Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> > > > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > > > --- > > > > > > drivers/staging/media/imx/imx-media-utils.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/staging/media/imx/imx-media-utils.c > > > b/drivers/staging/media/imx/imx-media-utils.c index > > > 32aaa2e81bea..e0a256a08c3b 100644 > > > --- a/drivers/staging/media/imx/imx-media-utils.c > > > +++ b/drivers/staging/media/imx/imx-media-utils.c > > > @@ -544,6 +544,9 @@ static int imx56_media_mbus_fmt_to_pix_fmt(struct > > > v4l2_pix_format *pix,> > > > > cc = imx_media_find_mbus_format(code, PIXFMT_SEL_YUV); > > > > The code passed to the function comes from the previous line: > > imx_media_enum_mbus_formats(&code, 0, PIXFMT_SEL_YUV); > > > > As far as I can tell, this is guaranteed to return a code that will > > result in imx_media_find_mbus_format() returning a non-NULL pointer. > > While I am not well-versed in the implicit code style of the kernel, I > decided to leave it in because it makes the code more locally legible. With > a check here, even a non-functional one, there's no need to understand the > internals of `imx_media_find_mbus_format` that are only implicit. That > makes the code less surprising when interested only in the outer function. > > The other advantage of a check is becoming robust against future changes to > `imx_media_find_mbus_format` itself. > > I don't have a strong preference about keeping or leaving this patch, but if > this check was there in the first place, I wouldn't have spent time trying > to figure out whether there's a bug here. Laurent, thanks for your feedback. I'm on Dorota's side here. While you are right that the code from imx_media_enum_mbus_formats(&code, 0, PIXFMT_SEL_YUV); is guaranteed to return something. I don't lnek this implicit assumption over 2 function calls. Better be safe than sorry. For that reason code should be initialized as well. Will create a patch for that. Regards, Alexander
Hello, On Mon, Feb 07, 2022 at 10:52:00AM +0100, Alexander Stein wrote: > Am Samstag, 5. Februar 2022, 08:51:51 CET schrieb Dorota Czaplejewicz: > > On Sat, 5 Feb 2022 06:07:37 +0200 Laurent Pinchart wrote: > > > On Fri, Feb 04, 2022 at 01:15:10PM +0100, Alexander Stein wrote: > > > > From: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> > > > > > > > > imx_media_find_mbus_format has NULL as a valid return value, > > > > therefore the caller should take it into account. > > > > > > > > Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> > > > > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > > > > --- > > > > > > > > drivers/staging/media/imx/imx-media-utils.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/staging/media/imx/imx-media-utils.c > > > > b/drivers/staging/media/imx/imx-media-utils.c index > > > > 32aaa2e81bea..e0a256a08c3b 100644 > > > > --- a/drivers/staging/media/imx/imx-media-utils.c > > > > +++ b/drivers/staging/media/imx/imx-media-utils.c > > > > @@ -544,6 +544,9 @@ static int imx56_media_mbus_fmt_to_pix_fmt(struct > > > > v4l2_pix_format *pix,> > > > > > cc = imx_media_find_mbus_format(code, PIXFMT_SEL_YUV); > > > > > > The code passed to the function comes from the previous line: > > > imx_media_enum_mbus_formats(&code, 0, PIXFMT_SEL_YUV); > > > > > > As far as I can tell, this is guaranteed to return a code that will > > > result in imx_media_find_mbus_format() returning a non-NULL pointer. > > > > While I am not well-versed in the implicit code style of the kernel, I > > decided to leave it in because it makes the code more locally legible. With > > a check here, even a non-functional one, there's no need to understand the > > internals of `imx_media_find_mbus_format` that are only implicit. That > > makes the code less surprising when interested only in the outer function. > > > > The other advantage of a check is becoming robust against future changes to > > `imx_media_find_mbus_format` itself. > > > > I don't have a strong preference about keeping or leaving this patch, but if > > this check was there in the first place, I wouldn't have spent time trying > > to figure out whether there's a bug here. > > Laurent, thanks for your feedback. > I'm on Dorota's side here. While you are right that the code from > imx_media_enum_mbus_formats(&code, 0, PIXFMT_SEL_YUV); > is guaranteed to return something. I don't lnek this implicit assumption over > 2 function calls. Better be safe than sorry. For that reason code should be > initialized as well. Will create a patch for that. I'm fine with hardening the code even if the issue can't occur at the moment.
diff --git a/drivers/staging/media/imx/imx-media-utils.c b/drivers/staging/media/imx/imx-media-utils.c index 32aaa2e81bea..e0a256a08c3b 100644 --- a/drivers/staging/media/imx/imx-media-utils.c +++ b/drivers/staging/media/imx/imx-media-utils.c @@ -544,6 +544,9 @@ static int imx56_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix, cc = imx_media_find_mbus_format(code, PIXFMT_SEL_YUV); } + if (!cc) + return -EINVAL; + /* Round up width for minimum burst size */ width = round_up(mbus->width, 8);