Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752504AbdHPP5w (ORCPT ); Wed, 16 Aug 2017 11:57:52 -0400 Received: from mail-yw0-f179.google.com ([209.85.161.179]:36677 "EHLO mail-yw0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751620AbdHPP5u (ORCPT ); Wed, 16 Aug 2017 11:57:50 -0400 Date: Wed, 16 Aug 2017 11:57:48 -0400 From: Tom Rini To: Rob Herring Cc: "devicetree@vger.kernel.org" , Tero Kristo , Nishanth Menon , Tomi Valkeinen , Sekhar Nori , Frank Rowand , Masahiro Yamada , Michal Marek , Pantelis Antoniou , Linux Kernel Mailing List , Linux Kbuild mailing list Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Message-ID: <20170816155748.GQ20467@bill-the-cat> References: <1502831736-28282-1-git-send-email-trini@konsulko.com> <20170815224924.GG20467@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8fO9XcmfgQpeuzfm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7090 Lines: 150 --8fO9XcmfgQpeuzfm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 me= mory > >> > 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 __symbo= ls__ > >> > 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 th= is, > >> > >> 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, disca= rd > >> > 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 opti= on > >> > and a different, 4th option. Frank was thinking that we might intro= duce > >> > a new symbol to control generation of __symbol__ information for opt= ion > >> > 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 depen= dent > >> > 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 tod= ay > >> > and more importantly, thought about. Today, all dtb content is > >> > independent of CONFIG options. If you build a dtb from a given kern= el > >> > tree, everyone will agree on the result. This is part of the "contr= act" > >> > 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). >=20 > 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. --=20 Tom --8fO9XcmfgQpeuzfm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJZlGt8AAoJEIf59jXTHXZSPaYP/3LSlq3SGpO7SYFAfLXoSamB +qpSTXKrRY7uYTbwbF4lty5DrXjjTHCfiHlnKpnatiJp7ws6BRfOmpHw7UeTsVdO LZc/EnyQq1PJ56qNVqOgE1Cb1/MF2XCjKe2STIE6XMuyN3IKokQa8vXWsxBQi30O YA+3KHnX+HY3n+otsMHPtbHi+gpXIkrmoB+l4pjU/84MbZIKQdwf49ebeZL6M/5f PMkoe55V3tb/DXbPEQdg9q8IPkKekgOzURI74Z86aoknV5UT3/bGp23FJQ3UIdn8 WQGr37FMT2g7WJwvqVIYQuryTNuLmDDrE2FA4F2KNZWIpXUxPmX36bR+OpQHsrN8 KAj5IC/4YNd2lvD6I2kuGQ5eKo0kD0X28/2WTnWkwBpg7JligihxIcI0xXMU9TX1 NUfcC11KfHJztkS2Gjf+wcbu9q6FcqrKQfFAVlriVcVQUoctmSRjJ3cnr+3+yzLb UnA7ZOtV2qmLEbyl3rZfXDUnPi7QQ8D9tipydkCPRKWRbw9PFtjjKHWzKcPdKGAH yCURrdspinVjoYg+Yl54QE4jDDRbTFZogKJkBzDyLHnkVjaIsMh37ycnzJQJ1hmf oZFW8Pv77n7dOY/xRotqKKaMSzgr85Hn6pbWx2t2pOMpVyItIO6xzDFbkR7ZEKk5 +AvcK3z6a93OvNlKCUh8 =L6KZ -----END PGP SIGNATURE----- --8fO9XcmfgQpeuzfm--