Message-ID: <20170816004238.GH20467@bill-the-cat>
Date:   Tue, 15 Aug 2017 20:42:38 -0400
From:   Tom Rini <trini@...sulko.com>
To:     Frank Rowand <frowand.list@...il.com>
Cc:     devicetree@...r.kernel.org, Tero Kristo <t-kristo@...com>,
        Nishanth Menon <nm@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Sekhar Nori <nsekhar@...com>, Rob Herring <robh+dt@...nel.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <mmarek@...e.com>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb
 files

On Tue, Aug 15, 2017 at 04:50:40PM -0700, Frank Rowand wrote:
> 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.
> > 
> > Cc: Rob Herring <robh+dt@...nel.org>
> > Cc: Frank Rowand <frowand.list@...il.com>
> > Cc: Masahiro Yamada <yamada.masahiro@...ionext.com>
> > Cc: Michal Marek <mmarek@...e.com>
> > Cc: Pantelis Antoniou <pantelis.antoniou@...sulko.com>
> > Cc: devicetree@...r.kernel.org
> > Cc: linux-kernel@...r.kernel.org
> > CC: linux-kbuild@...r.kernel.org
> > Signed-off-by: Tom Rini <trini@...sulko.com>
> > ---
> > In order for a dtb file to be useful with all types of overlays, it
> > needs to be generated with the -@ flag passed to dtc so that __symbols__
> > are generated.  This however is not free, and increases the resulting
> > dtb file by up to approximately 50% today.  In the current worst case
> > this is moving from 88KiB to 133KiB.  In talking with Frank about this,
> > he outlined 3 possible ways (with the 4th option of something else
> > entirely).
> > 
> > 1. Make passing -@ to dtc be dependent upon some CONFIG symbol.
> > 2. In the kernel, if the kernel does not have overlay support, discard
> > the __symbols__ information that we've been passed.
> > 3. Have the bootloader pass in, or not, __symbols__ information.
> 
> I also was hoping that other people might have ideas for additional
> approaches.

Yes, please.

> > This patch is an attempt to implement something between the 3rd option
> > and a different, 4th option.  Frank was thinking that we might introduce
> > a new symbol to control generation of __symbol__ information for option
> > 1.  I think this gets the usage backwards and will lead to confusion
> > among users and developers.
> > 
> > My proposal is that we do not want __symbols__ existence to be dependent
> > on some part of the kernel configuration for a number of reasons.
> > First, this is out of step with the rest of how dtbs are created today
> > and more importantly, thought about.  Today, all dtb content is
> > independent of CONFIG options.  If you build a dtb from a given kernel
> > tree, everyone will agree on the result.  This is part of the "contract"
> > on passing old kernels and new dtb files even.
> 
> I hope that dtb contents are independent of CONFIG options, but I don't
> feel confident is stating that there is not such dependency.  (Of course,
> whether to build a dtb can be dependent on a CONFIG option in the Makefile,
> but that is not the same concept.)
> 
> The only existing rule that I am aware of that helps avoid a dts dependency
> on kernel CONFIG options is that included files can not be from general kernel
> header files; they must be in include/dt-bindings/.

I'm fairly certain for in-kernel stuff at least, the assumption is
correct.

> Should we add text to Documentation/devicetree/bindings/submitting-patches.txt
> that explicitly states that dts files are not allowed to contain any
> dependency on kernel CONFIG options?

Certainly can't hurt.

> > Second, I think this is out of step with how a lot of overlay usage will
> > occur.  My thinking is that with maximally useful overlays being
> > available in mainline, lots of use-cases that we have today that result
> > in a number of DTS files being included can become just overlays.  This
> 
> I disagree with this.  My _opinion_ is that overlays should be the exception,
> not the common case.  Overlays require extra complexity in the various
> subsystems that interact with device trees.  For an overlay to work, these
> subsystems must be able to react to changes made to the device tree by
> an overlay.  The current mechanism is via notifiers, which only exist
> for a few subsystems.

Ah.  Now, I can't blame you for thinking with your kernel hat on, but,
you're thinking with your kernel hat on :)  (And taking mine off for a
minute is why I changed my mind between when we talked on IRC, and what
I posted).  Kernel run-time apply an overlay has various use cases that
I don't want to discount, but don't want to try and go in detail on
either.

At heart, one of the issues here is that the Linux kernel is the
authoritative source of dts and dtb files.  Assembling a dtb and N
overlays at some point prior to booting Linux, in order to give it a
complete and valid system is going to be a common case.  Even setting
aside all of the hobbyist board families out there, SoMs are a big
thing.  Eval modules are a big thing.  This turns not just enabling
these as a vendor but using them as a developer into a much less error
prone system.

To try and re-state my rational, if the Linux kernel needs some
safe-guards or other mechanisms to restrict what can be done on top of
OF_OVERLAY (which is not widely enabled in mainline), OK, that's
certainly a discussion to have and think about implications of.  But,
the Linux kernel is the producer of most dtbs that will be consumed by a
variety of platforms.  I feel it needs to generate the dtb that can be
used for all consumers, since it is the source of these resources.

-- 
Tom

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists