Hello,
here are three UART device-tree schema related fixes for the 32-bit
ARM SoCs.
These patches don't fix any functionality which is why linux-stable
is not Cc'ed on them.
Martin Blumenstingl (3):
ARM: dts: meson: Fix the UART compatible strings
ARM: dts: meson8: Fix the UART device-tree schema validation
ARM: dts: meson8b: Fix the UART device-tree schema validation
arch/arm/boot/dts/meson.dtsi | 8 ++++----
arch/arm/boot/dts/meson8.dtsi | 24 ++++++++++++------------
arch/arm/boot/dts/meson8b.dtsi | 24 ++++++++++++------------
3 files changed, 28 insertions(+), 28 deletions(-)
--
2.34.1
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 <[email protected]>
---
arch/arm/boot/dts/meson.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
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";
--
2.34.1
The dt-bindings for the UART controller only allow the following values
for Meson8 SoCs:
- "amlogic,meson8-uart", "amlogic,meson-ao-uart"
- "amlogic,meson8-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.
Also update the order of the clocks to match the order defined in the
yaml schema.
Fixes: 6ca77502050eff ("ARM: dts: meson8: use stable UART bindings with correct gate clock")
Signed-off-by: Martin Blumenstingl <[email protected]>
---
arch/arm/boot/dts/meson8.dtsi | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index f80ddc98d3a2..9997a5d0333a 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -736,27 +736,27 @@ &timer_abcde {
};
&uart_AO {
- compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
- clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_CLK81>;
- clock-names = "baud", "xtal", "pclk";
+ compatible = "amlogic,meson8-uart", "amlogic,meson-ao-uart";
+ clocks = <&xtal>, <&clkc CLKID_CLK81>, <&clkc CLKID_CLK81>;
+ clock-names = "xtal", "pclk", "baud";
};
&uart_A {
- compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
- clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART0>;
- clock-names = "baud", "xtal", "pclk";
+ compatible = "amlogic,meson8-uart";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
+ clock-names = "xtal", "pclk", "baud";
};
&uart_B {
- compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
- clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART1>;
- clock-names = "baud", "xtal", "pclk";
+ compatible = "amlogic,meson8-uart";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
+ clock-names = "xtal", "pclk", "baud";
};
&uart_C {
- compatible = "amlogic,meson8-uart", "amlogic,meson-uart";
- clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART2>;
- clock-names = "baud", "xtal", "pclk";
+ compatible = "amlogic,meson8-uart";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
+ clock-names = "xtal", "pclk", "baud";
};
&usb0 {
--
2.34.1
The dt-bindings for the UART controller only allow the following values
for Meson8 SoCs:
- "amlogic,meson8b-uart", "amlogic,meson-ao-uart"
- "amlogic,meson8b-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.
Also update the order of the clocks to match the order defined in the
yaml bindings.
Fixes: b02d6e73f5fc96 ("ARM: dts: meson8b: use stable UART bindings with correct gate clock")
Signed-off-by: Martin Blumenstingl <[email protected]>
---
arch/arm/boot/dts/meson8b.dtsi | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index b49b7cbaed4e..94f1c03decce 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -724,27 +724,27 @@ &timer_abcde {
};
&uart_AO {
- compatible = "amlogic,meson8b-uart", "amlogic,meson-uart";
- clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_CLK81>;
- clock-names = "baud", "xtal", "pclk";
+ compatible = "amlogic,meson8b-uart", "amlogic,meson-ao-uart";
+ clocks = <&xtal>, <&clkc CLKID_CLK81>, <&clkc CLKID_CLK81>;
+ clock-names = "xtal", "pclk", "baud";
};
&uart_A {
- compatible = "amlogic,meson8b-uart", "amlogic,meson-uart";
- clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART0>;
- clock-names = "baud", "xtal", "pclk";
+ compatible = "amlogic,meson8b-uart";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
+ clock-names = "xtal", "pclk", "baud";
};
&uart_B {
- compatible = "amlogic,meson8b-uart", "amlogic,meson-uart";
- clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART1>;
- clock-names = "baud", "xtal", "pclk";
+ compatible = "amlogic,meson8b-uart";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
+ clock-names = "xtal", "pclk", "baud";
};
&uart_C {
- compatible = "amlogic,meson8b-uart", "amlogic,meson-uart";
- clocks = <&clkc CLKID_CLK81>, <&xtal>, <&clkc CLKID_UART2>;
- clock-names = "baud", "xtal", "pclk";
+ compatible = "amlogic,meson8b-uart";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&clkc CLKID_CLK81>;
+ clock-names = "xtal", "pclk", "baud";
};
&usb0 {
--
2.34.1
Hi Neil,
On Mon, Dec 27, 2021 at 7:00 PM Martin Blumenstingl
<[email protected]> wrote:
>
> Hello,
>
> here are three UART device-tree schema related fixes for the 32-bit
> ARM SoCs.
> These patches don't fix any functionality which is why linux-stable
> is not Cc'ed on them.
The statement above still stands.
I would like you to apply this series to a 5.17-fixes branch because
of a change from the tty.git tree which will be going into 5.17 to
drop the "amlogic,meson-uart" earlycon handling: [0]
To make it clear: Backporting this series to kernels older than 5.17
won't break or fix anything.
Only 5.17 and newer will need this due to a change [0] in the tty.git
tree. Without the patches from this series the 32-bit SoCs won't have
earlycon support in 5.17.
Thank you!
Martin
[0] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=ad234e2bac274a43c9fa540bde8cd9f0c627b71f
Hi,
On 31/12/2021 16:38, Martin Blumenstingl wrote:
> Hi Neil,
>
> On Mon, Dec 27, 2021 at 7:00 PM Martin Blumenstingl
> <[email protected]> wrote:
>>
>> Hello,
>>
>> here are three UART device-tree schema related fixes for the 32-bit
>> ARM SoCs.
>> These patches don't fix any functionality which is why linux-stable
>> is not Cc'ed on them.
> The statement above still stands.
> I would like you to apply this series to a 5.17-fixes branch because
> of a change from the tty.git tree which will be going into 5.17 to
> drop the "amlogic,meson-uart" earlycon handling: [0]
>
> To make it clear: Backporting this series to kernels older than 5.17
> won't break or fix anything.
> Only 5.17 and newer will need this due to a change [0] in the tty.git
> tree. Without the patches from this series the 32-bit SoCs won't have
> earlycon support in 5.17.
OK, I'll submit it as fixes for for 5.17
Neil
>
>
> Thank you!
> Martin
>
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next&id=ad234e2bac274a43c9fa540bde8cd9f0c627b71f
>
> _______________________________________________
> linux-amlogic mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
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/[email protected]/
) 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
> [email protected]
> 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/[email protected]/
> ) 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/[email protected]/
>> ) 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/[email protected]/
> >> ) 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 [email protected] and we can
take it from there?
thanks,
greg k-h
Thanks Thorsten and Greg,
I sent the original report to [email protected]. 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 [email protected].
thx! let me tell regzbot about it:
#regzbot monitor:
https://lore.kernel.org/all/[email protected]/
#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