Re: [PATCH v2 12/12] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver

From: Daniel Scally <djrscally@gmail.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	devel@acpica.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Yong Zhi <yong.zhi@intel.com>, Bingbu Cao <bingbu.cao@intel.com>,
	Tian Shu Qiu <tian.shu.qiu@intel.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Robert Moore <robert.moore@intel.com>,
	Erik Kaneda <erik.kaneda@intel.com>,
	Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Jacopo Mondi <jacopo+renesas@jmondi.org>,
	kieran.bingham+renesas@ideasonboard.com,
	Linus Walleij <linus.walleij@linaro.org>,
	"Krogerus, Heikki" <heikki.krogerus@linux.intel.com>,
	Tsuchiya Yuto <kitakar@gmail.com>,
	jorhand@linux.microsoft.com
Subject: Re: [PATCH v2 12/12] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
Date: Mon, 21 Dec 2020 10:52:52 +0000	[thread overview]
Message-ID: <5ba6ada9-c8a6-fa66-b8d6-5769b7bcdfea@gmail.com> (raw)
In-Reply-To: <20201221102147.GJ26370@paasikivi.fi.intel.com>

On 21/12/2020 10:21, Sakari Ailus wrote:
> 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 <djrscally@gmail.com> 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.
Done for the next version
>
>>> ...
>>>
>>>>>> +                    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.

You mean just raise an error with dev_err()? Or fail the probe and
unwind the 4 sensors that were already connected successfully? I'm fine
with that if so - we have no in scope devices where that will be a
problem at the moment.