Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752202AbdHPQBB (ORCPT ); Wed, 16 Aug 2017 12:01:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:56642 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751461AbdHPQA7 (ORCPT ); Wed, 16 Aug 2017 12:00:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B54722C7D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh+dt@kernel.org MIME-Version: 1.0 In-Reply-To: <20170816154129.GP20467@bill-the-cat> References: <1502831736-28282-1-git-send-email-trini@konsulko.com> <599388D0.9050108@gmail.com> <20170816004238.GH20467@bill-the-cat> <20170816154129.GP20467@bill-the-cat> From: Rob Herring Date: Wed, 16 Aug 2017 11:00:37 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files To: Tom Rini Cc: Frank Rowand , "devicetree@vger.kernel.org" , Tero Kristo , Nishanth Menon , Tomi Valkeinen , Sekhar Nori , Masahiro Yamada , Michal Marek , Pantelis Antoniou , "linux-kernel@vger.kernel.org" , Linux Kbuild mailing list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3205 Lines: 71 On Wed, Aug 16, 2017 at 10:41 AM, Tom Rini wrote: > On Wed, Aug 16, 2017 at 10:22:03AM -0500, Rob Herring wrote: >> On Tue, Aug 15, 2017 at 7:42 PM, Tom Rini wrote: >> > 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 >> >> > 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, >> >> > 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. >> >> A couple of other options come to mind: >> >> "make DTC_FLAGS='-@' dtbs" should already work. So there's already a >> way to build what you want and the kernel is not setting the policy. > > Not ideal since that drops out the -Wno... flags we pass in. I don't > see off-hand why it's not appending to DTC_FLAGS, but that's a fixable > problem. I think that's a "feature" of make. Either it needs a different name or maybe it needs "DTC_FLAGS ?= ..." to pick up later "+=" which some of the arches do. It's been on my todo for a long time to kill off the per arch DTC_FLAGS BTW. > >> Do like we do for the unittests and make it a per board decision: >> >> DTC_FLAGS_my-som-board.dtb := -@ >> >> Then boards that actually need it like SoMs can turn it on. > > A concern about that of mine is that we'll start to see a 'flood' of > patches growing that list at the end of arch/arm/boot/dts/Makefile. Maybe that will motivate arm-soc to restructure things by vendor. If there's really a flood then maybe on should be the default and we turn it off per board. I'm somewhat skeptical that we'll see a flood though. Rob