Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753064AbdHPASL (ORCPT <rfc822;w@1wt.eu>);
        Tue, 15 Aug 2017 20:18:11 -0400
Received: from mail-pg0-f66.google.com ([74.125.83.66]:36864 "EHLO
        mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753012AbdHPASI (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 15 Aug 2017 20:18:08 -0400
Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb
 files
To: Tom Rini <trini@konsulko.com>, devicetree@vger.kernel.org
References: <1502831736-28282-1-git-send-email-trini@konsulko.com>
Cc: Tero Kristo <t-kristo@ti.com>, Nishanth Menon <nm@ti.com>,
        Tomi Valkeinen <tomi.valkeinen@ti.com>, Sekhar Nori <nsekhar@ti.com>,
        Rob Herring <robh+dt@kernel.org>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Michal Marek <mmarek@suse.com>,
        Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
        linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
From: Frank Rowand <frowand.list@gmail.com>
Message-ID: <59938F3B.30704@gmail.com>
Date: Tue, 15 Aug 2017 17:18:03 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <1502831736-28282-1-git-send-email-trini@konsulko.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3761
Lines: 54

On 08/15/17 14:15, Tom Rini wrote:
> With support for stacked overlays being part of libfdt it is now
> possible and likely that overlays which require __symbols__ will be
> applied to the dtb files generated by the kernel.  This is done by
> passing -@ to dtc.  This does increase the filesize (and resident memory
> usage) based on the number of __symbol__ entries added to match the
> contents of the dts.

< snip >

And for some background, for those who were not on the irc channel,
here is the conversation that Tom and I had:

<Tartarus> frowand: So, dtc knows -@, but the kernel doesn't globally use -@ yet due to increased memory usage, in the dtb?
<frowand> yes
<frowand> It is available via the pattern that you can see in drivers/of/unittest-data/Makefile
<Tartarus> Is there an opt-in way to get the extra symbols?
<frowand> # enable creation of __symbols__ node
<frowand> DTC_FLAGS_overlay := -@
<Tartarus> ah, hm
<frowand> The problem is that it is always on, once the flags are added
<frowand> there are a few ways I have thought of making it optional
<frowand> 1) DTC_FLAGS_overlay := CONFIG_OVERLAY_ENABLED_IN_BASE
<Tartarus> OK.  There's at least a few vendors that are eagerly awaiting overlays Just Working, is why I'm asking
<Tartarus> How much extra memory usage are we talking about, on a 'big' platform for example?
<frowand> where  CONFIG_OVERLAY_ENABLED_IN_BASE is a string of either empty or "-@".  I don't know if the kconfig allows that, but I'm guessing there is some way to do it
<frowand> Not sure of size penalty.
<Tartarus> CONFIG_USE_xxx as a bool, CONFIG_xxx as the string
<Tartarus> I would kind of assume wanting overlays to just work would be the common case, at least in terms of in-kernel users
<frowand> 2) When instantiating the device tree from the FDT, do not keep the __SYMBOLS__ node if overlays are not enabled in the kernel
<Tartarus> ie if it's a CONFIG opt-in, multi_v7_defconfig, etc, would want it on
<frowand> the issue with 2, is that the boot image still has the size penalty
<frowand> 3) the bootloader could choose whether to pass the __SYMBOLS__ node to the kernel or not
<Tartarus> I'm not sure about 3 honestly
<frowand> Yep, 3 is my least favorite.
<Tartarus> If one has a case where there's a desire for no overlay support, for whatever reason, that's a feature of the kernel
<frowand> There is probably also option 4, 5, etc.  But I haven't thought it through too deeply yet.
<Tartarus> I can see some sort of CONFIG option, default y, being a reasonable option here
<frowand> I'm not sure about the common case.  There are some boards where overlays would almost always be used, but there may also be boards where there are rarely used.
<frowand> But the common case is a bikeshed issue to me.
<Tartarus> heh
<Tartarus> Well, here's why I was thinking that
<frowand> As long as the users and distros have a way to control it.
<Tartarus> Lots of proprietary boards I've dealt with could just be an EVM + overlay
<Tartarus> wrt dtb
<frowand> what is EVM?
<Tartarus> Today it's take the evm dts, start hacking
<Tartarus> evaluation platform
<Tartarus> The second, similar, example would be custom platforms based on SoMs
<frowand> Are you saying to use an overlay to add onto the base EVM dts kinda sorta the way that some driver writers use kernel modules to add drivers?
<Tartarus> A reasonable analogy, yes
<frowand> ok, just wanted to verify I understood the model
<frowand> I see that as a reasonable development technique
<frowand> I have some time critical errands to run, so I'll be gone for a few hours.  It would be good to share what we just said with the mail list, and see if anyone else has some brilliant ideas.  Start with what the objectives/issues are, some possible solutions...