On Sat, Sep 19, 2026 at 08:29:34PM +0200, Heinrich Schuchardt wrote: > Am 18. September 2026 22:35:33 MESZ schrieb Han Gao <[email protected]>: > >Storage capacities above 4 GiB are truncated when stored in size_t > >on 32-bit systems. Use a 64-bit accumulator and promote the block > >count before multiplication so 32-bit LBA configurations are also > >handled correctly. > > > >Fixes: 86d462c05d57 ("cmd: add a fetch utility") > > > >Signed-off-by: Han Gao <[email protected]> > >--- > > cmd/ufetch.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >diff --git a/cmd/ufetch.c b/cmd/ufetch.c > >index d4b54f77b7b2..29ccbf654a4e 100644 > >--- a/cmd/ufetch.c > >+++ b/cmd/ufetch.c > >@@ -95,7 +95,7 @@ static int do_ufetch(struct cmd_tbl *cmdtp, int flag, int > >argc, > > const char *model, *compatible; > > char *ipaddr; > > int n_cmds, n_cpus = 0, compatlen; > >- size_t size = 0; > >+ u64 size = 0; > > ofnode np; > > bool skip_ascii = false; > > > >@@ -221,7 +221,7 @@ static int do_ufetch(struct cmd_tbl *cmdtp, int flag, > >int argc, > > ret = uclass_find_device_by_seq(UCLASS_BLK, line - > > STORAGE, &dev); > > if (!ret && dev) { > > desc = dev_get_uclass_plat(dev); > >- size = desc->lba * desc->blksz; > >+ size = (u64)desc->lba * desc->blksz; > > Shouldn't desc->lba itself be 64 bit to allow for drives larger than 2 TiB.
Likely so, yes. > Why do we allow CONFIG_SYS_64BIT_LBA=n? It'd be interesting to see the size growth from that change. -- Tom
signature.asc
Description: PGP signature
