From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "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-kernel@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"kunit-dev@googlegroups.com" <kunit-dev@googlegroups.com>,
Stephen Boyd <sboyd@kernel.org>,
Maxime Ripard <maxime@cerno.tech>,
Jonathan Cameron <jic23@kernel.org>,
"linux-iio@vger.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 12:01:15 +0200 [thread overview]
Message-ID: <91c8dc84-8eae-15d9-3d55-976c2c806421@gmail.com> (raw)
In-Reply-To: <ZBwUp/fRIjQZtjF7@kroah.com>
On 3/23/23 10:58, Greg Kroah-Hartman wrote:
> On Thu, Mar 23, 2023 at 07:17:40AM +0000, Vaittinen, Matti wrote:
>> On 3/22/23 20:57, Greg Kroah-Hartman wrote:
>>> On Wed, Mar 22, 2023 at 03:48:00PM +0200, Matti Vaittinen wrote:
>>>> Hi Greg,
>>>>
>>>> Thanks for looking at this.
>>>>
>>>> On 3/22/23 14:07, Greg Kroah-Hartman wrote:
>>>>> On Wed, Mar 22, 2023 at 11:05:55AM +0200, Matti Vaittinen wrote:
>>>> The biggest thing for me is that I don't like the idea of creating own 'test
>>>> device' in <add subsystem here> while we already have some in DRM (or
>>>> others). Thus, I do see value in adding generic helpers for supporting
>>>> running KUnit tests on devm_* APIs. Hence it'd be good to have _some_
>>>> support for it.
>>>
>>> I agree, let's use a virtual device and a virtual bus (you can use the
>>> auxbus code for this as that's all there for this type of thing)
>>
>> Hm. The auxiliary_devices require parent. What would be the best way to
>> deal with that in KUnit tests?
>
> If you use NULL as the parent, it goes into the root.
As far as I read this is not the case with auxiliary devices. Judging
the docs they were intended to be representing some part of a (parent)
device. I see the auxiliary_device_init() has explicit check for parent
being populated:
int auxiliary_device_init(struct auxiliary_device *auxdev)
{
struct device *dev = &auxdev->dev;
if (!dev->parent) {
pr_err("auxiliary_device has a NULL dev->parent\n");
return -EINVAL;
}
As I wrote in another mail, I thought of using a root_device for this
IIO test as was suggested by David. To tell the truth, implementing a
kunit bus device is starting to feel a bit overwhelming... I started
just adding a driver for a light sensor, ended up adding a helper for
IIO gain-time-scale conversions and I am slightly reluctant to going the
extra-extra mile of adding some UT infrastructure in the context of this
driver work...
Well, let's see. Maybe I change my mind after a good night's sleep :)
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 10:01 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 [this message]
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
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=91c8dc84-8eae-15d9-3d55-976c2c806421@gmail.com \
--to=mazziesaccount@gmail.com \
--cc=Matti.Vaittinen@fi.rohmeurope.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=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).