On Wed, Aug 15, 2018 at 09:31:30AM -0600, Rob Herring wrote:
> On Wed, Aug 15, 2018 at 8:51 AM Michal Simek <michal.simek@xxxxxxxxxx> wrote:
> >
> > Hi Rob,
> >
> > On 15.8.2018 16:34, Tom Rini wrote:
> > > On Wed, Aug 15, 2018 at 04:30:15PM +0200, Michal Simek wrote:
> > >> On 15.8.2018 16:17, Tom Rini wrote:
> > >>> On Mon, Aug 13, 2018 at 05:53:38PM +0200, Jens Wiklander wrote:
> > >>>
> > >>>> Just as /chosen may contain devices /firmware may contain devices, scan
> > >>>> for devices under /firmware too.
> > >>>>
> > >>>> Signed-off-by: Jens Wiklander <jens.wiklander@xxxxxxxxxx>
> > >>>> ---
> > >>>> drivers/core/root.c | 15 ++++++++++-----
> > >>>> 1 file changed, 10 insertions(+), 5 deletions(-)
> > >>>>
> > >>>> diff --git a/drivers/core/root.c b/drivers/core/root.c
> > >>>> index 72bcc7d7f2a3..0dca507e1187 100644
> > >>>> --- a/drivers/core/root.c
> > >>>> +++ b/drivers/core/root.c
> > >>>> @@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, const void *blob,
> > >>>> for (offset = fdt_first_subnode(blob, offset);
> > >>>> offset > 0;
> > >>>> offset = fdt_next_subnode(blob, offset)) {
> > >>>> - /* "chosen" node isn't a device itself but may contain some: */
> > >>>> - if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
> > >>>> - pr_debug("parsing subnodes of \"chosen\"\n");
> > >>>> + const char *node_name = fdt_get_name(blob, offset, NULL);
> > >>>> +
> > >>>> + /*
> > >>>> + * The "chosen" and "firmware" nodes aren't devices
> > >>>> + * themselves but may contain some:
> > >>>> + */
> > >>>> + if (!strcmp(node_name, "chosen") ||
> > >>>> + !strcmp(node_name, "firmware")) {
> > >>>> + pr_debug("parsing subnodes of \"%s\"\n", node_name);
> > >>>>
> > >>>> err = dm_scan_fdt_node(parent, blob, offset,
> > >>>> pre_reloc_only);
> > >>>
> > >>> So, the /firmware node seems special. Have you talked with the
> > >>> devicetree folks to get it listed in the spec? That would seem rather
> > >>> valuable for something used by many parties. Thanks!
> > >>>
> > >>
> > >> some days ago we have sent a patch for this too.
> > >> https://lists.denx.de/pipermail/u-boot/2018-August/338049.html
> > >>
> > >> It is using different way but it should do the same thing.
> > >
> > > OK, so it sounds like in terms of code clean-ups, we need something like
> > > what you reference and then some further clean-ups on top of that
> > > perhaps for other places to call dm_scan_fdt_ofnode_path() for special
> > > cases. And in terms of formalized specification bits, I do think
> > > /firmware should perhaps get kicked up to the spec itself so that it's
> > > very clear to all consumers.
> >
> > I was also checking latest devicetree spec and there is no record about
> > /firmware node and how it is supposed to be used.
>
> Patches welcome. :)
>
> It's really only a container to define non-discoverable firmware
> interfaces. Typically accessed thru a secure call (for ARM) or a
> mailbox. It is primarily just convention rather than a strict
> requirement. We have to support firmware nodes at the top-level too
> anyways.
Right. To be clear, I'm suggesting that someone (I was thinking Jens)
pop over to the devicetree-spec list and ask about adding _something_
there as "firmware" isn't even on the list of generic names and may even
warrant something in section 3 under base device node types.
--
Tom
Attachment:
signature.asc
Description: PGP signature
