From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1F899C433EF for ; Tue, 8 Feb 2022 01:16:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=aow6EzgOYMACWHT+ISTvBUeMH7ZhJknJm3XlfNO8zNg=; b=KjWs4URwhoi6DC 9l8e4GWANVrCJziPrZlDXO9AQgo06yJhMyAS0pjRDf8sS5/WCJt0i+CweDcvshBPYREpGpBXcsDYp 6NEB7BME7/7Sw4w8X1zBsPEXeZhtqThyWatxhIhG3cPzIMN2N4cexILYRwHVZHdJcUZa6YNdRuIcl RvkyGljZG67G9bryPZUxCgM9X/FNm3CR3TAYP4ibQVTiOV+sDyf8k4gHSIW8NPkFnDqwkeUqw0Coa BdX8mxy7oE2liYLpIkXhh1LQrF5edqdKUnAXMQxi3Lz7x9elnWGCHdtKhQe1RLCRampXR/40OgU+o nQ577FnCN9M9GIhIsDhQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nHF63-00C8GG-FS; Tue, 08 Feb 2022 01:15:07 +0000 Received: from perceval.ideasonboard.com ([213.167.242.64]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nHF5z-00C8EY-Np for linux-arm-kernel@lists.infradead.org; Tue, 08 Feb 2022 01:15:05 +0000 Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 02A60340; Tue, 8 Feb 2022 02:14:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1644282900; bh=blvBN8apDdKJGfvkuQRdzEoFeeraC+PwppRok6BR2Zk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=G43PehzyokojQcX2wngd0xQ2hpShQbkk+sdysXF9nIvq9IeVUZvELzCr6NUwTkdL7 Z/mtgc3Vq4BH5ryF70FJonQVUVesvtOdgJ448B616j1cIG0kV/hSospSUs/QHAvpto XBQ2Pvc86H7sQo3oVpVgtTkVBeW2jicD2Hq6axps= Date: Tue, 8 Feb 2022 03:14:57 +0200 From: Laurent Pinchart To: Alexander Stein Cc: Dorota Czaplejewicz , Steve Longerbeam , Philipp Zabel , Mauro Carvalho Chehab , Greg Kroah-Hartman , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Rui Miguel Silva , linux-media@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: (EXT) Re: [PATCH 4/8] media: imx: Fail conversion if pixel format not supported Message-ID: References: <20220204121514.2762676-1-alexander.stein@ew.tq-group.com> <20220205085151.61088d8e.dorota.czaplejewicz@puri.sm> <1905895.usQuhbGJ8B@steina-w> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1905895.usQuhbGJ8B@steina-w> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220207_171503_956415_01D59C3F X-CRM114-Status: GOOD ( 33.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > > > > > > > > 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 > > > > Signed-off-by: Alexander Stein > > > > --- > > > > > > > > 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. -- Regards, Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel