linux-kernel - Re: [PATCH v2 5/7] of/fdt: Simplify the logic of early_init_dt_scan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdXvqFEyY3p-+1FpDNFFLj8XLfF8v5xNfvhnZ_35mo8eZA@mail.gmail.com>
Date: Mon, 17 Nov 2025 13:44:18 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Rob Herring <robh@...nel.org>
Cc: Yuntao Wang <yuntao.wang@...ux.dev>, akpm@...ux-foundation.org, ardb@...nel.org, 
	bhe@...hat.com, catalin.marinas@....com, changyuanl@...gle.com, 
	devicetree@...r.kernel.org, geert+renesas@...der.be, geoff@...radead.org, 
	graf@...zon.com, james.morse@....com, linux-kernel@...r.kernel.org, 
	mark.rutland@....com, rppt@...nel.org, saravanak@...gle.com, 
	thunder.leizhen@...wei.com
Subject: Re: [PATCH v2 5/7] of/fdt: Simplify the logic of early_init_dt_scan_memory()

Hi Rob,

On Fri, 14 Nov 2025 at 16:11, Rob Herring <robh@...nel.org> wrote:
> On Thu, Nov 13, 2025 at 9:56 PM Yuntao Wang <yuntao.wang@...ux.dev> wrote:
> > There is another issue reported by kernel test robot:
> >
> > drivers/of/fdt.c:903:31: error: incompatible pointer types passing 'phys_addr_t *' (aka 'unsigned int *') to parameter of type 'u64 *' (aka 'unsigned long long *') [-Wincompatible-pointer-types]
> >
> > Given this, the problem exists regardless of which implementation we choose.
> >
> > I’m considering two possible solutions:
> >
> > 1. Convert of_fdt_read_addr_size() into a macro.
> > 2. Split it into two functions: of_fdt_read_addr() and of_fdt_read_size().
> >
> > I’m leaning toward the second option.
> >
> > What do you think? Or do you have a better approach?
>
> Just use local u64 variables and then assign the values to the struct.
> This will not warn:
>
> a_phys_addr = a_u64;
>
> (It could silently truncate values, but I'm pretty sure no one runs
> 32-bit LPAE systems with a non-LPAE kernel on the very few systems
> that even still exist).

You mean running multi_v7_defconfig on anything found by
'git grep "#address-cells\s*=\s*<2>" -- arch/arm/boot/dts'?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds