From: Frank Rowand <frowand.list@gmail.com>
To: Rob Herring <robh@kernel.org>, Tom Rini <trini@konsulko.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
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 Mailing List <linux-kernel@vger.kernel.org>,
linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files
Date: Tue, 15 Aug 2017 17:14:46 -0700 [thread overview]
Message-ID: <59938E76.3010807@gmail.com> (raw)
In-Reply-To: <CABGGiswpz6k4rnXk-3SLpwD5V8+zah-yaaB+yrrLofKY1eBx2w@mail.gmail.com>
On 08/15/17 15:36, Rob Herring wrote:
> On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini <trini@konsulko.com> wrote:
>> With support for stacked overlays being part of libfdt it is now
< snip >
>> 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.
< snip >
I also agree that use of CONFIG options is a solution that I do not like.
It has always seemed that there is a bit of an impedence mismatch in that
we build a dtb in an environment that is configured for a specific board
and architecture.
Does anyone have any thoughts on another way to control whether or not a
given dtb or a given build of a dtb would contain the symbols needed for
overlays or not include the symbols?
-Frank
WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>,
Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>,
Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>,
Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Masahiro Yamada
<yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>,
Michal Marek <mmarek-IBi9RG/b67k@public.gmane.org>,
Pantelis Antoniou
<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files
Date: Tue, 15 Aug 2017 17:14:46 -0700 [thread overview]
Message-ID: <59938E76.3010807@gmail.com> (raw)
In-Reply-To: <CABGGiswpz6k4rnXk-3SLpwD5V8+zah-yaaB+yrrLofKY1eBx2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 08/15/17 15:36, Rob Herring wrote:
> On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
>> With support for stacked overlays being part of libfdt it is now
< snip >
>> 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.
< snip >
I also agree that use of CONFIG options is a solution that I do not like.
It has always seemed that there is a bit of an impedence mismatch in that
we build a dtb in an environment that is configured for a specific board
and architecture.
Does anyone have any thoughts on another way to control whether or not a
given dtb or a given build of a dtb would contain the symbols needed for
overlays or not include the symbols?
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-08-16 0:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-15 21:15 [PATCH] devicetree: Enable generation of __symbols__ in all dtb files Tom Rini
2017-08-15 21:15 ` Tom Rini
2017-08-15 22:36 ` Rob Herring
2017-08-15 22:49 ` Tom Rini
2017-08-16 15:43 ` Rob Herring
2017-08-16 15:57 ` Tom Rini
2017-08-16 15:57 ` Tom Rini
2017-08-16 16:16 ` Rob Herring
2017-08-16 18:10 ` Frank Rowand
2017-08-16 18:10 ` Frank Rowand
2017-08-15 23:57 ` Frank Rowand
2017-08-15 23:59 ` Frank Rowand
2017-08-15 23:59 ` Frank Rowand
2017-08-16 9:42 ` Pantelis Antoniou
2017-08-16 9:42 ` Pantelis Antoniou
2017-08-16 17:55 ` Frank Rowand
2017-08-16 0:14 ` Frank Rowand [this message]
2017-08-16 0:14 ` Frank Rowand
2017-08-15 23:50 ` Frank Rowand
2017-08-16 0:42 ` Tom Rini
2017-08-16 0:42 ` Tom Rini
2017-08-16 3:22 ` Frank Rowand
2017-08-16 15:09 ` Tom Rini
2017-08-16 18:15 ` Frank Rowand
2017-08-16 15:22 ` Rob Herring
2017-08-16 15:41 ` Tom Rini
2017-08-16 16:00 ` Rob Herring
2017-08-16 16:00 ` Rob Herring
2017-08-16 0:18 ` Frank Rowand
2017-08-16 9:37 ` Pantelis Antoniou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59938E76.3010807@gmail.com \
--to=frowand.list@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.com \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=pantelis.antoniou@konsulko.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=t-kristo@ti.com \
--cc=tomi.valkeinen@ti.com \
--cc=trini@konsulko.com \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.