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

[Frank Rowand]

On 3/2/23 11:32, Rob Herring wrote:
> On Thu, Mar 2, 2023 at 2:14 AM David Gow <davidgow at google.com> wrote:
>>
>> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd at kernel.org> wrote:
>>>
>>> This patch series adds unit tests for the clk fixed rate basic type and
>>> the clk registration functions that use struct clk_parent_data. To get
>>> there, we add support for loading a DTB into the UML kernel that's
>>> running the unit tests along with probing platform drivers to bind to
>>> device nodes specified in DT.
>>>
>>> With this series, we're able to exercise some of the code in the common
>>> clk framework that uses devicetree lookups to find parents and the fixed
>>> rate clk code that scans devicetree directly and creates clks. Please
>>> review.
>>>
>>
>> Thanks Stephen -- this is really neat!
>>
>> This works well here, and I love all of the tests for the
>> KUnit/device-tree integration as well.
>>
>> I'm still looking through the details of it (alas, I've mostly lived
>> in x86-land, so my device-tree knowledge is, uh, spotty to say the
>> least), but apart from possibly renaming some things or similarly
>> minor tweaks, I've not got any real suggestions thus far.
>>
>> I do wonder whether we'll want, on the KUnit side, to have some way of
>> supporting KUnit device trees on non-UML architecctures (e.g., if we
>> need to test something architecture-specific, or on a big-endian
>> platform, etc), but I think that's a question for the future, rather
>> than something that affects this series.
> 
> I'll say that's a requirement. We should be able to structure the
> tests to not interfere with the running system's DT. The DT unittest
> does that.
> 
> As a side topic, Is anyone looking at getting UML to work on arm64?
> It's surprising how much x86 stuff there is which is I guess one
> reason it hasn't happened.
> 
>> Similarly, I wonder if there's something we could do with device tree
>> overlays, in order to make it possible for tests to swap nodes in and
>> out for testing.
> 
> Yes, that's how the DT unittest works. But it is pretty much one big
> overlay (ignoring the overlay tests). It could probably be more
> modular where it is apply overlay, test, remove overlay, repeat.

Actually, no, the bulk of the DT unittest devicetree data is _not_ an
overlay.  It is an FDT that is loaded via of_fdt_unflatten_tree() instead
of the overlay load API.  Note that the base DT unittest runs with
  CONFIG_OF_DYNAMIC=n
  CONFIG_OF_OVERLAY=n
so the overlay support code is not even present in the built kernel.

One can then enable CONFIG_OF_DYNAMIC to test the dynamic code.

One can further enable CONFIG_OF_OVERLAY to test the overlay code
(this will in turn select CONFIG_OF_DYNAMIC if not already enabled).

I would strongly discourage use of the overlay APIs for kunit tests,
unless the point of the kunit test is to test the overlay API.  Basic
tests should always be performed with devicetree data that has been
populated by the normal processing of an FDT during early boot.  If
one want to test proper overlay infrastructure functionality, then
those (essentially) same basic tests could/should be repeated with
devicetree data that has been populated by loading an overlay.

> 
> Rob