[PATCH v2 2/2] cmd/part.c: implement "part name" subcommand

[Quentin Schulz]

Hi Rasmus,

On 11/3/25 9:38 PM, Rasmus Villemoes wrote:
> On Mon, Nov 03 2025, Quentin Schulz <quentin.schulz at cherry.de> wrote:
> 
>> Hi Rasmus,
>>
>> On 10/20/25 2:11 PM, Rasmus Villemoes wrote:
>>> This is a natural buddy to the existing "part number", allowing one to
>>> get the partition name for a given partition number.
>>>
>>
>> Acked-by: Quentin Schuloz <quentin.schulz at cherry.de>
>>
Can't even type my own (short) name without typo :(

>>
>> Reading the code, it seems the part command tries to auto-detect the
>> base of the part number as passed by the user, which isn't that usual
>> I believe in U-Boot (usually either forced hex or dec?), so maybe it's
>> worth mentioning in the docs.
> 
> Fun story: I started doing this because I have a legacy stand-alone app
> which is involved in the bootflow, and it communicates the partition to
> load the kernel from by setting an env variable via
> 
>    sprintf(buf, "%d", kernel_part);
>    env_set("kernel_part", buf);
> 
> and on the U-Boot side, that $kernel_part is/was used with various "read
> mmc ..." or "mmc read ..." commands. Guess how well that works when
> kernel_part ends up being >= 10 and the U-Boot commands unconditionally
> interprets the partition argument as hex...
> 
> So what I wanted to do on the U-Boot side is to translate that
> $kernel_part into a name ASAP and then use that name exclusively, and
> for that the sane semantics of the "part" command came in handy. Except
> it lacked the ability to do the translation.
> 
> As for the "[not] that usual", `git grep strto -- cmd/` says that the
> base argument can be 0, 10 or 16 depending on the phase of the moon -
> it's a constant source of pain to figure out how numeric arguments
> to commands will be interpreted.
> 

Yeah, and I vaguely remember being upset by the same lack of consistency 
for printing numbers.

I share the pain. But that's API so cannot change it without breaking 
stuff :/

Quentin