Re: [PATCH v13 1/6] x86/boot: Introduce kstrtoull() to boot directory instead of simple_strtoull()

[Borislav Petkov]

On Fri, Dec 14, 2018 at 10:59:17AM +0800, Chao Fan wrote:
> Cant't use div_u64() in math64.h directly, because  that will cause ld error.

Ok, I see it now.

> Even in 64-bit environment, arch/x86/boot/*.o will be built as 32-bit
> binary. In 64-bit binary, the dividend is handled as 64-bit value,
> that's OK, but in 32-bit binary, that's wrong. So it's necessary
> to separate the dividend to upper and lower in 32-bit binary.
> That's why copy the needed div_u64() here.

You could've written this in the commit message. This is an important
piece of information.

> So just like Baoquan said, it's a good choice to use simple_strtoull()
> for now.

So, we tried a little, we encountered a problem and now we're giving up?
Is that what you're trying to tell me?

Please explain what are we in a hurry for and why aren't we doing it
right?

Btw, one more thing I noticed:

> +static acpi_physical_address get_acpi_rsdp(void)
> +{
> +#ifdef CONFIG_KEXEC
> +       unsigned long long res;
> +       int len = 0;
> +       char val[MAX_ADDRESS_LENGTH+1];
> +
> +       len = cmdline_find_option("acpi_rsdp", val, MAX_ADDRESS_LENGTH+1);
> +       if (len > 0) {
> +               val[len] = 0;
> +               return (acpi_physical_address)kstrtoull(val, 16, &res);

This would've never worked because the parsed integer gets returned in
res but you're returning the kstrtoull() return value, which is

"Returns 0 on success, -ERANGE on overflow and -EINVAL on parsing error."

So this could not have been tested successfully, if at all...

So let's please slow down, think about it good, do it right and test it
properly before sending next time, ok?

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.