From: Matti Vaittinen <mazziesaccount@gmail.com>
To: David Gow <davidgow@google.com>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Brendan Higgins <brendan.higgins@linux.dev>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
kunit-dev@googlegroups.com, Stephen Boyd <sboyd@kernel.org>,
Maxime Ripard <maxime@cerno.tech>,
Jonathan Cameron <jic23@kernel.org>,
linux-iio@vger.kernel.org
Subject: Re: [PATCH v5 1/8] drivers: kunit: Generic helpers for test device creation
Date: Thu, 23 Mar 2023 10:35:21 +0200 [thread overview]
Message-ID: <9d46a37d-21fe-328f-18b0-e5435756aeef@gmail.com> (raw)
In-Reply-To: <CABVgOS=KUg+18wJe=O29tgOB0tQghAk030kONEm5fOzJHgKLgw@mail.gmail.com>
Hi David, all,
On 3/23/23 09:30, David Gow wrote:
> On Wed, 22 Mar 2023 at 17:06, Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>>
>> The creation of a dummy device in order to test managed interfaces is a
>> generally useful test feature. The drm test helpers
>> drm_kunit_helper_alloc_device() and drm_kunit_helper_free_device()
>> are doing exactly this. It makes no sense that each and every component
>> which intends to be testing managed interfaces will create similar
>> helpers so stole these for more generic use.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> ---
>> Changes:
>> v4 => v5:
>> - Add accidentally dropped header and email recipients
>> - do not rename + move helpers from DRM but add temporary dublicates to
>> simplify merging. (This patch does not touch DRM and can be merged
>> separately. DRM patch and IIO test patch still depend on this one).
>>
>> Please note that there's something similar ongoing in the CCF:
>> https://lore.kernel.org/all/20230302013822.1808711-1-sboyd@kernel.org/
>>
>> I do like the simplicity of these DRM-originated helpers so I think
>> they're worth. I do equally like the Stephen's idea of having the
>> "dummy platform device" related helpers under drivers/base and the
>> header being in include/kunit/platform_device.h which is similar to real
>> platform device under include/linux/platform_device.h
>> ---
>
> Thanks for sending this my way.
>
> It's clear we need some way of creating "fake" devices for KUnit
> tests. Given that there are now (at least) three different drivers
> looking to use this, we'll ultimately need something which works for
> everyone.
>
> I think the questions we therefore need to answer are:
> - Do we specifically need a platform_device (or, any other specific
> device struct), or would any old struct device work? I can see why we
> would need a platform device for cases where we're testing things like
> device-tree properties (or, in the future, having e.g. USB-specific
> helpers which create usb_device). Most tests just use
> root_device_register() thus far, though.
Funny timing. I just found the root_device_register() while wondering
the parent for auxiliary_devices.
I think the root_device_[un]register() meets my current needs.
> - What helpers do we need to make creating, using, and cleaning up
> these devices as simple as possible.
>
> I think that in this particular case, we don't actually need a struct
> platform_device. Replacing these helpers with simple calls to
> root_device_register() and root_device_unregister() seems to work fine
> with this patch series for me. (It does break the
> drm_test_managed_run_action test, though.) So I don't think having
> these helpers actually help this series at the moment.
I am afraid that further work with these helpers is out of the scope for
me (at least for now). I'll drop the DRM and the helper patches from
this series && go with the root_device_register(),
root_device_unregister() in the IIO tests added in this series.
> That being said, if they used the KUnit resource system to
> automatically clean up the device when the test is finished (or
> otherwise exits),
My 10 cents to this is that yes, automatic unwinding at test exit would
be simple - and also correct for most of the time. However, I think
there might also be tests that would like to verify the unwinding
process has really managed to do what it was intended to do. That, I
think would require being able to manually drop the device in the middle
of the test.
> So, I guess we have three cases we need to look at:
> - A test just needs any old struct device. Tests thus far have
> hardcoded, or had their own wrappers around root_device_register() for
> this.
As said above, my case fits this category.
> - A test needs a device attached to a bus (but doesn't care which
> bus). Thus far, people have used struct platform_device for this (see
> the DRM helpers, which use a platform device for managed resource
> tests[2]). Maybe the right solution here is something like a struct
> kunit_device?
This sounds like, how to put it, "architecturally correct". But...
> - A test needs a device attached to a specific bus. We'll probably
> need some more detailed faking of that bus. This covers cases like
> having fake USB devices, devicetree integration, etc.
...if we in any case need this, wouldn't the kunit_device just be
unnecessary bloat because if the test does not care which bus it is
sitting in, then it could probably use a bus-specific device as well?
> I'd suggest that, for the majority of cases which only care about the
> first case, let's just use root_device_register() directly,
After finding the root_device_register() - I agree.
> or have a
> thin wrapper like the old root_device-based version of the DRM
> helpers[3]. This will probable serve us well enough while we work out
> how to handle the other two cases properly (which is already being
> looked at for the CLK/DeviceTree patches and the DRM stuff).
>
> If the resulting helpers are generally useful enough, they can
> probably sit in either drivers/base or lib/kunit. I'd rather not have
> code that's really specific to certain busses sitting in lib/kunit
> rather than alongside the device/bus code in drivers/base or some
> other subsystem/driver path, but I can tolerate it for the very
> generic struct device.
>
> Regardless, I've left a few notes on the patch itself below.
Thanks but I guess I'll just drop this one :)
>
> Cheers,
> -- David
>
> [1]: https://kunit-review.googlesource.com/c/linux/+/5434/3/include/kunit/resource.h
> [2]: https://lore.kernel.org/all/20221123-rpi-kunit-tests-v3-8-4615a663a84a@cerno.tech/
> [3]: https://elixir.bootlin.com/linux/v6.2/source/drivers/gpu/drm/tests/drm_kunit_helpers.c#L39
Thanks for the thorough analysis and these links! This was enlightening :)
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
next prev parent reply other threads:[~2023-03-23 8:37 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-22 9:05 [PATCH v5 0/8] Support ROHM BU27034 ALS sensor Matti Vaittinen
2023-03-22 9:05 ` [PATCH v5 1/8] drivers: kunit: Generic helpers for test device creation Matti Vaittinen
2023-03-22 12:04 ` Greg Kroah-Hartman
2023-03-22 12:07 ` Greg Kroah-Hartman
2023-03-22 13:48 ` Matti Vaittinen
2023-03-22 18:57 ` Greg Kroah-Hartman
2023-03-23 7:17 ` Vaittinen, Matti
2023-03-23 8:58 ` Greg Kroah-Hartman
2023-03-23 9:20 ` Matti Vaittinen
2023-03-23 10:25 ` Greg Kroah-Hartman
2023-03-23 10:43 ` Matti Vaittinen
2023-03-23 10:01 ` Matti Vaittinen
2023-03-23 10:27 ` Greg Kroah-Hartman
2023-03-23 11:00 ` Matti Vaittinen
2023-03-23 10:12 ` Maxime Ripard
2023-03-23 10:21 ` Greg Kroah-Hartman
2023-03-23 12:16 ` Matti Vaittinen
2023-03-23 12:29 ` Maxime Ripard
2023-03-23 13:02 ` Matti Vaittinen
2023-03-23 16:36 ` Maxime Ripard
2023-03-24 6:11 ` Matti Vaittinen
2023-03-24 6:34 ` David Gow
2023-03-24 6:51 ` Matti Vaittinen
2023-03-24 9:52 ` David Gow
2023-03-24 10:05 ` Matti Vaittinen
2023-03-24 10:17 ` Matti Vaittinen
2023-03-25 4:35 ` David Gow
2023-03-25 7:26 ` Matti Vaittinen
2023-03-24 12:46 ` Maxime Ripard
2023-03-24 12:31 ` Maxime Ripard
2023-03-25 5:40 ` David Gow
2023-03-29 19:43 ` Maxime Ripard
2023-03-25 17:50 ` Jonathan Cameron
2023-03-26 17:16 ` Lars-Peter Clausen
2023-04-01 15:30 ` Jonathan Cameron
2023-03-29 19:46 ` Maxime Ripard
2023-04-01 15:36 ` Jonathan Cameron
2023-03-24 12:36 ` Maxime Ripard
2023-03-24 12:43 ` Greg Kroah-Hartman
2023-03-24 13:02 ` Maxime Ripard
2023-03-24 13:42 ` Greg Kroah-Hartman
2023-03-22 12:08 ` Greg Kroah-Hartman
2023-03-23 7:30 ` David Gow
2023-03-23 8:35 ` Matti Vaittinen [this message]
2023-03-23 9:02 ` Greg Kroah-Hartman
2023-03-23 10:07 ` Maxime Ripard
2023-03-22 9:06 ` [PATCH v5 2/8] drm/tests: helpers: Use generic helpers Matti Vaittinen
2023-03-22 9:06 ` [PATCH v5 3/8] dt-bindings: iio: light: Support ROHM BU27034 Matti Vaittinen
2023-03-22 9:06 ` [PATCH v5 4/8] iio: light: Add gain-time-scale helpers Matti Vaittinen
2023-03-22 9:07 ` [PATCH v5 5/8] iio: test: test " Matti Vaittinen
2023-03-24 6:29 ` Matti Vaittinen
2023-03-22 9:07 ` [PATCH v5 6/8] MAINTAINERS: Add IIO " Matti Vaittinen
2023-03-22 9:07 ` [PATCH v5 7/8] iio: light: ROHM BU27034 Ambient Light Sensor Matti Vaittinen
2023-03-26 16:19 ` Jonathan Cameron
2023-03-27 7:16 ` Vaittinen, Matti
2023-03-22 9:08 ` [PATCH v5 8/8] MAINTAINERS: Add ROHM BU27034 Matti Vaittinen
2023-03-22 10:01 ` [PATCH v5 0/8] Support ROHM BU27034 ALS sensor Andy Shevchenko
2023-03-22 10:34 ` Javier Martinez Canillas
2023-03-22 10:59 ` Matti Vaittinen
2023-03-22 11:02 ` Andy Shevchenko
2023-03-23 9:28 ` Maxime Ripard
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=9d46a37d-21fe-328f-18b0-e5435756aeef@gmail.com \
--to=mazziesaccount@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brendan.higgins@linux.dev \
--cc=davidgow@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=jic23@kernel.org \
--cc=kunit-dev@googlegroups.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=maxime@cerno.tech \
--cc=rafael@kernel.org \
--cc=sboyd@kernel.org \
/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).