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]
Message-ID: <76b3d25-2ba3-2f9f-3ed6-61a63983a225@inria.fr>
Date: Tue, 30 Apr 2024 19:23:07 +0200 (CEST)
From: Julia Lawall <julia.lawall@...ia.fr>
To: R Sundar <prosunofficial@...il.com>
cc: Christophe JAILLET <christophe.jaillet@...adoo.fr>, mripard@...nel.org, 
    mchehab@...nel.org, linux-media@...r.kernel.org, 
    linux-kernel@...r.kernel.org, skhan@...uxfoundation.org, 
    javier.carrasco.cruz@...il.com
Subject: Re: [PATCH linux-next] media:cdns-csi2tx: replace of_node_put() with
 __free



On Tue, 30 Apr 2024, R Sundar wrote:

> On 30/04/24 00:10, Christophe JAILLET wrote:
> > Le 29/04/2024 à 19:15, R Sundar a écrit :
> > > Use the new cleanup magic to replace of_node_put() with
> > > __free(device_node) marking to auto release when they get out of scope.
> > >
> > > Suggested-by: Julia Lawall <julia.lawall@...ia.fr>
> > > Signed-off-by: R Sundar <prosunofficial@...il.com>
> > > ---
> > >   drivers/media/platform/cadence/cdns-csi2tx.c | 19 +++++++------------
> > >   1 file changed, 7 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/cadence/cdns-csi2tx.c
> > > b/drivers/media/platform/cadence/cdns-csi2tx.c
> > > index 3d98f91f1bee..88aed2f299fd 100644
> > > --- a/drivers/media/platform/cadence/cdns-csi2tx.c
> > > +++ b/drivers/media/platform/cadence/cdns-csi2tx.c
> > > @@ -496,48 +496,43 @@ static int csi2tx_get_resources(struct csi2tx_priv
> > > *csi2tx,
> > >   static int csi2tx_check_lanes(struct csi2tx_priv *csi2tx)
> > >   {
> > >       struct v4l2_fwnode_endpoint v4l2_ep = { .bus_type = 0 };
> > > -    struct device_node *ep;
> > >       int ret, i;
> > > -
> > > -    ep = of_graph_get_endpoint_by_regs(csi2tx->dev->of_node, 0, 0);
> > > +    struct device_node *ep __free(device_node) =
> > > +        of_graph_get_endpoint_by_regs(csi2tx->dev->of_node, 0, 0);
> > > +
> > >       if (!ep)
> > >           return -EINVAL;
> > >       ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &v4l2_ep);
> > >       if (ret) {
> > >           dev_err(csi2tx->dev, "Could not parse v4l2 endpoint\n");
> > > -        goto out;
> > > +        return ret;
> > >       }
> > >       if (v4l2_ep.bus_type != V4L2_MBUS_CSI2_DPHY) {
> > >           dev_err(csi2tx->dev, "Unsupported media bus type: 0x%x\n",
> > >               v4l2_ep.bus_type);
> > > -        ret = -EINVAL;
> > > -        goto out;
> > > +        return -EINVAL;
> > >       }
> > >       csi2tx->num_lanes = v4l2_ep.bus.mipi_csi2.num_data_lanes;
> > >       if (csi2tx->num_lanes > csi2tx->max_lanes) {
> > >           dev_err(csi2tx->dev,
> > >               "Current configuration uses more lanes than supported\n");
> > > -        ret = -EINVAL;
> > > -        goto out;
> > > +        return -EINVAL;
> > >       }
> > >       for (i = 0; i < csi2tx->num_lanes; i++) {
> > >           if (v4l2_ep.bus.mipi_csi2.data_lanes[i] < 1) {
> > >               dev_err(csi2tx->dev, "Invalid lane[%d] number: %u\n",
> > >                   i, v4l2_ep.bus.mipi_csi2.data_lanes[i]);
> > > -            ret = -EINVAL;
> > > -            goto out;
> > > +            return -EINVAL;
> > >           }
> > >       }
> > >       memcpy(csi2tx->lanes, v4l2_ep.bus.mipi_csi2.data_lanes,
> > >              sizeof(csi2tx->lanes));
> > > -out:
> > > -    of_node_put(ep);
> > >       return ret;
> >
> > Hi,
> >
> > Nit: return 0; ?
> >
> > CJ
> >
> > >   }
> >
> Hi,
>
> In success case, ret variable value also will be zero, else for non-zero ret
> value it will return from v4l2_fwnode_endpoint_parse()'s error case handling
> block.

Indeed, but it seems that the return ret at the end of the function always
returns 0?  If that is the case, return 0 would be better, as one can see
that that code is only reached in the success case.

julia

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ