Re: [PATCH] cmd_dtc: Enable generation of device tree symbols

[Uwe Kleine-König]

Hello Masahiro,

On 1/25/21 10:53 PM, Masahiro Yamada wrote:
> On Mon, Jan 25, 2021 at 8:07 PM Uwe Kleine-König <uwe@xxxxxxxxxxxxxxxxx> wrote:
> > Adding the -@ switch to dtc results in the binary devicetrees containing
> > a list of symbolic references and their paths. This is necessary to
> > apply device tree overlays e.g. on Raspberry Pi as described on
> > https://www.raspberrypi.org/documentation/configuration/device-tree.md.
> >
> > Obviously the downside of this change is an increas of the size of the
> > generated dtbs, for an arm out-of-tree build (multi_v7_defconfig):
> >
> >          $ du -s arch/arm/boot/dts*
> >          101380  arch/arm/boot/dts-pre
> >          114308  arch/arm/boot/dts-post
> >
> > so this is in average an increase of 12.8% in size.
> >
> > Signed-off-by: Uwe Kleine-König <uwe@xxxxxxxxxxxxxxxxx>
>
>
> (CCing DT ML.)

makes sense, thanks.

> https://www.spinics.net/lists/linux-kbuild/msg27904.html
>
> See Rob's comment:
>
> "We've already rejected doing that. Turning on '-@' can grow the dtb
> size by a significant amount which could be problematic for some
> boards."

The patch was created after some conversation on irc which continued
after I sent the patch. I added the participating parties to Cc:.

The (relevant) followups were:

Geert suggested to always generate the symbols and provide a way to
strip the symbols for installation if and when they are not needed.

Rob said: "I'm less concerned with the size increases, but rather that
labels go from purely source syntax to an ABI. I'd rather see some
decision as to which labels are enabled or not."

And then I learned with hints from Rob and Geert that symbols are not
really necessary for overlays, you just cannot use named labels. But
using

	target-path = "/soc/i2c@23473245";

or

	target = <&{/soc/i2c@23473245}>;

instead of

	target = <&i2c1>;

works fine. (And if you need to add a phandle the &{/path/to/node}
construct should work, too (but I didn't test).) Using labels is a tad 
nicer, but the problem I wanted to address with my patch now has a known 
different solution.

Best regards
Uwe

Attachment: OpenPGP_signature
Description: OpenPGP digital signature