* [PATCH v1] irqchip/atmel-aic5: Free SMR cache on init failure
From: Yuho Choi @ 2026-05-13 23:31 UTC (permalink / raw)
To: Thomas Gleixner, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea
Cc: linux-kernel, linux-arm-kernel, Yuho Choi
sama5d2_aic5_of_init() allocates the SMR cache before calling
aic5_of_init(). If that fails, the cache is left allocated even though
no IRQ domain was installed and the cache will not be used.
Free the cache on the failure path and clear the global pointer.
Fixes: a50ac562ef48 ("irqchip/atmel-aic5: Handle suspend to RAM")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
drivers/irqchip/irq-atmel-aic5.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-atmel-aic5.c b/drivers/irqchip/irq-atmel-aic5.c
index 1f14b401f71d..58650eb16880 100644
--- a/drivers/irqchip/irq-atmel-aic5.c
+++ b/drivers/irqchip/irq-atmel-aic5.c
@@ -358,13 +358,22 @@ static int __init sama5d2_aic5_of_init(struct device_node *node,
struct device_node *parent)
{
#ifdef CONFIG_PM
+ int rc = 0;
smr_cache = kcalloc(DIV_ROUND_UP(NR_SAMA5D2_IRQS, 32) * 32,
sizeof(*smr_cache), GFP_KERNEL);
if (!smr_cache)
return -ENOMEM;
-#endif
+ rc = aic5_of_init(node, parent, NR_SAMA5D2_IRQS);
+ if (rc) {
+ kfree(smr_cache);
+ smr_cache = NULL;
+ }
+
+ return rc;
+#else
return aic5_of_init(node, parent, NR_SAMA5D2_IRQS);
+#endif
}
IRQCHIP_DECLARE(sama5d2_aic5, "atmel,sama5d2-aic", sama5d2_aic5_of_init);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH/RFC 04/14] arm64: dts: renesas: ironhide: Enable SCMI devpd, sys, and reset
From: Marek Vasut @ 2026-05-13 23:31 UTC (permalink / raw)
To: Geert Uytterhoeven, Sudeep Holla, Cristian Marussi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Saravana Kannan,
Michael Turquette, Stephen Boyd, Philipp Zabel, Ulf Hansson,
Rafael J . Wysocki, Kevin Hilman, Florian Fainelli, Wolfram Sang,
Marek Vasut, Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel
In-Reply-To: <2eb3c62df7b6ccedb525569fe34c10403e2fdcf5.1776793163.git.geert+renesas@glider.be>
On 4/21/26 8:11 PM, Geert Uytterhoeven wrote:
Hello Geert,
> SCP FW SDKv4.28.0 and later for Renesas R-Car X5H Ironhide not only
> implements the SCMI base and clock management protocols, but also the
> SCMI power domain, system power, and reset domain management protocols.
>
> Enable support for the latter by adding the corresponding SCMI protocol
> subnodes.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
> index e2470257d2f32a03..2fb9557a7eb9dbb7 100644
> --- a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
> @@ -31,10 +31,24 @@ scmi: scmi {
> #address-cells = <1>;
> #size-cells = <0>;
>
> + scmi_devpd: protocol@11 {
> + reg = <0x11>;
> + #power-domain-cells = <1>;
Please indent with tabs.
> + };
> +
> + scmi_sys: protocol@12 {
> + reg = <0x12>;
Please indent with tabs.
> + };
> +
> scmi_clk: protocol@14 {
> reg = <0x14>;
> #clock-cells = <1>;
Here it is OK.
> };
> +
> + scmi_reset: protocol@16 {
> + reg = <0x16>;
> + #reset-cells = <1>;
Please indent with tabs.
I hope it helps!
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: leds: issi,is31fl319x: Add description for the shutdown-gpios property
From: Rob Herring (Arm) @ 2026-05-13 23:26 UTC (permalink / raw)
To: Jun Yan
Cc: Andrew Lunn, devicetree, linux-kernel, Krzysztof Kozlowski,
Jesper Nilsson, Paul Barker, Grant Feng, Manivannan Sadhasivam,
linux-arm-msm, Sebastian Hesselbarth, Robert Marko, Lee Jones,
Vincent Knecht, Viresh Kumar, Enric Balletbo i Serra,
Pavel Machek, Andre Przywara, Krzysztof Kozlowski,
linux-arm-kernel, Bjorn Andersson, Pavel Machek, linux-leds,
Gregory Clement, Conor Dooley, Peter Rosin, Baruch Siach,
Konrad Dybcio
In-Reply-To: <20260508152435.21389-2-jerrysteve1101@gmail.com>
On Fri, 08 May 2026 23:24:18 +0800, Jun Yan wrote:
> The IS31FL319X series features an SDB shutdown pin.
> Driving it low (active low) places the chip into hardware shutdown
> mode for power saving, while all register contents are preserved
> and registers are not reset.
>
> Add description for the shutdown down (SDB) pin and fix the example
> device tree binding.
>
> Fixes: dbc801b472c1 ("dt-bindings: leds: Convert is31fl319x to dtschema")
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> .../devicetree/bindings/leds/issi,is31fl319x.yaml | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC 8/8] clk: sunxi-ng: a733: Add reset lines
From: Andre Przywara @ 2026-05-13 23:22 UTC (permalink / raw)
To: Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Philipp Zabel, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Richard Cochran, linux-clk, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-riscv, netdev
In-Reply-To: <20260310-a733-clk-v1-8-36b4e9b24457@pigmoral.tech>
On Tue, 10 Mar 2026 16:34:01 +0800
Junhui Liu <junhui.liu@pigmoral.tech> wrote:
Hi,
compare the list below against my version of the manual. You list more
than shown there, can you say where those extra reset bits come from?
> Add the reset lines for the Allwinner A733 SoC. These reset control bits
> are integrated into the Bus Gate Reset (BGR) registers, typically
> sharing the same register address with their corresponding bus clock
> gates. Integrate them into the main CCU driver using the existing
> sunxi-ng ccu_reset framework, allowing the CCU to also function as a
> reset controller for the SoC.
>
> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> ---
> drivers/clk/sunxi-ng/ccu-sun60i-a733.c | 128 +++++++++++++++++++++++++++++++++
> 1 file changed, 128 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun60i-a733.c b/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> index c0b09f9197d1..7d1ee9235436 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> @@ -17,6 +17,7 @@
> #include "../clk.h"
>
> #include "ccu_common.h"
> +#include "ccu_reset.h"
>
> #include "ccu_div.h"
> #include "ccu_gate.h"
> @@ -2169,11 +2170,138 @@ static struct clk_hw_onecell_data sun60i_a733_hw_clks = {
> .num = CLK_FANOUT3 + 1,
> };
>
> +static struct ccu_reset_map sun60i_a733_ccu_resets[] = {
> + [RST_BUS_ITS_PCIE] = { 0x574, BIT(16) },
> + [RST_BUS_NSI] = { 0x580, BIT(30) },
What is this NSI device? Some interconnect? Do we really want to handle
this reset and clock? Is there some device referencing this? Otherwise
the kernel will turn at least the clock off, which is probably fatal.
Also the manual says this is a secure register, so I feel like the
kernel must not mess with this.
> + [RST_BUS_NSI_CFG] = { 0x584, BIT(16) },
Similar here, I guess, though this might not be secure only.
> + [RST_BUS_IOMMU0_SYS] = { 0x58c, BIT(16) },
> + [RST_BUS_MSI_LITE0_AHB] = { 0x594, BIT(16) },
> + [RST_BUS_MSI_LITE0_MBUS] = { 0x594, BIT(17) },
> + [RST_BUS_MSI_LITE1_AHB] = { 0x59c, BIT(16) },
> + [RST_BUS_MSI_LITE1_MBUS] = { 0x59c, BIT(17) },
> + [RST_BUS_MSI_LITE2_AHB] = { 0x5a4, BIT(16) },
> + [RST_BUS_MSI_LITE2_MBUS] = { 0x5a4, BIT(17) },
> + [RST_BUS_IOMMU1_SYS] = { 0x5b4, BIT(16) },
> + [RST_BUS_DMA0] = { 0x704, BIT(16) },
> + [RST_BUS_DMA1] = { 0x70c, BIT(16) },
> + [RST_BUS_SPINLOCK] = { 0x724, BIT(16) },
> + [RST_BUS_MSGBOX] = { 0x744, BIT(16) },
> + [RST_BUS_PWM0] = { 0x784, BIT(16) },
> + [RST_BUS_PWM1] = { 0x78c, BIT(16) },
> + [RST_BUS_DBG] = { 0x7a4, BIT(16) },
> + [RST_BUS_SYSDAP] = { 0x7ac, BIT(16) },
> + [RST_BUS_TIMER0] = { 0x850, BIT(16) },
> + [RST_BUS_DE] = { 0xa04, BIT(16) },
> + [RST_BUS_DI] = { 0xa24, BIT(16) },
> + [RST_BUS_G2D] = { 0xa44, BIT(16) },
> + [RST_BUS_EINK] = { 0xa6c, BIT(16) },
> + [RST_BUS_DE_SYS] = { 0xa74, BIT(16) },
> + [RST_BUS_VE_ENC] = { 0xa8c, BIT(16) },
The manual calls this ENC0, and since bit 17 is not documented, I
wonder if there is an ENC1 used with some other packaging, maybe? So
maybe calling it ENC0 would be safer here.
> + [RST_BUS_VE_DEC] = { 0xa8c, BIT(18) },
> + [RST_BUS_CE] = { 0xac4, BIT(16) },
> + [RST_BUS_CE_SYS] = { 0xac4, BIT(17) },
> + [RST_BUS_NPU_CORE] = { 0xb04, BIT(16) },
> + [RST_BUS_NPU_AXI] = { 0xb04, BIT(17) },
> + [RST_BUS_NPU_AHB] = { 0xb04, BIT(18) },
> + [RST_BUS_NPU_SRAM] = { 0xb04, BIT(19) },
> + [RST_BUS_GPU] = { 0xb24, BIT(16) },
> + [RST_BUS_DRAM] = { 0xc0c, BIT(16) },
> + [RST_BUS_NAND] = { 0xc8c, BIT(16) },
> + [RST_BUS_MMC0] = { 0xd0c, BIT(16) },
> + [RST_BUS_MMC1] = { 0xd1c, BIT(16) },
> + [RST_BUS_MMC2] = { 0xd2c, BIT(16) },
> + [RST_BUS_MMC3] = { 0xd3c, BIT(16) },
> + [RST_BUS_UFS_AHB] = { 0xd8c, BIT(16) },
> + [RST_BUS_UFS_AXI] = { 0xd8c, BIT(17) },
> + [RST_BUS_UFS_PHY] = { 0xd8c, BIT(18) },
> + [RST_BUS_UFS_CORE] = { 0xd8c, BIT(19) },
> + [RST_BUS_UART0] = { 0xe00, BIT(16) },
> + [RST_BUS_UART1] = { 0xe04, BIT(16) },
> + [RST_BUS_UART2] = { 0xe08, BIT(16) },
> + [RST_BUS_UART3] = { 0xe0c, BIT(16) },
> + [RST_BUS_UART4] = { 0xe10, BIT(16) },
> + [RST_BUS_UART5] = { 0xe14, BIT(16) },
> + [RST_BUS_UART6] = { 0xe18, BIT(16) },
> + [RST_BUS_I2C0] = { 0xe80, BIT(16) },
> + [RST_BUS_I2C1] = { 0xe84, BIT(16) },
> + [RST_BUS_I2C2] = { 0xe88, BIT(16) },
> + [RST_BUS_I2C3] = { 0xe8c, BIT(16) },
> + [RST_BUS_I2C4] = { 0xe90, BIT(16) },
> + [RST_BUS_I2C5] = { 0xe94, BIT(16) },
> + [RST_BUS_I2C6] = { 0xe98, BIT(16) },
> + [RST_BUS_I2C7] = { 0xe9c, BIT(16) },
> + [RST_BUS_I2C8] = { 0xea0, BIT(16) },
> + [RST_BUS_I2C9] = { 0xea4, BIT(16) },
> + [RST_BUS_I2C10] = { 0xea8, BIT(16) },
> + [RST_BUS_I2C11] = { 0xeac, BIT(16) },
> + [RST_BUS_I2C12] = { 0xeb0, BIT(16) },
> + [RST_BUS_SPI0] = { 0xf04, BIT(16) },
> + [RST_BUS_SPI1] = { 0xf0c, BIT(16) },
> + [RST_BUS_SPI2] = { 0xf14, BIT(16) },
> + [RST_BUS_SPIF] = { 0xf1c, BIT(16) },
> + [RST_BUS_SPI3] = { 0xf24, BIT(16) },
> + [RST_BUS_SPI4] = { 0xf2c, BIT(16) },
SPI4 isn't mentioned in my version of the manual.
> + [RST_BUS_GPADC] = { 0xfc4, BIT(16) },
> + [RST_BUS_THS] = { 0xfe4, BIT(16) },
> + [RST_BUS_IRRX] = { 0x1004, BIT(16) },
> + [RST_BUS_IRTX] = { 0x100c, BIT(16) },
> + [RST_BUS_LRADC] = { 0x1024, BIT(16) },
> + [RST_BUS_SGPIO] = { 0x1064, BIT(16) },
> + [RST_BUS_LPC] = { 0x1084, BIT(16) },
Where do those two come from? There are not in my version of the manual.
> + [RST_BUS_I2SPCM0] = { 0x120c, BIT(16) },
> + [RST_BUS_I2SPCM1] = { 0x121c, BIT(16) },
> + [RST_BUS_I2SPCM2] = { 0x122c, BIT(16) },
> + [RST_BUS_I2SPCM3] = { 0x123c, BIT(16) },
> + [RST_BUS_I2SPCM4] = { 0x124c, BIT(16) },
> + [RST_BUS_OWA] = { 0x128c, BIT(16) },
> + [RST_BUS_DMIC] = { 0x12cc, BIT(16) },
> + [RST_USB_PHY0] = { 0x1300, BIT(30) },
> + [RST_BUS_OHCI0] = { 0x1304, BIT(16) },
> + [RST_BUS_EHCI0] = { 0x1304, BIT(20) },
> + [RST_BUS_OTG] = { 0x1304, BIT(24) },
> + [RST_USB_PHY1] = { 0x1308, BIT(30) },
> + [RST_BUS_OHCI1] = { 0x130c, BIT(16) },
> + [RST_BUS_EHCI1] = { 0x130c, BIT(20) },
> + [RST_BUS_USB2] = { 0x135c, BIT(16) },
> + [RST_BUS_PCIE] = { 0x138c, BIT(17) },
> + [RST_BUS_PCIE_PWRUP] = { 0x138c, BIT(16) },
Just a nit, but those two are ordered wrongly.
> + [RST_BUS_SERDES] = { 0x13c4, BIT(16) },
> + [RST_BUS_GMAC0] = { 0x141c, BIT(16) },
> + [RST_BUS_GMAC0_AXI] = { 0x141c, BIT(17) },
> + [RST_BUS_GMAC1] = { 0x142c, BIT(16) },
> + [RST_BUS_GMAC1_AXI] = { 0x142c, BIT(17) },
GMAC1 is not listed in my manual, where does this come from?
> + [RST_BUS_TCON_LCD0] = { 0x1504, BIT(16) },
> + [RST_BUS_TCON_LCD1] = { 0x150c, BIT(16) },
> + [RST_BUS_TCON_LCD2] = { 0x1514, BIT(16) },
No LCD2 in my manual.
The rest looks alright.
Cheers,
Andre
> + [RST_BUS_LVDS0] = { 0x1544, BIT(16) },
> + [RST_BUS_LVDS1] = { 0x154c, BIT(16) },
> + [RST_BUS_DSI0] = { 0x1584, BIT(16) },
> + [RST_BUS_DSI1] = { 0x158c, BIT(16) },
> + [RST_BUS_TCON_TV0] = { 0x1604, BIT(16) },
> + [RST_BUS_TCON_TV1] = { 0x160c, BIT(16) },
> + [RST_BUS_EDP] = { 0x164c, BIT(16) },
> + [RST_BUS_HDMI_MAIN] = { 0x168c, BIT(16) },
> + [RST_BUS_HDMI_SUB] = { 0x168c, BIT(17) },
> + [RST_BUS_HDMI_HDCP] = { 0x168c, BIT(18) },
> + [RST_BUS_DPSS_TOP0] = { 0x16c4, BIT(16) },
> + [RST_BUS_DPSS_TOP1] = { 0x16cc, BIT(16) },
> + [RST_BUS_VIDEO_OUT0] = { 0x16e4, BIT(16) },
> + [RST_BUS_VIDEO_OUT1] = { 0x16ec, BIT(16) },
> + [RST_BUS_LEDC] = { 0x1704, BIT(16) },
> + [RST_BUS_DSC] = { 0x1744, BIT(16) },
> + [RST_BUS_CSI] = { 0x1844, BIT(16) },
> + [RST_BUS_VIDEO_IN] = { 0x1884, BIT(16) },
> + [RST_BUS_APB2JTAG] = { 0x1c04, BIT(16) },
> +};
> +
> static const struct sunxi_ccu_desc sun60i_a733_ccu_desc = {
> .ccu_clks = sun60i_a733_ccu_clks,
> .num_ccu_clks = ARRAY_SIZE(sun60i_a733_ccu_clks),
>
> .hw_clks = &sun60i_a733_hw_clks,
> +
> + .resets = sun60i_a733_ccu_resets,
> + .num_resets = ARRAY_SIZE(sun60i_a733_ccu_resets),
> };
>
> static const u32 pll_regs[] = {
>
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: media: qcom: x1e80100-camss: drop src clock
From: Rob Herring (Arm) @ 2026-05-13 23:21 UTC (permalink / raw)
To: Wenmeng Liu
Cc: Bjorn Andersson, Vladimir Zapolskiy, Pengutronix Kernel Team,
linux-arm-kernel, Todor Tomov, linux-media, Conor Dooley,
Robert Foss, Krzysztof Kozlowski, Fabio Estevam, Sascha Hauer,
linux-kernel, Bryan O'Donoghue, Mauro Carvalho Chehab,
devicetree, Konrad Dybcio, imx, Bryan O'Donoghue,
linux-arm-msm, Frank Li
In-Reply-To: <20260508-hamoa_evk-v2-2-3ebdca3e4ae2@oss.qualcomm.com>
On Fri, 08 May 2026 19:39:58 +0800, Wenmeng Liu wrote:
> The src clocks are always-on parent clocks and do not need to be
> explicitly listed for CAMSS consumers. Drop cphy rx src clk.
>
> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a78000: Add PSCI node
From: Marek Vasut @ 2026-05-13 22:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Kuninori Morimoto, Magnus Damm, Rob Herring,
devicetree, linux-renesas-soc
Describe SMC based PSCI access in SoC DT. The system can interact
with TFA BL31 PSCI provider running on the Cortex-A cores via SMC
calls.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a78000.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a78000.dtsi b/arch/arm64/boot/dts/renesas/r8a78000.dtsi
index 73be51787265c..d14f0cc0ad360 100644
--- a/arch/arm64/boot/dts/renesas/r8a78000.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a78000.dtsi
@@ -665,6 +665,11 @@ extalr_clk: extalr-clk {
/* clock-frequency must be set on board */
};
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
/* External SCIF clock - to be overridden by boards that provide it */
scif_clk: scif-clk {
compatible = "fixed-clock";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH V14 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Bjorn Helgaas @ 2026-05-13 22:49 UTC (permalink / raw)
To: Sherry Sun
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach,
imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-3-sherry.sun@nxp.com>
On Wed, Apr 22, 2026 at 05:35:39PM +0800, Sherry Sun wrote:
> Introduce generic helper functions to parse Root Port device tree nodes
> and extract common properties like reset GPIOs. This allows multiple
> PCI host controller drivers to share the same parsing logic.
>
> Define struct pci_host_port to hold common Root Port properties
> (currently only list of PERST# GPIO descriptors) and add
> pci_host_common_parse_ports() to parse Root Port nodes from device tree.
>
> Also add the 'ports' list to struct pci_host_bridge for better maintain
> parsed Root Port information.
> ...
> +static int pci_host_common_parse_port(struct device *dev,
> + struct pci_host_bridge *bridge,
> + struct device_node *node)
> +{
> + struct pci_host_port *port;
> + int ret;
> +
> + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> + if (!port)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(&port->perst);
> +
> + ret = pci_host_common_parse_perst(dev, port, node);
> + if (ret)
> + return ret;
> +
> + /*
> + * 1. PERST# found in RP or its child nodes - list is not empty, continue
> + * 2. PERST# not found in RP/children, but found in RC node - return -ENODEV
> + * to fallback legacy binding
> + * 3. PERST# not found anywhere - list is empty, continue (optional PERST#)
> + */
> + if (list_empty(&port->perst)) {
> + if (of_property_present(dev->of_node, "reset-gpios") ||
> + of_property_present(dev->of_node, "reset-gpio"))
> + return -ENODEV;
This doesn't seem right to me. The parser of per-Root Port properties
should not be responsible for deciding whether legacy methods are
valid, i.e., whether a property is in the Root Complex node. I think
it's up to the caller to decide whether it needs to look elsewhere.
I don't think this even needs to return a "success/failure" value
because there may be more properties in the future, and not all will
be required. This function can't tell which properties a specific
driver requires and which are optional.
The caller can check whether we found what it needs and fall back to a
legacy method as needed.
> + }
> +
> + INIT_LIST_HEAD(&port->list);
> + list_add_tail(&port->list, &bridge->ports);
> +
> + return 0;
> +}
> +
> +/**
> + * pci_host_common_parse_ports - Parse Root Port nodes from device tree
> + * @dev: Device pointer
> + * @bridge: PCI host bridge
> + *
> + * This function iterates through child nodes of the host bridge and parses
> + * Root Port properties (currently only reset GPIOs).
> + *
> + * Returns: 0 on success, -ENODEV if no ports found or PERST# found in RC node
> + * (legacy binding should be used), Other negative error codes on failure.
> + */
> +int pci_host_common_parse_ports(struct device *dev, struct pci_host_bridge *bridge)
> +{
> + int ret = -ENODEV;
> +
> + for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> + if (!of_node_is_type(of_port, "pci"))
> + continue;
> + ret = pci_host_common_parse_port(dev, bridge, of_port);
> + if (ret)
> + goto err_cleanup;
> + }
I think we should export pci_host_common_parse_port() itself and drop
this so we deal with a single Root Port, and drivers that support
multiple RPs should include their own loop similar to this. That way
the driver can do several things at once in each iteration of that
loop, e.g., get resources, power up, configure, etc.
I see that would require some rework of the devm_add_action_or_reset()
cleanup.
> + if (ret)
> + return ret;
> +
> + return devm_add_action_or_reset(dev, pci_host_common_delete_ports,
> + &bridge->ports);
> +
> +err_cleanup:
> + pci_host_common_delete_ports(&bridge->ports);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(pci_host_common_parse_ports);
> ...
> + * struct pci_host_perst - PERST# GPIO descriptor
> + * @list: List node for linking multiple PERST# GPIOs
> + * @desc: GPIO descriptor for PERST# signal
> + *
> + * This structure holds a single PERST# GPIO descriptor.
> + */
> +struct pci_host_perst {
> + struct list_head list;
> + struct gpio_desc *desc;
> +};
How do we associate an element of this list with something?
Based on the imx6 changes, I guess we don't; we don't even associate
the pci_host_port with an RP. We just assert/deassert PERST# for
every RP at once, and we do it for every GPIO associated with each RP.
There's no way to assert PERST# for a single RP. I guess we don't
need that?
> +/**
> + * struct pci_host_port - Generic Root Port properties
> + * @list: List node for linking multiple ports
> + * @perst: List of PERST# GPIO descriptors for this port and its children
> + *
> + * This structure contains common properties that can be parsed from
> + * Root Port device tree nodes.
> + */
> +struct pci_host_port {
"host_port" is not really a standard term. And despite the comments
above and below, I don't think the list is restricted to Root Ports
because we traverse the whole hierarchy below the RP.
> + struct list_head list;
> + struct list_head perst;
> +};
> + struct list_head ports; /* Root Port list (pci_host_port) */
^ permalink raw reply
* Re: [PATCH 03/16] dt-bindings: timer: arm,arch_timer: Fix requirements for interrupt description
From: Rob Herring (Arm) @ 2026-05-13 22:33 UTC (permalink / raw)
To: Marc Zyngier
Cc: devicetree, Conor Dooley, Mark Rutland, Thierry Reding,
Ivaylo Ivanov, linux-acpi, Neil Armstrong, Sascha Hauer,
Dinh Nguyen, Sudeep Holla, Will Deacon, Chen-Yu Tsai,
Matthias Brugger, Rafael J. Wysocki, Lars Persson, Alim Akhtar,
Konrad Dybcio, Heiko Stuebner, Krzysztof Kozlowski, Jerome Brunet,
Catalin Marinas, Andreas Färber, Orson Zhai, Ge Gordon,
linux-kernel, Bjorn Andersson, Shawn Lin, Jernej Skrabec,
Martin Blumenstingl, Frank Li, Baolin Wang, Samuel Holland,
AngeloGioacchino Del Regno, Michal Simek, Pengutronix Kernel Team,
Hanjun Guo, Lorenzo Pieralisi, Fabio Estevam, Thomas Gleixner,
Jesper Nilsson, Kevin Hilman, linux-arm-kernel, Daniel Lezcano,
Jonathan Hunter, BST Linux Kernel Upstream Group
In-Reply-To: <20260507125544.2903406-4-maz@kernel.org>
On Thu, 07 May 2026 13:55:31 +0100, Marc Zyngier wrote:
> The arm,arch_timer DT binding is extremely imprecise in describing
> the requirements for interrupts.
>
> Follow the architecture by making it explicit that:
> - the EL1 secure timer irq is required if EL3 is implemented
> - the EL1 physical timer irq is always required
> - the EL1 virtual timer irq is always required
> - the EL2 physical timer irq is required if EL2 is implemented
> - the EL2 virtual timer irq is required if FEAT_VHE is implemented
>
> The consequence of the above is that the minimum number of interrupts
> to be described is 2, and not 1.
>
> Finally, clean up the description which made the assumption that
> the timers are plugged into a GIC (unfortunately, that's not always
> true), drop the MMIO nonsense that has long be moved to a separate
> binding, and use the architectural terminology to describe the various
> interrupts.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> .../bindings/timer/arm,arch_timer.yaml | 21 +++++++------------
> 1 file changed, 8 insertions(+), 13 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a78000: Fix GIC-720AE View 1 Redistributor description
From: Marek Vasut @ 2026-05-13 22:30 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Kuninori Morimoto, Magnus Damm, Marc Zyngier,
Rob Herring, devicetree, linux-renesas-soc
The Renesas R-Car X5H (R8A78000) SoC contains Arm CoreLink GIC-720AE
Generic Interrupt Controller with Multi View capability. Firmware has
access to configuration View 0, Linux kernel has access to View 1.
The Arm CoreLink GIC-720AE Generic Interrupt Controller Technical
Reference Manual, currently latest r2p1 [1], chapter "Programmers model
for GIC-720AE", subchapter "Redistributor registers for control and
physical LPIs summary", part "GICR_TYPER, Redistributor Type Register"
clarifies register "GICR_TYPER" bit 4 "Last" behavior in Multi View
setup as follows:
"
Last
Last Redistributor:
0 ... This Redistributor is not the last Redistributor on the chip.
1 ... This Redistributor is the last Redistributor on the chip.
When GICD_CFGID.VIEW == 1, for views 1, 2, or 3 this bit
always returns 1.
"
On this SoC, GICD_CFGID.VIEW is 1 and the Linux kernel has access to
View 1, therefore Linux kernel GICv3 driver will interpret register
"GICR_TYPER" bit 4 "Last" = 1 in the first Redistributor in continuous
Redistributor page as that first Redistributor being the one and only
Redistributor and will stop processing the continuous Redistributor
page further. This will prevent the other Redistributors from being
recognized by the system and used for other PEs.
Because the hardware indicates that the continuous Redistributor page
is not continuous for View 1, 2, or 3, describe every Redistributor
separately in the DT. This makes all Redistributors for all cores
accessible in Linux.
[1] https://developer.arm.com/documentation/102666/0201/Programmers-model-for-GIC-720AE/Redistributor-registers-for-control-and-physical-LPIs-summary/GICR-TYPER--Redistributor-Type-Register?lang=en
Fixes: 63500d12cf76 ("arm64: dts: renesas: Add R8A78000 SoC support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a78000.dtsi | 36 +++++++++++++++++++++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a78000.dtsi b/arch/arm64/boot/dts/renesas/r8a78000.dtsi
index 3ec1b53d27828..73be51787265c 100644
--- a/arch/arm64/boot/dts/renesas/r8a78000.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a78000.dtsi
@@ -689,8 +689,40 @@ gic: interrupt-controller@39000000 {
#interrupt-cells = <3>;
#address-cells = <0>;
interrupt-controller;
- reg = <0 0x39000000 0 0x10000>,
- <0 0x39080000 0 0x800000>;
+ #redistributor-regions = <32>;
+ reg = <0x0 0x39000000 0x0 0x10000>,
+ <0x0 0x39080000 0x0 0x40000>,
+ <0x0 0x390c0000 0x0 0x40000>,
+ <0x0 0x39100000 0x0 0x40000>,
+ <0x0 0x39140000 0x0 0x40000>,
+ <0x0 0x39180000 0x0 0x40000>,
+ <0x0 0x391c0000 0x0 0x40000>,
+ <0x0 0x39200000 0x0 0x40000>,
+ <0x0 0x39240000 0x0 0x40000>,
+ <0x0 0x39280000 0x0 0x40000>,
+ <0x0 0x392c0000 0x0 0x40000>,
+ <0x0 0x39300000 0x0 0x40000>,
+ <0x0 0x39340000 0x0 0x40000>,
+ <0x0 0x39380000 0x0 0x40000>,
+ <0x0 0x393c0000 0x0 0x40000>,
+ <0x0 0x39400000 0x0 0x40000>,
+ <0x0 0x39440000 0x0 0x40000>,
+ <0x0 0x39480000 0x0 0x40000>,
+ <0x0 0x394c0000 0x0 0x40000>,
+ <0x0 0x39500000 0x0 0x40000>,
+ <0x0 0x39540000 0x0 0x40000>,
+ <0x0 0x39580000 0x0 0x40000>,
+ <0x0 0x395c0000 0x0 0x40000>,
+ <0x0 0x39600000 0x0 0x40000>,
+ <0x0 0x39640000 0x0 0x40000>,
+ <0x0 0x39680000 0x0 0x40000>,
+ <0x0 0x396c0000 0x0 0x40000>,
+ <0x0 0x39700000 0x0 0x40000>,
+ <0x0 0x39740000 0x0 0x40000>,
+ <0x0 0x39780000 0x0 0x40000>,
+ <0x0 0x397c0000 0x0 0x40000>,
+ <0x0 0x39800000 0x0 0x40000>,
+ <0x0 0x39840000 0x0 0x40000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4] dt-bindings: i2c: convert davinci i2c to dt-schema
From: Andi Shyti @ 2026-05-13 22:02 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: robh, krzk+dt, conor+dt, brgl, bartosz.golaszewski, linux-i2c,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260513123758.4955-1-chaitanya.msabnis@gmail.com>
Hi Chaitanya,
On Wed, May 13, 2026 at 06:07:57PM +0530, Chaitanya Sabnis wrote:
> Convert the Texas Instruments DaVinci and Keystone I2C controller
> bindings from legacy text format to modern dt-schema (YAML).
>
> During the conversion, the `interrupts` property was made required
> to match the strict requirement in the driver probe function. The
> custom `ti,has-pfunc` and `power-domains` properties were also
> properly defined to match SoC-specific hardware features.
>
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
merged to i2c/i2c-host.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v6 06/25] iommu/io-pgtable-arm: Rework to use the iommu-pages API
From: Mostafa Saleh @ 2026-05-13 21:54 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-arm-kernel, linux-kernel, kvmarm, iommu, catalin.marinas,
will, maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
joro, jean-philippe, mark.rutland, qperret, tabba, vdonnefort,
sebastianene, keirf
In-Reply-To: <20260511141849.GO9285@ziepe.ca>
On Mon, May 11, 2026 at 11:18:49AM -0300, Jason Gunthorpe wrote:
> On Mon, May 11, 2026 at 11:16:47AM +0000, Mostafa Saleh wrote:
> > > IDK, why? virt_to_phys() is part of the iommu-pages API, I'd just
> > > leave it.. If you want to narrow it then #define it for pkvm when
> > > compiling this file..
> >
> > It is not going to be part of the iommu-pages API, I meant in
> > io-pgtable-arm, we will use something arm_lpae_virt_to_phys()...
> > which is then implemented differently for pkvm.
>
> Again why? I think the main goal should be to not mess up the normal
> code.
>
> #define virt_to_phys pkvm_virt_to_phys
>
> Does that, we should be leaning into this pattern I think, not adding
> unnecessary churn...
>
> If anything is needed then it should be an iommu_pages function to
> wrapper virt_to_phys() for use by iommu_pages uses but I'd rather
> not..
>
Sure, no strong opinion, I did post this patch along with cleanups
separately in:
https://lore.kernel.org/linux-iommu/20260513215203.3852661-1-smostafa@google.com/
Thanks,
Mostafa
> Jason
^ permalink raw reply
* [PATCH 3/3] iommu/io-pgtable-arm: Use address conversion consistently
From: Mostafa Saleh @ 2026-05-13 21:52 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel
Cc: robin.murphy, will, joro, jgg, Mostafa Saleh
In-Reply-To: <20260513215203.3852661-1-smostafa@google.com>
Use consistent address conversions in the driver:
- virt_to_phys(): For all virtual to physical address conversion,
convert __pa users as we don’t need to rely on it type casting.
- phys_to_virt(): For all physical to virtual address conversion,
similarly, convert __va users.
That changes nothing at all. However, it will be useful when
compiling this file for the KVM hypervisor as it can cleanly
replace virt_to_phys/phys_to_virt
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
drivers/iommu/io-pgtable-arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 86b23aa04324..476c0e25631a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -143,7 +143,7 @@
#define ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC 0x8DULL
/* IOPTE accessors */
-#define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
+#define iopte_deref(pte, d) phys_to_virt(iopte_to_paddr(pte, d))
#define iopte_type(pte) \
(((pte) >> ARM_LPAE_PTE_TYPE_SHIFT) & ARM_LPAE_PTE_TYPE_MASK)
@@ -429,7 +429,7 @@ static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
arm_lpae_iopte old, new;
struct io_pgtable_cfg *cfg = &data->iop.cfg;
- new = paddr_to_iopte(__pa(table), data) | ARM_LPAE_PTE_TYPE_TABLE;
+ new = paddr_to_iopte(virt_to_phys(table), data) | ARM_LPAE_PTE_TYPE_TABLE;
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
new |= ARM_LPAE_PTE_NSTABLE;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH 2/3] iommu/io-pgtable-arm: Rework to use the iommu-pages API
From: Mostafa Saleh @ 2026-05-13 21:52 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel
Cc: robin.murphy, will, joro, jgg, Mostafa Saleh
In-Reply-To: <20260513215203.3852661-1-smostafa@google.com>
Update the io-pgtable-arm allocator to use the iommu-pages API.
Replace the DMA API usage from __arm_lpae_alloc_pages() with
iommu_pages_start_incoherent() and from __arm_lpae_free_pages() with
iommu_pages_free_incoherent().
Since the iommu-pages API relies on metadata stored in the struct page
during iommu_alloc_pages_node_sz(), it cannot be used safely with memory
allocated via the custom cfg->alloc (which may not be backed by pages).
So, isolate that logic and keep it as it.
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
drivers/iommu/io-pgtable-arm.c | 79 ++++++++++++++++++++++++----------
1 file changed, 56 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 0cbe545c491d..86b23aa04324 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -248,24 +248,15 @@ static dma_addr_t __arm_lpae_dma_addr(void *pages)
return (dma_addr_t)virt_to_phys(pages);
}
-static void *__arm_lpae_alloc_pages(size_t size, gfp_t gfp,
- struct io_pgtable_cfg *cfg,
- void *cookie)
+static void *__arm_lpae_cfg_alloc(size_t size, gfp_t gfp,
+ struct io_pgtable_cfg *cfg,
+ void *cookie)
{
struct device *dev = cfg->iommu_dev;
dma_addr_t dma;
void *pages;
- /*
- * For very small starting-level translation tables the HW requires a
- * minimum alignment of at least 64 to cover all cases.
- */
- size = max(size, 64);
- if (cfg->alloc)
- pages = cfg->alloc(cookie, size, gfp);
- else
- pages = iommu_alloc_pages_node_sz(dev_to_node(dev), gfp, size);
-
+ pages = cfg->alloc(cookie, size, gfp);
if (!pages)
return NULL;
@@ -289,14 +280,55 @@ static void *__arm_lpae_alloc_pages(size_t size, gfp_t gfp,
dma_unmap_single(dev, dma, size, DMA_TO_DEVICE);
out_free:
- if (cfg->free)
- cfg->free(cookie, pages, size);
- else
- iommu_free_pages(pages);
-
+ cfg->free(cookie, pages, size);
return NULL;
}
+static void __arm_lpae_cfg_free(void *pages, size_t size,
+ struct io_pgtable_cfg *cfg,
+ void *cookie)
+{
+ if (!cfg->coherent_walk)
+ dma_unmap_single(cfg->iommu_dev, __arm_lpae_dma_addr(pages),
+ size, DMA_TO_DEVICE);
+
+ cfg->free(cookie, pages, size);
+}
+
+static void *__arm_lpae_alloc_pages(size_t size, gfp_t gfp,
+ struct io_pgtable_cfg *cfg,
+ void *cookie)
+{
+ struct device *dev = cfg->iommu_dev;
+ void *pages;
+
+ /*
+ * For very small starting-level translation tables the HW requires a
+ * minimum alignment of at least 64 to cover all cases.
+ */
+ size = max(size, 64);
+
+ if (cfg->alloc)
+ return __arm_lpae_cfg_alloc(size, gfp, cfg, cookie);
+
+ pages = iommu_alloc_pages_node_sz(dev_to_node(dev), gfp, size);
+ if (!pages)
+ return NULL;
+
+ if (!cfg->coherent_walk) {
+ int ret = iommu_pages_start_incoherent(pages, dev);
+
+ if (ret) {
+ if (ret == -EOPNOTSUPP)
+ dev_err(dev, "Cannot accommodate DMA translation for IOMMU page tables\n");
+ iommu_free_pages(pages);
+ return NULL;
+ }
+ }
+
+ return pages;
+}
+
static void __arm_lpae_free_pages(void *pages, size_t size,
struct io_pgtable_cfg *cfg,
void *cookie)
@@ -304,12 +336,13 @@ static void __arm_lpae_free_pages(void *pages, size_t size,
/* See __arm_lpae_alloc_pages(). */
size = max(size, 64);
- if (!cfg->coherent_walk)
- dma_unmap_single(cfg->iommu_dev, __arm_lpae_dma_addr(pages),
- size, DMA_TO_DEVICE);
+ if (cfg->free) {
+ __arm_lpae_cfg_free(pages, size, cfg, cookie);
+ return;
+ }
- if (cfg->free)
- cfg->free(cookie, pages, size);
+ if (!cfg->coherent_walk)
+ iommu_pages_free_incoherent(pages, cfg->iommu_dev);
else
iommu_free_pages(pages);
}
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH 1/3] iommu/io-pgtable-arm: Use consistent sizes for page allocation and freeing
From: Mostafa Saleh @ 2026-05-13 21:52 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel
Cc: robin.murphy, will, joro, jgg, Mostafa Saleh
In-Reply-To: <20260513215203.3852661-1-smostafa@google.com>
At the moment we use alloc_size to allocate memory but then there
is a logical error where we just size in the error and free path,
which might be smaller.
Also we size to do DMA-API operations, which is OK, but confusing.
Instead of this error-prone handling, just set size to alloc_size
and use it everywhere.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
drivers/iommu/io-pgtable-arm.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 0208e5897c29..0cbe545c491d 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -253,7 +253,6 @@ static void *__arm_lpae_alloc_pages(size_t size, gfp_t gfp,
void *cookie)
{
struct device *dev = cfg->iommu_dev;
- size_t alloc_size;
dma_addr_t dma;
void *pages;
@@ -261,12 +260,11 @@ static void *__arm_lpae_alloc_pages(size_t size, gfp_t gfp,
* For very small starting-level translation tables the HW requires a
* minimum alignment of at least 64 to cover all cases.
*/
- alloc_size = max(size, 64);
+ size = max(size, 64);
if (cfg->alloc)
- pages = cfg->alloc(cookie, alloc_size, gfp);
+ pages = cfg->alloc(cookie, size, gfp);
else
- pages = iommu_alloc_pages_node_sz(dev_to_node(dev), gfp,
- alloc_size);
+ pages = iommu_alloc_pages_node_sz(dev_to_node(dev), gfp, size);
if (!pages)
return NULL;
@@ -303,6 +301,9 @@ static void __arm_lpae_free_pages(void *pages, size_t size,
struct io_pgtable_cfg *cfg,
void *cookie)
{
+ /* See __arm_lpae_alloc_pages(). */
+ size = max(size, 64);
+
if (!cfg->coherent_walk)
dma_unmap_single(cfg->iommu_dev, __arm_lpae_dma_addr(pages),
size, DMA_TO_DEVICE);
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH 0/3] iommu/io-pgtable-arm: iommu-pages and cleanup
From: Mostafa Saleh @ 2026-05-13 21:52 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel
Cc: robin.murphy, will, joro, jgg, Mostafa Saleh
This is a small cleanup coming from the pKVM SMMUv3 support [1].
However, they are not pKVM specific and useful in general.
The first patch is to fix a theoretical issues with alloc/free size.
The second patch is the main one to convert the code to iommu-pages.
The third patch is a cleanup to use address conversion consistently.
[1] https://lore.kernel.org/linux-iommu/20260501111928.259252-1-smostafa@google.com/
Mostafa Saleh (3):
iommu/io-pgtable-arm: Use consistent sizes for page allocation and
freeing
iommu/io-pgtable-arm: Rework to use the iommu-pages API
iommu/io-pgtable-arm: Use address conversion consistently
drivers/iommu/io-pgtable-arm.c | 88 +++++++++++++++++++++++-----------
1 file changed, 61 insertions(+), 27 deletions(-)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: adc: sun20i-gpadc: add A523 gpadc support
From: Andre Przywara @ 2026-05-13 21:34 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Sanjay Chitroda, Michal Piekos, 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: <20260513171638.77af3b24@jic23-huawei>
On Wed, 13 May 2026 17:16:38 +0100
Jonathan Cameron <jic23@kernel.org> wrote:
Hi,
> On Wed, 13 May 2026 13:53:49 +0200
> Andre Przywara <andre.przywara@arm.com> wrote:
>
> > Hi Sanjay,
> >
> > thanks for having a look!
> >
> > 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:
> > >> A523 differs from existing sun20i-gpadc-iio by having two clocks; bus
> > >> clock and module clock.
> > >>
> > >> Change driver to enable all clocks.
> > >>
> > >> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > >> ---
> > >> drivers/iio/adc/sun20i-gpadc-iio.c | 11 +++++++----
> > >> 1 file changed, 7 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/drivers/iio/adc/sun20i-gpadc-iio.c b/drivers/iio/adc/sun20i-gpadc-iio.c
> > >> index 861c14da75ad..3f1f07b3a385 100644
> > >> --- a/drivers/iio/adc/sun20i-gpadc-iio.c
> > >> +++ b/drivers/iio/adc/sun20i-gpadc-iio.c
> > >> @@ -180,7 +180,7 @@ static int sun20i_gpadc_probe(struct platform_device *pdev)
> > >> struct iio_dev *indio_dev;
> > >> struct sun20i_gpadc_iio *info;
> > >> struct reset_control *rst;
> > >> - struct clk *clk;
> > >> + struct clk_bulk_data *clks;
> > >> int irq;
> > >> int ret;
> > >>
> > >> @@ -205,9 +205,11 @@ static int sun20i_gpadc_probe(struct platform_device *pdev)
> > >> if (IS_ERR(info->regs))
> > >> return PTR_ERR(info->regs);
> > >>
> > >> - clk = devm_clk_get_enabled(dev, NULL);
> > >> - if (IS_ERR(clk))
> > >> - 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)
> > >
> > > 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.
> >
> > 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.
>
> True but passing 0 to dev_err_probe() isn't going to do the right thing.
>
> Though from this function, 0 is an error you need to return an error code
> not 0 which to the caller looks like a success.
Ah, that's true - should have read your email first before answering to
Andy ;-)
So yeah, that needs a split handling, for == 0, and for < 0.
Cheers,
Andre
>
>
>
> >
> > To me that change looks good:
> >
> > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> >
> > Cheers,
> > Andre
> >
> >
> > >
> > > Thanks, Sanjay
> > >
> > >
> > >> + return dev_err_probe(
> > >> + dev, ret,
> > >> + "failed to enable clocks or no clocks defined\n");
> > >>
> > >> rst = devm_reset_control_get_exclusive(dev, NULL);
> > >> if (IS_ERR(rst))
> > >> @@ -243,6 +245,7 @@ static int sun20i_gpadc_probe(struct platform_device *pdev)
> > >>
> > >> static const struct of_device_id sun20i_gpadc_of_id[] = {
> > >> { .compatible = "allwinner,sun20i-d1-gpadc" },
> > >> + { .compatible = "allwinner,sun55i-a523-gpadc" },
> > >> { }
> > >> };
> > >> MODULE_DEVICE_TABLE(of, sun20i_gpadc_of_id);
> > >>
> > >
> >
>
>
^ permalink raw reply
* [PATCH 2/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
In-Reply-To: <20260514-zx29uart-v1-0-68470ecc3977@gmail.com>
This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte
zx platform"). I did not bring back the zx29-uart .compatible as the
arm,primecell-periphid does the job.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changes since v4:
Use ZTE's JEDEC ID instead of 0xfe for the DT-Provided AMBA ID.
---
drivers/tty/serial/amba-pl011.c | 42 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 028e37ad8d79..8ed91e1da22b 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -240,6 +240,38 @@ static struct vendor_data vendor_nvidia = {
.get_fifosize = get_fifosize_nvidia,
};
+static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
+ [REG_DR] = ZX_UART011_DR,
+ [REG_FR] = ZX_UART011_FR,
+ [REG_LCRH_RX] = ZX_UART011_LCRH,
+ [REG_LCRH_TX] = ZX_UART011_LCRH,
+ [REG_IBRD] = ZX_UART011_IBRD,
+ [REG_FBRD] = ZX_UART011_FBRD,
+ [REG_CR] = ZX_UART011_CR,
+ [REG_IFLS] = ZX_UART011_IFLS,
+ [REG_IMSC] = ZX_UART011_IMSC,
+ [REG_RIS] = ZX_UART011_RIS,
+ [REG_MIS] = ZX_UART011_MIS,
+ [REG_ICR] = ZX_UART011_ICR,
+ [REG_DMACR] = ZX_UART011_DMACR,
+};
+
+static unsigned int get_fifosize_zte(struct amba_device *dev)
+{
+ return 16;
+}
+
+static struct vendor_data vendor_zte = {
+ .reg_offset = pl011_zte_offsets,
+ .access_32b = true,
+ .ifls = UART011_IFLS_RX4_8 | UART011_IFLS_TX4_8,
+ .fr_busy = ZX_UART01x_FR_BUSY,
+ .fr_dsr = ZX_UART01x_FR_DSR,
+ .fr_cts = ZX_UART01x_FR_CTS,
+ .fr_ri = ZX_UART011_FR_RI,
+ .get_fifosize = get_fifosize_zte,
+};
+
/* Deals with DMA transactions */
struct pl011_dmabuf {
@@ -3180,6 +3212,16 @@ static const struct amba_id pl011_ids[] = {
.mask = 0x000fffff,
.data = &vendor_nvidia,
},
+ {
+ /* This is an invented ID. The actual hardware that contains
+ * these ZTE UARTs (zx29 boards) has no AMBA PIDs stored. ZTE
+ * JEDEC ID (ignoring banks) and the "011" part number as used
+ * by ARM.
+ */
+ .id = 0x0008c011,
+ .mask = 0x000fffff,
+ .data = &vendor_zte,
+ },
{ 0, 0 },
};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] ARM: zte: Add support for zx29 low level debug
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
In-Reply-To: <20260514-zx29uart-v1-0-68470ecc3977@gmail.com>
This is based on the removed zx29 code. A separate (more complicated)
patch will re-add the register map to the pl011 serial driver.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Patch changelog:
v8: Adjust UART01x_FR_BUSY to match the different ZX UART registers
(Sashiko). I am unsure about UART01x_FR_TXFF and my boards do not expose
flow control pins to allow me to test if it works.
I am unsure about the virtual address. It doesn't seem to matter, as
long as it is a valid address. This address is based on the old removed
code. Is there a rule-of-thumb physical to virtual mapping I can use to
give a sensible default value?
---
arch/arm/Kconfig.debug | 12 ++++++++++++
arch/arm/include/debug/pl01x.S | 9 +++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 366f162e147d..98d8a5a60048 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1331,6 +1331,16 @@ choice
This option selects UART0 on VIA/Wondermedia System-on-a-chip
devices, including VT8500, WM8505, WM8650 and WM8850.
+ config DEBUG_ZTE_ZX
+ bool "Kernel low-level debugging via zx29 UART"
+ select DEBUG_UART_PL01X
+ depends on ARCH_ZTE
+ help
+ Say Y here if you are enabling ZTE zx297520v3 SOC and need
+ debug UART support. This UART is a PL011 with different
+ register addresses. The UART for boot messages on zx29 boards
+ is usually UART1 and is operating at 921600 8N1.
+
config DEBUG_ZYNQ_UART0
bool "Kernel low-level debugging on Xilinx Zynq using UART0"
depends on ARCH_ZYNQ
@@ -1545,6 +1555,7 @@ config DEBUG_UART_8250
config DEBUG_UART_PHYS
hex "Physical base address of debug UART"
+ default 0x01408000 if DEBUG_ZTE_ZX
default 0x01c28000 if DEBUG_SUNXI_UART0
default 0x01c28400 if DEBUG_SUNXI_UART1
default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1
@@ -1701,6 +1712,7 @@ config DEBUG_UART_VIRT
default 0xf31004c0 if DEBUG_MESON_UARTAO
default 0xf4090000 if DEBUG_LPC32XX
default 0xf4200000 if DEBUG_GEMINI
+ default 0xf4708000 if DEBUG_ZTE_ZX
default 0xf6200000 if DEBUG_PXA_UART1
default 0xf7000000 if DEBUG_SUN9I_UART0
default 0xf7000000 if DEBUG_S3C64XX_UART && DEBUG_S3C_UART0
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
index c7e02d0628bf..9dcdeed2357d 100644
--- a/arch/arm/include/debug/pl01x.S
+++ b/arch/arm/include/debug/pl01x.S
@@ -8,6 +8,15 @@
*/
#include <linux/amba/serial.h>
+#ifdef CONFIG_DEBUG_ZTE_ZX
+#undef UART01x_DR
+#undef UART01x_FR
+#undef UART01x_FR_BUSY
+#define UART01x_DR 0x04
+#define UART01x_FR 0x14
+#define UART01x_FR_BUSY (1<<8)
+#endif
+
#ifdef CONFIG_DEBUG_UART_PHYS
.macro addruart, rp, rv, tmp
ldr \rp, =CONFIG_DEBUG_UART_PHYS
--
2.53.0
^ permalink raw reply related
* [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
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