From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: "François Ozog" <francois.ozog@linaro.org>
Cc: sjg@chromium.org, u-boot@lists.denx.de, trini@konsulko.com,
bmeng.cn@gmail.com, ilias.apalodimas@linaro.org,
bill.mills@linaro.org, xypron.glpk@gmx.de,
albert.u.boot@aribaud.net, vanbaren@cideas.com, marex@denx.de,
yamada.masahiro@socionext.com, morpheus.ibis@gmail.com,
qemu-devel@nongnu.org
Subject: Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Date: Mon, 1 Nov 2021 19:19:05 +0100 (CET) [thread overview]
Message-ID: <d3caa60fcbd1a482@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <CAHFG_=X1DeBFkzwFBkirMkmHB0_OSa9OkQj+CvpG6dT5HZEWBA@mail.gmail.com> (message from François Ozog on Mon, 1 Nov 2021 09:53:40 +0100)
> From: François Ozog <francois.ozog@linaro.org>
> Date: Mon, 1 Nov 2021 09:53:40 +0100
[...]
> We could further leverage Passage to pass Operating Systems parameters that
> could be removed from device tree (migration of /chosen to Passage). Memory
> inventory would still be in DT but allocations for CMA or GPUs would be in
> Passage. This idea is to reach a point where device tree is a "pristine"
> hardware description.
I wanted to react on something you said in an earlier thread, but this
discussion seems to be appropriate as well:
The notion that device trees only describe the hardware isn't really
correct. Device trees have always been used to configure firmware
options (through the /options node) and between firmware and the OS
(through the /chosen node) and to describe firmware interfaces
(e.g. OpenFirmware calls, PSCI (on ARM), RTAS (on POWER)). This was
the case on the original Open Firmware systems, and is still done on
PowerNV systems that use flattened device trees.
I don't see what the benefits are from using Passage instead. It
would only fragment things even more.
next prev parent reply other threads:[~2021-11-01 18:19 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 1:17 [PATCH 00/31] passage: Define a standard for firmware data flow Simon Glass
2021-11-01 1:17 ` [PATCH 01/31] Makefile: Correct TPL rule for OF_REAL Simon Glass
2021-11-01 6:54 ` Ilias Apalodimas
2021-11-14 0:34 ` Simon Glass
2021-11-01 1:17 ` [PATCH 02/31] kconfig: Add support for conditional values Simon Glass
2021-11-01 7:05 ` Ilias Apalodimas
2022-01-12 21:28 ` Simon Glass
2022-01-12 21:56 ` Tom Rini
2022-01-12 22:22 ` Simon Glass
2022-01-12 23:04 ` Tom Rini
2022-01-13 7:56 ` Rasmus Villemoes
2022-01-13 12:52 ` Tom Rini
2022-01-13 13:56 ` Simon Glass
2022-01-13 15:01 ` Rasmus Villemoes
2022-01-13 15:29 ` Tom Rini
2021-11-01 1:17 ` [PATCH 03/31] dm: core: Allow getting some basic stats Simon Glass
2021-11-01 7:07 ` Ilias Apalodimas
2021-11-01 1:17 ` [PATCH 04/31] stddef: Avoid warning with clang with offsetof() Simon Glass
2022-01-13 8:08 ` Rasmus Villemoes
2022-01-13 13:07 ` Tom Rini
2022-01-13 13:37 ` Simon Glass
2022-01-13 13:41 ` Tom Rini
2022-01-13 13:50 ` Simon Glass
2021-11-01 1:17 ` [PATCH 05/31] fdt: Drop SPL_BUILD macro Simon Glass
2021-11-01 7:42 ` Ilias Apalodimas
2021-11-01 1:17 ` [PATCH 06/31] bloblist: Put the magic number first Simon Glass
2021-11-01 1:17 ` [PATCH 07/31] bloblist: Rename the SPL tag Simon Glass
2021-11-01 1:17 ` [PATCH 08/31] bloblist: Drop unused tags Simon Glass
2021-11-01 1:17 ` [PATCH 09/31] bloblist: Use explicit numbering for the tags Simon Glass
2021-11-01 1:17 ` [PATCH 10/31] bloblist: Support allocating the bloblist Simon Glass
2021-11-01 1:17 ` [PATCH 11/31] bloblist: Use LOG_CATEGORY to simply logging Simon Glass
2021-11-01 1:17 ` [PATCH 12/31] bloblist: Use 'phase' consistently for bloblists Simon Glass
2021-11-01 1:17 ` [PATCH 13/31] bloblist: Refactor Kconfig to support alloc or fixed Simon Glass
2021-11-01 1:17 ` [PATCH 14/31] arm: qemu: Add an SPL build Simon Glass
2021-11-01 1:17 ` [PATCH 15/31] bloblist: Add functions to obtain base address and size Simon Glass
2021-11-01 1:17 ` [PATCH 16/31] passage: Support an incoming passage Simon Glass
2021-11-01 1:17 ` [PATCH 17/31] passage: Support a control devicetree Simon Glass
2021-11-01 1:17 ` [PATCH 18/31] passage: arm: Accept a passage from the previous phase Simon Glass
2021-11-01 1:17 ` [PATCH 19/31] passage: spl: Support adding the dtb to the passage bloblist Simon Glass
2021-11-01 1:17 ` [PATCH 20/31] passage: spl: Support passing the passage to U-Boot Simon Glass
2021-11-01 1:17 ` [PATCH 21/31] passage: Record where the devicetree came from Simon Glass
2021-11-01 1:17 ` [PATCH 22/31] passage: Report the devicetree source Simon Glass
2021-11-01 1:17 ` [PATCH 23/31] passage: Add a qemu test for ARM Simon Glass
2021-11-01 1:17 ` [PATCH 24/31] bloblist: doc: Bring in the API documentation Simon Glass
2021-11-01 1:17 ` [PATCH 25/31] bloblist: Relicense to allow BSD-3-Clause Simon Glass
2021-11-01 1:17 ` [PATCH 26/31] sandbox: Add a way of checking structs for standard passage Simon Glass
2021-11-01 1:17 ` [PATCH 27/31] passage: Add documentation Simon Glass
2021-11-01 1:17 ` [PATCH 28/31] passage: Add docs for spl_handoff Simon Glass
2021-11-01 1:17 ` [PATCH 29/31] x86: Move Intel GNVS file into the common include directory Simon Glass
2021-11-01 1:17 ` [PATCH 30/31] passage: Add checks for pre-existing blobs Simon Glass
2021-11-01 1:17 ` [PATCH 31/31] WIP: RFC: Add a gitlab test Simon Glass
2021-11-01 8:53 ` [PATCH 00/31] passage: Define a standard for firmware data flow François Ozog
2021-11-01 18:19 ` Mark Kettenis [this message]
2021-11-01 20:45 ` François Ozog
2021-11-02 14:58 ` Simon Glass
2021-11-02 16:03 ` François Ozog
2021-11-05 2:02 ` Simon Glass
2021-11-05 8:26 ` François Ozog
2021-11-05 16:12 ` Simon Glass
2021-11-05 16:31 ` François Ozog
2021-11-05 17:16 ` Simon Glass
2021-11-08 16:20 ` François Ozog
2021-11-10 19:37 ` Simon Glass
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=d3caa60fcbd1a482@bloch.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=albert.u.boot@aribaud.net \
--cc=bill.mills@linaro.org \
--cc=bmeng.cn@gmail.com \
--cc=francois.ozog@linaro.org \
--cc=ilias.apalodimas@linaro.org \
--cc=marex@denx.de \
--cc=morpheus.ibis@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=vanbaren@cideas.com \
--cc=xypron.glpk@gmx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox