Re: [PATCH 1/3] ARM: dts: meson: Fix the UART compatible strings

Re: [PATCH 1/3] ARM: dts: meson: Fix the UART compatible strings

[Thorsten Leemhuis]

[CCing the stable list as well as Greg and Sasha so they can correct me
if I write something stupid]

On 06.04.23 10:27, Ricardo Cañuelo wrote:
> 
> On 5/4/23 19:14, Thorsten Leemhuis wrote:
>> Wait, what? A patch (5225e1b87432 ("ARM: dts: meson: Fix the UART
>> compatible strings")) that was merged for v5.17-rc4 and is not in the
>> list of patches that were in 4.14.312-rc1
>> (https://lore.kernel.org/all/20230403140351.636471867@linuxfoundation.org/
>> ) is meant to suddenly cause this? How is this possible? Am I totally on
>> the wrong track here and misunderstanding something, or is this a
>> bisection that went horribly sideways?
> 
> I didn't say this was introduced in 4.14.312-rc1, this has been failing
> for a long time and it was merged for 4.14.267:
> https://lwn.net/Articles/884977/
> 
> Sorry I wasn't clear before.

Ahh, no worries and thx for this. But well, in that case let me get back
to something from your report:

>>> KernelCI detected that this patch introduced a regression in
>>> stable-rc/linux-4.14.y on a meson8b-odroidc1.
>>> After this patch was applied the tests running on this platform don't
>>> show any serial output.
>>> 
>>> This doesn't happen in other stable branches nor in mainline, but 4.14
>>> hasn't still reached EOL and it'd be good to find a fix.

Well, the stable maintainers may correct me if I'm wrong, but as far as
I know in that case it's the duty of the stable team (which was not even
CCed on the report afaics) to look into this for two reasons:

* the regression does not happened in mainline (and maybe never has)

* mainline developers never signed up for maintaining their work in
longterm kernels; quite a few nevertheless help in situation like this,
at least for recent series and if they asked for a backport through a
"CC: <stable@" tag – but the latter doesn't seem to be the case here
(not totally sure, but it looks like AUTOSEL picked this up) and it's a
quite old series.

>>> #regzbot introduced: 5225e1b87432dcf0d0fc3440824b91d04c1d6cc1

Thx for getting regzbot involved, but due to your usage it now considers
this a mainline regression, as 5225e1b87432 is a mainline commit. As
this only happens in a particular stable tree, it should use a commit id
from there instead:

#regzbot introduced: 23dfa42a0a2a91d640ef3fce585194b970d8680c

(above line will make regzbot adjust this)

Ciao, Thorsten

Re: [PATCH 1/3] ARM: dts: meson: Fix the UART compatible strings

[Greg KH]

On Thu, Apr 06, 2023 at 11:06:50AM +0200, Thorsten Leemhuis wrote:
> [CCing the stable list as well as Greg and Sasha so they can correct me
> if I write something stupid]
> 
> On 06.04.23 10:27, Ricardo Cañuelo wrote:
> > 
> > On 5/4/23 19:14, Thorsten Leemhuis wrote:
> >> Wait, what? A patch (5225e1b87432 ("ARM: dts: meson: Fix the UART
> >> compatible strings")) that was merged for v5.17-rc4 and is not in the
> >> list of patches that were in 4.14.312-rc1
> >> (https://lore.kernel.org/all/20230403140351.636471867@linuxfoundation.org/
> >> ) is meant to suddenly cause this? How is this possible? Am I totally on
> >> the wrong track here and misunderstanding something, or is this a
> >> bisection that went horribly sideways?
> > 
> > I didn't say this was introduced in 4.14.312-rc1, this has been failing
> > for a long time and it was merged for 4.14.267:
> > https://lwn.net/Articles/884977/
> > 
> > Sorry I wasn't clear before.
> 
> Ahh, no worries and thx for this. But well, in that case let me get back
> to something from your report:
> 
> >>> KernelCI detected that this patch introduced a regression in
> >>> stable-rc/linux-4.14.y on a meson8b-odroidc1.
> >>> After this patch was applied the tests running on this platform don't
> >>> show any serial output.
> >>> 
> >>> This doesn't happen in other stable branches nor in mainline, but 4.14
> >>> hasn't still reached EOL and it'd be good to find a fix.
> 
> Well, the stable maintainers may correct me if I'm wrong, but as far as
> I know in that case it's the duty of the stable team (which was not even
> CCed on the report afaics) to look into this for two reasons:
> 
> * the regression does not happened in mainline (and maybe never has)
> 
> * mainline developers never signed up for maintaining their work in
> longterm kernels; quite a few nevertheless help in situation like this,
> at least for recent series and if they asked for a backport through a
> "CC: <stable@" tag – but the latter doesn't seem to be the case here
> (not totally sure, but it looks like AUTOSEL picked this up) and it's a
> quite old series.

That is all true.

So can the original report be sent to stable@vger.kernel.org and we can
take it from there?

thanks,

greg k-h

Re: [PATCH 1/3] ARM: dts: meson: Fix the UART compatible strings

[Ricardo Cañuelo]

Thanks Thorsten and Greg,

I sent the original report to stable@vger.kernel.org. Sorry for
the confusion, I'm still learning about how report regressions
properly using regzbot, specially for stable branches. Thorsten's
guidelines are being very helpful here.

Cheers,
Ricardo

Re: [PATCH 1/3] ARM: dts: meson: Fix the UART compatible strings

[Linux regression tracking (Thorsten Leemhuis)]

On 10.04.23 08:09, Ricardo Cañuelo wrote:
> 
> I sent the original report to stable@vger.kernel.org. 

thx! let me tell regzbot about it:

#regzbot monitor:
https://lore.kernel.org/all/1fcff522-337a-c334-42a7-bc9b4f0daec4@collabora.com/
#regzbot ignore-activity

> Sorry for
> the confusion, I'm still learning about how report regressions
> properly using regzbot, specially for stable branches. Thorsten's
> guidelines are being very helpful here.

Great to hear! But FWIW, I really should try to find some time to fine
tune reporting-issues.rst, reporting-regressions.rst, and
handling-regressions.rst some more, as there are quite a few things that
afaics could or need to be improved. Especially the aspect
"stable/longterm is handled by different set of people (but regular
developers might help)" is something that needs to become clearer afaics.

But there is still this "there are only 24 hours in a day, but so many
things to do" problem...

Ciao, Thorsten