| Message ID | 20211227180026.4068352-2-martin.blumenstingl@googlemail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: dts: meson: fix UART device-tree schema validation | expand |
Hi Martin, On lun 27-12-2021 19:00:24, Martin Blumenstingl wrote: > The dt-bindings for the UART controller only allow the following values > for Meson6 SoCs: > - "amlogic,meson6-uart", "amlogic,meson-ao-uart" > - "amlogic,meson6-uart" > > Use the correct fallback compatible string "amlogic,meson-ao-uart" for > AO UART. Drop the "amlogic,meson-uart" compatible string from the EE > domain UART controllers. 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. Here's the bisection report: https://groups.io/g/kernelci-results/message/40147 KernelCI info: https://linux.kernelci.org/test/case/id/64234f7761021a30b262f776/ Test log: https://storage.kernelci.org/stable-rc/linux-4.14.y/v4.14.311-43-g88e481d604e9/arm/multi_v7_defconfig/gcc-10/lab-baylibre/baseline-meson8b-odroidc1.html Thanks, Ricardo #regzbot introduced: 5225e1b87432dcf0d0fc3440824b91d04c1d6cc1 #regzbot title: no serial output in KernelCI tests on meson8b-odroidc1 for stable-4.14
On 05.04.23 15:29, Ricardo Cañuelo wrote: > Hi Martin, > > On lun 27-12-2021 19:00:24, Martin Blumenstingl wrote: >> The dt-bindings for the UART controller only allow the following values >> for Meson6 SoCs: >> - "amlogic,meson6-uart", "amlogic,meson-ao-uart" >> - "amlogic,meson6-uart" >> >> Use the correct fallback compatible string "amlogic,meson-ao-uart" for >> AO UART. Drop the "amlogic,meson-uart" compatible string from the EE >> domain UART controllers. > > 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. > > Here's the bisection report: > https://groups.io/g/kernelci-results/message/40147 > > KernelCI info: > https://linux.kernelci.org/test/case/id/64234f7761021a30b262f776/ 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? Ciao, Thorsten > Test log: > https://storage.kernelci.org/stable-rc/linux-4.14.y/v4.14.311-43-g88e481d604e9/arm/multi_v7_defconfig/gcc-10/lab-baylibre/baseline-meson8b-odroidc1.html > > Thanks, > Ricardo > > #regzbot introduced: 5225e1b87432dcf0d0fc3440824b91d04c1d6cc1 > #regzbot title: no serial output in KernelCI tests on meson8b-odroidc1 > for stable-4.14 > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi, 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. Regards, Ricardo
[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
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
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
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
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi index 3be7cba603d5..26eaba3fa96f 100644 --- a/arch/arm/boot/dts/meson.dtsi +++ b/arch/arm/boot/dts/meson.dtsi @@ -59,7 +59,7 @@ hwrng: rng@8100 { }; uart_A: serial@84c0 { - compatible = "amlogic,meson6-uart", "amlogic,meson-uart"; + compatible = "amlogic,meson6-uart"; reg = <0x84c0 0x18>; interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>; fifo-size = <128>; @@ -67,7 +67,7 @@ uart_A: serial@84c0 { }; uart_B: serial@84dc { - compatible = "amlogic,meson6-uart", "amlogic,meson-uart"; + compatible = "amlogic,meson6-uart"; reg = <0x84dc 0x18>; interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>; status = "disabled"; @@ -105,7 +105,7 @@ saradc: adc@8680 { }; uart_C: serial@8700 { - compatible = "amlogic,meson6-uart", "amlogic,meson-uart"; + compatible = "amlogic,meson6-uart"; reg = <0x8700 0x18>; interrupts = <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>; status = "disabled"; @@ -228,7 +228,7 @@ ir_receiver: ir-receiver@480 { }; uart_AO: serial@4c0 { - compatible = "amlogic,meson6-uart", "amlogic,meson-ao-uart", "amlogic,meson-uart"; + compatible = "amlogic,meson6-uart", "amlogic,meson-ao-uart"; reg = <0x4c0 0x18>; interrupts = <GIC_SPI 90 IRQ_TYPE_EDGE_RISING>; status = "disabled";
The dt-bindings for the UART controller only allow the following values for Meson6 SoCs: - "amlogic,meson6-uart", "amlogic,meson-ao-uart" - "amlogic,meson6-uart" Use the correct fallback compatible string "amlogic,meson-ao-uart" for AO UART. Drop the "amlogic,meson-uart" compatible string from the EE domain UART controllers. Fixes: ec9b59162fd831 ("ARM: dts: meson6: use stable UART bindings") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)