From: Brendan Higgins <brendanhiggins@google.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 1/1] of: unittest: unflatten device tree on UML when testing
Date: Fri, 15 Feb 2019 01:49:45 -0800 [thread overview]
Message-ID: <CAFd5g44HkBLJmK8e4F+iaGPg1FEzubGtcUW-251GAOv1UmE5rg@mail.gmail.com> (raw)
In-Reply-To: <bfa00740-9b67-58f9-6273-3de98de952f6@gmail.com>
On Thu, Feb 14, 2019 at 6:48 PM Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 2/14/19 5:26 PM, Brendan Higgins wrote:
> > On Thu, Feb 14, 2019 at 4:10 PM Frank Rowand <frowand.list@gmail.com> wrote:
> >>
> >> On 2/12/19 10:53 AM, Brendan Higgins wrote:
> >>> UML supports enabling OF, and is useful for running the device tree
> >>> tests, so add support for unflattening device tree blobs so we can
> >>> actually use it.
> >>>
> >>> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> >>> ---
> >>> drivers/of/unittest.c | 3 +++
> >>> 1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> >>> index 84427384654d5..effa4e2b9d992 100644
> >>> --- a/drivers/of/unittest.c
> >>> +++ b/drivers/of/unittest.c
> >>> @@ -2527,6 +2527,9 @@ static int __init of_unittest(void)
> >>> }
> >>> of_node_put(np);
> >>>
> >>> + if (IS_ENABLED(CONFIG_UML))
> >>> + unflatten_device_tree();
> >>> +
> >>> pr_info("start of unittest - you will see error messages\n");
> >>> of_unittest_check_tree_linkage();
> >>> of_unittest_check_phandles();
> >>>
> >>
> >> (Insert my usual disclaimer that I am clueless about UML, I still need to learn
> >> about it...)
> >>
> >> This does not look correct to me.
> >>
> >> A few lines earlier in of_unittest(), the live devicetree needs to exist for
> >> unittest_data_data() and a few of_*() functions to succeed. So it seems
> >> that the unflatten_device_tree() for uml should be at the beginning of
> >> of_unittest().
> >
> > It is true that other functions ahead of it depend on the presence of
> > a device tree, but an unflattened tree does get linked in somewhere
> > else. Despite that, this is needed for overlay_base_root. I got
> > similar behavior if you don't link in a flattened device tree on x86.
> > Thus, the order in which you call them doesn't actually seem to
> > matter. I found no difference from changing the order in UML myself.
> >
> > Without my patch we get the following error,
> > ### dt-test ### FAIL of_unittest_overlay_high_level():2372
> > overlay_base_root not initialized
> > ### dt-test ### end of unittest - 219 passed, 1 failed
> >
> > With my patch we get:
> > ### dt-test ### end of unittest - 224 passed, 0 failed
>
> Thanks for reporting both the failure and the success cases,
> that helps me understand a little bit better.
>
> If instead of the above patch, if you add the following (untested,
> not even compile tested) to the beginning of of_unittest():
>
> if (IS_ENABLED(CONFIG_UML))
> unittest_unflatten_overlay_base();
>
> does that also result in a good test result of:
>
> ### dt-test ### end of unittest - 224 passed, 0 failed
Yep, I just tried it. It works as you suspected.
>
> I think I need to find some time to build and boot a UML kernel soon.
It's really no big deal, just copy the .config I sent and build with
`make ARCH=um` then you "boot" the kernel with `./linux` (note this
will mess up your terminal settings); that's it! (Shameless plug: you
can also try it out with the KUnit patchset with
`./tools/testing/kunit/kunit.py --timeout=30 --jobs=12 --defconfig`,
which builds the kernel with a pretty similar config, boots the
kernel, and then parses the output for you. ;-) )
>
> My current _guess_ is that the original problem was not a failure to
> unflatten any present devicetree in UML but instead that the UML
> kernel does not call unflatten_device_tree() and thus fails to
> indirectly call unittest_unflatten_overlay_base(), which is
> called by unflatten_device_tree().
I think you are right. Sorry for not noticing this before making my
change. Since it was pretty much the only architecture (the only one I
care about) that does not unflatten DT, I assumed that was the
problem. I didn't put too much thought into it after that point beyond
making sure that it did what I wanted.
>
> unittest_unflatten_overlay_base() is an unfortunate wart that I
> added, but I don't have a better alternative yet.
Hey, I get it. No worries.
In any case, it seems like unittest_unflatten_overlay_base() is the
right function to call there. I will send out patch. Do you want me to
send a patch on top of this one, or do you want to revert this one and
for me to send a v2 follow up to this patch? I don't care either way,
whatever you guys prefer.
Cheers
next prev parent reply other threads:[~2019-02-15 9:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 18:53 [PATCH v1 0/1] of: unittest: unflatten device tree on UML when testing Brendan Higgins
2019-02-12 18:53 ` [PATCH v1 1/1] " Brendan Higgins
2019-02-13 19:12 ` Rob Herring
2019-02-15 0:10 ` Frank Rowand
2019-02-15 1:26 ` Brendan Higgins
2019-02-15 2:48 ` Frank Rowand
2019-02-15 9:49 ` Brendan Higgins [this message]
2019-02-15 19:44 ` Rob Herring
2019-02-15 23:06 ` Frank Rowand
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=CAFd5g44HkBLJmK8e4F+iaGPg1FEzubGtcUW-251GAOv1UmE5rg@mail.gmail.com \
--to=brendanhiggins@google.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=robh+dt@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).