From: Chee, Tien Fong <tien.fong.chee@intel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 3/3] common: Generic loader for file system
Date: Mon, 2 Jul 2018 08:12:12 +0000 [thread overview]
Message-ID: <1530519132.9877.8.camel@intel.com> (raw)
In-Reply-To: <20180629141334.09b2000f@crub>
On Fri, 2018-06-29 at 14:13 +0200, Anatolij Gustschin wrote:
> Hi,
>
> please see some comments below.
>
> On Mon, 25 Jun 2018 21:28:58 +0800
> tien.fong.chee at intel.com tien.fong.chee at intel.com wrote:
>
> >
> > +/**
> > + * _request_firmware_prepare - Prepare firmware struct.
> > + *
> > + * @firmware_p: Pointer to pointer to firmware image.
> > + * @name: Name of firmware file.
> > + * @dbuf: Address of buffer to load firmware into.
> > + * @size: Size of buffer.
> > + * @offset: Offset of a file for start reading into buffer.
> > + *
> > + * Return: Negative value if fail, 0 for successful.
> > + */
> > +static int _request_firmware_prepare(struct firmware **firmware_p,
> > + const char *name, void *dbuf,
> > + size_t size, u32 offset)
> > +{
> > + struct firmware *firmware;
> > + struct firmware_priv *fw_priv;
> > +
> > + *firmware_p = NULL;
> > +
> > + if (!name || name[0] == '\0')
> > + return -EINVAL;
> > +
> > + firmware = calloc(1, sizeof(*firmware));
> > + if (!firmware)
> > + return -ENOMEM;
> > +
> > + fw_priv = calloc(1, sizeof(*fw_priv));
> > + if (!fw_priv) {
> > + free(firmware);
> > + return -ENOMEM;
> > + }
> please add a note to API description that the API user should
> free() *firmware_p and *firmware_p->priv structs after usage of
> request_firmware_into_buf(), otherwise it will always leak memory
> while subsequent calls of request_firmware_into_buf() with the
> same *firmware_p argument.
>
Okay, i will add the description into doc. I can create a function to
release memory allocation and setting both *firmware_p and fw_priv to
null for user.
> Or probably we should better allow request_firmware_into_buf() to
> be called multiple times with prepared *firmware_p stuct for
> reloading the same firmware image when needed.
> Then request_firmware_into_buf() should check if the given
> *firmware_p stuct is already initialized and must not call
> _request_firmware_prepare() in this case.
>
Okay, this should work in this way by checking both *firmware_p and
fw_priv, if they are not null, memory allocation would be skipped for
better performance. However, *firmware_p always need to get updated
with function arguments, because it could be chunk by chunk
transferring if image is larger than available buffer.
> >
> > +
> > + fw_priv->name = name;
> > + fw_priv->offset = offset;
> > + firmware->data = dbuf;
> > + firmware->size = size;
> > + firmware->priv = fw_priv;
> > + *firmware_p = firmware;
> > +
> > + return 0;
> > +}
> --
> Anatolij
>
prev parent reply other threads:[~2018-07-02 8:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-25 13:28 [U-Boot] [PATCH v3 0/3] Generic file system firmware loader DM tien.fong.chee at intel.com
2018-06-25 13:28 ` [U-Boot] [PATCH v3 1/3] doc: Add new doc for file system firmware loader driver model tien.fong.chee at intel.com
2018-06-25 13:28 ` [U-Boot] [PATCH v3 2/3] doc: dtbinding: Add file system firmware loader binding document tien.fong.chee at intel.com
2018-06-26 3:58 ` Simon Glass
2018-06-27 8:32 ` Chee, Tien Fong
2018-06-27 21:03 ` Simon Glass
2018-06-28 8:04 ` Chee, Tien Fong
2018-06-28 8:58 ` Chee, Tien Fong
2018-06-30 4:19 ` Simon Glass
2018-07-02 8:26 ` Chee, Tien Fong
2018-07-09 2:39 ` Simon Glass
2018-07-09 6:50 ` Chee, Tien Fong
2018-06-25 13:28 ` [U-Boot] [PATCH v3 3/3] common: Generic loader for file system tien.fong.chee at intel.com
2018-06-26 3:58 ` Simon Glass
2018-06-27 8:41 ` Chee, Tien Fong
2018-06-27 21:03 ` Simon Glass
2018-06-28 4:45 ` Chee, Tien Fong
2018-06-27 20:23 ` Tom Rini
2018-06-29 12:13 ` Anatolij Gustschin
2018-07-02 8:12 ` Chee, Tien Fong [this message]
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=1530519132.9877.8.camel@intel.com \
--to=tien.fong.chee@intel.com \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox