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
