public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
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.

  reply	other threads:[~2010-03-24 17:08 UTC|newest]

Thread overview: 46+ 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-24  6:07 ` Grant Likely
2010-03-24 12:05   ` Timur Tabi
2010-03-24 17:00     ` Segher Boessenkool
2010-03-24 17:07       ` Grant Likely [this message]
2010-03-24 17:31         ` Timur Tabi
2010-03-24 18:10           ` Grant Likely
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-25  1:49           ` Segher Boessenkool
2010-03-25 14:42             ` Timur Tabi
2010-03-25 16:10               ` Grant Likely
2010-03-25 16:34                 ` Scott Wood
2010-03-25 16:46                   ` Timur Tabi
2010-03-26 18:23                     ` Rafal Jaworowski
2010-03-25 23:53               ` M. Warner Losh
2010-03-26  0:22                 ` Timur Tabi
2010-03-25 15:16             ` Scott Wood
2010-03-25 15:29               ` Mitch Bradley
2010-03-25 16:16                 ` Grant Likely
2010-03-25 16:36                   ` Timur Tabi
2010-03-25 16:50                     ` Scott Wood
2010-03-25 16:59                     ` Grant Likely
2010-03-25 17:03                       ` Timur Tabi
2010-03-25 17:35                         ` Grant Likely
2010-03-25 18:05                           ` Timur Tabi
2010-03-25 19:53                           ` Scott Wood
2010-03-25 20:04                             ` Timur Tabi
2010-03-25 21:54                               ` Grant Likely
2010-03-25 22:19                                 ` Timur Tabi
2010-03-25 21:39                             ` Grant Likely
2010-03-25 22:47                               ` Scott Wood
2010-03-25 21:22                       ` David Gibson
2010-03-26  1:26                     ` Grant Likely
2010-03-26 15:17                       ` Timur Tabi
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:48                               ` Timur Tabi
2010-03-26 18:56                                 ` Grant Likely
2010-03-26 18:58                                 ` Mitch Bradley
2010-03-26 19:07                                   ` Grant Likely
2010-03-26 18:48                             ` Mitch Bradley
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$(echo .)ca \
    --cc=devicetree-discuss@lists$(echo .)ozlabs.org \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    --cc=segher@kernel$(echo .)crashing.org \
    --cc=timur@freescale$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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