From: Stephen Boyd <sboyd@kernel.org>
To: David Gow <davidgow@google.com>
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>,
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>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.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 3/8] kunit: Add test managed platform_device/driver APIs
Date: Thu, 09 Mar 2023 15:25:03 -0800 [thread overview]
Message-ID: <b0d4d450a7ad9b39336771b74b48f086.sboyd@kernel.org> (raw)
In-Reply-To: <CABVgOSmR0_u8Tw0E8C1mRFxSiGKwdKG5ka_+X_36Hj4VNLdg2g@mail.gmail.com>
Quoting David Gow (2023-03-02 23:15:31)
> On Thu, 2 Mar 2023 at 09:38, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Introduce KUnit resource wrappers around platform_driver_register(),
> > platform_device_alloc(), and platform_device_add() so that test authors
> > can register platform drivers/devices from their tests and have the
> > drivers/devices automatically be unregistered when the test is done.
> >
> > This makes test setup code simpler when a platform driver or platform
> > device is needed. Add a few test cases at the same time to make sure the
> > APIs work as intended.
> >
> > Cc: Brendan Higgins <brendan.higgins@linux.dev>
> > Cc: David Gow <davidgow@google.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> > ---
> >
> > Should this be moved to drivers/base/ and called platform_kunit.c?
> > The include/kunit/platform_driver.h could also be
> > kunit/platform_device.h to match linux/platform_device.h if that is more
> > familiar.
>
> DRM has a similar thing already (albeit with a root_device, which is
> more common with KUnit tests generally):
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_kunit_helpers.h
>
> But that's reasonably drm-specific, so it makes sense that it lives
> with DRM stuff. platform_device is a bit more generic.
>
> I'd probably personally err on the side of having these in
> drivers/base/, as I think we'll ultimately need similar things for a
> lot of different devices, and I'd rather not end up with things like
> USB device helpers living in the lib/kunit directory alongside the
> "core" KUnit code. But I could be persuaded otherwise.
Ok no problem. I'll move it.
>
> >
> > And I'm not super certain about allocating a driver structure and
> > embedding it in a wrapper struct. Maybe the code should just use
> > kunit_get_current_test() instead?
>
> I think there are enough cases througout the kernel where
> device/driver structs are needed that having this makes sense.
> Combined with the fact that, while kunit_get_current_test() can be
> used even when KUnit is not loaded, actually doing anything with the
> resulting struct kunit pointer will probably require (at least for the
> moment) KUnit functions to be reachable, so would break if
> CONFIG_KUNIT=m.
Wouldn't it still work in that case? The unit tests would be modular as
well because they depend on CONFIG_KUNIT.
>
> So, unless you actually find kunit_get_current_test() and friends to
> be easier to work with, I'd probably stick with this.
>
Alright thanks.
> > diff --git a/lib/kunit/platform_driver.c b/lib/kunit/platform_driver.c
> > new file mode 100644
> > index 000000000000..11d155114936
> > --- /dev/null
> > +++ b/lib/kunit/platform_driver.c
> > @@ -0,0 +1,207 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Test managed platform driver
> > + */
> > +
> > +#include <linux/device/driver.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include <kunit/resource.h>
> > +
> > +struct kunit_platform_device_alloc_params {
> > + const char *name;
> > + int id;
> > +};
>
> FYI: It's my plan to eventually get rid of (or at least de-emphasize)
> the whole 'init' function aspect of KUnit resources so we don't need
> all of these extra structs and the like. It probably won't make it in
> for 6.4, but we'll see...
Will we be able to get the error values out of the init function? It's
annoying that the error values can't be returned as error pointers to
kunit_alloc_resource(). I end up skipping init, and doing it directly
before or after calling the kunit_alloc_resource() function. I'll try to
avoid init functions in the allocations.
next prev parent reply other threads:[~2023-03-09 23:25 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 [this message]
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
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=b0d4d450a7ad9b39336771b74b48f086.sboyd@kernel.org \
--to=sboyd@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=robh+dt@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