On Wed, Aug 17, 2022 at 7:43 AM David Gow <davidgow@xxxxxxxxxx> wrote: > > On Mon, Aug 15, 2022 at 5:16 PM Ramon Fried <rfried.dev@xxxxxxxxx> wrote: > > > > Hi. > > I implemented a test suite that checks a platform driver, that's the > > only way I can test interrupts behavior in the code. > > Because it's a platform, I can't use kunit_test_suite(), so I call > > __kunit_test_suites_init() as part of the platform driver probe > > function. > > > > This works fine but has the following problems. > > "TAP version 14" string is not printed and it's impossible to parse > > the results using the script. > > In addition, the suite is not displayed in /sys/kernel/debug/kunit. > > > > It would be my pleasure to provide a patch that fixes this, I just > > wanted to make sure that my testing strategy makes sense. > > > > Thanks, > > Ramon > > > Hi Ramon, > > Thanks for reaching out. Calling __kunit_test_suites_init() directly > is not something we'd recommend (and are trying desperately to remove > existing uses), so several of the issues re: the "TAP version 14" > string et al are side effects of calling what is supposed to be an > internal KUnit function manually. > > That being said, we definitely do want to make testing platform > drivers as convenient as possible. I'm not sure why kunit_test_suite() > doesn't work for you for platform drivers: are you just missing some > way of instantiating the device from within a test context? > > I know Brendan has experimented with some hardware faking code, for > which there's some example use here: > https://kunit-review.googlesource.com/c/linux/+/5275 > (Note that you'll need to look at the other patches in the 'relation > chain' for dependencies.) > > Equally, I've experimented a bit with testing old soundcard drivers > (via a platform device) here, which may be an easier way to look > through: > https://github.com/sulix/linux/commit/4e1620c86553b9edde7f032318cf417dc13e4d26 > > Note that neither of those examples are anything other than > experiments, so may not work as-is, or be ideal. > > Otherwise, we're always happy to accept patches, though again, if > there's any way of getting your tests working without a direct call to > __kunit_test_suites_init() --- even if that would require patches to > work --- that'd be preferable on our end. > > Cheers, > -- David Hi David, Thanks for replying. I looked at the examples you shared, and they all fake the actual device. My intention is to actually interact with the real device. - get a real interrupt, etc. Is it wrong, was the intention that the platform device be mocked ? Thanks, Ramon.
