[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220205085151.61088d8e.dorota.czaplejewicz@puri.sm>
Date: Sat, 5 Feb 2022 08:51:51 +0100
From: Dorota Czaplejewicz <dorota.czaplejewicz@...i.sm>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Alexander Stein <alexander.stein@...tq-group.com>,
Steve Longerbeam <slongerbeam@...il.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Rui Miguel Silva <rmfrfs@...il.com>,
linux-media@...r.kernel.org, linux-staging@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] media: imx: Fail conversion if pixel format not
supported
Hi Laurent,
On Sat, 5 Feb 2022 06:07:37 +0200
Laurent Pinchart <laurent.pinchart@...asonboard.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@...i.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@...i.sm>
> > Signed-off-by: Alexander Stein <alexander.stein@...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);
> >
>
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists