From: Takahiro Akashi <takahiro.akashi@linaro.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Masahisa Kojima <masahisa.kojima@linaro.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Simon Glass <sjg@chromium.org>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
u-boot@lists.denx.de
Subject: Re: [RESEND v9 1/9] efi_loader: move udevice pointer into struct efi_object
Date: Wed, 20 Jul 2022 14:23:26 +0900 [thread overview]
Message-ID: <20220720052326.GD36287@laputa> (raw)
In-Reply-To: <ac270077-fb75-e623-8e27-37678eb44740@gmx.de>
On Sun, Jul 17, 2022 at 01:23:41PM +0200, Heinrich Schuchardt wrote:
> On 7/17/22 10:09, Heinrich Schuchardt wrote:
> > On 7/15/22 16:47, Masahisa Kojima wrote:
> > > This is a preparation patch to provide the unified method
> > > to access udevice pointer associated with the block io device.
> > > The EFI handles of both EFI block io driver implemented in
> > > lib/efi_loader/efi_disk.c and EFI block io driver implemented
> > > as EFI payload can posess the udevice pointer in the struct efi_object.
> > >
> > > We can use this udevice pointer to get the U-Boot friendly
> > > block device name(e.g. mmc 0:1, nvme 0:1) through efi_handle_t.
> > >
> > > Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
> > > ---
> > > Newly created in v9
> > >
> > > include/efi_loader.h | 8 ++++++++
> > > lib/efi_loader/efi_disk.c | 20 +++++++++++++-------
> > > 2 files changed, 21 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > index 3a63a1f75f..bba5ffd482 100644
> > > --- a/include/efi_loader.h
> > > +++ b/include/efi_loader.h
> > > @@ -226,6 +226,12 @@ const char *__efi_nesting_dec(void);
> > > #define EFI_CACHELINE_SIZE 128
> > > #endif
> > >
> > > +/**
> > > + * efi_handle_to_udev - accessor to the DM device associated to the
> > > EFI handle
> > > + * @handle: pointer to the EFI handle
> > > + */
> > > +#define efi_handle_to_udev(handle) (((struct efi_object *)handle)->dev)
> >
> > This conversion will hide errors if handle is not of type efi_handle_t.
> > We should avoid the conversion and see build time errors instead.
> > Please, remove the macro.
> >
> > For every handle of type efi_handle_t you can access the field
> > handle->dev directly.
> >
> > For struct efi_disk_obj we can use disk->header.dev.
> >
> > > +
> > > /* Key identifying current memory map */
> > > extern efi_uintn_t efi_memory_map_key;
> > >
> > > @@ -375,6 +381,7 @@ enum efi_object_type {
> > > * @protocols: linked list with the protocol interfaces installed
> > > on this
> > > * handle
> > > * @type: image type if the handle relates to an image
> > > + * @dev: pointer to the DM device which is associated with this
> > > EFI handle
> > > *
> > > * UEFI offers a flexible and expandable object model. The objects
> > > in the UEFI
> > > * API are devices, drivers, and loaded images. struct efi_object is
> > > our storage
> > > @@ -392,6 +399,7 @@ struct efi_object {
> > > /* The list of protocols */
> > > struct list_head protocols;
> > > enum efi_object_type type;
> > > + struct udevice *dev;
> > > };
> > >
> > > enum efi_image_auth_status {
> > > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > > index 1d700b2a6b..a8e8521e3e 100644
> > > --- a/lib/efi_loader/efi_disk.c
> > > +++ b/lib/efi_loader/efi_disk.c
> > > @@ -46,7 +46,6 @@ struct efi_disk_obj {
> > > struct efi_device_path *dp;
> > > unsigned int part;
> > > struct efi_simple_file_system_protocol *volume;
> > > - struct udevice *dev; /* TODO: move it to efi_object */
> >
> > ok
> >
> > > };
> > >
> > > /**
> > > @@ -124,16 +123,16 @@ static efi_status_t efi_disk_rw_blocks(struct
> > > efi_block_io *this,
> > > return EFI_BAD_BUFFER_SIZE;
> > >
> > > if (CONFIG_IS_ENABLED(PARTITIONS) &&
> > > - device_get_uclass_id(diskobj->dev) == UCLASS_PARTITION) {
> > > + device_get_uclass_id(efi_handle_to_udev(diskobj)) ==
> > > UCLASS_PARTITION) {
> >
> > device_get_uclass_id(diskobj->header.hdev)) == UCLASS_PARTITION) {
> >
> > > if (direction == EFI_DISK_READ)
> > > - n = dev_read(diskobj->dev, lba, blocks, buffer);
> > > + n = dev_read(efi_handle_to_udev(diskobj), lba, blocks,
> > > buffer);
> >
> > dev_read(diskobj->header.hdev)
> >
> > > else
> > > - n = dev_write(diskobj->dev, lba, blocks, buffer);
> > > + n = dev_write(efi_handle_to_udev(diskobj), lba, blocks,
> > > buffer);
> >
> > dev_write(diskobj->header.hdev)
> >
> > > } else {
> > > /* dev is a block device (UCLASS_BLK) */
> > > struct blk_desc *desc;
> > >
> > > - desc = dev_get_uclass_plat(diskobj->dev);
> > > + desc = dev_get_uclass_plat(efi_handle_to_udev(diskobj));
> >
> > dev_get_uclass(diskobj->header.hdev)
> >
> >
> > > if (direction == EFI_DISK_READ)
> > > n = blk_dread(desc, lba, blocks, buffer);
> > > else
> > > @@ -552,7 +551,7 @@ static int efi_disk_create_raw(struct udevice *dev)
> > >
> > > return -1;
> > > }
> > > - disk->dev = dev;
> > > + efi_handle_to_udev(disk) = dev;
> > > if (dev_tag_set_ptr(dev, DM_TAG_EFI, &disk->header)) {
> > > efi_free_pool(disk->dp);
> > > efi_delete_handle(&disk->header);
> > > @@ -609,7 +608,7 @@ static int efi_disk_create_part(struct udevice *dev)
> > > log_err("Adding partition for %s failed\n", dev->name);
> > > return -1;
> > > }
> > > - disk->dev = dev;
> > > + efi_handle_to_udev(disk) = dev;
> >
> > disk->header.dev = dev;
> >
> > > if (dev_tag_set_ptr(dev, DM_TAG_EFI, &disk->header)) {
> > > efi_free_pool(disk->dp);
> > > efi_delete_handle(&disk->header);
> > > @@ -656,6 +655,13 @@ static int efi_disk_probe(void *ctx, struct event
> > > *event)
> > > ret = efi_disk_create_raw(dev);
> > > if (ret)
> > > return -1;
> > > + } else {
> > > + efi_handle_t handle;
> > > +
> > > + if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **)&handle))
>
> Setting handle->dev can be done more easily in efi_bl_bind():
I don't think so.
"dev" field should be maintained in *one* place, i.e. efi_disk_probe(),
which is uniquely called from probe event (even for efi_block_dev case).
To make this clear, we'd better put the code in efi_disk_create_raw():
efi_disk_create_raw()
if (desc->if_type == IF_TYPE_EFI_LOADER) {
/* handle should exist now */
dev_tag_get_ptr(dev, DM_TAG_EFI, (void **)&handle));
efi_set_udev(handle, dev);
return 0;
}
/* normal block devices */
...
efi_set_udev(&disk->header, dev);
...
-Takahiro Akashi
> handle->dev = bdev;
>
> We can further remove the field handle from struct blk_create_device as
> it is now available in handle->dev.
>
> Best regards
>
> Heinrich
>
> > > + return -1;
> > > +
> > > + efi_handle_to_udev(handle) = dev;
> >
> > handle->dev = dev;
> >
> > Best regards
> >
> > Heinrich
> >
> > > }
> > >
> > > device_foreach_child(child, dev) {
> >
>
next prev parent reply other threads:[~2022-07-20 5:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 14:47 [RESEND v9 0/9] enable menu-driven UEFI variable maintenance Masahisa Kojima
2022-07-15 14:47 ` [RESEND v9 1/9] efi_loader: move udevice pointer into struct efi_object Masahisa Kojima
2022-07-17 8:09 ` Heinrich Schuchardt
2022-07-17 11:23 ` Heinrich Schuchardt
2022-07-20 5:23 ` Takahiro Akashi [this message]
2022-07-20 7:37 ` Heinrich Schuchardt
2022-07-22 2:00 ` Masahisa Kojima
2022-07-19 23:56 ` Takahiro Akashi
2022-07-20 7:44 ` Heinrich Schuchardt
2022-07-22 2:42 ` Takahiro Akashi
2022-07-15 14:47 ` [RESEND v9 2/9] eficonfig: menu-driven addition of UEFI boot option Masahisa Kojima
2022-07-18 13:31 ` Ilias Apalodimas
2022-07-18 23:06 ` Masahisa Kojima
2022-07-19 7:33 ` Ilias Apalodimas
2022-07-19 10:11 ` Ilias Apalodimas
2022-07-22 2:01 ` Masahisa Kojima
2022-07-15 14:47 ` [RESEND v9 3/9] eficonfig: add "Edit Boot Option" menu entry Masahisa Kojima
2022-07-15 14:47 ` [RESEND v9 4/9] menu: add KEY_PLUS and KEY_MINUS handling Masahisa Kojima
2022-07-18 12:39 ` Ilias Apalodimas
2022-07-15 14:47 ` [RESEND v9 5/9] eficonfig: add "Change Boot Order" menu entry Masahisa Kojima
2022-07-19 13:09 ` Ilias Apalodimas
2022-07-15 14:47 ` [RESEND v9 6/9] eficonfig: add "Delete Boot Option" " Masahisa Kojima
2022-07-15 14:47 ` [RESEND v9 7/9] bootmenu: add removable media entries Masahisa Kojima
2022-07-20 14:07 ` Ilias Apalodimas
2022-07-15 14:47 ` [RESEND v9 8/9] doc:bootmenu: add description for UEFI boot support Masahisa Kojima
2022-07-18 13:05 ` Ilias Apalodimas
2022-07-15 14:47 ` [RESEND v9 9/9] doc:eficonfig: add documentation for eficonfig command Masahisa Kojima
2022-07-19 8:03 ` Ilias Apalodimas
2022-07-19 10:15 ` Masahisa Kojima
2022-07-19 12:52 ` Ilias Apalodimas
2022-07-22 2:03 ` Masahisa Kojima
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=20220720052326.GD36287@laputa \
--to=takahiro.akashi@linaro.org \
--cc=ilias.apalodimas@linaro.org \
--cc=mark.kettenis@xs4all.nl \
--cc=masahisa.kojima@linaro.org \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.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