From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: kunit-dev@googlegroups.com, kasan-dev@googlegroups.com,
linux-kselftest@vger.kernel.org,
Brendan Higgins <brendanhiggins@google.com>,
Daniel Latypov <dlatypov@google.com>
Subject: Re: [PATCH v5 3/6] thunderbolt: test: use NULL macros
Date: Fri, 11 Feb 2022 18:26:51 +0200 [thread overview]
Message-ID: <YgaOS8BLz23k6JVq@lahna> (raw)
In-Reply-To: <CANiDSCs3+637REhtGjKy+MSnUm-Mh-k1S7Lk9UKqC8JY-k=zTw@mail.gmail.com>
On Fri, Feb 11, 2022 at 04:49:21PM +0100, Ricardo Ribalda wrote:
> Hi Mika
>
> On Fri, 11 Feb 2022 at 11:08, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > Hi,
> >
> > On Fri, Feb 11, 2022 at 10:41:30AM +0100, Ricardo Ribalda wrote:
> > > Replace the NULL checks with the more specific and idiomatic NULL macros.
> > >
> > > Acked-by: Daniel Latypov <dlatypov@google.com>
> > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > > ---
> >
> > ...
> >
> > > @@ -2496,50 +2496,50 @@ static void tb_test_property_parse(struct kunit *test)
> > > struct tb_property *p;
> > >
> > > dir = tb_property_parse_dir(root_directory, ARRAY_SIZE(root_directory));
> > > - KUNIT_ASSERT_TRUE(test, dir != NULL);
> > > + KUNIT_ASSERT_NOT_NULL(test, dir);
> > >
> > > p = tb_property_find(dir, "foo", TB_PROPERTY_TYPE_TEXT);
> > > - KUNIT_ASSERT_TRUE(test, !p);
> > > + KUNIT_ASSERT_NOT_NULL(test, p);
> >
> > This should be KUNIT_ASSERT_NULL(test, p) as we specifically want to
> > check that the property does not exist (!p is same as p == NULL).
> >
> > > p = tb_property_find(dir, "vendorid", TB_PROPERTY_TYPE_TEXT);
> > > - KUNIT_ASSERT_TRUE(test, p != NULL);
> > > + KUNIT_ASSERT_NOT_NULL(test, p);
> > > KUNIT_EXPECT_STREQ(test, p->value.text, "Apple Inc.");
> > >
> > > p = tb_property_find(dir, "vendorid", TB_PROPERTY_TYPE_VALUE);
> > > - KUNIT_ASSERT_TRUE(test, p != NULL);
> > > + KUNIT_ASSERT_NOT_NULL(test, p);
> > > KUNIT_EXPECT_EQ(test, p->value.immediate, 0xa27);
> > >
> > > p = tb_property_find(dir, "deviceid", TB_PROPERTY_TYPE_TEXT);
> > > - KUNIT_ASSERT_TRUE(test, p != NULL);
> > > + KUNIT_ASSERT_NOT_NULL(test, p);
> > > KUNIT_EXPECT_STREQ(test, p->value.text, "Macintosh");
> > >
> > > p = tb_property_find(dir, "deviceid", TB_PROPERTY_TYPE_VALUE);
> > > - KUNIT_ASSERT_TRUE(test, p != NULL);
> > > + KUNIT_ASSERT_NOT_NULL(test, p);
> > > KUNIT_EXPECT_EQ(test, p->value.immediate, 0xa);
> > >
> > > p = tb_property_find(dir, "missing", TB_PROPERTY_TYPE_DIRECTORY);
> > > - KUNIT_ASSERT_TRUE(test, !p);
> > > + KUNIT_ASSERT_NOT_NULL(test, p);
> >
> > Ditto here.
> >
> > With those fixed (please also run the tests if possible to see that they
> > still pass) you can add,
> >
>
> Thanks!
>
> To test it I had enabled:
> PCI, USB4 and USB4_KUNIT_TEST
>
> and then run it with
>
> ./tools/testing/kunit/kunit.py run --jobs=$(nproc) --arch=x86_64
>
> Unfortunately, kunit was not able to run the tests
>
> This hack did the trick:
>
>
> int tb_test_init(void)
> {
> - return __kunit_test_suites_init(tb_test_suites);
> + //return __kunit_test_suites_init(tb_test_suites);
> + return 0;
> }
>
> void tb_test_exit(void)
> {
> - return __kunit_test_suites_exit(tb_test_suites);
> + //return __kunit_test_suites_exit(tb_test_suites);
> }
> +
> +kunit_test_suites(&tb_test_suite);
>
> I looked into why we do this and I found:
>
> thunderbolt: Allow KUnit tests to be built also when CONFIG_USB4=m
>
>
> I am a bit confused. The patch talks about build coverage, but even
> with that patch reverted if
> USB4_KUNIT_TEST=m
> then test.c is built.
>
> Shouldn't we simply revert that patch?
Nah, either build it into the kernel or load the driver manually:
# modprobe thunderbolt
next prev parent reply other threads:[~2022-02-11 16:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 9:41 [PATCH v5 1/6] kunit: Introduce _NULL and _NOT_NULL macros Ricardo Ribalda
2022-02-11 9:41 ` [PATCH v5 2/6] kunit: use NULL macros Ricardo Ribalda
2022-02-11 9:41 ` [PATCH v5 3/6] thunderbolt: test: " Ricardo Ribalda
2022-02-11 10:08 ` Mika Westerberg
2022-02-11 15:49 ` Ricardo Ribalda
2022-02-11 16:26 ` Mika Westerberg [this message]
2022-02-11 16:31 ` Mika Westerberg
2022-02-11 16:33 ` Ricardo Ribalda
2022-02-11 22:54 ` Daniel Latypov
2022-02-14 6:24 ` Mika Westerberg
2022-02-14 18:43 ` Daniel Latypov
2022-02-11 9:41 ` [PATCH v5 4/6] kasan: test: Use " Ricardo Ribalda
2022-02-11 9:41 ` [PATCH v5 5/6] mctp: " Ricardo Ribalda
2022-02-11 9:41 ` [PATCH v5 6/6] apparmor: " Ricardo Ribalda
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=YgaOS8BLz23k6JVq@lahna \
--to=mika.westerberg@linux.intel.com \
--cc=brendanhiggins@google.com \
--cc=dlatypov@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=ribalda@chromium.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