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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Dec 2020 12:57:32 +0200
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Daniel Scally <djrscally@...il.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        devel@...ica.org, "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Yong Zhi <yong.zhi@...el.com>,
        Bingbu Cao <bingbu.cao@...el.com>,
        Tian Shu Qiu <tian.shu.qiu@...el.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Robert Moore <robert.moore@...el.com>,
        Erik Kaneda <erik.kaneda@...el.com>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        kieran.bingham+renesas@...asonboard.com,
        Linus Walleij <linus.walleij@...aro.org>,
        "Krogerus, Heikki" <heikki.krogerus@...ux.intel.com>,
        Tsuchiya Yuto <kitakar@...il.com>, jorhand@...ux.microsoft.com
Subject: Re: [PATCH v2 12/12] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver

On Mon, Dec 21, 2020 at 10:52:52AM +0000, Daniel Scally wrote:
> 
> 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@...il.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

Both.

> with that if so - we have no in scope devices where that will be a
> problem at the moment.

I guess there will be quite a few additional things to address before
getting anything with four sensors working.

-- 
Regards,

Sakari Ailus