From: Chee, Tien Fong <tien.fong.chee@intel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
Date: Tue, 17 Jul 2018 04:46:36 +0000 [thread overview]
Message-ID: <1531802795.9620.9.camel@intel.com> (raw)
In-Reply-To: <CAPnjgZ3DBBPV9BRA5kJgR_MaHAfX+yVcm76FeXAjSBHNVR03wQ@mail.gmail.com>
On Sun, 2018-07-15 at 15:21 -0600, Simon Glass wrote:
> Hi Tien Fong,
>
> On 12 July 2018 at 01:19, Chee, Tien Fong <tien.fong.chee@intel.com>
> wrote:
> >
> > On Wed, 2018-07-11 at 14:13 -0600, Simon Glass wrote:
> > >
> > > Hi Tien,
> > >
> > > On 6 July 2018 at 02:28, <tien.fong.chee@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>
> > > > ---
> > > > drivers/misc/Kconfig | 10 ++
> > > > drivers/misc/Makefile | 1 +
> > > > drivers/misc/fs_loader.c | 295
> > > > +++++++++++++++++++++++++++++++++++++++++++++++
> > > > include/dm/uclass-id.h | 1 +
> > > > include/fs_loader.h | 79 +++++++++++++
> > > > 5 files changed, 386 insertions(+)
> > > > create mode 100644 drivers/misc/fs_loader.c
> > > > create mode 100644 include/fs_loader.h
> > > >
> [..]
>
> >
> > >
> > >
> > > >
> > > >
> > > > + (*firmwarep)->priv = calloc(1, sizeof(struct
> > > > firmware_priv));
> > > > + if (!(*firmwarep)->priv) {
> > > > + free(*firmwarep);
> > > > + return -ENOMEM;
> > > > + }
> > > > + }
> > > > +
> > > > + ((struct firmware_priv *)((*firmwarep)->priv))->name =
> > > > name;
> > > Again this needs a local variable.
> > Why?
> Because these casts are really ugly and repetitive, particularly when
> used for assignments :-)
Okay.
>
> [..]
>
> >
> > >
> > > >
> > > > + * release_firmware - Release the resource associated with a
> > > > firmware image
> > > > + * @firmware: Firmware resource to release
> > > > + */
> > > > +void release_firmware(struct firmware *firmware);
> > > > +
> > > > +/**
> > > > + * request_firmware_into_buf - Load firmware into a previously
> > > > allocated buffer.
> > > > + * @plat: Platform data such as storage and partition firmware
> > > > loading from.
> > > > + * @name: Name of firmware file.
> > > > + * @buf: Address of buffer to load firmware into.
> > > > + * @size: Size of buffer.
> > > > + * @offset: Offset of a file for start reading into buffer.
> > > > + * @firmwarep: Pointer to firmware image.
> > > > + *
> > > > + * The firmware is loaded directly into the buffer pointed to
> > > > by
> > > > @buf and
> > > > + * the @firmwarep data member is pointed at @buf.
> > > > + *
> > > > + * Return: Size of total read, negative value when error.
> > > > + */
> > > > +int request_firmware_into_buf(struct device_platdata *plat,
> > > > + const char *name,
> > > > + void *buf, size_t size, u32
> > > > offset,
> > > > + struct firmware **firmwarep);
> > > Without a test it's hard to see how this is used, but I'm not
> > > keen on
> > > the struct firmware ** here.
> > >
> > > Can you just use struct firmware * instead?
> > >
> > > Or maybe just return the fields individually since you only have
> > > start
> > > address and size, I think.
> > I can try to remove struct firmware, let driver model handles all
> > memory allocation, and then struct device_platdata *plat will
> > change
> > to struct udevice *dev. So, it would become like this
> > int request_firmware_into_buf(struct udevice *dev,
> > const char *name,
> > void *buf, size_t size, u32 offset);
> > I will remove release_firmware() after letting driver model to
> > handle
> > all memory deallocation.
> > So, the API interface would looks a bit different compare to Linux
> > firmware API interface. Does this change OK for you?
> I believe you would need:
>
> >
> > int request_firmware_into_buf(struct udevice *dev,
> > const char *name,
> > void **bufp, size_t *sizep, u32
> > offset);
> since you need to return the buffer and size?
Why need to return the buffer and size? There is no modification
required on noth buffer and size arguments by
request_firmware_into_buf().
Both buffer and size are allocated and defined by user, then
request_firmware_into_buf() would load the file into buffer based on
the size exactly defined by user.
>
> What exactly is 'dev'? Is it the device in the FS_LOADER uclass?
Yes, contains FDT HW data.
>
> Regards,
> Simon
next prev parent reply other threads:[~2018-07-17 4:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-06 8:28 [U-Boot] [PATCH v4 6/6] common: Generic loader for file system tien.fong.chee at intel.com
2018-07-11 14:02 ` Simon Glass
2018-07-11 14:20 ` Chee, Tien Fong
2018-07-11 20:13 ` Simon Glass
2018-07-12 7:19 ` Chee, Tien Fong
2018-07-15 21:21 ` Simon Glass
2018-07-17 4:46 ` Chee, Tien Fong [this message]
2018-07-18 14:48 ` Michal Simek
2018-07-25 6:31 ` Chee, Tien Fong
2018-07-25 9:48 ` Michal Simek
2018-07-25 15:47 ` Simon Glass
2018-07-25 16:03 ` Tom Rini
2018-07-26 9:03 ` Michal Simek
2018-07-27 8:40 ` Chee, Tien Fong
2018-07-30 7:07 ` Michal Simek
2018-07-30 13:26 ` Simon Glass
2018-07-30 13:30 ` Michal Simek
2018-07-30 16:05 ` Simon Glass
2018-07-31 5:12 ` Chee, Tien Fong
2018-07-31 6:22 ` Michal Simek
2018-09-21 4:42 ` Chee, Tien Fong
2018-09-25 7:02 ` Chee, Tien Fong
2018-09-25 19:37 ` Tom Rini
2018-09-27 8:08 ` Chee, Tien Fong
2018-09-25 19:39 ` Simon Glass
2018-07-26 9:23 ` Chee, Tien Fong
2018-07-26 10:29 ` Michal Simek
2018-07-27 8:18 ` Chee, Tien Fong
2018-09-29 15:43 ` [U-Boot] [U-Boot, v4, " Tom Rini
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=1531802795.9620.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.