* [PATCH 0/2] amba/serial: amba-pl011: Bring back zx29 UART support
From: Stefan Dösinger @ 2026-05-13 21:34 UTC (permalink / raw)
To: Russell King, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-arm-kernel, linux-kernel, linux-serial,
Stefan Dösinger, Linus Walleij
This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte
zx platform"). It was previously discussed and reviewed on the
linux-arm-kernel mailing list as part of my patchset to add initial
support for ZTE's zx297520v3 router board. I am sending the two UART
driver patches to linux-serial. The rest goes through the soc list.
Note that the first patch (LLDEBUG) uses a Kconfig symbol introduced by
my platform patch, which was sent to the soc mailing list. I don't know
what the correct way to handle this is. I can delay/resend this patchset
after the soc changes are merged.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Stefan Dösinger (2):
ARM: zte: Add support for zx29 low level debug
amba/serial: amba-pl011: Bring back zx29 UART support
arch/arm/Kconfig.debug | 12 ++++++++++++
arch/arm/include/debug/pl01x.S | 9 +++++++++
drivers/tty/serial/amba-pl011.c | 42 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 63 insertions(+)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260513-zx29uart-ef44af731390
Best regards,
--
Stefan Dösinger <stefandoesinger@gmail.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: adc: sun20i-gpadc: add A523 gpadc support
From: Andy Shevchenko @ 2026-05-13 21:34 UTC (permalink / raw)
To: Andre Przywara
Cc: Sanjay Chitroda, Michal Piekos, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maksim Kiselev, linux-iio, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260513231901.05dc9a82@ryzen.lan>
On Wed, May 13, 2026 at 11:19:01PM +0200, Andre Przywara wrote:
> On Wed, 13 May 2026 23:12:05 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Wed, May 13, 2026 at 01:53:49PM +0200, Andre Przywara wrote:
> > > On 5/13/26 13:44, Sanjay Chitroda wrote:
> > > > On 13 May 2026 10:29:43 am IST, Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
...
> > > > > + if (ret <= 0)
> > > >
> > > > Thank you Michal for the change.
> > > >
> > > > Have you validated the changes ?
> > > > It looks while success ret would be 0 and it would give return error.
>
> No, it doesn't. Returning 0 means no clocks found:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-devres.c#n300
>
> > Good catch!
> >
> > > But devm_clk_bulk_get_all_enabled() returns the number of clocks found and
> > > enabled. And since we need at least one, I think this is correct, and the
> > > error message below reflects that.
> > >
> > > To me that change looks good:
> > >
> > > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> >
> > == 0 ???
> > Doesn't look like correct code.
>
> Not sure I follow:
> devm_clk_bulk_get_all_enabled() returns the number of clocks in that
> node, or a negative error value. If it returns 0, that means no clocks
> have been found,
Not in this code. Here it will be resent to the caller as success.
> which is an error in our case, since we expect at
> least one clock. This is what the second part of the error message
> refers to.
But not the error code itself! There will be no error message, IIRC the
implementation of dev_err_probe().
> So we want one or two as the return value, with the current bindings,
> but really anything greater than 0 is fine, from the driver's
> perspective, since we don't care about the clocks beyond them being
> enabled.
>
> So am I missing something?
Yes!
You returned that to the caller, meaning everything is fine. There is a success
that is returned. The code is buggy (okay, not that, it rather will behave not
as intended).
TL;DR:
You should have something like
if (ret < 0)
return dev_err_probe(ret);
if (ret == 0)
return dev_err_probe(-Exxx, "Needs at least one clock!\n");
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Herzlichen Glückwunsch
From: Euro Millions @ 2026-05-13 21:28 UTC (permalink / raw)
To: linux-arm-kernel
Herzlichen Glückwunsch, Sie haben €650.000,00 bei den monatlichen
Gewinnspielen von Euro Millions/Google Promo am 1.Mai 2026
gewonnen.
Bitte geben Sie die folgenden Informationen ein, damit Ihr
Gewinnbetrag an Sie überwiesen werden kann.
Vollständiger Name:
Heimatadresse:
Geschlecht:
Alter:
Telefon:
John Andrew
Online-Koordinator
^ permalink raw reply
* [GIT PULL] arm: zte: defconfig: zx297520v3 defconfig for 7.2
From: Stefan Dösinger @ 2026-05-13 21:21 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
Hi,
This final pull request adds a defconfig file for zx297520v3 boards. The rationale behind the defconfig is that this board is too underpowered for multi_v7_defconfig and quite odd - it is a Cortex A53 without an FPU running in 32 bit mode.
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://gitlab.com/stefandoesinger/zx297520-kernel.git tags/zx29-defconfig-for-7.2
for you to fetch changes up to 9afbe04564c59a217c7d1142ce685c4bd951a8d9:
ARM: zte: defconfig: Add a zx29 defconfig file (2026-05-14 00:04:05 +0300)
----------------------------------------------------------------
ARM: zte: defconfig: zx29 defconfig file for 7.2
The rationale behind the defconfig is that this board is too
underpowered for multi_v7_defconfig and quite odd - it is a Cortex A53
without an FPU running in 32 bit mode.
----------------------------------------------------------------
Stefan Dösinger (1):
ARM: zte: defconfig: Add a zx29 defconfig file
arch/arm/configs/zx29_defconfig | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 arch/arm/configs/zx29_defconfig
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [GIT PULL] ARM: dts: zte: Add ZTE zx297520v3 for 7.2
From: Stefan Dösinger @ 2026-05-13 21:20 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
Dear SoC Maintainers,
This pull request adds a device tree board binding for zx297520v3 boards and one initial board (D-Link DWR-932M) that is based on it.
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://gitlab.com/stefandoesinger/zx297520-kernel.git tags/zx29-dts-for-7.2
for you to fetch changes up to 7d1f68e87b7302d0bd22c001e6c0511d0e827875:
ARM: dts: zte: Add D-Link DWR-932M support (2026-05-14 00:02:39 +0300)
----------------------------------------------------------------
ARM: dts: zte: zx297520v3 device tree for 7.2
This pull request adds board bindings and DTS files for ZTE zx297520v3
boards as well as one initial device (D-Link DWR 932M) based on this
board.
----------------------------------------------------------------
Stefan Dösinger (2):
dt-bindings: arm: zte: Add D-Link DWR932M board based on zx297520v3 SoC
ARM: dts: zte: Add D-Link DWR-932M support
Documentation/devicetree/bindings/arm/zte.yaml | 26 ++++++++++++++++++++++++++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zte/Makefile | 3 +++
arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts | 22 ++++++++++++++++++++++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 103 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 155 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/zte.yaml
create mode 100644 arch/arm/boot/dts/zte/Makefile
create mode 100644 arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts
create mode 100644 arch/arm/boot/dts/zte/zx297520v3.dtsi
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [GIT PULL] ARM: zte: Add zx297520v3 platform support
From: Stefan Dösinger @ 2026-05-13 21:19 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]
Dear SoC maintainers,
Here is my pull request for adding initial support for ZTE's zx297520v3 SoC.
The code has been reviewed on the linux-arm-kernel mailing list. My ultimate
goal is to run OpenWRT on these devices.
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
and sold by ISPs themselves. They are widespread in Africa, China,
Russia and Eastern Europe.
This SoC is a relative of the zx296702 and zx296718 that had some
upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
platform").
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://gitlab.com/stefandoesinger/zx297520-kernel.git tags/zx29-plat-for-7.2
for you to fetch changes up to 220ae5d36dba278003d265aabd080ffa78553f5a:
ARM: zte: Add zx297520v3 platform support (2026-05-13 23:59:56 +0300)
----------------------------------------------------------------
ARM: zte: Add zx297520v3 platform support
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
and sold by ISPs themselves. They are widespread in Africa, China,
Russia and Eastern Europe.
This SoC is a relative of the zx296702 and zx296718 that had some
upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
platform").
----------------------------------------------------------------
Stefan Dösinger (1):
ARM: zte: Add zx297520v3 platform support
Documentation/arch/arm/index.rst | 2 ++
Documentation/arch/arm/zte/index.rst | 10 ++++++++++
Documentation/arch/arm/zte/zx297520v3.rst | 167 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MAINTAINERS | 9 +++++++++
arch/arm/Kconfig | 2 ++
arch/arm/Makefile | 1 +
arch/arm/mach-zte/Kconfig | 29 +++++++++++++++++++++++++++++
arch/arm/mach-zte/Makefile | 2 ++
arch/arm/mach-zte/zx297520v3.c | 16 ++++++++++++++++
9 files changed, 238 insertions(+)
create mode 100644 Documentation/arch/arm/zte/index.rst
create mode 100644 Documentation/arch/arm/zte/zx297520v3.rst
create mode 100644 arch/arm/mach-zte/Kconfig
create mode 100644 arch/arm/mach-zte/Makefile
create mode 100644 arch/arm/mach-zte/zx297520v3.c
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: adc: sun20i-gpadc: add A523 gpadc support
From: Andre Przywara @ 2026-05-13 21:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sanjay Chitroda, Michal Piekos, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maksim Kiselev, linux-iio, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <agTbFbicv9yzTQb9@ashevche-desk.local>
On Wed, 13 May 2026 23:12:05 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
Hi Andy,
> On Wed, May 13, 2026 at 01:53:49PM +0200, Andre Przywara wrote:
> > On 5/13/26 13:44, Sanjay Chitroda wrote:
> > > On 13 May 2026 10:29:43 am IST, Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
>
> > > > + if (ret <= 0)
> > >
> > > Thank you Michal for the change.
> > >
> > > Have you validated the changes ?
> > > It looks while success ret would be 0 and it would give return error.
No, it doesn't. Returning 0 means no clocks found:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-devres.c#n300
>
> Good catch!
>
> > But devm_clk_bulk_get_all_enabled() returns the number of clocks found and
> > enabled. And since we need at least one, I think this is correct, and the
> > error message below reflects that.
> >
> > To me that change looks good:
> >
> > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>
> == 0 ???
> Doesn't look like correct code.
Not sure I follow:
devm_clk_bulk_get_all_enabled() returns the number of clocks in that
node, or a negative error value. If it returns 0, that means no clocks
have been found, which is an error in our case, since we expect at
least one clock. This is what the second part of the error message
refers to.
So we want one or two as the return value, with the current bindings,
but really anything greater than 0 is fine, from the driver's
perspective, since we don't care about the clocks beyond them being
enabled.
So am I missing something?
Cheers,
Andre
^ permalink raw reply
* [PATCH] arm64: dts: ti: k3-am62l: Enable HDMI & DSI display
From: Swamil Jain @ 2026-05-13 21:09 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt, tomi.valkeinen
Cc: r-sharma3, devarsht, praneeth, linux-arm-kernel, devicetree,
linux-kernel, s-jain1
From: Devarsh Thakkar <devarsht@ti.com>
Enable DSS, DSI and HDMI related nodes and pinmuxes.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Swamil Jain <s-jain1@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62l-main.dtsi | 47 ++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am62l3-evm.dts | 58 +++++++++++++++++++++++
2 files changed, 105 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62l-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62l-main.dtsi
index 80615ca1e01a..1d255c9138db 100644
--- a/arch/arm64/boot/dts/ti/k3-am62l-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62l-main.dtsi
@@ -584,4 +584,51 @@ scmi_shmem: sram@0 {
bootph-all;
};
};
+
+ dss: dss@30200000 {
+ compatible = "ti,am62l-dss";
+ reg = <0x00 0x30200000 0x00 0x1000>, /* common */
+ <0x00 0x30202000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x3020a000 0x00 0x1000>, /* vp1 */
+ <0x00 0x30201000 0x00 0x1000>; /* common1 */
+ reg-names = "common", "vidl1", "ovr1", "vp1", "common1";
+ power-domains = <&scmi_pds 39>;
+ clocks = <&scmi_clk 162>,
+ <&scmi_clk 161>;
+ clock-names = "fck", "vp1";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+
+ dss_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ dphy_tx0: phy@301c0000 {
+ compatible = "ti,j721e-dphy";
+ reg = <0x0 0x301c0000 0x0 0x1000>;
+ clocks = <&scmi_clk 348>, <&scmi_clk 343>;
+ clock-names = "psm", "pll_ref";
+ #phy-cells = <0>;
+ power-domains = <&scmi_pds 86>;
+ assigned-clocks = <&scmi_clk 343>;
+ assigned-clock-parents = <&scmi_clk 341>;
+ assigned-clock-rates = <25000000>;
+ status = "disabled";
+ };
+
+ dsi0: dsi@30500000 {
+ compatible = "ti,j721e-dsi";
+ reg = <0x0 0x30500000 0x0 0x100000>, <0x0 0x30270000 0x0 0x100>;
+ clocks = <&scmi_clk 155>, <&scmi_clk 158>;
+ clock-names = "dsi_p_clk", "dsi_sys_clk";
+ power-domains = <&scmi_pds 38>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&dphy_tx0>;
+ phy-names = "dphy";
+ status = "disabled";
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts b/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
index a1af4571a815..7462921e2180 100644
--- a/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
@@ -119,6 +119,18 @@ vcc_1v8: regulator-3 {
regulator-always-on;
regulator-boot-on;
};
+
+ hdmi0: connector-hdmi {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&sii9022_out>;
+ };
+ };
+ };
};
&gpio0 {
@@ -192,6 +204,36 @@ exp2: gpio@23 {
bootph-all;
};
+ sii9022: bridge-hdmi@3b {
+ compatible = "sil,sii9022";
+ reg = <0x3b>;
+ interrupt-parent = <&exp1>;
+ interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
+ #sound-dai-cells = <0>;
+ sil,i2s-data-lanes = < 0 >;
+ bootph-all;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ sii9022_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ sii9022_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
};
&i2c2 {
@@ -375,6 +417,22 @@ &usb1 {
pinctrl-0 = <&usb1_default_pins>;
};
+&dss {
+ status = "okay";
+ bootph-all;
+};
+
+&dss_ports {
+ /* VP1: DPI Output */
+ port@0 {
+ reg = <0>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&sii9022_in>;
+ };
+ };
+};
+
&wkup_uart0 {
pinctrl-0 = <&wkup_uart0_pins_default>;
pinctrl-names = "default";
^ permalink raw reply related
* [PATCH v1] ARM: devtree: Fix /cpus node reference leak
From: Yuho Choi @ 2026-05-13 20:57 UTC (permalink / raw)
To: Russell King; +Cc: linux-arm-kernel, linux-kernel, Yuho Choi
of_find_node_by_path() returns a referenced device node. In
arm_dt_init_cpu_maps(), the /cpus node is kept across CPU node parsing
but is never released on the success path or on post-acquire error
paths.
Route all exits after the /cpus lookup through a common cleanup label so
the node reference is dropped.
Fixes: a0ae02405076a ("ARM: kernel: add device tree init map function")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
arch/arm/kernel/devtree.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 3b78966e750a..88a072d3b8e1 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -93,7 +93,7 @@ void __init arm_dt_init_cpu_maps(void)
*/
if (hwid & ~MPIDR_HWID_BITMASK) {
of_node_put(cpu);
- return;
+ goto out_put_cpus;
}
/*
@@ -107,7 +107,7 @@ void __init arm_dt_init_cpu_maps(void)
if (WARN(tmp_map[j] == hwid,
"Duplicate /cpu reg properties in the DT\n")) {
of_node_put(cpu);
- return;
+ goto out_put_cpus;
}
/*
@@ -149,7 +149,7 @@ void __init arm_dt_init_cpu_maps(void)
if (!bootcpu_valid) {
pr_warn("DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map\n");
- return;
+ goto out_put_cpus;
}
/*
@@ -162,6 +162,9 @@ void __init arm_dt_init_cpu_maps(void)
cpu_logical_map(i) = tmp_map[i];
pr_debug("cpu logical map 0x%x\n", cpu_logical_map(i));
}
+
+out_put_cpus:
+ of_node_put(cpus);
}
bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 11/11] iio: dac: add mcf54415 DAC
From: Andy Shevchenko @ 2026-05-13 20:28 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Greg Ungerer,
linux-m68k, linux-kernel, linux-stm32, linux-arm-kernel,
linux-iio
In-Reply-To: <20260513-wip-stmark2-dac-v2-11-fcdae50cf51a@baylibre.com>
On Wed, May 13, 2026 at 11:14:35AM +0200, Angelo Dureghello wrote:
>
> Add basic version of mcf54415 DAC driver. DAC is embedded in the cpu and
> DAC configuration registers are mapped in the internal IO address space.
>
> The DAC accepts a 12-bit digital signal and creates a monotonic 12-bit
> analog output varying from DAC_VREFL to DAC_VREFH. The DAC module
> consists of a conversion unit, an output amplifier, and the associated
> digital control blocks. Default register values for DAC_VREFL and DAC_VREFH
> are respectively 0 and 0xfff, left untouched in this initial version.
>
> This initial version of the driver is minimalistic, "output raw" only, to
> be extended in the future. DMA and external sync are disabled, default mode
> is high speed, default format is right-justified 12bit on 16bit word.
...
> +#include <linux/array_size.h>
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/compiler_types.h>
> +#include <linux/delay.h>
+ err.h
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
...
> +struct mcf54415_dac {
> + struct clk *clk;
> + struct regmap *map;
I believe that regmap pointer is used more often, can you check with
bloat-o-meter that swapping these two (by the order) gives any benefit in
object size?
> +};
...
> + .max_register = 0x1F,
No definition? What datasheet says about this? Perhaps define the MAX as per
last defined register in the datasheet?
> +};
...
> +static void mcf54415_dac_init(struct mcf54415_dac *info)
> +{
> + /* Keeping defaults and enable DAC (bit 0 set to 0) */
> + regmap_write(info->map, MCF54415_DAC_CR, MCF54415_DAC_CR_FILT |
> + FIELD_PREP(MCF54415_DAC_CR_WMLVL, 1));
Seems the whole driver ignores IO errors, why?
> + /* DAC is ready after 12us, from RM table 40-3 */
> + fsleep(12);
> +}
...
> +static void mcf54415_dac_exit(void *data)
> +{
> + struct mcf54415_dac *info = data;
> +
> + regmap_update_bits(info->map, MCF54415_DAC_CR, MCF54415_DAC_CR_PDN,
> + MCF54415_DAC_CR_PDN);
regmap_set_bits()
> +}
...
> +static int mcf54415_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct mcf54415_dac *info = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (val < 0 || val > 4095)
Do we have a definition for the resolution? I'm fine with the plain numbers,
but it's better to add a short comment to say that this is "based on the
resolution of XXX register per datasheet".
> + return -EINVAL;
> + regmap_write(info->map, MCF54415_DAC_DATA, val);
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
...
> +static int mcf54415_dac_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct iio_dev *indio_dev;
> + struct mcf54415_dac *info;
> + void __iomem *regs;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*info));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + info = iio_priv(indio_dev);
> +
> + regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(regs))
> + return dev_err_probe(dev, PTR_ERR(regs),
> + "failed to get io regs\n");
One line.
> +
> + info->map = devm_regmap_init_mmio(dev, regs,
> + &mcf54415_dac_regmap_config);
> + if (IS_ERR(info->map))
> + return PTR_ERR(info->map);
> +
> + info->clk = devm_clk_get_enabled(dev, "dac");
> + if (IS_ERR(info->clk))
> + return dev_err_probe(dev, PTR_ERR(info->clk),
> + "failed getting clock\n");
Also can be a single line, but this one a bit longer than above, gives
88 characters.
> + platform_set_drvdata(pdev, indio_dev);
> +
> + indio_dev->name = "mcf54415";
> + indio_dev->info = &mcf54415_dac_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = mcf54415_dac_iio_channels;
> + indio_dev->num_channels = ARRAY_SIZE(mcf54415_dac_iio_channels);
> +
> + mcf54415_dac_init(info);
> +
> + ret = devm_add_action_or_reset(dev, mcf54415_dac_exit, info);
> + if (ret)
> + return ret;
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] media: rc: sunxi-cir: unregister rc device on probe failure
From: Jernej Škrabec @ 2026-05-13 20:23 UTC (permalink / raw)
To: Sean Young, Mauro Carvalho Chehab, 박명훈
Cc: Myeonghun Pak, Chen-Yu Tsai, Samuel Holland, linux-media,
linux-arm-kernel, linux-sunxi, linux-kernel, stable, Ijae Kim
In-Reply-To: <20260424000000.558-1-mhun512@gmail.com>
Dne sreda, 13. maj 2026 ob 09:11:03 Srednjeevropski poletni čas je 박명훈 napisal(a):
> From: Myeonghun Pak <mhun512@gmail.com>
>
> After rc_register_device() succeeds, later probe failures must undo the
> registration with rc_unregister_device(). The current error path jumps to
> the allocation cleanup label and only calls rc_free_device(), leaving the
> rc device registration and resources created by rc_register_device()
> behind.
>
> Add a registered-device unwind label for the IRQ lookup, IRQ request, and
> hardware initialization failure paths. Keep rc_free_device() for failures
> before rc_register_device() succeeds.
>
> Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver")
> Cc: stable@vger.kernel.org
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> ---
> drivers/media/rc/sunxi-cir.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> index 92ef4e7c6f..cc64a68dfe 100644
> --- a/drivers/media/rc/sunxi-cir.c
> +++ b/drivers/media/rc/sunxi-cir.c
> @@ -344,22 +344,26 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> ir->irq = platform_get_irq(pdev, 0);
> if (ir->irq < 0) {
> ret = ir->irq;
> - goto exit_free_dev;
> + goto exit_unregister_dev;
> }
>
> ret = devm_request_irq(dev, ir->irq, sunxi_ir_irq, 0, SUNXI_IR_DEV, ir);
> if (ret) {
> dev_err(dev, "failed request irq\n");
> - goto exit_free_dev;
> + goto exit_unregister_dev;
> }
>
> ret = sunxi_ir_hw_init(dev);
> if (ret)
> - goto exit_free_dev;
> + goto exit_unregister_dev;
>
> dev_info(dev, "initialized sunXi IR driver\n");
> return 0;
>
> +exit_unregister_dev:
> + rc_unregister_device(ir->rc);
> + return ret;
This return should not be here. Device must be freed too.
Best regards,
Jernej
> +
> exit_free_dev:
> rc_free_device(ir->rc);
>
>
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: David Sterba @ 2026-05-13 20:19 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Herbert Xu, Dan Williams,
Chris Mason, David Sterba, Arnd Bergmann, Song Liu, Yu Kuai,
Li Nan, linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260513054742.GA1018@lst.de>
On Wed, May 13, 2026 at 07:47:42AM +0200, Christoph Hellwig wrote:
> On Tue, May 12, 2026 at 01:42:31PM +0200, David Sterba wrote:
> > On Tue, May 12, 2026 at 07:20:41AM +0200, Christoph Hellwig wrote:
> > > While the RAID6 algorithm could in theory support 3 devices by just
> > > copying the data disk to the two parity disks, this version is not only
> > > useless because it is a suboptimal version of 3-way mirroring, but also
> > > broken with various crashes and incorrect parity generation in various
> > > architecture-optimized implementations. Disallow it similar to mdraid
> > > which requires at least 4 devices for RAID 6.
> > >
> > > Fixes: 53b381b3abeb ("Btrfs: RAID5 and RAID6")
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > This patch should have been sent separately as it has user visible
> > impact and can potentially break some setups.
>
> It _is_ sent out separate.
It's public interface change of btrfs but in a patch series cleaning
up some library code, I noticed it by accident.
> > The degenerate modes of
> > raid0, 5, or 6 are explicit as a possible middle step when converting
> > profiles. We can use a fallback implementation for this case if the
> > accelerated implementations cannot do it.
>
> This is not about a degenerated mode. For a degenerated RAID 6, parity
> generation uses the RAID 5 XOR routines as the second parity will be
> missing. This is about generating two parities for a single data disk,
> which must be explicitly selected.
The calcuation is a different than what I'm concened about, changing
minimum devices from 3 to 4 is a breaking change. If the library won't
provide the xor/parity functions then we'll have to add a fallback for
this special case.
^ permalink raw reply
* Re: [PATCH v2 09/11] m68k: stmark2: use ioport.h macros for resources
From: Andy Shevchenko @ 2026-05-13 20:18 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Greg Ungerer,
linux-m68k, linux-kernel, linux-stm32, linux-arm-kernel,
linux-iio
In-Reply-To: <20260513-wip-stmark2-dac-v2-9-fcdae50cf51a@baylibre.com>
On Wed, May 13, 2026 at 11:14:33AM +0200, Angelo Dureghello wrote:
> Align also other resource declaration using DEFINE_RES_.
DEFINE_RES_*()
...
> static struct resource dspi_spi0_resource[] = {
> - [0] = {
> - .start = MCFDSPI_BASE0,
> - .end = MCFDSPI_BASE0 + 0xFF,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = 12,
> - .end = 13,
> - .flags = IORESOURCE_DMA,
> - },
> - [2] = {
> - .start = MCF_IRQ_DSPI0,
> - .end = MCF_IRQ_DSPI0,
> - .flags = IORESOURCE_IRQ,
> - },
> + DEFINE_RES_MEM(MCFDSPI_BASE0, 0x100),
> + DEFINE_RES_DMA(12),
> + DEFINE_RES_DMA(13),
> + DEFINE_RES_IRQ(MCF_IRQ_DSPI0),
> };
This conversion drops hard indices, would it be a problem (for example,
some code modifies the fields based on the [hard coded] index...)?
If not, perhaps good to mention in the commit message and move IRQ to be the
second one?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 08/11] m68k: stmark2: add mcf5441x DAC platform devices
From: Andy Shevchenko @ 2026-05-13 20:16 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Greg Ungerer,
linux-m68k, linux-kernel, linux-stm32, linux-arm-kernel,
linux-iio
In-Reply-To: <20260513-wip-stmark2-dac-v2-8-fcdae50cf51a@baylibre.com>
On Wed, May 13, 2026 at 11:14:32AM +0200, Angelo Dureghello wrote:
> Add mcf5441x DAC platform devices.
...
> +static struct resource dac0_resource[] = {
> + DEFINE_RES_MEM(MCFDAC_BASE0, 0x100),
> +};
> +
> +static struct platform_device dac0_device = {
> + .name = "mcf54415_dac",
> + .id = 0,
> + .num_resources = ARRAY_SIZE(dac0_resource),
> + .resource = dac0_resource,
> +};
It can be
static struct resource dac0_resource = DEFINE_RES_MEM(MCFDAC_BASE0, 0x100);
static struct platform_device dac0_device = {
.name = "mcf54415_dac",
.id = 0,
.num_resources = 1,
.resource = &dac0_resource,
};
...
Same for the rest. But I haven't seen the followups and don't know if those
structures are going to be expanded. The commit message doesn't say anything
about that. So I assume my suggestion valid.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: adc: sun20i-gpadc: add A523 gpadc support
From: Andy Shevchenko @ 2026-05-13 20:12 UTC (permalink / raw)
To: Andre Przywara
Cc: Sanjay Chitroda, Michal Piekos, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maksim Kiselev, linux-iio, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <4248ac7e-3cce-4db8-a2c1-710f2c903490@arm.com>
On Wed, May 13, 2026 at 01:53:49PM +0200, Andre Przywara wrote:
> On 5/13/26 13:44, Sanjay Chitroda wrote:
> > On 13 May 2026 10:29:43 am IST, Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
> > > + if (ret <= 0)
> >
> > Thank you Michal for the change.
> >
> > Have you validated the changes ?
> > It looks while success ret would be 0 and it would give return error.
Good catch!
> But devm_clk_bulk_get_all_enabled() returns the number of clocks found and
> enabled. And since we need at least one, I think this is correct, and the
> error message below reflects that.
>
> To me that change looks good:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
== 0 ???
Doesn't look like correct code.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: adc: sun20i-gpadc: add A523 gpadc support
From: Andy Shevchenko @ 2026-05-13 20:10 UTC (permalink / raw)
To: Michal Piekos
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maksim Kiselev, linux-iio,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <20260513-sunxi-a523-gpadc-v2-2-d5efde151dac@mmpsystems.pl>
On Wed, May 13, 2026 at 06:59:43AM +0200, Michal Piekos wrote:
> A523 differs from existing sun20i-gpadc-iio by having two clocks; bus
> clock and module clock.
>
> Change driver to enable all clocks.
...
> struct iio_dev *indio_dev;
> struct sun20i_gpadc_iio *info;
> struct reset_control *rst;
> - struct clk *clk;
> + struct clk_bulk_data *clks;
Try to follow reversed xmas tree order.
> int irq;
> int ret;
...
> - return dev_err_probe(dev, PTR_ERR(clk), "failed to enable bus clock\n");
> + ret = devm_clk_bulk_get_all_enabled(dev, &clks);
> + if (ret <= 0)
> + return dev_err_probe(
> + dev, ret,
> + "failed to enable clocks or no clocks defined\n");
Is this done by clang-format or so? Please, don't do wrapping on the open
parenthesis. Also note for more than 10 years checkpatch does not complain
on the trailing string literals that go over 80 characters.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: ti: icssg: Derive stats array lengths from ARRAY_SIZE
From: Jacob Keller @ 2026-05-13 20:00 UTC (permalink / raw)
To: MD Danish Anwar, David CARLIER
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Meghana Malladi, Kevin Hao, Vadim Fedorenko, netdev,
linux-doc, linux-kernel, linux-arm-kernel, Vignesh Raghavendra
In-Reply-To: <6a1f411c-d7ed-463b-abf1-277d8cc0c184@ti.com>
On 5/12/2026 2:40 AM, MD Danish Anwar wrote:
> Hi David,
>
> On 12/05/26 1:28 pm, David CARLIER wrote:
>> Hi MD,
>>
>> On Tue, 12 May 2026 at 07:06, MD Danish Anwar <danishanwar@ti.com> wrote:
>>>
>>> Replace the manually maintained ICSSG_NUM_MIIG_STATS and
>>> ICSSG_NUM_PA_STATS constants with ARRAY_SIZE() expressions derived
>>> directly from the corresponding stat descriptor arrays, so that adding
>>> new entries to icssg_all_miig_stats[] or icssg_all_pa_stats[] no longer
>>> requires a separate update to a numeric constant.
>>>
>>> To make this self-contained, break the circular include dependency
>>> between icssg_stats.h and icssg_prueth.h:
>>>
>>> - icssg_stats.h previously included icssg_prueth.h (transitively
>>> pulling in icssg_switch_map.h and ETH_GSTRING_LEN). Replace that
>>> with direct includes of <linux/ethtool.h>, <linux/kernel.h> and
>>> "icssg_switch_map.h".
>>>
>>> - icssg_prueth.h now includes icssg_stats.h, giving it access to
>>> the ARRAY_SIZE-based ICSSG_NUM_MIIG_STATS and ICSSG_NUM_PA_STATS
>>> before they are used in the prueth_emac struct and ICSSG_NUM_STATS.
>>>
>>> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
>>> ---
>>> drivers/net/ethernet/ti/icssg/icssg_prueth.h | 3 +--
>>> drivers/net/ethernet/ti/icssg/icssg_stats.h | 7 ++++++-
>>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_prueth.h b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
>>> index df93d15c5b78..e2ccecb0a0dd 100644
>>> --- a/drivers/net/ethernet/ti/icssg/icssg_prueth.h
>>> +++ b/drivers/net/ethernet/ti/icssg/icssg_prueth.h
>>> @@ -43,6 +43,7 @@
>>>
>>> #include "icssg_config.h"
>>> #include "icss_iep.h"
>>> +#include "icssg_stats.h"
>>> #include "icssg_switch_map.h"
>>>
>>> #define PRUETH_MAX_MTU (2000 - ETH_HLEN - ETH_FCS_LEN)
>>> @@ -57,8 +58,6 @@
>>>
>>> #define ICSSG_MAX_RFLOWS 8 /* per slice */
>>>
>>> -#define ICSSG_NUM_PA_STATS 32
>>> -#define ICSSG_NUM_MIIG_STATS 60
>>> /* Number of ICSSG related stats */
>>> #define ICSSG_NUM_STATS (ICSSG_NUM_MIIG_STATS + ICSSG_NUM_PA_STATS)
>>> #define ICSSG_NUM_STANDARD_STATS 31
>>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> index 5ec0b38e0c67..b854eb587c1e 100644
>>> --- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> +++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> @@ -8,10 +8,15 @@
>>> #ifndef __NET_TI_ICSSG_STATS_H
>>> #define __NET_TI_ICSSG_STATS_H
>>>
>>> -#include "icssg_prueth.h"
>>> +#include <linux/ethtool.h>
>>> +#include <linux/kernel.h>
>>> +#include "icssg_switch_map.h"
>>>
>>> #define STATS_TIME_LIMIT_1G_MS 25000 /* 25 seconds @ 1G */
>>>
>>> +#define ICSSG_NUM_MIIG_STATS ARRAY_SIZE(icssg_all_miig_stats)
>>> +#define ICSSG_NUM_PA_STATS ARRAY_SIZE(icssg_all_pa_stats)
>>> +
>>> struct miig_stats_regs {
>>> /* Rx */
>>> u32 rx_packets;
>>> --
>>> 2.34.1
>>>
>>
>> One thing that caught my eye: icssg_all_miig_stats[] and
>> icssg_all_pa_stats[] are 'static const' arrays in icssg_stats.h with
>> ETH_GSTRING_LEN name buffers per entry. Right now only icssg_stats.c
>> and icssg_ethtool.c pull them in. After this patch icssg_prueth.h
>> includes icssg_stats.h, so every .c in the driver (classifier,
>> common, config, mii_cfg, queues, switchdev, ...) ends up with its own
>> static-const copy of both tables.
>>
>> Would a static_assert() work for what you're after? Something like:
>>
>
> While adding more stats manually, The ARRAY_SIZE() approach was
> explicitly requested by maintainer [1]:
>
> This patch is a direct response to that feedback. static_assert() would
> still require updating the numeric constant on every array change. The
> goal here is to eliminate the need of manually incrementing stats count
> whenever new stats are added
>
> Your concern about multiple copies of table is noted and valid. Could
> you advise on the preferred way to reconcile these two requirements? I
> am happy to restructure if there is an approach that satisfies both.
>
The way we solved this in the Intel drivers is to use a single array
which contains both the stat name as well as the offset from the
structure where the stat resides.
The stat string code just iterates over the stat list for the strings,
while the stat value code iterates the array and computes the stat
address from the offset and size and base structure pointer. Each object
that has stats has its own stat array structure.
This is probably overkill, but the advantage is that the strings and
their values are stored together and adding a new stat is as simple as
adding a new entry to that list.
I.e.
struct ice_stats {
char stat_string[ETH_GSTRING_LEN];
int sizeof_stat;
int stat_offset;
};
#define ICE_STAT(_type, _name, _stat) { \
.stat_string = _name, \
.sizeof_stat = sizeof_field(_type, _stat), \
.stat_offset = offsetof(_type, _stat) \
}
#define ICE_VSI_STAT(_name, _stat) \
ICE_STAT(struct ice_vsi, _name, _stat)
#define ICE_PF_STAT(_name, _stat) \
ICE_STAT(struct ice_pf, _name, _stat)
Then the stats for the individial arrays are defined like this:
static const struct ice_stats ice_gstrings_vsi_stats[] = {
ICE_VSI_STAT(ICE_RX_UNICAST, eth_stats.rx_unicast),
ICE_VSI_STAT(ICE_TX_UNICAST, eth_stats.tx_unicast),
ICE_VSI_STAT(ICE_RX_MULTICAST, eth_stats.rx_multicast),
ICE_VSI_STAT(ICE_TX_MULTICAST, eth_stats.tx_multicast),
ICE_VSI_STAT(ICE_RX_BROADCAST, eth_stats.rx_broadcast),
ICE_VSI_STAT(ICE_TX_BROADCAST, eth_stats.tx_broadcast),
...
};
(Note, ICE_RX_UNICAST is a macro that defines the string value.. I don't
recall who changed this to macros or why vs just having the strings be
directly in the definition...)
This is probably a lot bigger refactor to make work, and may not be
exactly suitable for your driver. I've considered "upgrading" these data
structures and logic as helpers to the core ethtool code (or perhaps
now, to libeth) but never got around to it.
^ permalink raw reply
* Re: [PATCH tty v4 2/6] serial: Replace driver usage of UPF_CONS_FLOW
From: Krzysztof Kozlowski @ 2026-05-13 19:50 UTC (permalink / raw)
To: John Ogness, Greg Kroah-Hartman, Jiri Slaby, Alim Akhtar
Cc: Andy Shevchenko, linux-kernel, David S. Miller,
Ilpo Järvinen, Andy Shevchenko, Thomas Fourier, Kees Cook,
linux-serial, linux-arm-kernel, linux-samsung-soc, sparclinux,
Peter Griffin, Tudor Ambarus, André Draszik, Alexey Klimov
In-Reply-To: <87lddvy2dl.fsf@jogness.linutronix.de>
On 07/05/2026 11:50, John Ogness wrote:
> Hi,
>
> (This email is particularly directed at the Samsung folks.)
>
> Responding to Sashiko:
>
> https://sashiko.dev/#/patchset/20260506121606.5805-1-john.ogness%40linutronix.de
>
> On 2026-05-06, Sashiko wrote:
>>> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
>>> index e27806bf2cf3e..2f94fc798cffb 100644
>>> --- a/drivers/tty/serial/samsung_tty.c
>>> +++ b/drivers/tty/serial/samsung_tty.c
>>> @@ -319,7 +319,7 @@ static void s3c24xx_serial_stop_tx(struct uart_port *port)
>>> ourport->tx_enabled = 0;
>>> ourport->tx_in_progress = 0;
>>>
>>> - if (port->flags & UPF_CONS_FLOW)
>>> + if (uart_cons_flow_enabled(port))
>>> s3c24xx_serial_rx_enable(port);
>>
>> This isn't a new bug introduced by this patch, but does this code
>> result in a recursive spinlock acquisition and deadlock when console
>> flow control is enabled?
>>
>> The serial core framework calls port->ops->stop_tx() with the
>> port->lock spinlock already held. When uart_cons_flow_enabled(port)
>> evaluates to true, s3c24xx_serial_stop_tx() invokes
>> s3c24xx_serial_rx_enable().
>>
>> Looking at s3c24xx_serial_rx_enable(), it unconditionally attempts to
>> acquire the exact same lock again:
>>
>> static void s3c24xx_serial_rx_enable(struct uart_port *port)
>> {
>> struct s3c24xx_uart_port *ourport = to_ourport(port);
>> unsigned long flags;
>> ...
>> uart_port_lock_irqsave(port, &flags);
>> ...
>> }
>>
>> Because spinlocks are not recursive in the kernel, it appears this
>> sequence would cause an immediate deadlock on the same CPU.
>
> Although out of scope for my series, the reported issue is real. Perhaps
> something for Krzysztof or Alim to look into.
>
>>> @@ -493,7 +493,7 @@ static void s3c24xx_serial_start_tx(struct uart_port *port)
>>> struct tty_port *tport = &port->state->port;
>>>
>>> if (!ourport->tx_enabled) {
>>> - if (port->flags & UPF_CONS_FLOW)
>>> + if (uart_cons_flow_enabled(port))
>>> s3c24xx_serial_rx_disable(port);
>>
>> Similarly here, s3c24xx_serial_start_tx() is also called with
>> port->lock held, and s3c24xx_serial_rx_disable() will attempt to
>> acquire port->lock again:
>>
>> static void s3c24xx_serial_rx_disable(struct uart_port *port)
>> {
>> struct s3c24xx_uart_port *ourport = to_ourport(port);
>> unsigned long flags;
>> ...
>> uart_port_lock_irqsave(port, &flags);
>> ...
>> }
>>
>> Could this pre-existing locking issue in the samsung_tty driver be
>> addressed so that the rx enable/disable helpers do not try to take the
>> port lock when it is already held by the caller?
>
> Also legitimate. But out of scope for my series.
Thanks for letting us know. Deadlock did not happen so far, so something
is missing in Sashiko's report. :)
I am just back from vacation, so I won't have time to dig into this, but
I will keep your email in the inbox. Cc-ing also a few Linaro folks
which are using this platform and might be able to help us here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Jamie Nguyen @ 2026-05-13 19:48 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260513-tremendous-conscious-sunfish-06eecb@sudeepholla>
> On May 13, 2026, at 10:15 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
>
> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
>> __ffa_partition_info_get_regs() walks the response with a hardcoded
>> 24-byte stride (regs += 3) even though the SPMC tells us the actual
>> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
>> read into buf_sz and then thrown away.
>>
>> That works while every SPMC returns the FF-A v1.1 layout, but it falls
>> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
>> strides over half a descriptor at a time and ends up parsing every
>> other entry from a slice of two adjacent ones.
>>
>> The FF-A spec (v1.2, section 18.5) says that the producer should
>> report the descriptor size, and the consumer is supposed to stride by
>> that size and ignore any trailing fields it doesn't understand. The
>> non-REGS path (__ffa_partition_info_get) does this already, and the
>> REGS path should match.
>>
>> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
>> reports something we can't safely walk.
>>
>
> Can you check if the issue is addressed in -next by:
> Commit 3974ea193840 ("firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies")
Thanks for the pointer. I tested 3974ea193840 on the same hardware
that reproduces the bug, but the descriptor-stride issue is still
present.
The relevant loop at the end of __ffa_partition_info_get_regs()
still has:
buf_sz = PARTITION_INFO_SZ(partition_info.a2);
if (buf_sz > sizeof(*buffer))
buf_sz = sizeof(*buffer);
...
for (idx = 0; idx < nr_desc; idx++, buf++) {
...
regs += 3; /* bug is here */
}
With 48-byte descriptors the SPMC returns nr_desc = 2 per call,
which passes the new MAX_DESC = 5 bound, and the loop then runs
the 24-byte stride over 48-byte entries.
Here are the test results on the same SBIOS / same hardware:
unpatched: 5 partitions enumerated, two with
garbled UUIDs and partition_ids
3974ea193840 alone: same misparsed enumeration
3974ea193840 + my patch: 6 partitions, all entries correct
So the two fixes look complementary rather than overlapping.
> --
> Regards,
> Sudeep
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme interrupts
From: Krzysztof Kozlowski @ 2026-05-13 19:47 UTC (permalink / raw)
To: mani@kernel.org, Hongxing Zhu
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
bhelgaas@google.com, Frank Li, l.stach@pengutronix.de,
lpieralisi@kernel.org, kwilczynski@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <t3d2s6rl25ywobis4xiwwdvjrccua2qrpwfsxqpvp6qw5pzofa@kjm4wzcpjcli>
On 12/05/2026 15:26, mani@kernel.org wrote:
>>>>>>
>>>>>> These interrupts are optional for existing variants (imx6q, imx6sx,
>>>>>> imx6qp, imx7d, imx8mq, imx8mm, imx8mp) to maintain backward
>>>>>> compatibility with existing device trees.
>>>>>>
>>>>>> For fsl,imx95-pcie, all 5 interrupts (msi, dma, intr, aer, pme) are
>>>>>> mandatory due to hardware requirements.
>>>>>>
>>>>>> This introduces an ABI requirement for fsl,imx95-pcie. The i.MX95
>>>>>> hardware requires dedicated interrupt lines for AER, PME, and
>>>>>> general controller events due to its redesigned interrupt
>>>>>> architecture. i.MX95 cannot function correctly without explicit
>>>>>> interrupt routing for error handling, power management and link event
>>> detection.
>>>>>
>>>>> fsl,imx95-pcie was added more than two years ago, so how it cannot
>>>>> function correctly? Are you saying that for two years you had here
>>>>> completely broken code?
>>>>>
>>>>> If this wasn't tested for two years, how can we believe anything is tested now?
>>>> The basic PCIe functionality has been working since the initial
>>>> fsl,imx95-pcie support. However, AER (Advanced Error Reporting) and
>>>> link up/down detection were not previously enabled. This patch-set
>>>> adds and verifies support for these advanced features.
>>>>
>>>
>>> That is not what you said in the commit msg.
>> Hi Krzysztof:
>> Sorry for the delayed response due to a holiday.
>> After reviewing this patch-set again, I'd like to suggest an alternative
>> approach: would it be possible to mark these newly added interrupts as
>> optional?
>
> Yes, since even without these interrupts, PCIe functionality still works. Only
> issue is that it cannot report error and recover from LDn.
Yes. Please mention how the hardware or SW implementation behave when
these are missing, which is then serving as proof why they can be optional.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] [v2] iommu, debugobjects: avoid gcc-16.1 section mismatch warnings
From: Arnd Bergmann @ 2026-05-13 19:35 UTC (permalink / raw)
To: Miguel Ojeda, Arnd Bergmann
Cc: Will Deacon, Joerg Roedel, Miguel Ojeda, Andrew Morton,
Thomas Gleixner, Nathan Chancellor, linux-kbuild, stable,
Robin Murphy, Kees Cook, linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <CANiq72nbRw14wdZA4GH17K22Krh4ujB_wtuv9u5RQTGtidpq0g@mail.gmail.com>
On Wed, May 13, 2026, at 17:48, Miguel Ojeda wrote:
> On Wed, May 13, 2026 at 4:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
>>
>> With some more experimenting, I found that marking these functions as
>> __attribute__((noipa)) is both logical and reliable.
>>
>> In order to keep the syntax readable, add a custom macro for this in
>> include/linux/compiler_attributes.h next to other related macros and
>> use it to annotate both files.
>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
Thanks!
> If you don't mind, please add underscores (i.e. `((__noipa__))`) and
> place it after `__noinline__` to keep it sorted (the file is meant to
> be sorted by actual attribute name, though some entries were added
> that break that, but I will clean that and a couple other things up at
> some point).
Ok, changed now, will wait for other comments before resending.
Arnd
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Chia-I Wu @ 2026-05-13 19:31 UTC (permalink / raw)
To: Liviu Dudau
Cc: Boris Brezillon, Marcin Ślusarz, Ketil Johnsen, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Daniel Almeida, Alice Ryhl,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin, nd
In-Reply-To: <agNJasayW8VCHTiU@e142607>
On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <liviu.dudau@arm.com> wrote:
>
> On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote:
> > On Tue, 12 May 2026 14:47:27 +0100
> > Liviu Dudau <liviu.dudau@arm.com> wrote:
> >
> > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > > > On Thu, 7 May 2026 11:02:26 +0200
> > > > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> > > >
> > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > > > return ret;
> > > > > > > }
> > > > > > >
> > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > > > >
> > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > > > name is "" already?
> > > > >
> > > > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > > > This check prevents that.
> > > >
> > > > Yeah, that's also a questionable design choice. I mean, we can
> > > > currently probe and boot the FW even though we never setup the
> > > > protected FW sections, so why should we defer the probe here? Can't we
> > > > just retry the next time a group with the protected bit is created and
> > > > fail if we can find a protected heap?
> > >
> > > The problem we have with the current firmware is that it does a number of setup steps at "boot"
> > > time only. One of the steps is preparing its internal structures for when it enters protected
> > > mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> > > process when we have a group with protected mode set.
> >
> > No, but we can force a full/slow reset and have that thing
> > re-initialized, can't we? I mean, that's basically what we do when a
> > fast reset fails: we re-initialize all the sections and reset again, at
> > which point the FW should start from a fresh state, and be able to
> > properly initialize the protected-related stuff if protected sections
> > are populated. Am I missing something?
>
> Right, we can do that. For some reason I keep associating the reset with the
> error handling and not with "normal" operations.
I kind of hope we end up with either
- panthor knows the exact heap to use and fails with EPROBE_DEFER if
the heap is missing, or
- panthor gets a dma-buf from userspace and does the full reset
- userspace also needs to provide a dma-buf for each protected
group for the suspend buffer
than something in-between. The latter is more ad-hoc and basically
kicks the issue to the userspace.
For the former, expressing the relation in DT seems to be the best,
but only if possible :-). Otherwise, a kconfig option (instead of
module param) should be easier to work with.
Looking at the userspace implementation, can we also have an panthor
ioctl to return the heap to userspace? A dma-heap ioctl to query the
heap size is also lacking.
>
> Best regards,
> Liviu
>
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
>
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-13 18:26 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Marc Zyngier, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <CABgObfaM-JtNn2MuYXaiadQnLfAhTEaoHAcTG9=J6LkMcQCJ3A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6837 bytes --]
On Wed, 2026-05-13 at 18:24 +0200, Paolo Bonzini wrote:
> Il mer 13 mag 2026, 15:57 David Woodhouse <dwmw2@infradead.org> ha scritto:
> > > x86 doesn't do bug-for-bug compatibility, thankfully - we have quirks
> > > but only 11 of them, or about one per year since we started adding them.
> > > We only add quirks, generally speaking, when 1) we change the way file
> > > descriptors are initialized, 2) guests in the wild were relying on it,
> > > or 3) it prevends restoring state saved from an old kernel. Is there
> > > anything else?
> > >
> > > https://lore.kernel.org/kvm/e03f092dfbb7d391a6bf2797ba01e122ba080bcd.camel@infradead.org/
> > > is an example of a bug that "no SW can make any reasonable use of".
> >
> > I actually believe that the focus on ICEBP was triggered by some weird
> > gaming software's anti-DRM mechanism, and that it *did* affect actual
> > guests in the wild?
> >
> > But yeah, *fixing* it should not have any adverse effects. That's the
> > key.
>
> Yep, so "bug for bug" is not it.
Of course. I'm not discriminating between 'bugs' and 'features'. In
this context I only care about guest-visible behaviour changes,
whatever the reason.
What I said was:
> > > > Once a behaviour is present in a released version of Linux/KVM, we
> > > > can't just declare it "wrong" and unilaterally impose a change in
> > > > guest-visible behaviour on *running* guests as a side-effect of a
> > > > kernel upgrade.
And yes, you're technically right to challenge that phrasing of it. It
does need the additional caveat of "...unless we are sure that changing
it in either direction underneath running guests cannot cause
problems", as discussed. That's the key for the ICEBP thing.
> >
> > > And besides, both miss the point of *configurability* which is the basis of
> > > it all.
> >
> > Hm, configurability *is* the point, I thought.
>
> Yes, and configurability goes way beyond bugs/quirks, which are to
> some extent a red herring. Configurability for example says that "KVM:
> arm64: vgic: Allow userspace to set IIDR revision 1" shouldn't be
> controversial at all.
Indeed it shouldn't. And yet here we are.
> > > So we have the third case, "restoring state saved from an old kernel".
> > > If this case arises, I do believe that Arm will have to deal with it and
> > > introduce quirks or KVM_GET/SET_REG hacks. Maybe it hasn't happened
> > > yet, lucky you.
> >
> > We literally have those mechanisms already.
>
> I am not talking about guest-visible changes across save/restore here,
> but rather about round-trips through userspace. For example, see the
> effect of KVM_X2APIC_API_USE_32BIT_IDS on KVM_GET/SET_LAPIC: it
> couldn't be made the default, because userspace expects to take old
> data returned by KVM_GET_LAPIC and shove it into KVM_SET_LAPIC. Sucks
> but can't be avoided.
Yes, you're right. And I fully expect and trust x86 to get that right
and not break existing userspace in any way at all.
But honestly, the bar for Arm is so low right now that anything I
physically *can* work around in userspace, I'm prepared to tolerate.
If KVM/arm did the equivalent of just changing the KVM_[SG]ET_LAPIC
data without the KVM_X2APIC_API_USE_32BIT_IDS trick, I wouldn't even
bat an eyelid; I'd just accommodate it and move on.
> > See commit https://git.kernel.org/torvalds/c/49a1a2c70a7f which adds a
> > new guest-visible feature in revision 3, but allowed userspace to
> > restore the old behaviour by setting it to revision 2. All my patch above does, is make it possible to set it to revision 1 as
> > well. Because https://git.kernel.org/torvalds/c/d53c2c29ae0d previously
> > changed the behaviour and bumped the default to 2 *without* allowing
> > userspace to restore the prior behaviour, and we've been carrying a
> > *revert* of that patch.
> >
> > Why would we *not* accept such a patch?
>
> Agreed. Even ignoring your revert, there's no reason why any upgrade
> past 49a1a2c70a7f has to be from after d53c2c29ae0d.
>
> > Marc seems terribly insistent that we SHOULD NOT
> > restore the behaviour that older KVM offered to guests, and we MUST
> > change it unconditionally underneath running guests, making these
> > registers writable on upgrade... and reverting them to read-only for
> > running guests on a rollback.
> >
> > And there we do have a very different viewpoint.
>
> That's the design decision I mentioned, of not starting the guest
> configuration from a clean slate. I believe it complicates things
> because you have to design from the beginning with the ability to
> rollback to old versions and to potentially detect conflicts
> introduced by the rollback. This is exactly why
> KVM_X86_QUIRK_STUFF_FEATURE_MSRS was introduced: "KVM's initialization
> of feature MSRs during vCPU creation results in a failed save/restore
> of PERF_CAPABILITIES. If userspace configures the VM to _not_ have a
> PMU, because KVM initializes the vCPU's PERF_CAPABILITIES, trying to
> save/restore the non-zero value will be rejected by the destination."
> (https://lkml.org/lkml/2024/8/2/1032)
No, I don't think this is like that. In that case, IIUC it was at least
*possible* for userspace to manually filter out capabilities and adjust
things. But it kind of sucked if we *made* userspace do that and broke
things for existing userspace, so of *course* x86 did better.
I'm not even *dreaming* about a world where KVM/arm meets that bar.
> For Arm, however, it may be too late to change it; if not, I'll
> happily watch you argue with Marc about it.
I'm not even going to try. You're right that it's the better option,
and it most certainly *isn't* too late for Arm to choose to be a stable
and mature platform providing continuity to userspace like x86 does.
But we are *so* far from that right now; we're fighting even to have
the *possibility* for userspace to remain compatible — even if
userspace *is* updated to know everything that the latest kernel
changed underneath it.
> But even without that,
> this doc patch (and the idea that "Where a new kernel introduces a
> guest-visible change, it provides a mechanism for userspace to select
> the previous behaviour") should be uncontroversial.
Indeed. And again, if you really want then you can add the caveat
discussed above, "unless you're really sure it won't make *any*
difference to the zoo of possible guests running Linux, Windows,
FreeBSD, or any number of random home-grown or network appliance
operating systems".
Although I didn't think it really needed spelling out in the doc, just
as I didn't think it needed spelling out earlier today (although you
called my sentence nonsense purely because it lacked that obvious
caveat, AFAICT).
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: rockchip: Add LCKFB Taishan Pi 3M
From: Rob Herring (Arm) @ 2026-05-13 19:21 UTC (permalink / raw)
To: Liu Changjie
Cc: devicetree, conor+dt, heiko, linux-arm-kernel, krzk+dt,
linux-rockchip, linux-kernel
In-Reply-To: <MN0PR19MB6091C07C729B83E594722E84AC3C2@MN0PR19MB6091.namprd19.prod.outlook.com>
On Thu, 07 May 2026 11:07:52 +0800, Liu Changjie wrote:
> Add the compatible string for LCKFB Taishan Pi 3M, a board based on
> the Rockchip RK3576 SoC.
>
> Signed-off-by: Liu Changjie <liucj1228@outlook.com>
> ---
> Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: Add Airoha AN7583 SoC and AN7583 Evaluation Board
From: Lorenzo Bianconi @ 2026-05-13 19:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Felix Fietkau,
John Crispin, Matthias Brugger, AngeloGioacchino Del Regno
Cc: Christian Marangi, devicetree, linux-arm-kernel, linux-mediatek,
Lorenzo Bianconi
In-Reply-To: <20260513-airoha-7583-v2-0-ee0d82b37ce7@kernel.org>
Introduce the Airoha AN7583 SoC's dtsi and the Airoha AN7583 Evaluation
Board's dts file.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
arch/arm64/boot/dts/airoha/Makefile | 2 +-
arch/arm64/boot/dts/airoha/an7583-evb.dts | 23 ++++++
arch/arm64/boot/dts/airoha/an7583.dtsi | 133 ++++++++++++++++++++++++++++++
3 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/airoha/Makefile b/arch/arm64/boot/dts/airoha/Makefile
index ebea112ce1d7..6027978a35c2 100644
--- a/arch/arm64/boot/dts/airoha/Makefile
+++ b/arch/arm64/boot/dts/airoha/Makefile
@@ -1,2 +1,2 @@
# SPDX-License-Identifier: GPL-2.0-only
-dtb-$(CONFIG_ARCH_AIROHA) += en7581-evb.dtb
+dtb-$(CONFIG_ARCH_AIROHA) += en7581-evb.dtb an7583-evb.dtb
diff --git a/arch/arm64/boot/dts/airoha/an7583-evb.dts b/arch/arm64/boot/dts/airoha/an7583-evb.dts
new file mode 100644
index 000000000000..fa260f6e41c1
--- /dev/null
+++ b/arch/arm64/boot/dts/airoha/an7583-evb.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/dts-v1/;
+
+#include "an7583.dtsi"
+
+/ {
+ model = "Airoha AN7583 Evaluation Board";
+ compatible = "airoha,an7583-evb", "airoha,an7583";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlycon";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x20000000>;
+ };
+};
diff --git a/arch/arm64/boot/dts/airoha/an7583.dtsi b/arch/arm64/boot/dts/airoha/an7583.dtsi
new file mode 100644
index 000000000000..a82ed916e61d
--- /dev/null
+++ b/arch/arm64/boot/dts/airoha/an7583.dtsi
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ atf@80000000 {
+ no-map;
+ reg = <0x0 0x80000000 0x0 0x200000>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-level = <2>;
+ cache-unified;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ clk25m: clock-25000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ clock-output-names = "clkxtal";
+ };
+
+ i2c_clock: clock-20000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <20000000>;
+ clock-output-names = "i2c_clock";
+ };
+
+ sys_hclk: clock-100000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "sys_hclk";
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller@9000000 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x0 0x09000000 0x0 0x20000>,
+ <0x0 0x09080000 0x0 0x80000>,
+ <0x0 0x09400000 0x0 0x2000>,
+ <0x0 0x09500000 0x0 0x2000>,
+ <0x0 0x09600000 0x0 0x20000>;
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ uart1: serial@1fbf0000 {
+ compatible = "ns16550a";
+ reg = <0x0 0x1fbf0000 0x0 0x30>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <1843200>;
+ };
+
+ watchdog@1fbf0100 {
+ compatible = "airoha,an7583-wdt", "airoha,en7581-wdt";
+ reg = <0x0 0x1fbf0100 0x0 0x38>;
+
+ clocks = <&sys_hclk>;
+ clock-names = "bus";
+ };
+ };
+};
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox