From: Frank Rowand <frowand.list@gmail.com>
To: Rob Herring <robh+dt@kernel.org>, Stephen Boyd <sboyd@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
patches@lists.linux.dev,
Brendan Higgins <brendan.higgins@linux.dev>,
David Gow <davidgow@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>,
Vincent Whitchurch <vincent.whitchurch@axis.com>,
Christian Marangi <ansuelsmth@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
devicetree@vger.kernel.org, linux-um@lists.infradead.org,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com
Subject: Re: [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data
Date: Sat, 4 Mar 2023 09:37:58 -0600 [thread overview]
Message-ID: <0dcf26a8-7d33-37cf-8365-2428ecd6d7cf@gmail.com> (raw)
In-Reply-To: <CAL_JsqLdPWRLu8TNqCG+dw9Pz2cS798QwGX=C5X18KKqAXwjSQ@mail.gmail.com>
On 3/2/23 14:18, Rob Herring wrote:
> On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd@kernel.org> wrote:
>>
>> Quoting Rob Herring (2023-03-02 09:13:59)
>>> On Wed, Mar 1, 2023 at 7:38 PM Stephen Boyd <sboyd@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.
>>>>
>>>> I Cced everyone to all the patches so they get the full context. I'm
>>>> hoping I can take the whole pile through the clk tree as they almost all
>>>> depend on each other. In the future I imagine it will be easy to add
>>>> more test nodes to the clk.dtsi file and not need to go across various
>>>> maintainer trees like this series does.
>>>>
>>>> Stephen Boyd (8):
>>>> dt-bindings: Add linux,kunit binding
>>>> of: Enable DTB loading on UML for KUnit tests
>>>> kunit: Add test managed platform_device/driver APIs
>>>> clk: Add test managed clk provider/consumer APIs
>>>> dt-bindings: kunit: Add fixed rate clk consumer test
>>>> clk: Add KUnit tests for clk fixed rate basic type
>>>> dt-bindings: clk: Add KUnit clk_parent_data test
>>>> clk: Add KUnit tests for clks registered with struct clk_parent_data
>>>
>>> Good to see bindings for this. I've been meaning to do something about
>>> the DT unittest ones being undocumented, but I hadn't really decided
>>> whether it was worth writing schemas for them. The compatibles at
>>> least show up with 'make dt_compatible_check'. Perhaps we want to just
>>> define some vendor (not 'linux') that's an exception rather than
>>> requiring schemas (actually, that already works for 'foo').
>>
>> Sure. Maybe "kunit" should be the vendor prefix? Or "dtbunit"?
>
> We'd want to use the same thing on the DT unittests or anything else
> potentially. How about just 'test'?
>
>>> It's
>>> likely that we want test DTs that fail normal checks and schemas get
>>> in the way of that as we don't have a way to turn off checks.
>>
>> Having the schemas is nice to make sure tests that are expecting some
>> binding are actually getting that. But supporting broken bindings is
>> also important to test any error paths in functions that parse
>> properties. Maybe we keep the schema and have it enforce that incorrect
>> properties are being set?
>
> I wasn't suggesting throwing them out. More why I hadn't written any I guess.
>
>> Do we really need to test incorrect bindings? Doesn't the
>> dt_bindings_check catch these problems so we don't have to write DTB
>> verifiers in the kernel?
>
> Fair enough. Using my frequently stated position against me. :)
>
> I do have a secret plan to implement (debug) type checks into the
> of_property_* APIs by extracting the type information from schemas
> into C.
>
>
>>> We already have GPIO tests in the DT unittests, so why is clocks
>>> different? Or should the GPIO tests be moved out (yes, please!)?
>>
>> Ah I didn't notice the GPIO tests in there. There are i2c tests too,
>> right? All I can say is clks are using kunit, that's the difference ;-)
>
> Yeah, they should perhaps all move to the subsystems.
>
>>> What happens when/if the DT unittest is converted to kunit? I think
>>> that would look confusing from the naming. My initial thought is
>>> 'kunit' should be dropped from the naming of a lot of this. Note that
>>> the original kunit submission converted the DT unittests. I would
>>> still like to see that happen. Frank disagreed over what's a unit test
>>> or not, then agreed, then didn't... I don't really care. If there's a
>>> framework to use, then we should use it IMO.
>>
>> Honestly I don't want to get involved in migrating the existing DT
>> unittest code to kunit. I'm aware that it was attempted years ago when
>> kunit was introduced. Maybe if the overlay route works well enough I can
>> completely sidestep introducing any code in drivers/of/ besides some
>> kunit wrappers for this. I'll cross my fingers!
>
> Yeah, I wasn't expecting you to. I just want to make sure this meshes
> with any future conversion to kunit.
>
> There's also some plans to always populate the DT root node if not
> present. That may help here. Or not. There's been a few versions
> posted with Frank's in the last week or 2.
As noted in that thread, by code inspection (not actual testing) I
think that the patch series breaks DT unittest for UML. It should be
a trivial change in the next patch version to fix.
>
> Rob
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2023-03-04 15:38 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 1:38 [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data Stephen Boyd
2023-03-02 1:38 ` [PATCH 1/8] dt-bindings: Add linux,kunit binding Stephen Boyd
2023-03-03 7:14 ` David Gow
2023-03-03 7:49 ` Geert Uytterhoeven
2023-03-09 23:12 ` Stephen Boyd
2023-03-10 7:55 ` David Gow
2023-03-02 1:38 ` [PATCH 2/8] of: Enable DTB loading on UML for KUnit tests Stephen Boyd
2023-03-03 7:15 ` David Gow
2023-03-09 23:19 ` Stephen Boyd
2023-03-10 8:09 ` David Gow
2023-03-10 23:34 ` Stephen Boyd
2023-03-11 6:42 ` David Gow
2023-03-13 16:02 ` Frank Rowand
2023-03-14 4:28 ` Frank Rowand
2023-03-15 7:04 ` David Gow
2023-03-15 21:35 ` Frank Rowand
2023-03-16 0:45 ` Frank Rowand
2023-03-16 4:15 ` David Gow
2023-03-21 20:56 ` Stephen Boyd
2023-03-08 19:46 ` Rob Herring
2023-03-02 1:38 ` [PATCH 3/8] kunit: Add test managed platform_device/driver APIs Stephen Boyd
2023-03-03 7:15 ` David Gow
2023-03-03 14:35 ` Maxime Ripard
2023-03-09 23:31 ` Stephen Boyd
2023-03-15 8:27 ` Maxime Ripard
2023-03-09 23:25 ` Stephen Boyd
2023-03-10 8:19 ` David Gow
2023-03-02 1:38 ` [PATCH 4/8] clk: Add test managed clk provider/consumer APIs Stephen Boyd
2023-03-03 7:15 ` David Gow
2023-03-10 23:21 ` Stephen Boyd
2023-03-11 6:32 ` David Gow
2023-03-21 14:32 ` Maxime Ripard
2023-03-02 1:38 ` [PATCH 5/8] dt-bindings: kunit: Add fixed rate clk consumer test Stephen Boyd
2023-03-02 1:38 ` [PATCH 6/8] clk: Add KUnit tests for clk fixed rate basic type Stephen Boyd
2023-03-02 1:38 ` [PATCH 7/8] dt-bindings: clk: Add KUnit clk_parent_data test Stephen Boyd
2023-03-02 1:38 ` [PATCH 8/8] clk: Add KUnit tests for clks registered with struct clk_parent_data Stephen Boyd
2023-03-02 8:13 ` [PATCH 0/8] clk: Add kunit tests for fixed rate and parent data David Gow
2023-03-02 17:32 ` Rob Herring
2023-03-02 19:27 ` Stephen Boyd
2023-03-02 19:47 ` Geert Uytterhoeven
2023-03-05 3:32 ` Frank Rowand
2023-03-05 9:26 ` Geert Uytterhoeven
2023-03-06 5:32 ` Frank Rowand
2023-03-04 15:04 ` Frank Rowand
2023-03-07 21:53 ` Stephen Boyd
2023-03-04 14:48 ` Frank Rowand
2023-03-02 17:13 ` Rob Herring
2023-03-02 19:44 ` Stephen Boyd
2023-03-02 20:18 ` Rob Herring
2023-03-02 23:57 ` Stephen Boyd
2023-03-04 15:39 ` Frank Rowand
2023-03-06 12:53 ` Rob Herring
2023-03-06 15:03 ` Frank Rowand
2023-03-04 15:37 ` Frank Rowand [this message]
2023-03-04 15:33 ` Frank Rowand
2023-03-03 14:38 ` Maxime Ripard
2023-03-07 22:37 ` Stephen Boyd
2023-03-04 15:50 ` Frank Rowand
2023-03-10 7:48 ` David Gow
2023-03-13 15:30 ` 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=0dcf26a8-7d33-37cf-8365-2428ecd6d7cf@gmail.com \
--to=frowand.list@gmail.com \
--cc=ansuelsmth@gmail.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=brendan.higgins@linux.dev \
--cc=davidgow@google.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=johannes@sipsolutions.net \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=patches@lists.linux.dev \
--cc=rafael@kernel.org \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=vincent.whitchurch@axis.com \
/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).