Re: [PATCH 2/2] ubi: build: replace simple_strtoul with kstrtoul in bytes_str_to_int()

[Haoyu Lu]

Hi Richard, Zhihao,

Thanks for the feedback. I will drop this patch.

Thanks,
Haoyu

On Thu, May 7, 2026 at 3:50 PM Richard Weinberger <richard@xxxxxx> wrote:
>
> ----- Ursprüngliche Mail -----
> > Von: "chengzhihao1" <chengzhihao1@xxxxxxxxxx>
> > An: "haoyu.lu" <hechushiguitu666@xxxxxxxxx>, "Miquel Raynal" <miquel.raynal@xxxxxxxxxxx>, "richard" <richard@xxxxxx>,
> > "Vignesh Raghavendra" <vigneshr@xxxxxx>
> > CC: "linux-mtd" <linux-mtd@xxxxxxxxxxxxxxxxxxx>, "linux-kernel" <linux-kernel@xxxxxxxxxxxxxxx>
> > Gesendet: Donnerstag, 7. Mai 2026 09:45:24
> > Betreff: Re: [PATCH 2/2] ubi: build: replace simple_strtoul with kstrtoul in bytes_str_to_int()
>
> > 在 2026/5/7 11:23, haoyu.lu 写道:
> >> From: Haoyu Lu <hechushiguitu666@xxxxxxxxx>
> >>
> >> Replace the deprecated simple_strtoul() with kstrtoul() in the
> >> bytes_str_to_int() helper function. Since kstrtoul() rejects trailing
> >> non-numeric characters (such as the G/M/K suffixes), the numeric prefix
> >> is first extracted with strspn() and then parsed separately before
> >> handling the suffix.
> >>
> >> This provides proper error handling through the kstrto* family while
> >> preserving the existing suffix semantics for byte count parameters.
> >>
> >> Note: the original simple_strtoul() with base=0 accepted hexadecimal
> >> (0x prefix) and octal (0 prefix) formats, while kstrtoul() with base=10
> >> only supports decimal. This is not a practical concern since MTD byte
> >> count parameters are always specified as decimal values in boot
> >> parameters.
> > The ubi could be loaded by module insertion, many vendors set param
> > 'vid_hdr_offs' to save space. We cannot make the assumption that all
> > users use the decimal system.
>
> That's a good point!
>
> In general I'm not fond of such changes. They change code for the sake
> of changing code without fixing actual issues.
> I'll happily accept patches that point out real issues with the current
> usage of various string functions, though.
>
> Thanks,
> //richard