On Fri, 10 Mar 2023 at 07:19, Stephen Boyd sboyd@kernel.org wrote:

Quoting David Gow (2023-03-02 23:15:04)

...

On Thu, 2 Mar 2023 at 09:38, Stephen Boyd sboyd@kernel.org wrote:

...

To fully exercise common clk framework code in KUnit we need to associate 'struct device' pointers with 'struct device_node' pointers so that things like clk_get() can parse DT nodes for 'clocks' and so that clk providers can use DT to provide clks; the most common mode of operation for clk providers.

Adding support to KUnit so that it loads a DTB is fairly simple after commit b31297f04e86 ("um: Add devicetree support"). We can simply pass a pre-compiled deviectree blob (DTB) on the kunit.py commandline and UML will load it. The problem is that tests won't know that the commandline has been modified, nor that a DTB has been loaded. Take a different approach so that tests can skip if a DTB hasn't been loaded.

Reuse the Makefile logic from the OF unittests to build a DTB into the kernel. This DTB will be for the mythical machine "linux,kunit", i.e. the devicetree for the KUnit "board". In practice, it is a dtsi file that will gather includes for kunit tests that rely in part on a devicetree being loaded. The devicetree should only be loaded if CONFIG_OF_KUNIT=y. Make that a choice config parallel to the existing CONFIG_OF_UNITTEST so that only one devicetree can be loaded in the system at a time. Similarly, the kernel commandline option to load a DTB is ignored if CONFIG_OF_KUNIT is enabled so that only one DTB is loaded at a time.

This feels a little bit like it's just papering over the real problem, which is that there's no way tests can skip themselves if no DTB is loaded.

Hmm. I think you're suggesting that the unit test data be loaded whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for CONFIG_OF and skip if it isn't enabled?

More of the opposite: that we should have some way of supporting tests which might want to use a DTB other than the built-in one. Mostly for non-UML situations where an actual devicetree is needed to even boot far enough to get test output (so we wouldn't be able to override it with a compiled-in test one).

I think moving to overlays probably will render this idea obsolete: but the thought was to give test code a way to check for the required devicetree nodes at runtime, and skip the test if they weren't found. That way, the failure mode for trying to boot this on something which required another device tree for, e.g., serial, would be "these tests are skipped because the wrong device tree is loaded", not "I get no output because serial isn't working".

Again, though, it's only really needed for non-UML, and just loading overlays as needed should be much more sensible anyway.

...

That being said, I do think that there's probably some sense in supporting the compiled-in DTB as well (it's definitely simpler than patching kunit.py to always pass the extra command-line option in, for example). But maybe it'd be nice to have the command-line option override the built-in one if present.

Got it. I need to test loading another DTB on the commandline still, but I think this won't be a problem. We'll load the unittest-data DTB even with KUnit on UML, so assuming that works on UML right now it should be unchanged by this series once I resend.

Again, moving to overlays should render this mostly obsolete, no? Or am I misunderstanding how the overlay stuff will work?

One possible future advantage of being able to test with custom DTs at boot time would be for fuzzing (provide random DT properties, see what happens in the test). We've got some vague plans to support a way of passing custom data to tests to support this kind of case (though, if we're using overlays, maybe the test could just patch those if we wanted to do that).

Cheers, -- David