All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v6 3/7] cmd: efidebug: add devices command
Date: Wed, 20 Feb 2019 11:20:51 +0900	[thread overview]
Message-ID: <20190220022049.GF20286@linaro.org> (raw)
In-Reply-To: <c86048ed-cd38-c507-b717-2befdbd55766@gmx.de>

On Tue, Feb 19, 2019 at 08:46:52PM +0100, Heinrich Schuchardt wrote:
> On 1/24/19 12:04 PM, AKASHI Takahiro wrote:
> > "devices" command prints all the uefi variables on the system.
> > 
> > => efi devices
> > Scanning disk ahci_scsi.id0lun0...
> > Scanning disk ahci_scsi.id1lun0...
> > Found 4 disks
> > Device           Device Path
> > ================ ====================
> > 000000007ef07ea0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > 000000007ef00c10 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)
> > 000000007ef00dd0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)
> > 000000007ef07be0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,MBR,0x086246ba,0x800,0x40000)
> > 000000007ef07510 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > 
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
> >  cmd/efidebug.c | 102 ++++++++++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 101 insertions(+), 1 deletion(-)
> > 
> > diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> > index d836576cf6e0..8a7f775b117a 100644
> > --- a/cmd/efidebug.c
> > +++ b/cmd/efidebug.c
> > @@ -15,6 +15,102 @@
> >  #include <search.h>
> >  #include <linux/ctype.h>
> >  
> > +#define BS systab.boottime
> > +
> 
> Please, add Sphinx style descriptions to all functions, their
> parameters, and return values.

Sure, but please clearify what you mean by "all."
Do you expect descriptions for exactly all the functions,
even for some helper functions of a few lines of code?

> Why do you need this function? Can't you call LocateHandleBuffer() which
> takes care of the allocation of the buffer?
> 
> > +static int efi_get_handles_by_proto(efi_guid_t *guid, efi_handle_t **handlesp,
> > +				    int *num)

Right. I will use locate_handle_buffer here.
But why does UEFI spec define functionally-duplicated functions,
LocateHandle() and LocateHandleBuffer()?

> > +{
> > +	efi_handle_t *handles = NULL;
> > +	efi_uintn_t size = 0;
> > +	efi_status_t ret;
> > +
> > +	if (guid) {
> > +		ret = BS->locate_handle(BY_PROTOCOL, guid, NULL, &size,
> > +					handles);
> 
> This will not work on i386. Please, always use EFI_CALL when invoking a
> function which calls EFI_ENTRY().

OK, but let me make sure.
We don't have to use EFI_CALL() for any of (internal) efi_xxx() functions,
say, efi_add_protocol(). Right?

> > +		if (ret == EFI_BUFFER_TOO_SMALL) {
> > +			handles = calloc(1, size);
> > +			if (!handles)
> > +				return -1;
> > +
> > +			ret = BS->locate_handle(BY_PROTOCOL, guid, NULL, &size,
> > +						handles);
> > +		}
> > +		if (ret != EFI_SUCCESS) {
> > +			free(handles);
> 
> The handles are not allocated by malloc(). Use FreePool() here.

Will take care of that along with the change above.

-Takahiro Akashi


> > +			return -1;
> > +		}
> > +	} else {
> > +		ret = BS->locate_handle(ALL_HANDLES, NULL, NULL, &size, NULL);
> > +		if (ret == EFI_BUFFER_TOO_SMALL) {
> > +			handles = calloc(1, size);
> > +			if (!handles)
> > +				return -1;
> > +
> > +			ret = BS->locate_handle(ALL_HANDLES, NULL, NULL, &size,
> > +						handles);
> > +		}
> > +		if (ret != EFI_SUCCESS) {
> > +			free(handles);
> 
> Same here.
> 
> > +			return -1;
> > +		}
> > +	}
> > +
> > +	*handlesp = handles;
> > +	*num = size / sizeof(efi_handle_t);
> > +
> > +	return 0;
> > +}
> > +
> > +static int efi_get_device_handle_info(efi_handle_t handle, u16 **dev_path_text)
> > +{
> > +	struct efi_device_path *dp;
> > +	efi_status_t ret;
> > +
> > +	ret = BS->open_protocol(handle, &efi_guid_device_path,
> > +				(void **)&dp, NULL /* FIXME */, NULL,
> > +				EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> > +	if (ret == EFI_SUCCESS) {
> > +		*dev_path_text = efi_dp_str(dp);
> > +		return 0;
> > +	} else {
> > +		return -1;
> > +	}
> > +}
> > +
> > +#define EFI_HANDLE_WIDTH ((int)sizeof(efi_handle_t) * 2)
> > +
> > +static const char spc[] = "                ";
> > +static const char sep[] = "================";
> > +
> > +static int do_efi_show_devices(cmd_tbl_t *cmdtp, int flag,
> > +			       int argc, char * const argv[])
> > +{
> > +	efi_handle_t *handles;
> > +	u16 *dev_path_text;
> > +	int num, i;
> > +
> > +	handles = NULL;
> > +	num = 0;
> > +	if (efi_get_handles_by_proto(NULL, &handles, &num))
> > +		return CMD_RET_FAILURE;
> > +
> > +	if (!num)
> > +		return CMD_RET_SUCCESS;
> > +
> > +	printf("Device%.*s Device Path\n", EFI_HANDLE_WIDTH - 6, spc);
> > +	printf("%.*s ====================\n", EFI_HANDLE_WIDTH, sep);
> > +	for (i = 0; i < num; i++) {
> > +		if (!efi_get_device_handle_info(handles[i], &dev_path_text)) {
> > +			printf("%p %ls\n", handles[i], dev_path_text);
> > +			efi_free_pool(dev_path_text);
> > +		}
> > +	}
> > +
> > +	free(handles);
> 
> FreePool()!
> 
> Best regards
> 
> Heinrich
> 
> > +
> > +	return CMD_RET_SUCCESS;
> > +}
> > +
> >  static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
> >  			   int argc, char * const argv[])
> >  {
> > @@ -406,6 +502,8 @@ static int do_efi_boot_opt(cmd_tbl_t *cmdtp, int flag,
> >  
> >  static cmd_tbl_t cmd_efidebug_sub[] = {
> >  	U_BOOT_CMD_MKENT(boot, CONFIG_SYS_MAXARGS, 1, do_efi_boot_opt, "", ""),
> > +	U_BOOT_CMD_MKENT(devices, CONFIG_SYS_MAXARGS, 1, do_efi_show_devices,
> > +			 "", ""),
> >  };
> >  
> >  /* Interpreter command to configure UEFI environment */
> > @@ -451,7 +549,9 @@ static char efidebug_help_text[] =
> >  	"  - set UEFI BootNext variable\n"
> >  	"efidebug boot order [<bootid#1> [<bootid#2> [<bootid#3> [...]]]]\n"
> >  	"  - set/show UEFI boot order\n"
> > -	"\n";
> > +	"\n"
> > +	"efidebug devices\n"
> > +	"  - show uefi devices\n";
> >  #endif
> >  
> >  U_BOOT_CMD(
> > 
> 

  parent reply	other threads:[~2019-02-20  2:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 11:04 [U-Boot] [PATCH v6 0/7] cmd: add efidebug for efi environment AKASHI Takahiro
2019-01-24 11:04 ` [U-Boot] [PATCH v6 1/7] cmd: env: add "-e" option for handling UEFI variables AKASHI Takahiro
2019-01-25 12:42   ` Alexander Graf
2019-01-29  3:22     ` AKASHI Takahiro
2019-01-24 11:04 ` [U-Boot] [PATCH v6 2/7] cmd: add efidebug command AKASHI Takahiro
2019-02-19 19:32   ` Heinrich Schuchardt
2019-02-20  4:58     ` AKASHI Takahiro
2019-02-20  6:40       ` Heinrich Schuchardt
2019-01-24 11:04 ` [U-Boot] [PATCH v6 3/7] cmd: efidebug: add devices command AKASHI Takahiro
2019-02-19 19:46   ` Heinrich Schuchardt
2019-02-19 19:53     ` Heinrich Schuchardt
2019-02-20  2:20     ` AKASHI Takahiro [this message]
2019-02-20  6:49       ` Heinrich Schuchardt
2019-02-20  7:42         ` AKASHI Takahiro
2019-01-24 11:04 ` [U-Boot] [PATCH v6 4/7] cmd: efidebug: add drivers command AKASHI Takahiro
2019-02-19 19:49   ` Heinrich Schuchardt
2019-02-20  2:22     ` AKASHI Takahiro
2019-01-24 11:04 ` [U-Boot] [PATCH v6 5/7] cmd: efidebug: add dh command AKASHI Takahiro
2019-01-24 11:04 ` [U-Boot] [PATCH v6 6/7] cmd: efidebug: add images command AKASHI Takahiro
2019-01-29 15:35   ` Alexander Graf
2019-01-30  0:00     ` AKASHI Takahiro
2019-02-19 19:51   ` Heinrich Schuchardt
2019-01-24 11:04 ` [U-Boot] [PATCH v6 7/7] cmd: efidebug: add memmap command AKASHI Takahiro
2019-02-19 19:11   ` Heinrich Schuchardt
2019-02-20  0:53     ` AKASHI Takahiro
2019-02-20  6:53       ` Heinrich Schuchardt
2019-02-20  7:45         ` AKASHI Takahiro
2019-01-25 11:56 ` [U-Boot] [PATCH v6 0/7] cmd: add efidebug for efi environment Alexander Graf
2019-01-29  3:07   ` 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=20190220022049.GF20286@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 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.