[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <86mt9kdjrj.wl-maz@kernel.org>
Date: Tue, 25 Oct 2022 16:07:28 +0100
From: Marc Zyngier <maz@...nel.org>
To: "Tyler Hicks (Microsoft)" <code@...icks.com>
Cc: Mark Rutland <mark.rutland@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Vijay Balakrishna <vijayb@...ux.microsoft.com>,
Will Deacon <will@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clocksource/drivers/arm_arch_timer: Fix event stream param in Kconfig
Hi Tyler,
On Tue, 25 Oct 2022 15:18:54 +0100,
"Tyler Hicks (Microsoft)" <code@...icks.com> wrote:
>
> On 2022-10-25 11:24:55, Marc Zyngier wrote:
> > Hi Tyler,
> >
> > On Mon, 24 Oct 2022 20:51:18 +0100,
> > Tyler Hicks <code@...icks.com> wrote:
> > >
> > > From: "Tyler Hicks (Microsoft)" <code@...icks.com>
> > >
> > > Fix the event stream timer command line parameter name that's documented
> > > in the Kconfig description for CONFIG_ARM_ARCH_TIMER_EVTSTREAM. It
> > > didn't match the command line parameter name that's actually honored in
> > > the source code.
> > >
> > > Reported-by: Vijay Balakrishna <vijayb@...ux.microsoft.com>
> > > Fixes: 46fd5c6b3059 ("clocksource/drivers/arm_arch_timer: Control the evtstrm via the cmdline")
> > > Cc: stable@...r.kernel.org
> >
> > No, this really doesn't deserve a Cc: stable. This bit may be wrong,
> > but we have the correct information in the kernel-parameters.txt file,
> > which is authoritative AFAIC.
>
> Thanks for the review!
>
> I added the stable tag because it caused an actual waste of time in an
> investigation. Upon discovering this option, I didn't notice the subtle
> difference in cmdline parameter name from the Kconfig, to the
> kernel-parameters.txt file and the code. I ran long-running stress tests
> with the incorrect parameter name copied and pasted from the Kconfig.
> This error resulted in a bad data point in the investigation and it took
> a second set of eyes (Vijay's) to uncover my mistake days later when we
> were trying to reconcile the bad data point with other good data points.
I appreciate this has caused a certain waste of time, but the rules
for stable inclusion are pretty clear: it has to be a runtime bug.
Documentation bugs, as irritating as they are, do not fall into this
category (it really *is* a typo).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists