mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Brendan Higgins <brendanhiggins@google.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: Thu, 14 Feb 2019 18:48:35 -0800	[thread overview]
Message-ID: <bfa00740-9b67-58f9-6273-3de98de952f6@gmail.com> (raw)
In-Reply-To: <CAFd5g441+6ATUKcNz7OstAB6Qd2BqeDh77SNnGUpZGBNvgysmg@mail.gmail.com>

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

I think I need to find some time to build and boot a UML kernel soon.

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().

unittest_unflatten_overlay_base() is an unfortunate wart that I
added, but I don't have a better alternative yet.

-Frank

> 
> I used the following .config for these results:
> CONFIG_OF=y
> CONFIG_OF_UNITTEST=y
> CONFIG_OF_OVERLAY=y
> CONFIG_I2C=y
> CONFIG_I2C_MUX=y
> 
>>
>> Rob, if I am correct please revert this patch.
>>
> 
> Cheers
> 


  reply	other threads:[~2019-02-15  2:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12 18:53 [PATCH v1 0/1] " 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 [this message]
2019-02-15  9:49         ` Brendan Higgins
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=bfa00740-9b67-58f9-6273-3de98de952f6@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=brendanhiggins@google.com \
    --cc=devicetree@vger.kernel.org \
    --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

Powered by JetHome