[RFC PATCH] disk: Don't loop over MAX_SEARCH_PARTITIONS in part_create_block_devices()

[AKASHI Takahiro]

Hi,

Thank you for catching this issue.

On Tue, Jan 10, 2023 at 09:00:38AM +0100, Stefan Roese wrote:
> I've noticed that the first ext4 file loading from a MMC partition for
> ZynqMP takes quite some time (~ 1 second). Debugging showed, that the
> MMC driver reads the partition info 128 time (MAX_SEARCH_PARTITIONS)
> resulting in this boot delay. To fix this, let's just end creating the
> block drives in part_create_block_devices() when no more valid partition
> is found. This reduces the first file reading from ~0.9s to ~0.3s.
> 
> Signed-off-by: Stefan Roese <sr at denx.de>
> Cc: Simon Glass <sjg at chromium.org>
> Cc: AKASHI Takahiro <takahiro.akashi at linaro.org>
> Cc: Heinrich Schuchardt <xypron.glpk at gmx.de>
> ---
> Reasoning for RFC:
> I did not dig into the current disk / partition stuff too deeply, so I'm
> not 100% sure that this patch does not break anything.

I'm afraid that this fix won't work for all the partition types,
especially for those in which entries in a partition table can be sparsely filled,
or in other words, valid partition numbers may not always be contiguous
even if they don't reach a maximum number.

I somehow confirmed this against a GPT partition by using gdisk.

-Takahiro Akashi

> ---
>  disk/disk-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/disk/disk-uclass.c b/disk/disk-uclass.c
> index d32747e2242d..2999f7285b5a 100644
> --- a/disk/disk-uclass.c
> +++ b/disk/disk-uclass.c
> @@ -36,7 +36,7 @@ int part_create_block_devices(struct udevice *blk_dev)
>  	/* Add devices for each partition */
>  	for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
>  		if (part_get_info(desc, part, &info))
> -			continue;
> +			break;
>  		snprintf(devname, sizeof(devname), "%s:%d", blk_dev->name,
>  			 part);
>  
> -- 
> 2.39.0
>