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

+frank

On 1/26/21 1:20 AM, Uwe Kleine-König wrote:

Hello Masahiro,

On 1/25/21 10:53 PM, Masahiro Yamada wrote:

quoted

On Mon, Jan 25, 2021 at 8:07 PM Uwe Kleine-König [off-list ref] wrote:

quoted

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 <redacted>

(CCing DT ML.)

makes sense, thanks.

quoted

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel