Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752437AbdHPSKk (ORCPT ); Wed, 16 Aug 2017 14:10:40 -0400 Received: from mail-pg0-f44.google.com ([74.125.83.44]:35895 "EHLO mail-pg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751692AbdHPSKi (ORCPT ); Wed, 16 Aug 2017 14:10:38 -0400 Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files To: Rob Herring , Tom Rini References: <1502831736-28282-1-git-send-email-trini@konsulko.com> <20170815224924.GG20467@bill-the-cat> <20170816155748.GQ20467@bill-the-cat> Cc: "devicetree@vger.kernel.org" , Tero Kristo , Nishanth Menon , Tomi Valkeinen , Sekhar Nori , Masahiro Yamada , Michal Marek , Pantelis Antoniou , Linux Kernel Mailing List , Linux Kbuild mailing list , Stephen Boyd From: Frank Rowand Message-ID: <59948A99.4000605@gmail.com> Date: Wed, 16 Aug 2017 11:10:33 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6534 Lines: 121 On 08/16/17 09:16, Rob Herring wrote: > On Wed, Aug 16, 2017 at 10:57 AM, Tom Rini wrote: >> On Wed, Aug 16, 2017 at 10:43:16AM -0500, Rob Herring wrote: >>> On Tue, Aug 15, 2017 at 5:49 PM, Tom Rini wrote: >>>> On Tue, Aug 15, 2017 at 05:36:11PM -0500, Rob Herring wrote: >>>>> On Tue, Aug 15, 2017 at 4:15 PM, 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 >>>>>> Cc: Frank Rowand >>>>>> Cc: Masahiro Yamada >>>>>> Cc: Michal Marek >>>>>> Cc: Pantelis Antoniou >>>>>> Cc: devicetree@vger.kernel.org >>>>>> Cc: linux-kernel@vger.kernel.org >>>>>> CC: linux-kbuild@vger.kernel.org >>>>>> Signed-off-by: Tom Rini >>>>>> --- >>>>>> 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, >>>>> >>>>> Plus some amount for the unflattened tree in memory, too. >>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>> >>>>> Agree completely. I don't even like that building dtbs depends on the ARCH. >>>>> >>>>> However, option 2 may still be useful. There's no point exposing what >>>>> can't be used. Furthermore, exposing __symbols__ in /proc/device-tree >>>>> at all may be a bad idea. We should consider if it should always be >>>>> hidden. That would also allow storing the __symbols__ data however we >>>>> want internally (i.e. with less memory usage). The complication is >>>>> always kexec which I haven't thought about too much here. >>>> >>>> A further patch to the kernel at run-time, OK. If you give me some >>>> crumbs I'll see if I can figure out the next steps. >>>> >>>>> Also, perhaps we need finer grain control of __symbols__ generation. >>>> >>>> Here I have to disagree. >>>> >>>>> We really don't want userspace to be able to modify anything in the DT >>>>> at any point in time. That's a big can of worms and we don't want to >>>>> start there. The problem is labels are widely used just for >>>>> convenience and weren't part of the ABI. With overlays that changes, >>>>> so we either need to restrict labels usage or define another way. It >>>>> could be as simple as defining some prefix for label names for labels >>>>> to export. >>>> >>>> I think there needs to be a difference noted between "here is what >>>> policy the kernel is going to enforce about run time changes" and "here >>>> is what the user is going to assemble a system to look like". Again, >>>> stemming from the part where the Linux kernel is where dts files reside >>>> and are generated from normally. If we have it in __symbols__, someone >>>> can make use of it in hardware design (again, think of the SoM + carrier >>>> + custom) bit, I've seen so many real life products now that would be >>>> simplified in this manner). >>> >>> I agree the usecase is an important one and one we should target, but >>> I think there are other issues to solve first before we get to the >>> trivial change needing to enable __symbols__. Do we have any dts files >>> actually structured for the SoM + carrier use case? I guess it's done >>> with includes ATM if we do. The run-time restrictions aren't just >>> kernel policy. The SoM itself is going to have restrictions defined by >>> its pinout. I think those need to be described in DT via a connector >>> binding. I worry about leaving things wide open and having overlays >>> just be a DT configuration tool with every platform structuring things >>> however they want. From what I've looked at on RPi, I'm very concerned >>> about having things like CMA overlays to set the CMA size. (On the >>> flip side as a user, it was very nice to just apply the RPi 1-wire >>> gpio overlay and things just worked.) >> >> I believe the various SoM and EVM and hobbyist cases are all either out >> of tree, or glued together (see imx6sx-udoo-neo-* in-tree, RPi or >> Hummingboard or TI DRA7 EVM + LCDs) as various groups decided it >> wouldn't be accepted to push in N "complete" DTS files for each valid >> combination). Moving forward with an in-kernel policy on how it should >> be done, structure-wise would help with consistency and defining what's >> really acceptable. > > IMO, that starts with a connector binding. Stephen Boyd has been > working towards that[1]. I guess "gpio nexus" is so obscure that all > the masses clamoring for overlays and modular board support haven't > noticed. > > Rob > > [1] https://www.spinics.net/lists/arm-kernel/msg600125.html Agreed. The connector binding is needed for overlays to move forward. -Frank