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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox