All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chee, Tien Fong <tien.fong.chee@intel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 2/2] common: Generic firmware loader for file system
Date: Thu, 21 Dec 2017 05:39:37 +0000	[thread overview]
Message-ID: <1513834776.4001.9.camel@intel.com> (raw)
In-Reply-To: <20171219122155.2960c7b4@karo-electronics.de>

On Sel, 2017-12-19 at 12:21 +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Tue, 19 Dec 2017 10:31:13 +0000 Chee, Tien Fong wrote:
> > 
> > On Isn, 2017-12-18 at 08:39 +0100, Lothar Waßmann wrote:
> > > 
> > > Hi,
> > > 
> > > On Mon, 18 Dec 2017 13:10:56 +0800 tien.fong.chee at intel.com
> > > wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > ---
> > > >  common/Makefile            |   1 +
> > > >  common/fs_loader.c         | 311
> > > > +++++++++++++++++++++++++++++++++++++++++++++
> > > >  doc/README.firmware_loader |  77 +++++++++++
> > > >  include/fs_loader.h        |  28 ++++
> > > >  4 files changed, 417 insertions(+)
> > > >  create mode 100644 common/fs_loader.c
> > > >  create mode 100644 doc/README.firmware_loader
> > > >  create mode 100644 include/fs_loader.h
> > > > 
> > > [...]
> > > > 
> > > > 
> > > > diff --git a/common/fs_loader.c b/common/fs_loader.c
> > > > new file mode 100644
> > > > index 0000000..81cf5d6
> > > > --- /dev/null
> > > > +++ b/common/fs_loader.c
> > > [...]
> > > > 
> > > > 
> > > > +/*
> > > > + * Prepare firmware struct;
> > > > + * return -ve if fail.
> > > > + */
> > > > +static int _request_firmware_prepare(struct firmware
> > > > **firmware_p,
> > > > +				     const char *name, void
> > > > *dbuf,
> > > > +				     size_t size, u32 offset)
> > > > +{
> > > > +	struct firmware *firmware = NULL;
> > > > +	struct firmware_priv *fw_priv = NULL;
> > > > +
> > > > +	*firmware_p = NULL;
> > > > +
> > > > +	if (!name || name[0] == '\0')
> > > > +		return -EINVAL;
> > > > +
> > > > +	*firmware_p = firmware = calloc(1, sizeof(*firmware));
> > > > +
> > > > +	if (!firmware) {
> > > > +		printf("%s: calloc(struct firmware) failed\n",
> > > > __func__);
> > > > +		return -ENOMEM;
> > > > +	}
> > > > +
> > > > +	fw_priv = calloc(1, sizeof(*fw_priv));
> > > > +
> > > > +	if (!fw_priv) {
> > > > +		printf("%s: calloc(struct fw_priv) failed\n",
> > > > __func__);
> > > > +		return -ENOMEM;
> > > What about freeing 'firmware' and NULLing *firmware_p here?
> > There is no "freeing" support in U-Boot. I can assign NULL
> > 
> How do you come to that conclusion?
> 
Sorry for misleading because i was tracking the free function until i
saw the function direct return when the bit GD_FLG_FULL_MALLOC_INIT was
found in gd->flags in beginning of the function long time ago. So, i
always assume that memory will always be freed in relocation on most
cases.
I will put the free to the firmware in next release.
> > 
> > to *firmware_p.
> > > 
> > > Or better, do the assignment of *firmware_p at the end.
> > Are you means switch the location between *firmware_p and fw_priv
> > in
> > calloc?
> > 
> No. I would assign *firmware_p only when everything else was OK, so
> that there won't be a valid pointer in *firmware_p when the struct
> firmware it is pointing to has not been set up completely.
> 
> I would do like this:
> 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) {
> 		printf("%s: calloc(struct firmware) failed\n",
> __func__);
> 		return -ENOMEM;
> 	}
> 
> 	fw_priv = calloc(1, sizeof(*fw_priv));
> 	if (!fw_priv) {
> 		printf("%s: calloc(struct fw_priv) failed\n",
> __func__);
> 		free(firmware);
> 		return -ENOMEM;
> 	}
> 
> 	fw_priv->name = name;
> 	fw_priv->offset = offset;
> 	firmware->data = dbuf;
> 	firmware->size = size;
> 	firmware->priv = fw_priv;
> 	*firmware_p = firmware;
> 
> 	return 0;
> }
> so that *firmware_p is only assigned to when everything was OK.
> (Note, that there is no need to initialize firmware and fw_priv to
> NULL)
> 
Okay.
> > 
> > > 
> > > > 
> > > > + * fw_get_filesystem_firmware - load firmware into an
> > > > allocated
> > > > buffer
> > > > + * @location: An array of supported firmware location
> > > > + * @firmware_p: pointer to firmware image
> > > > + *
> > > > + * @return: size of total read
> > > > + *	    -ve when error
> > > > + */
> > > > +static int fw_get_filesystem_firmware(struct device_location
> > > > *location,
> > > > +				      struct firmware
> > > > *firmware_p)
> > > > +{
> > > > +	struct firmware_priv *fw_priv = NULL;
> > > > +	loff_t actread;
> > > > +	char *dev_part;
> > > > +	int ret;
> > > > +
> > > > +	dev_part = env_get("FW_DEV_PART");
> > > > +	if (dev_part)
> > > > +		set_storage_devpart(location->name, dev_part);
> > > > +
> > > > +	ret = init_storage_device(location);
> > > > +	if (ret)
> > > > +		goto out;
> > > > +
> > > > +	select_fs_dev(location);
> > > > +	if (ret)
> > > > +		goto out;
> > > > +
> > > > +	fw_priv = (struct firmware_priv *)firmware_p->priv;
> > > > +
> > > useless type cast.
> > > 
> > I assume you are saying autocast, right? Let me check is there any
> > warning from compiler after removing the cast.
> > 
> In C void pointers can be assigned to any type pointers without need
> for
> a cast.
> 
Oo....initially i worry the compiler would trigger warnings when the
fw_priv was pass as parameter to fs_read function without casting.
However, i have ran the check, and there is no warning from compiler
without casting. So, i will remove the cast.
> 
> Lothar Waßmann

      reply	other threads:[~2017-12-21  5:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18  5:10 [U-Boot] [PATCH v4 0/2] Generic firmware loader tien.fong.chee at intel.com
2017-12-18  5:10 ` [U-Boot] [PATCH v4 1/2] spl: Remove static declaration on spl_mmc_find_device function tien.fong.chee at intel.com
2017-12-18  5:10 ` [U-Boot] [PATCH v4 2/2] common: Generic firmware loader for file system tien.fong.chee at intel.com
2017-12-18  7:39   ` Lothar Waßmann
2017-12-19 10:31     ` Chee, Tien Fong
2017-12-19 11:15       ` Marek Vasut
2017-12-19 11:21       ` Lothar Waßmann
2017-12-21  5:39         ` 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=1513834776.4001.9.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 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.