Re: [PATCH 0/3] Synchronize DTC to 1.7.2

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

On Sun, Nov 16, 2025 at 10:48:45PM +0100, Marek Vasut wrote:
> On 11/16/25 3:11 PM, Tom Rini wrote:
> > On Sun, Nov 16, 2025 at 12:23:30AM +0100, Marek Vasut wrote:
> > > On 11/13/25 7:49 PM, Tom Rini wrote:
> > > 
> > > Hello Tom,
> > > 
> > > > > CI does show that no boards went oversize . If there is some growth on
> > > > > existing devices, maybe we can shrink that, but maintaining obsolete DTC
> > > > > code base going forward and picking random updates into it, that will only
> > > > > lead to increasing maintenance pain, so I don't want to do that.
> > > > 
> > > > Yeah, it's not an easy spot. But I'm really not happy with growing main
> > > > U-Boot almost everywhere by 2KiB - 4KiB, and SPL by ~512 bytes or more
> > > > just to keep up. I do see that integratorcp_cm1136 barely grows at all,
> > > > so maybe there's something that can be done more widely and just wasn't
> > > > clear at first. m68k only grows an average of 500 bytes and MIPS is
> > > > ~1KiB. PowerPC grows a lot. RISC-V a little.
> > > I suspect this might have to do with DTO support. The imx8mp_dhcom do use
> > > DTOs and the fdt_overlay.c code grew a lot.
> > > 
> > > I also found out that if I patch out can_assume() and replace it with plain
> > > 1 , then the size drops by 1-2 kiB, but that's probably not what we want to
> > > do.
> > 
> > I'm not sure, maybe we do? Or maybe we need to look and have *one* place
> > that confirms correct alignment and either fixes/complains
> 
> That's already part of new libfdt, that is also what triggered the various
> fixes I posted recently:
> 
> scripts/dtc/libfdt/fdt.c:       if ((uintptr_t)fdt & 7)
> scripts/dtc/libfdt/fdt.c:       if ((uintptr_t)fdt & 7)
> 
> > , and then
> > every follow-up location doesn't need to perform that (or possibly many
> > other as well) validation checks. My impression from when I looked at
> > the code last, a few year ago, was that it was designed with "validate
> > with most? every? function" and we would be happy enough with "validate
> > once".
> 
> If you can make that assumption -- that whatever we feed into libfdt is
> valid -- then we can simply patch out can_assume() .

Maybe the question I have then is, why isn't can_assume being optimized
out at compile time, if we set the mask right. Makes me wonder if
there's not something to fix upstream too. Or maybe we need to change
the default to higher than 0?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]