[PATCH 0/8] clk: Add kunit tests for fixed rate and parent data

[Stephen Boyd]

Quoting Frank Rowand (2023-03-04 07:04:48)
> On 3/2/23 13:27, Stephen Boyd wrote:
> > 
> > But perhaps this design is too much of an end-to-end test and not a unit
> > test? In the spirit of unit testing we shouldn't care about how the node
> > is added to the live devicetree, just that there is a devicetree at all.
> > 
> > Supporting overlays to more easily test combinations sounds like a good
> > idea. Probably some kunit_*() prefixed functions could be used to
> 
> In an imaginary world where overlay support was completed, then _maybe_.
> 
> To me, the most important  environment to test is where the devictree
> data is populated in early boot from an FDT.  This is the environment
> that drivers currently exist in.
> 
> Populating devicetree data via an overlay adds in the functioning of the
> overlay apply code (and how the rules behind that functioning may differ
> from devicetree data populated in early boot from an FDT).

For the purposes of clk unit tests I don't care where the devicetree
nodes come from. All I care about is that they're rooted in the live
devicetree for the system and that they have platform devices attached
to them. The clk unit tests will assert that the overlay has been
applied and that should be sufficient to make sure the tests has
satisfied pre-conditions.

If these were end-to-end tests then I would agree that making the nodes
be loaded during early boot from an FDT would be the right approach.
That would test the integration of early DTB loading and code that runs
on the FDT. These aren't integration tests though, so when the nodes are
created and unflattened doesn't matter.

I'll introduce various unit tests around the kunit specific overlay
application API so that I know it makes platform devices and they have
device nodes attached to them. And those same tests should be able to
confirm that devices are destroyed when the overlay is removed.