[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240723142659.GB26137@willie-the-truck>
Date: Tue, 23 Jul 2024 15:26:59 +0100
From: Will Deacon <will@...nel.org>
To: Dev Jain <dev.jain@....com>
Cc: Remington Brasga <rbrasga@....edu>,
Catalin Marinas <catalin.marinas@....com>,
Shuah Khan <shuah@...nel.org>, linux-arm-kernel@...ts.infradead.org,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kernel-mentees@...ts.linuxfoundation.org,
Anshuman.Khandual@....com, Mark Brown <broonie@...nel.org>,
Ryan Roberts <ryan.roberts@....com>
Subject: Re: [PATCH] kselftest: missing arg in ptrace.c
On Thu, Jul 18, 2024 at 04:34:10PM +0100, Will Deacon wrote:
> On Tue, Jul 16, 2024 at 09:49:12AM +0530, Dev Jain wrote:
> >
> > On 7/13/24 04:47, Remington Brasga wrote:
> > > The string passed to ksft_test_result_skip is missing the `type_name`
> > >
> > > Signed-off-by: Remington Brasga <rbrasga@....edu>
> > > ---
> > > clang-tidy reported clang-diagnostic-format-insufficient-args warning
> > > on this line, so I am fixing it.
> > >
> > > tools/testing/selftests/arm64/abi/ptrace.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tools/testing/selftests/arm64/abi/ptrace.c b/tools/testing/selftests/arm64/abi/ptrace.c
> > > index abe4d58d731d..6144f83f8ab4 100644
> > > --- a/tools/testing/selftests/arm64/abi/ptrace.c
> > > +++ b/tools/testing/selftests/arm64/abi/ptrace.c
> > > @@ -156,7 +156,7 @@ static void test_hw_debug(pid_t child, int type, const char *type_name)
> > > /* Zero is not currently architecturally valid */
> > > ksft_test_result(arch, "%s_arch_set\n", type_name);
> > > } else {
> > > - ksft_test_result_skip("%s_arch_set\n");
> > > + ksft_test_result_skip("%s_arch_set\n", type_name);
> > > }
> > > }
> >
> > Okay, I almost forgot that I had a patch fixing this as part of another series:
> > https://lore.kernel.org/all/20240625122408.1439097-6-dev.jain@arm.com/
> > If that is OK, Will, can you please pull that? Or should I send that as a
> > separate patch?
>
> I think Mark already suggested sending that separately:
>
> | This should ideally be a separate patch, there's no overlap.
>
> and he's right: it's best to keep fixes and features separate.
I didn't spot a patch from you, so I'm going to pick this one up instead.
Will
Powered by blists - more mailing lists