public inbox for u-boot@lists.denx.de
 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 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

  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