From: Anatolij Gustschin <agust@denx.de>
To: u-boot@lists.denx.de
Subject: [RFC PATCH] imx: skip unused compatible strings in drivers
Date: Tue, 26 May 2020 15:15:16 +0200 [thread overview]
Message-ID: <20200526151516.4d6633a4@crub> (raw)
In-Reply-To: <19ca7297-b7a6-62f5-e88f-e7f981386ffb@denx.de>
On Tue, 26 May 2020 14:42:08 +0200
Marek Vasut marex at denx.de wrote:
> On 5/26/20 2:40 PM, Peng Fan wrote:
> >> Subject: Re: [RFC PATCH] imx: skip unused compatible strings in drivers
> >>
> >> On Tue, 26 May 2020 13:25:00 +0200
> >> Marek Vasut marex at denx.de wrote:
> >>
> >>> On 5/26/20 1:12 PM, Soeren Moch wrote:
> >>>> On 25.05.20 22:24, Anatolij Gustschin wrote:
> >>>>> Converting to DM increases binary size and breaks building some
> >>>>> boards (i.e. tbs2910, gcc 9.2). The approach to address this issue
> >>>>> via cutting off unused properties/nodes in device tree via custom
> >>>>> u-boot.dtsi was not welcome, even if the affected boards do not
> >>>>> pass the built-in device tree to the kernel.
> >>>> But there is CONFIG_OF_REMOVE_PROPS="dmas dma-names
> >> interrupt-parent
> >>>> interrupts interrupts-extended interrupt-names interrupt-map
> >>>> interrupt-map-mask" in tbs2910_defconfig. So removing properties is
> >>>> already done via this config option. Removing nodes is not
> >>>> implemented (yet? AFAIK). But would be welcome if someone implements
> >>>> this in a similar way, I think.
> >>>
> >>> Why don't we turn this the other way around -- put the { compat string
> >>> , driver } tuple list into a U-Boot linker list, then filter this
> >>> linker list against a DT which will be used for the platform (what if
> >>> there are multiple DTs?), and then scrub all unreferrenced symbols.
> >>
> >> This might be a topic again when new bloat causes build breakage again. For
> >> now I've succeeded to build the tbs2910 board with default CI tool chain
> >> without this patch (by making DM_VIDEO parts optional). Stripping unused
> >> compatible entries doesn't save much here (around 800 bytes). So the
> >> question is if it is worth the effort to implement such scrubbing.
> >
> > I vote for this. Whether u-boot or SPL, currently the size is larger and larger.
>
> Can you send a patch prototyping this ?
I'm not working on this, so do not expect patches from me, at least
not in the near future.
--
Anatolij
next prev parent reply other threads:[~2020-05-26 13:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 20:24 [RFC PATCH] imx: skip unused compatible strings in drivers Anatolij Gustschin
2020-05-26 11:12 ` Soeren Moch
2020-05-26 11:25 ` Marek Vasut
2020-05-26 11:35 ` Soeren Moch
2020-05-26 11:58 ` Anatolij Gustschin
2020-05-26 12:00 ` Marek Vasut
2020-05-26 12:40 ` Peng Fan
2020-05-26 12:42 ` Marek Vasut
2020-05-26 13:15 ` Anatolij Gustschin [this message]
2020-05-26 11:43 ` Anatolij Gustschin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200526151516.4d6633a4@crub \
--to=agust@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox