[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z918-4psPV3j9c-d@finisterre.sirena.org.uk>
Date: Fri, 21 Mar 2025 14:51:39 +0000
From: Mark Brown <broonie@...nel.org>
To: Nico Pache <npache@...hat.com>
Cc: rf@...nsource.cirrus.com, patches@...nsource.cirrus.com,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
kunit-dev@...glegroups.com, simont@...nsource.cirrus.com,
ckeepax@...nsource.cirrus.com, brendan.higgins@...ux.dev,
davidgow@...gle.com, rmoar@...gle.com, johannes.berg@...el.com,
sj@...nel.org
Subject: Re: [PATCH] kunit: cs_dsp: Depend on FW_CS_DSP rather then enabling
it
On Fri, Mar 21, 2025 at 05:37:50AM -0600, Nico Pache wrote:
> On Thu, Mar 20, 2025 at 4:49 PM Mark Brown <broonie@...nel.org> wrote:
> > Simply adding it to the all_tests.config will just result in it getting
> > turned off by Kconfig during the build since it's not a visible option
> > so that's not accomplishing anything. all_tests.config is not UML
> > specific, it's for enabling all the KUnit tests that could run in UML no
> > matter how you're running them.
> So would the correct approach be allowing users to select FW_CS_DSP,
> then apply these changes?
That user select should only be visible if KUnit is enabled though,
it really is library code so shouldn't actually be user selectable. I'm
not sure if there's some other strategy other KUnit tests for libraries
use.
> It also looks like FW_CS_DSP_KUNIT_TEST_UTILS and FW_CS_DSP_KUNIT_TEST
> are redundant.
Possibly there's more tests to come that'll use them?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists