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: Fri, 22 Jul 2022 11:42:10 +0900 [thread overview]
Message-ID: <20220722024210.GA15175@laputa> (raw)
In-Reply-To: <0203ed6c-0fd6-5d9f-6d0b-43966d7f5b4f@gmx.de>
On Wed, Jul 20, 2022 at 09:44:43AM +0200, Heinrich Schuchardt wrote:
> On 7/20/22 01:56, Takahiro Akashi wrote:
> > On Sun, Jul 17, 2022 at 10:09:42AM +0200, 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.
> >
> > I don't think we should remove the macro itself, but only the type casting.
> >
> > I think it is a good practice to hide an implementation how the relationship
> > between udev and efi_object is maintained *behind* accessor macros.
> >
> > > 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.
> >
> > This is a good example for hiding the implementation from the rest of code.
>
> Such a macro is pure code obfuscation.
I don't think so. It will help make it easier to read the code.
If I follow your logic, why did you introduce/accept guidcpy/guidcmp()?
-Takahiro Akashi
> I won't take such a patch.
>
> Best regards
>
> Heinrich
>
> >
> > > > +
> > > > /* 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;
> >
> > It's my preference, but I would suggest another accessor:
> > efi_set_udev(handle, dev);
> > to hide an implementation.
> >
> > -Takahiro Akashi
> >
> > >
> > > > 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))
> > > > + 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-22 2:42 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
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 [this message]
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=20220722024210.GA15175@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 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.