[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABVgOSnxa=H5A-0U0QRCAv+OWCGb0zN_f7gP5FmhGjRy7NCUSw@mail.gmail.com>
Date: Wed, 17 Aug 2022 12:43:19 +0800
From: David Gow <davidgow@...gle.com>
To: Ramon Fried <rfried.dev@...il.com>
Cc: Brendan Higgins <brendanhiggins@...gle.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
KUnit Development <kunit-dev@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Running kunit tests on platform devices
On Mon, Aug 15, 2022 at 5:16 PM Ramon Fried <rfried.dev@...il.com> 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
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4003 bytes)
Powered by blists - more mailing lists