linux-um.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: Frank Rowand <frowand.list@gmail.com>, 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: Mon, 6 Mar 2023 06:53:32 -0600	[thread overview]
Message-ID: <CAL_Jsq+yhdSqiAVfUKh1DGaKTEGHOMPKAYpQPPB=ywA76C6EvA@mail.gmail.com> (raw)
In-Reply-To: <c81211fa-2836-fe21-637f-a5cca7237d43@gmail.com>

On Sat, Mar 4, 2023 at 9:39 AM Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 3/2/23 17:57, Stephen Boyd wrote:
> > Quoting Rob Herring (2023-03-02 12:18:34)
> >> On Thu, Mar 2, 2023 at 1:44 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >>>
> >>> Quoting Rob Herring (2023-03-02 09:13:59)
> >>>>
> >>>> 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'?
> >
> > Sounds good.
> >
> >>
> >>>> 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.
> >>
> >
> > Ok. I suspect we may want to test error paths though so I don't know
>
> Yes, exactly.
>
> > what to do here. For now I'll just leave the bindings in place and
> > change the prefix to "test".
> >
> >>
> >>>> 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.
> >
> > Got it.
> >
> >>
> >>>> 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.
> >
> > Phew!
> >
> >>
> >> 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.
> >>
> >
> > Ok. I think I have some time to try this overlay approach so let me see
> > what is needed.
>
> Please avoid overlays.  See my other replies in this thread for why.

If overlays work for the constrained environment of unit tests, then
use them. If overlays are not to be used, then remove the support from
the kernel. Putting issues in a todo list is not going to get them
done. Having users will.

Rob

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

  reply	other threads:[~2023-03-06 12:53 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 [this message]
2023-03-06 15:03             ` Frank Rowand
2023-03-04 15:37       ` Frank Rowand
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='CAL_Jsq+yhdSqiAVfUKh1DGaKTEGHOMPKAYpQPPB=ywA76C6EvA@mail.gmail.com' \
    --to=robh+dt@kernel.org \
    --cc=ansuelsmth@gmail.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=brendan.higgins@linux.dev \
    --cc=davidgow@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --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=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).