All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Alex Elder <elder@linaro.org>, Ohad Ben-Cohen <ohad@wizery.com>,
	Suman Anna <s-anna@ti.com>,
	linux-remoteproc <linux-remoteproc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] remoteproc: Split firmware name allocation from rproc_alloc()
Date: Tue, 14 Apr 2020 09:43:22 -0600	[thread overview]
Message-ID: <CANLsYkx69cZotLUrt170XYiYxpkTGKBNC8FUioBD=OSnDYm46Q@mail.gmail.com> (raw)
In-Reply-To: <20200414005506.GG20625@builder.lan>

Hi guys,

On Mon, 13 Apr 2020 at 18:54, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Mon 13 Apr 13:56 PDT 2020, Alex Elder wrote:
>
> > On 4/13/20 2:33 PM, Mathieu Poirier wrote:
> > > Make the firmware name allocation a function on its own in order to
> > > introduce more flexibility to function rproc_alloc().
> > >
> > > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> >
> > I didn't look at the larger context (MCU series); I'm only looking
> > at this (and the others in this series) in isolation.  I like
> > that you're encapsulating this stuff into functions but doing so
> > doesn't really add any flexibility.
> >
> > Two small suggestions for you to consider but they're truly
> > more about style so it's entirely up to you.  Outside of that
> > this looks straightforward to me, and the result of the series
> > is an improvement.
> >
> > I'll let you comment on my suggestions before offering my
> > "reviewed-by" indication.
> >
> >                                       -Alex
> >
> > > ---
> > >  drivers/remoteproc/remoteproc_core.c | 66 ++++++++++++++++------------
> > >  1 file changed, 39 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > > index 80056513ae71..4dee63f319ba 100644
> > > --- a/drivers/remoteproc/remoteproc_core.c
> > > +++ b/drivers/remoteproc/remoteproc_core.c
> > > @@ -1979,6 +1979,33 @@ static const struct device_type rproc_type = {
> > >     .release        = rproc_type_release,
> > >  };
> > >
> > > +static int rproc_alloc_firmware(struct rproc *rproc,
> > > +                           const char *name, const char *firmware)
> > > +{
> > > +   char *p, *template = "rproc-%s-fw";
> > > +   int name_len;
> >
> > Not a big deal (and maybe it's not consistent with other nearby
> > style) but template and name_len could be defined inside the
> > "if (!firmware)" block.
> >
>
> I prefer variables declared in the beginning of the function, so I'm
> happy with this.
>
> > > +   if (!firmware) {
> > > +           /*
> > > +            * If the caller didn't pass in a firmware name then
> > > +            * construct a default name.
> > > +            */
> > > +           name_len = strlen(name) + strlen(template) - 2 + 1;
> > > +           p = kmalloc(name_len, GFP_KERNEL);
> >
> >
> > I don't know if it would be an improvement, but you could
> > check for a null p value below for both cases.  I.e.:
> >
> >               if (p)
> >                       snprintf(p, ...);
> >
>
> Moving the common NULL check and return out seems nice, but given that
> we then have to have this positive conditional I think the end result is
> more complex.
>
> That said, if we're not just doing a verbatim copy from rproc_alloc() I
> think we should make this function:
>
>         if (!firmware)
>                 p = kasprintf(GFP_KERNEL, "rproc-%s-fw", name);
>         else
>                 p = kstrdup_const(firmware, GFP_KERNEL);
>
>         rproc->firmware = p;
>
>         return p ? 0 : -ENOMEM;

At this time I was going for a pure re-arrangement of the code and
avoiding further improvement.  This is simple enough that it can be
rolled-in the next revision.

Thanks,
Mathieu

>
> Regards,
> Bjorn
>
> > (more below)
> >
> > > +           if (!p)
> > > +                   return -ENOMEM;
> > > +           snprintf(p, name_len, template, name);
> > > +   } else {
> > > +           p = kstrdup(firmware, GFP_KERNEL);
> > > +           if (!p)
> > > +                   return -ENOMEM;
> > > +   }
> > > +
> >
> >       if (!p)
> >               return -ENOMEM;
> >
> > > +   rproc->firmware = p;
> > > +
> > > +   return 0;
> > > +}
> > > +
> > >  /**
> > >   * rproc_alloc() - allocate a remote processor handle
> > >   * @dev: the underlying device
> > > @@ -2007,42 +2034,21 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
> > >                       const char *firmware, int len)
> > >  {
> > >     struct rproc *rproc;
> > > -   char *p, *template = "rproc-%s-fw";
> > > -   int name_len;
> > >
> > >     if (!dev || !name || !ops)
> > >             return NULL;
> > >
> > > -   if (!firmware) {
> > > -           /*
> > > -            * If the caller didn't pass in a firmware name then
> > > -            * construct a default name.
> > > -            */
> > > -           name_len = strlen(name) + strlen(template) - 2 + 1;
> > > -           p = kmalloc(name_len, GFP_KERNEL);
> > > -           if (!p)
> > > -                   return NULL;
> > > -           snprintf(p, name_len, template, name);
> > > -   } else {
> > > -           p = kstrdup(firmware, GFP_KERNEL);
> > > -           if (!p)
> > > -                   return NULL;
> > > -   }
> > > -
> > >     rproc = kzalloc(sizeof(struct rproc) + len, GFP_KERNEL);
> > > -   if (!rproc) {
> > > -           kfree(p);
> > > +   if (!rproc)
> > >             return NULL;
> > > -   }
> > > +
> > > +   if (rproc_alloc_firmware(rproc, name, firmware))
> > > +           goto free_rproc;
> > >
> > >     rproc->ops = kmemdup(ops, sizeof(*ops), GFP_KERNEL);
> > > -   if (!rproc->ops) {
> > > -           kfree(p);
> > > -           kfree(rproc);
> > > -           return NULL;
> > > -   }
> > > +   if (!rproc->ops)
> > > +           goto free_firmware;
> > >
> > > -   rproc->firmware = p;
> > >     rproc->name = name;
> > >     rproc->priv = &rproc[1];
> > >     rproc->auto_boot = true;
> > > @@ -2091,6 +2097,12 @@ struct rproc *rproc_alloc(struct device *dev, const char *name,
> > >     rproc->state = RPROC_OFFLINE;
> > >
> > >     return rproc;
> > > +
> > > +free_firmware:
> > > +   kfree(rproc->firmware);
> > > +free_rproc:
> > > +   kfree(rproc);
> > > +   return NULL;
> > >  }
> > >  EXPORT_SYMBOL(rproc_alloc);
> > >
> > >
> >

  parent reply	other threads:[~2020-04-14 15:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 19:33 [PATCH 0/4] remoteproc: Refactor function rproc_alloc() Mathieu Poirier
2020-04-13 19:33 ` [PATCH 1/4] remoteproc: Fix a bug in rproc_alloc() Mathieu Poirier
2020-04-13 19:33 ` [PATCH 2/4] remoteproc: Split firmware name allocation from rproc_alloc() Mathieu Poirier
2020-04-13 20:56   ` Alex Elder
2020-04-14  0:55     ` Bjorn Andersson
2020-04-14  0:55       ` Bjorn Andersson
2020-04-14  0:55         ` Bjorn Andersson
2020-04-14 12:36         ` Alex Elder
2020-04-14 15:43         ` Mathieu Poirier [this message]
2020-04-14 19:48           ` Bjorn Andersson
2020-04-14 19:48             ` Bjorn Andersson
2020-04-14 19:48               ` Bjorn Andersson
2020-04-14 19:44         ` Mathieu Poirier
2020-04-14 23:16           ` Bjorn Andersson
2020-04-14 23:16             ` Bjorn Andersson
2020-04-14 23:16               ` Bjorn Andersson
2020-04-15 19:34               ` Mathieu Poirier
2020-04-14 16:11     ` Mathieu Poirier
2020-04-13 19:34 ` [PATCH 3/4] remoteproc: Split rproc_ops " Mathieu Poirier
2020-04-13 20:56   ` Alex Elder
2020-04-13 19:34 ` [PATCH 4/4] remoteproc: Get rid of tedious error path Mathieu Poirier
2020-04-13 20:56   ` Alex Elder
2020-04-13 20:56   ` Alex Elder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANLsYkx69cZotLUrt170XYiYxpkTGKBNC8FUioBD=OSnDYm46Q@mail.gmail.com' \
    --to=mathieu.poirier@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=elder@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=s-anna@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.