From: Maxime Ripard <maxime@cerno.tech>
To: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Brendan Higgins <brendan.higgins@linux.dev>,
David Gow <davidgow@google.com>,
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>,
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 13:29:25 +0100 [thread overview]
Message-ID: <20230323122925.kqdnomr7i46qnyo4@houat> (raw)
In-Reply-To: <8a03a6fb-39b9-cd17-cc10-ece71111357d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4623 bytes --]
On Thu, Mar 23, 2023 at 02:16:52PM +0200, Matti Vaittinen wrote:
> Hi Maxime, all
>
> On 3/23/23 12:21, Greg Kroah-Hartman wrote:
> > On Thu, Mar 23, 2023 at 11:12:16AM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 22, 2023 at 07:57:10PM +0100, Greg Kroah-Hartman wrote:
> > > > > > > +/**
> > > > > > > + * test_kunit_helper_alloc_device - Allocate a mock device for a KUnit test
> > > > > > > + * @test: The test context object
> > > > > > > + *
> > > > > > > + * This allocates a fake struct &device to create a mock for a KUnit
> > > > > > > + * test. The device will also be bound to a fake driver. It will thus be
> > > > > > > + * able to leverage the usual infrastructure and most notably the
> > > > > > > + * device-managed resources just like a "real" device.
> > > > > >
> > > > > > What specific "usual infrastructure" are you wanting to access here?
> > > > > >
> > > > > > And again, if you want a fake device, make a virtual one, by just
> > > > > > calling device_create().
> > > > > >
> > > > > > Or are you wanting to do "more" with that device pointer than
> > > > > > device_create() can give you?
> > > > >
> > > > > Personally, I was (am) only interested in devm_ unwinding. I guess the
> > > > > device_create(), device_add(), device_remove()... (didn't study this
> > > > > sequence in details so sorry if there is errors) could've been sufficient
> > > > > for me. I haven't looked how much of the code that there is for 'platform
> > > > > devices' should be duplicated to support that sequence for testability
> > > > > purposes.
> > > >
> > > > Any device can access devm_ code, there's no need for it to be a
> > > > platform device at all.
> > >
> > > Sure but the resources are only released if the device is part of a bus,
> > > so it can't be a root_device (or bare device) either
> >
> > The resources are not cleaned up when the device is freed no matter if
> > it's on a bus or not? If so, then that's a bug that needs to be fixed,
> > and tested :)
>
> This is strange. I just ran a test on a beaglebone black using Linux
> 6.3.0-rc2 + the IIO patches we se here (but the IIO test patch modified to
> use the root_device_register() and root_device_unregister().
>
> I passed the device pointer from root_device_register() to the
> devm_iio_init_iio_gts()
>
> // snip
> dev = root_device_register(IIO_GTS_TEST_DEV);
> KUNIT_EXPECT_NOT_ERR_OR_NULL(test, dev);
> if (IS_ERR_OR_NULL(dev))
> return NULL;
>
> ret = devm_iio_init_iio_gts(dev, TEST_SCALE_1X, 0, g_table, num_g,
> i_table, num_i, gts);
>
> - and saw the tables for available scales allocated:
>
> if (gts.num_avail_all_scales)
> pr_info("GTS: table allocation succeeded\n");
> else
> pr_info("GTS: table allocation failed\n");
>
> pr_info("gts: num_avail_all_scales %d\n", gts.num_avail_all_scales);
>
> (this printed:
> [ 52.132966] # Subtest: iio-gain-time-scale
> [ 52.132982] 1..7
> [ 52.157455] GTS: table allocation succeeded
> [ 52.164077] gts: num_avail_all_scales 16
>
> Next I unregister the root-device and check if the unwinding code which
> frees the tables and zeroes the scale count was ran:
>
> root_device_unregister(dev);
> pr_info("gts: num_avail_all_scales %d\n", gts.num_avail_all_scales);
>
> if (gts.num_avail_all_scales)
> pr_info("devm unwinding not done\n");
> else
> pr_info("devm unwinding succeeded\n");
>
> Which printed:
> [ 52.168101] gts: num_avail_all_scales 0
> [ 52.171957] devm unwinding succeeded
>
> I can send patch(es) just for testing this on other machines if someone
> want's to see if the lack of devm unwinding is somehow architecture specific
> (which sounds very strange to me) - although using this IIO series just for
> checking the unwinding is a bit of an overkill. I just happened to have
> these tests at my hands / in my tree for testing.
>
> In any case, devm unwinding using root_device_[un]register() seems to "work
> on my machine".
>
> Naxime, what was the environment where you observed lack of unwinding? (Huh,
> I am so afraid of sending this post out - I've experienced too many "Oh, boy
> - how I didn't notice THAT" moments in the past and maybe I am again
> overlooking something...)
This is the description of what was happening:
https://lore.kernel.org/dri-devel/20221117165311.vovrc7usy4efiytl@houat/
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-03-23 12:29 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 [this message]
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
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=20230323122925.kqdnomr7i46qnyo4@houat \
--to=maxime@cerno.tech \
--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=mazziesaccount@gmail.com \
--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).