[PATCH v2 2/7] common: binman: Calling initr_binman() when BINMAN_FDT

Tom Rini trini at konsulko.com
Mon Dec 9 16:32:16 CET 2024


On Mon, Dec 09, 2024 at 04:26:15PM +0100, Michal Simek wrote:
> 
> 
> On 12/6/24 20:20, Simon Glass wrote:
> > On Fri, 1 Nov 2024 at 03:18, Michal Simek <michal.simek at amd.com> wrote:
> > > 
> > > Calling empty function when BINMAN_FDT is adding +64B for nothing which is
> > > not helping on size sensitive configurations as Xilinx mini configurations.
> > > 
> > > Signed-off-by: Michal Simek <michal.simek at amd.com>
> > > ---
> > > 
> > > Changes in v2:
> > > - new patch
> > > 
> > >  From my perspective there is no reason to call empty function. It is just
> > > increase footprint for nothing and we are not far from that limit now.
> > > 
> > > ---
> > >   common/board_r.c | 7 +++----
> > >   1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > Reviewed-by: Simon Glass <sjg at chromium.org>
> > 
> > This is a bit odd, though. Do you have LTO enabled?
> > 
> 
> yes LTO is enabled. And there are other candidates like this.
> Is LTO able to fix function arrays which is calling empty function?
> 
> (without this patch)
> 
> 00000000fffc0eb4 <initr_of_live>:
>     fffc0eb4:   52800000        mov     w0, #0x0                        // #0
>     fffc0eb8:   d65f03c0        ret
> 
> 00000000fffc0ebc <initr_dm_devices>:
>     fffc0ebc:   52800000        mov     w0, #0x0                        // #0
>     fffc0ec0:   d65f03c0        ret
> 
> 00000000fffc0ec4 <initr_bootstage>:
>     fffc0ec4:   52800000        mov     w0, #0x0                        // #0
>     fffc0ec8:   d65f03c0        ret
> 
> 00000000fffc0ecc <power_init_board>:
>     fffc0ecc:   52800000        mov     w0, #0x0                        // #0
>     fffc0ed0:   d65f03c0        ret
> 
> 00000000fffc0ed4 <initr_announce>:
>     fffc0ed4:   52800000        mov     w0, #0x0                        // #0
>     fffc0ed8:   d65f03c0        ret
> 
> 00000000fffc0edc <initr_binman>:
>     fffc0edc:   52800000        mov     w0, #0x0                        // #0
>     fffc0ee0:   d65f03c0        ret
> 
> 00000000fffc0ee4 <initr_status_led>:
>     fffc0ee4:   52800000        mov     w0, #0x0                        // #0
>     fffc0ee8:   d65f03c0        ret
> 
> 00000000fffc0eec <initr_boot_led_blink>:
>     fffc0eec:   52800000        mov     w0, #0x0                        // #0
>     fffc0ef0:   d65f03c0        ret
> 
> 00000000fffc0ef4 <initr_boot_led_on>:
>     fffc0ef4:   52800000        mov     w0, #0x0                        // #0
>     fffc0ef8:   d65f03c0        ret
> 
> 00000000fffc0efc <initr_lmb>:
>     fffc0efc:   52800000        mov     w0, #0x0                        // #0
>     fffc0f00:   d65f03c0        ret

No, but maybe Simon would prefer if we marked all of the could-be-empty
functions as __maybe_unused and did:
	CONFIG_IS_ENABLED(BINMAN_FDT, initr_binman),
etc in the list instead?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241209/26394de0/attachment.sig>


More information about the U-Boot mailing list