From: Grant Likely <grant.likely@secretlab.ca>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
Timur Tabi <timur@freescale.com>
Subject: Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Date: Wed, 24 Mar 2010 11:07:42 -0600 [thread overview]
Message-ID: <fa686aa41003241007mf6052d5s4643795f4a87cdcf@mail.gmail.com> (raw)
In-Reply-To: <90D93687-940F-47FB-8CEA-F3C065EA611D@kernel.crashing.org>
On Wed, Mar 24, 2010 at 11:00 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>>> Why the phandle redirection? =A0Why not just put the firmware blob into
>>> a property in the QE node, or as a subnode?
>>
>> Because there might be multiple QE devices on a single chip, and each
>> will need to upload the same firmware. =A0So instead of embedding the
>> firmware multiple times, just embed it once, and have a pointer.
>
> You're messing up the binding because of a (perceived) deficiency in
> the DTB format? =A0Or maybe just the DTS format. =A0Or maybe you shouldn'=
t
> even care about size here. =A0Or really, the device tree is the wrong
> place to store firmware blobs at all.
That is a good question. Why is it necessary to pass the blob via the
tree? So far we've avoided using firmware blobs in the flat trees.
Or to ask in other words; what is the use case that requires passing
via the device tree?
Also, depending on firmware to correctly squirt the firmware blob into
the dtb at boot is risky. Even when firmware is buggy, there is
resistance to upgrading firmware on working boards because it could
result in a bricked board. In fact, every time we depend on firmware
to modify the dtb at boot is risky, so it should only be done when
strictly necessary (I would even say that to date we've probably been
rather too liberal about getting u-boot to modify the device tree).
I would say that either the firmware should be loaded via the existing
(non-dt) firmware loading mechanism, or it should be built into the
static dtb blob. Don't try to add it at runtime.
g.
WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
Timur Tabi <timur@freescale.com>
Subject: Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Date: Wed, 24 Mar 2010 11:07:42 -0600 [thread overview]
Message-ID: <fa686aa41003241007mf6052d5s4643795f4a87cdcf@mail.gmail.com> (raw)
In-Reply-To: <90D93687-940F-47FB-8CEA-F3C065EA611D@kernel.crashing.org>
On Wed, Mar 24, 2010 at 11:00 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>>> Why the phandle redirection? Why not just put the firmware blob into
>>> a property in the QE node, or as a subnode?
>>
>> Because there might be multiple QE devices on a single chip, and each
>> will need to upload the same firmware. So instead of embedding the
>> firmware multiple times, just embed it once, and have a pointer.
>
> You're messing up the binding because of a (perceived) deficiency in
> the DTB format? Or maybe just the DTS format. Or maybe you shouldn't
> even care about size here. Or really, the device tree is the wrong
> place to store firmware blobs at all.
That is a good question. Why is it necessary to pass the blob via the
tree? So far we've avoided using firmware blobs in the flat trees.
Or to ask in other words; what is the use case that requires passing
via the device tree?
Also, depending on firmware to correctly squirt the firmware blob into
the dtb at boot is risky. Even when firmware is buggy, there is
resistance to upgrading firmware on working boards because it could
result in a bricked board. In fact, every time we depend on firmware
to modify the dtb at boot is risky, so it should only be done when
strictly necessary (I would even say that to date we've probably been
rather too liberal about getting u-boot to modify the device tree).
I would say that either the firmware should be loaded via the existing
(non-dt) firmware loading mechanism, or it should be built into the
static dtb blob. Don't try to add it at runtime.
g.
next prev parent reply other threads:[~2010-03-24 17:08 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 21:42 [PATCH] powerpc/fsl: add device tree binding for QE firmware Timur Tabi
2010-03-23 21:42 ` Timur Tabi
2010-03-24 6:07 ` Grant Likely
2010-03-24 6:07 ` Grant Likely
2010-03-24 12:05 ` Timur Tabi
2010-03-24 12:05 ` Timur Tabi
2010-03-24 17:00 ` Segher Boessenkool
2010-03-24 17:00 ` Segher Boessenkool
2010-03-24 17:07 ` Grant Likely [this message]
2010-03-24 17:07 ` Grant Likely
2010-03-24 17:31 ` Timur Tabi
2010-03-24 17:31 ` Timur Tabi
2010-03-24 18:10 ` Grant Likely
2010-03-24 18:10 ` Grant Likely
2010-03-24 18:21 ` Mitch Bradley
2010-03-24 18:21 ` Mitch Bradley
2010-03-24 18:25 ` Timur Tabi
2010-03-24 18:24 ` M. Warner Losh
2010-03-24 18:31 ` Timur Tabi
2010-03-24 18:31 ` Timur Tabi
2010-03-25 1:49 ` Segher Boessenkool
2010-03-25 1:49 ` Segher Boessenkool
2010-03-25 14:42 ` Timur Tabi
2010-03-25 14:42 ` Timur Tabi
2010-03-25 16:10 ` Grant Likely
2010-03-25 16:10 ` Grant Likely
2010-03-25 16:34 ` Scott Wood
2010-03-25 16:34 ` Scott Wood
2010-03-25 16:46 ` Timur Tabi
2010-03-25 16:46 ` Timur Tabi
2010-03-26 18:23 ` Rafal Jaworowski
2010-03-26 18:23 ` Rafal Jaworowski
2010-03-25 23:53 ` M. Warner Losh
2010-03-25 23:53 ` M. Warner Losh
2010-03-26 0:22 ` Timur Tabi
2010-03-26 0:22 ` Timur Tabi
2010-03-25 15:16 ` Scott Wood
2010-03-25 15:16 ` Scott Wood
2010-03-25 15:29 ` Mitch Bradley
2010-03-25 15:29 ` Mitch Bradley
2010-03-25 16:16 ` Grant Likely
2010-03-25 16:16 ` Grant Likely
2010-03-25 16:36 ` Timur Tabi
2010-03-25 16:36 ` Timur Tabi
2010-03-25 16:50 ` Scott Wood
2010-03-25 16:50 ` Scott Wood
2010-03-25 16:59 ` Grant Likely
2010-03-25 16:59 ` Grant Likely
2010-03-25 17:03 ` Timur Tabi
2010-03-25 17:35 ` Grant Likely
2010-03-25 17:35 ` Grant Likely
2010-03-25 18:05 ` Timur Tabi
2010-03-25 19:53 ` Scott Wood
2010-03-25 19:53 ` Scott Wood
2010-03-25 20:04 ` Timur Tabi
2010-03-25 21:54 ` Grant Likely
2010-03-25 21:54 ` Grant Likely
2010-03-25 22:19 ` Timur Tabi
2010-03-25 22:19 ` Timur Tabi
2010-03-25 21:39 ` Grant Likely
2010-03-25 21:39 ` Grant Likely
2010-03-25 22:47 ` Scott Wood
2010-03-25 22:47 ` Scott Wood
2010-03-25 21:22 ` David Gibson
2010-03-25 21:22 ` David Gibson
2010-03-26 1:26 ` Grant Likely
2010-03-26 1:26 ` Grant Likely
2010-03-26 15:17 ` Timur Tabi
2010-03-26 15:17 ` Timur Tabi
2010-03-26 18:20 ` Grant Likely
2010-03-26 18:20 ` Grant Likely
2010-03-26 18:39 ` Timur Tabi
2010-03-26 18:44 ` Grant Likely
2010-03-26 18:44 ` Grant Likely
2010-03-26 18:48 ` Timur Tabi
2010-03-26 18:48 ` Timur Tabi
2010-03-26 18:56 ` Grant Likely
2010-03-26 18:56 ` Grant Likely
2010-03-26 18:58 ` Mitch Bradley
2010-03-26 18:58 ` Mitch Bradley
2010-03-26 19:07 ` Grant Likely
2010-03-26 19:07 ` Grant Likely
2010-03-26 18:48 ` Mitch Bradley
2010-03-26 18:48 ` Mitch Bradley
2010-03-24 18:27 ` Scott Wood
2010-03-24 18:27 ` Scott Wood
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=fa686aa41003241007mf6052d5s4643795f4a87cdcf@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=segher@kernel.crashing.org \
--cc=timur@freescale.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.