Received-SPF: pass (google.com: domain of linux-kernel+bounces-98921-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Mon, 11 Mar 2024 09:54:09 -0400
From: =?utf-8?B?TsOtY29sYXMgRi4gUi4gQS4=?= Prado <nfraprado@collabora.com>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Chen-Yu Tsai <wenst@chromium.org>, regressions@lists.linux.dev,
	linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	kernel@collabora.com
Subject: Re: Probe regression of efuse@11f10000 on
 mt8183-kukui-jacuzzi-juniper-sku16 running next-20240202
Message-ID: <82c0c04c-ccea-4839-80dc-16bcf6794bf3@notapiano>
References: <47cdeac1-121d-4b1a-a3ac-e2affc7a2fc3@notapiano>
 <c4416256-eedc-4c9b-b968-3a02490c4c09@notapiano>
 <b888cbe2-6071-4445-91cd-8ce7cc9cc8f4@leemhuis.info>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b888cbe2-6071-4445-91cd-8ce7cc9cc8f4@leemhuis.info>

On Sat, Mar 09, 2024 at 03:06:38PM +0100, Thorsten Leemhuis wrote:
> On 08.03.24 15:31, N?colas F. R. A. Prado wrote:
> > On Tue, Feb 06, 2024 at 11:11:00AM -0500, N?colas F. R. A. Prado wrote:
> >>
> >> KernelCI has identified a regression [1] on the
> >> mt8183-kukui-jacuzzi-juniper-sku16 machine running on next-20240202 compared to
> >> next-20240118:
> >>
> >> #regzbot introduced next-20240118..next-20240202
> > 
> > Not sure why this got filed by regzbot under the mainline tab rather than next.
> > Maybe it was the missing collon? 
> 
> No, I guess that is a bug in regzbot: the support for -next is there,
> but not much tested. Will need to take a closer look, will do so in the
> next few days.

Ah ok, that's good to know.

> 
> > In any case, the fix has already made it to linux-next, so this should close the
> > regression:
> >
> > #regzbot fix: nvmem: mtk-efuse: Drop NVMEM device name
> 
> Out of interest: Is involving regzbot worth it in case the fix is
> already in -next? Or is that primarily to keep track of "we found a
> regression and a fix was already available in next". I don't mind if
> it's the latter, just curious.

When the fix has already landed in next, no, I guess it wouldn't make sense to
involve regzbot, as that would be like creating a regression ticket that is
closed from the start. (And basically it would mean we're testing an outdated
kernel release, which is not very helpful)

In this case when I sent the regression report the regression was still there on
the latest next. The fix had been sent, but not yet merged into next. In that
case it's very much helpful to involve regzbot so we can track the fix and make
sure it gets applied. Also, as was for this case, and probably many others, the
fix patch didn't have that much information on the symptoms and circumstances of
the issue, while the regression report I sent did, so the regression report
should be easier to find for people encountering the regression, and then they
can easily see the status of the regression through regzbot.

Thanks,
N?colas