Re: [PATCH v6 3/7] kunit: Add kunit wrappers for (root) device creation

[Maxime Ripard]

Hi,

On Tue, Mar 28, 2023 at 08:45:09PM +0800, David Gow wrote:
> > > Ok. I understood using the root-device has been a work-around in some other
> > > tests. Thus continuing use it for tests where we don't need the bus until we
> > > have a proper alternative was suggested by David.
> > >
> > > > Do the right thing here, create a fake bus and add devices to it.
> > > >
> > > > Heck, I'll even write that code if you want it, what's the requirement,
> > > > something like:
> > > >     struct device *kunit_device_create(struct kunit *test, const char *name);
> > > >     void kunit_device_destroy(struct device *dev);
> > >
> > > Thanks for the offer Greg. This, however, is being already worked on by
> > > David. I don't want to step on his toes by writing the same thing, nor do I
> > > think I should be pushing him to rush on his work.
> >
> > Ok, David, my offer stands, if you want me to write this I will be glad
> > to do so.
> 
> I'm happy to keep working on this, but would definitely appreciate
> your feedback.
> 
> I've put my work-in-progress code here:
> https://kunit.googlesource.com/linux/+/refs/heads/kunit/device-helpers%5E%21/#F0
> 
> It creates a "kunit" bus, and adds a few helpers to create both
> devices and drivers on that bus, and clean them up when the test
> exits. It seems to work on all of the tests which used
> root_device_register so far (except those -- only
> test_iio_find_closest_gain_low so far -- which create multiple devices
> with the same name, as the driver name won't be unique), and the drm
> tests work fine when ported to it as well.
> 
> There's still a lot of cleanup to do and questions which need
> answering, including:
> - Working out how best to provide an owning module (it's currently
> just kunit, but probably should be the module which contains the
> actual tests)
> - Improving the API around drivers: probably exposing the helper to
> create a driver, and add a way of cleaning it up early.

I'm not sure we need to give the ability for a test to pass a driver.
I'd expect there's two main use-cases: either we want to test a function
that uses a device as an argument, or we want to probe the whole driver
and test it.

The former is covered by kunit_device_register(), and I'd expect the
latter to be covered by the work Stephen is doing, where we will load an
entire overlay, which will in turn probe the driver.

> - Properly testing it with modules, not just with kunit.py (including
> looking at what actually appears in sysfs)
> - Experimenting with using probe, etc, callbacks.
> - Cleaning up lots of ugly, still experimental code, documenting, testing, etc.
>
> The thought of trying to expand the match function to support, e.g.,
> devicetree occurred to me, but I _think_ that devicetree-based tests
> are probably still better off using a platform_device. Regardless, it
> can probably wait to a follow-up

Yeah, probing the entire driver will require to instantiate the device
the driver expects, hence why relying on the overlays also makes a lot
of sense.

Maxime