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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48BF0C433DB for ; Mon, 21 Dec 2020 10:23:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1B76B22ADF for ; Mon, 21 Dec 2020 10:23:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726491AbgLUKXm (ORCPT ); Mon, 21 Dec 2020 05:23:42 -0500 Received: from mga05.intel.com ([192.55.52.43]:11752 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725796AbgLUKXm (ORCPT ); Mon, 21 Dec 2020 05:23:42 -0500 IronPort-SDR: fq4WAh9/8GzWh5LiMCr33F+oPJDvsno9QMZu6G0z3FPnncavWE1034LdXDDOIv/o/dq5dqnlya EmdhfjzN3tFQ== X-IronPort-AV: E=McAfee;i="6000,8403,9841"; a="260435755" X-IronPort-AV: E=Sophos;i="5.78,436,1599548400"; d="scan'208";a="260435755" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Dec 2020 02:21:56 -0800 IronPort-SDR: VfLDvac3fdFGdpCf23qdjQpfyWmKH3bg+KqqFuFCDCXXjnSj0R9/JiHSqwvM80aDuFoCn1gkGs DqKKQtVal4Xw== X-IronPort-AV: E=Sophos;i="5.78,436,1599548400"; d="scan'208";a="491515405" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Dec 2020 02:21:49 -0800 Received: by paasikivi.fi.intel.com (Postfix, from userid 1000) id D2725205F7; Mon, 21 Dec 2020 12:21:47 +0200 (EET) Date: Mon, 21 Dec 2020 12:21:47 +0200 From: Sakari Ailus To: Daniel Scally Cc: Andy Shevchenko , Andy Shevchenko , Linux Kernel Mailing List , ACPI Devel Maling List , Linux Media Mailing List , devel@acpica.org, "Rafael J. Wysocki" , Len Brown , Greg Kroah-Hartman , Yong Zhi , Bingbu Cao , Tian Shu Qiu , Mauro Carvalho Chehab , Robert Moore , Erik Kaneda , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Rasmus Villemoes , Laurent Pinchart , Jacopo Mondi , kieran.bingham+renesas@ideasonboard.com, Linus Walleij , "Krogerus, Heikki" , Tsuchiya Yuto , jorhand@linux.microsoft.com Subject: Re: [PATCH v2 12/12] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver Message-ID: <20201221102147.GJ26370@paasikivi.fi.intel.com> References: <20201217234337.1983732-1-djrscally@gmail.com> <20201217234337.1983732-13-djrscally@gmail.com> <20201218211732.GE4077@smile.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, Andy, On Sat, Dec 19, 2020 at 11:48:51PM +0000, Daniel Scally wrote: > On 19/12/2020 18:52, Andy Shevchenko wrote: > > On Sat, Dec 19, 2020 at 2:25 AM Daniel Scally wrote: > >> On 18/12/2020 21:17, Andy Shevchenko wrote: > >>> On Thu, Dec 17, 2020 at 11:43:37PM +0000, Daniel Scally wrote: > > > > ... > > > >>>> + sensor->ep_properties[0] = PROPERTY_ENTRY_U32(sensor->prop_names.bus_type, 4); > >>> > >>> Does 4 has any meaning that can be described by #define ? > >> > >> It's V4L2_FWNODE_BUS_TYPE_CSI2_DPHY: > >> > >> https://elixir.bootlin.com/linux/latest/source/drivers/media/v4l2-core/v4l2-fwnode.c#L36 > >> > >> That enum's not in an accessible header, but I can define it in this > >> module's header > > > > Maybe you can do a preparatory patch to make it visible to v4l2 > > drivers? (Like moving to one of v4l2 headers) > > Sure ok, guess media/v4l2-fwnode.h makes the most sense. Yes, please. > > > ... > > > >>>> + if (bridge->n_sensors >= CIO2_NUM_PORTS) { > >>>> + dev_warn(&cio2->dev, "Exceeded available CIO2 ports\n"); > >>> > >>>> + /* overflow i so outer loop ceases */ > >>>> + i = ARRAY_SIZE(cio2_supported_sensors); > >>>> + break; > >>> > >>> Why not to create a new label below and assign ret here with probably comment > >>> why it's not an error? > >> > >> Sure, I can do that, but since it wouldn't need any cleanup I could also > >> just return 0 here as Laurent suggest (but with a comment explaining why > >> that's ok as you say) - do you have a preference? > > > > While it's a good suggestion it will bring a bit of inconsistency into > > approach. Everywhere else in the function you are using the goto > > approach. > > So yes, I have a preference. > > No problem Laurent also commented on the return code. I might just handle this as an error. The earlier ports are fine, but there's also a problem with the data here. It'd be easier to spot that this way, and we can change this in the future if need be. -- Kind regards, Sakari Ailus