From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/3] efi_loader: remove block device details from efi file
Date: Thu, 10 Jan 2019 09:37:46 +0900 [thread overview]
Message-ID: <20190110003745.GA20286@linaro.org> (raw)
In-Reply-To: <b427ca92-9371-2a50-b63d-10e7356d546e@suse.de>
Alex,
On Wed, Jan 09, 2019 at 10:18:16AM +0100, Alexander Graf wrote:
>
>
> On 15.11.18 05:58, AKASHI Takahiro wrote:
> > Logically, details on u-boot block device used to implement efi file
> > protocol are mostly unnecessary, as well as being duplicated, in
> > efi_file structure.
> > Moreover, a newly introduced flag, _EFI_DISK_FLAG_INVALID, should be
> > honored in any file operations via efi file protocol.
> > These observation suggests that those internal details be set behind
> > efi_disk object.
> >
> > So rework in this patch addresses all those issues above although
> > there is little change in its functionality.
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
> > include/efi_loader.h | 6 +++++-
> > lib/efi_loader/efi_disk.c | 38 ++++++++++++++++++++++++++++++++++++--
> > lib/efi_loader/efi_file.c | 21 ++++++++-------------
> > 3 files changed, 49 insertions(+), 16 deletions(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 3bae1844befb..108ef3fe52ee 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -264,6 +264,10 @@ efi_status_t efi_disk_register(void);
> > bool efi_disk_is_valid(efi_handle_t handle);
> > /* Called by bootefi to find and update disk storage information */
> > efi_status_t efi_disk_update(void);
> > +/* Called by file protocol to set internal block io device */
> > +int efi_disk_set_blk_dev(efi_handle_t disk);
> > +/* Called by file protocol to get disk/partition information */
> > +int efi_disk_get_info(efi_handle_t disk, disk_partition_t *part);
> > /* Create handles and protocols for the partitions of a block device */
> > int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
> > const char *if_typename, int diskid,
> > @@ -355,7 +359,7 @@ void efi_signal_event(struct efi_event *event, bool check_tpl);
> >
> > /* open file system: */
> > struct efi_simple_file_system_protocol *efi_simple_file_system(
> > - struct blk_desc *desc, int part, struct efi_device_path *dp);
> > + efi_handle_t disk);
> >
> > /* open file from device-path: */
> > struct efi_file_handle *efi_file_from_path(struct efi_device_path *fp);
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index 0c4d79ee3fc9..180e8e10bb28 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -9,6 +9,7 @@
> > #include <blk.h>
> > #include <dm.h>
> > #include <efi_loader.h>
> > +#include <fs.h>
> > #include <part.h>
> > #include <malloc.h>
> >
> > @@ -254,6 +255,40 @@ efi_fs_from_path(struct efi_device_path *full_path)
> > return handler->protocol_interface;
> > }
> >
> > +/*
> > + * Set block device for later block io's from file system protocol
> > + *
> > + * @disk handle to uefi disk device
> > + * @return 0 for success, -1 for failure
> > + */
> > +int efi_disk_set_blk_dev(efi_handle_t disk)
> > +{
> > + struct efi_disk_obj *diskobj;
> > +
> > + diskobj = container_of(disk, struct efi_disk_obj, header);
> > +
> > + return fs_set_blk_dev_with_part(diskobj->desc, diskobj->part);
> > +}
> > +
> > +/*
> > + * Get disk/partition information
> > + *
> > + * @disk handle to uefi disk device
> > + * @part pointer to disk/partition information to be returned
> > + * @return 0 for success, -1 for failure
> > + */
> > +int efi_disk_get_info(efi_handle_t disk, disk_partition_t *part)
> > +{
> > + struct efi_disk_obj *diskobj;
> > +
> > + diskobj = container_of(disk, struct efi_disk_obj, header);
> > +
> > + if (diskobj->part >= 1)
> > + return part_get_info(diskobj->desc, diskobj->part, part);
> > + else
> > + return part_get_info_whole_disk(diskobj->desc, part);
> > +}
> > +
> > /*
> > * Create a handle for a partition or disk
> > *
> > @@ -308,8 +343,7 @@ static efi_status_t efi_disk_add_dev(
> > if (ret != EFI_SUCCESS)
> > return ret;
> > if (part >= 1) {
> > - diskobj->volume = efi_simple_file_system(desc, part,
> > - diskobj->dp);
> > + diskobj->volume = efi_simple_file_system(&diskobj->header);
> > ret = efi_add_protocol(&diskobj->header,
> > &efi_simple_file_system_protocol_guid,
> > diskobj->volume);
> > diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
> > index beb4fba917d8..944383224f30 100644
> > --- a/lib/efi_loader/efi_file.c
> > +++ b/lib/efi_loader/efi_file.c
> > @@ -17,9 +17,7 @@ const efi_guid_t efi_file_system_info_guid = EFI_FILE_SYSTEM_INFO_GUID;
> >
> > struct file_system {
> > struct efi_simple_file_system_protocol base;
> > - struct efi_device_path *dp;
> > - struct blk_desc *desc;
> > - int part;
> > + efi_handle_t disk;
>
> Is there a particular reason we can't just make this a struct
> efi_disk_obj *?
Just because efi_disk_obj is an internally-defined structure in efi_disk.c.
> Inside our own code base, we don't need to abstract things away to
> handles, right? We also want to have the compiler catch the fact early
> if people pass in non-disk-objects in as parameter.
If you don't mind efi_disk_obj definition being moved to, say, efi_loader.h,
I would follow your suggestion.
Thanks,
-Takahiro Akashi
>
> Alex
next prev parent reply other threads:[~2019-01-10 0:37 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 4:58 [U-Boot] [PATCH v2 0/3] efi_loader: add removable device support AKASHI Takahiro
2018-11-15 4:58 ` [U-Boot] [PATCH v2 1/3] efi_loader: export efi_locate_handle() function AKASHI Takahiro
2018-11-15 4:58 ` [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time AKASHI Takahiro
2018-12-11 19:55 ` Heinrich Schuchardt
2018-12-13 7:58 ` AKASHI Takahiro
2019-01-09 1:05 ` AKASHI Takahiro
2019-01-09 9:06 ` Alexander Graf
2019-01-10 2:13 ` AKASHI Takahiro
2019-01-10 6:21 ` Alexander Graf
2019-01-10 7:26 ` AKASHI Takahiro
2019-01-10 7:30 ` Alexander Graf
2019-01-10 8:02 ` AKASHI Takahiro
2019-01-10 8:15 ` Alexander Graf
2019-01-10 9:16 ` AKASHI Takahiro
2019-01-10 9:22 ` Alexander Graf
2019-01-10 19:22 ` Heinrich Schuchardt
2019-01-11 5:08 ` AKASHI Takahiro
2019-01-11 4:29 ` AKASHI Takahiro
2019-01-11 7:57 ` Alexander Graf
2019-01-12 21:32 ` Simon Glass
2019-01-12 22:00 ` Alexander Graf
2019-01-16 21:34 ` Simon Glass
2019-01-22 8:29 ` AKASHI Takahiro
2019-01-22 9:08 ` Alexander Graf
2019-01-22 19:39 ` Simon Glass
2019-01-22 21:04 ` Heinrich Schuchardt
2019-01-23 8:06 ` AKASHI Takahiro
2019-01-23 21:58 ` Simon Glass
2019-01-24 0:53 ` AKASHI Takahiro
2019-01-24 20:18 ` Simon Glass
2019-01-24 21:19 ` Heinrich Schuchardt
2019-01-25 2:27 ` AKASHI Takahiro
2019-01-23 9:51 ` Alexander Graf
2019-01-23 22:01 ` Simon Glass
2019-01-25 8:27 ` AKASHI Takahiro
2019-01-25 8:52 ` Alexander Graf
2019-01-25 9:18 ` AKASHI Takahiro
2019-01-25 9:31 ` Alexander Graf
2019-01-28 8:56 ` AKASHI Takahiro
2019-01-28 9:36 ` Alexander Graf
2019-01-29 0:46 ` Simon Glass
2019-01-29 1:22 ` AKASHI Takahiro
2019-01-23 8:12 ` AKASHI Takahiro
2019-01-23 9:30 ` Alexander Graf
2019-01-10 12:57 ` Simon Glass
2019-01-11 4:51 ` AKASHI Takahiro
2019-01-11 8:00 ` Alexander Graf
2019-01-11 13:03 ` Mark Kettenis
2018-11-15 4:58 ` [U-Boot] [PATCH v2 3/3] efi_loader: remove block device details from efi file AKASHI Takahiro
2019-01-09 9:18 ` Alexander Graf
2019-01-10 0:37 ` AKASHI Takahiro [this message]
2019-01-10 6:22 ` Alexander Graf
2019-01-10 6:36 ` AKASHI Takahiro
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=20190110003745.GA20286@linaro.org \
--to=takahiro.akashi@linaro.org \
--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