[PATCH v3 0/3] Restore support of short name for type UUID parameter

[Patrick DELAUNAY]

Hi,

On 6/12/25 19:58, Tom Rini wrote:
> On Mon, Jun 02, 2025 at 03:59:31PM +0200, Patrick Delaunay wrote:
>
>> V3 version solve issue for "ESP" support when
>> CONFIG_CMD_EFIDEBUG and CONFIG_EFI is not activated
>> for example for test with qemu-arm-sbsa defconfig
>>
>> Fix and add documentation/tests for selection by string for known
>> partition type GUID introduced by bcb41dcaefac ("uuid: add
>> selection by string for known partition type GUID"):
>>
>> - split list_guid for short name (used also for partiton
>>    description with type parameter) and full name to display
>>    information
>>
>> - as the function are uuid_str_to_bin() / uuid_guid_get_str()
>>    are no more under CONFIG_PARTITION_TYPE_GUID,  since commit
>>    31ce367cd100 ("lib/uuid.c: change prototype of uuid_guid_get_str()")
>>    and commit c1528f324c60 ("lib: compile uuid_guid_get_str if
>>    CONFIG_LIB_UUID=y") move the content of array under EFI_PARTITION
>>    and linker will remove it is not used it (in SPL)
>>
>> - Add and fix documentation for gpt command
>>
>> - Add test test_gpt_write_part_type to test "type=" parameters
>>
>> This first patch solves an issue for the "system" shortcut for ESP,
>> removed by commit d54e1004b8b1 ("lib/uuid.c: use unique name
>> for PARTITION_SYSTEM_GUID") but used in 2 location (at least):
>>
>> 1- board/samsung/e850-96/e850-96.env:10:
>>
>> partitions=name=esp,start=512K,size=128M,bootable,type=system;
>> partitions+=name=rootfs,size=-,bootable,type=linux
>>
>> 2- arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c:1151
>>
>> 			case PART_ESP:
>> 				/* EFI System Partition */
>> 				type_str = "system"
>> ....
>> 			offset += snprintf(buf + offset,
>> 					   buflen - offset,
>> 					   ",type=%s", type_str);
>>
>>
>> Changes in v3:
>> - The definition for ESP = "system" partition in list_guid[]
>>    is no more under CONFIG_CMD_EFIDEBUG or CONFIG_EFI flags,
>>    and restore the initial level (always support for display)
>>    as it is done for MBR partition or when U-Boot is a UEFI
>>    loader (CONFIG_CMD_BOOTEFI).
> This still has CI failures:
> https://source.denx.de/u-boot/u-boot/-/jobs/1168239

Sorry for the remaining side effect.

After my last "24 HOURS OF LE MANS" week, I pushed a V4 series with 
correction in tests.

https://patchwork.ozlabs.org/project/uboot/list/?series=461114

To be sure, I also check the CI result, and now it is OK

https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/26699


Thanks,