Re: [RFC] disk/part: partition number parsed as hex in blk_get_device_part_str

On Mon, Aug 10, 2026 at 03:34:48PM +0200, Quentin Schulz wrote:
> Hi Albin,
> 
> On 8/10/26 1:43 PM, Raj, Albin via U-Boot wrote:
> > Hello,
> > 
> > While testing GPT partitions on USB media, I noticed that partition identifiers passed on the command line appear to be parsed as hexadecimal values.
> > 
> > Example:
> > 
> > => part list usb 0
> > 
> > Partition Map for USB device 0  --   Partition Type: EFI
> > 
> > Part    Start LBA       End LBA         Name
> >          Attributes
> >          Type GUID
> >          Partition GUID
> >    1     0x00000800      0x008007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   5d33e1b1-c3ae-4e58-8677-13a295ce7b41
> >    2     0x00800800      0x010007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   277f159b-1239-4be1-bc1e-54c718331584
> >    3     0x01000800      0x018007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   470b684e-6d99-4a26-866f-14663b13dcbf
> >    4     0x01800800      0x020007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   1f598bf7-5d31-47bf-9a1d-75c2c6b74dd4
> >    5     0x02000800      0x028007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   30491f52-e2d7-4f15-8925-92c00ca6e8fb
> >    6     0x02800800      0x030007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   aef06b97-9320-494b-bff9-3f2cb472ba7f
> >    7     0x03000800      0x038007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   74143690-f5ab-4437-949e-b098199435c3
> >    8     0x03800800      0x040007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   fca32ea9-8165-404a-8eac-b22b80a15c8a
> >    9     0x04000800      0x048007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   fd4d818b-205e-43ef-9de5-7be6bf8550c8
> > 10     0x04800800      0x050007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   a4b21c4c-f0cf-4fb7-b70a-0f191b9fd874
> > 11     0x05000800      0x058007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   243ae3ce-4fd5-4230-ba83-137d8655ea8c
> > 12     0x05800800      0x060007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   671bdeba-dd6a-43e0-a99c-e880ebab991b
> > 13     0x06000800      0x068007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   b5fd6923-e40b-4018-9808-541c91ec81f5
> > 14     0x06800800      0x070007ff      ""
> >          attrs:  0x0000000000000000
> >          type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> >          guid:   29634671-56d8-45f7-8a22-f2b7c33520a5
> > 
> > 
> > Partition 9 can be accessed successfully:
> > 
> > => part uuid usb 0:9
> > fd4d818b-205e-43ef-9de5-7be6bf8550c8
> > 
> > However:
> > 
> > => part uuid usb 0:10
> > ** Invalid partition 16 **
> > 
> > => part uuid usb 0:11
> > ** Invalid partition 17 **
> > 
> > Looking at blk_get_device_part_str() the partition number is parsed with:
> > 
> >      part = (int)hextoul(part_str, &ep);
> > 
> > which converts:
> > 
> >      10 -> 16
> >      11 -> 17
> > 
> > Since "part list" displays partition identifiers in decimal, users reasonably expect "0:10" to refer to partition 10 rather than partition 16.
> > 
> > Is this behavior intentional for backward compatibility, or would decimal parsing be preferred?
> > 
> 
> We will not change the parsing of numbers for existing commands, as you
> guessed, for backward compatibility. However, we certainly could document it
> explicitly in https://docs.u-boot-project.org/en/latest/usage/cmd/part.html
> (which you can change in our source tree in doc/usage/cmd/part.rst).

It should be clear in the general documentation as all inputs (with a
few rare exceptions such as "sleep") take hexadecimal.

> I think it could also be a good idea to update what "part list" prints to
> use hex instead of decimal, but I'm not sure everybody will agree.

It's probably worth doing here, yes.

-- 
Tom

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTzzqh0PWDgGS+bTHor4qD1Cr/kCgUCann2CwAKCRAr4qD1Cr/k
Cgf3AQCxj3sBe0qnnAvBT8mRRcVQVU1zsa3QvJyCt/qEMwXFoAD9E85ASbOVgr17
Hih6MH1btB2KW+H09OPOatKQpiTXAwM=
=TpQQ
-----END PGP SIGNATURE-----