From: "Vincent Stehlé" <vincent.stehle@arm.com>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>,
Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH] bootstd: cros: store partition type in an efi_guid_t
Date: Wed, 3 Jul 2024 11:09:19 +0200 [thread overview]
Message-ID: <ZoUVP_CQK_Or28bg@debian> (raw)
In-Reply-To: <13D2D563-69DD-4BD3-8A97-37B39A0B5D52@gmx.de>
On Thu, Jun 27, 2024 at 09:28:04PM +0200, Heinrich Schuchardt wrote:
>
Hi Heinrich,
Thanks for your review.
My comments below.
Best regards,
Vincent.
>
> Am 27. Juni 2024 19:06:29 MESZ schrieb "Vincent Stehlé" <vincent.stehle@arm.com>:
> >The scan_part() function uses a struct uuid to store the little-endian
> >partition type GUID, but this structure should be used only to contain a
> >big-endian UUID. Use an efi_guid_t instead.
> >
> >Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
> >Cc: Simon Glass <sjg@chromium.org>
> >Cc: Tom Rini <trini@konsulko.com>
> >---
> > boot/bootmeth_cros.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
> >index f015f2e1c75..1f83c14aeab 100644
> >--- a/boot/bootmeth_cros.c
> >+++ b/boot/bootmeth_cros.c
> >@@ -148,7 +148,7 @@ static int scan_part(struct udevice *blk, int partnum,
> > {
> > struct blk_desc *desc = dev_get_uclass_plat(blk);
> > struct vb2_keyblock *hdr;
> >- struct uuid type;
> >+ efi_guid_t type;
>
> Does Chrome OS only support GPT partitioning?
>
> > ulong num_blks;
> > int ret;
> >
> >@@ -161,7 +161,7 @@ static int scan_part(struct udevice *blk, int partnum,
> >
> > /* Check for kernel partition type */
> > log_debug("part %x: type=%s\n", partnum, info->type_guid);
> >- if (uuid_str_to_bin(info->type_guid, (u8 *)&type, UUID_STR_FORMAT_GUID))
> >+ if (uuid_str_to_bin(info->type_guid, type.b, UUID_STR_FORMAT_GUID))
> > return log_msg_ret("typ", -EINVAL);
>
> struct disk_partition containing a string which is only needed in the CLI instead of the 16 byte GUID was a bad idea to start with. Shouldn't we replace it or add least add a GUID field instead of first converting to string and than back to GUID?
I had a quick look and it seems that converting all those UUIDs from strings to
binary would indeed impact many places; let's separate this longer-term effort
from this change if you agree.
>
> >
> > if (memcmp(&cros_kern_type, &type, sizeof(type)))
>
> You could use the guidcmp() macro here.
Thanks for the tip; I will send a v2 series.
>
> Best regards
>
> Heinrich
>
next prev parent reply other threads:[~2024-07-03 9:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-27 17:06 [PATCH] bootstd: cros: store partition type in an efi_guid_t Vincent Stehlé
2024-06-27 19:05 ` Simon Glass
2024-06-27 19:28 ` Heinrich Schuchardt
2024-06-28 7:32 ` Simon Glass
2024-07-03 9:09 ` Vincent Stehlé [this message]
2024-07-03 11:37 ` [PATCH v2 0/2] Respin bootstd cros patch into a series of two Vincent Stehlé
2024-07-03 11:37 ` [PATCH v2 1/2] efi: move guid helper functions to efi.h Vincent Stehlé
2024-07-03 11:37 ` [PATCH v2 2/2] bootstd: cros: store partition type in an efi_guid_t Vincent Stehlé
2024-07-18 13:41 ` [PATCH v2 0/2] Respin bootstd cros patch into a series of two 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=ZoUVP_CQK_Or28bg@debian \
--to=vincent.stehle@arm.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--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.