* [PATCH v1] arm64: dts: imx94: Add Root Port node and PERST property
From: hongxing.zhu @ 2026-06-04 2:24 UTC (permalink / raw)
To: sherry.sun, robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu, Richard Zhu
From: Richard Zhu <hongxing.zhu@oss.nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx94.dtsi | 11 +++++++++++
arch/arm64/boot/dts/freescale/imx943-evk.dts | 10 ++++++++++
arch/arm64/boot/dts/freescale/imx943.dtsi | 11 +++++++++++
3 files changed, 32 insertions(+)
---
Since the patch-set [1] issued by Sherry had been landed. Add according
changes on i.MX943 board too.
[1] https://lkml.org/lkml/2026/6/1/1461
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index 1f9035e6cf159..dfbb73603cb24 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -1411,6 +1411,17 @@ pcie0: pcie@4c300000 {
power-domains = <&scmi_devpd IMX94_PD_HSIO_TOP>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie0_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pcie-ep@4c300000 {
diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts b/arch/arm64/boot/dts/freescale/imx943-evk.dts
index 7cfd424689507..ed3abd3e76e56 100644
--- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
@@ -1034,12 +1034,17 @@ &pcie0 {
<&pcie_ref_clk>;
clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
"ref", "extref";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
vpcie3v3aux-supply = <®_m2_wlan>;
supports-clkreq;
status = "okay";
};
+&pcie0_port0 {
+ reset-gpio = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
+};
+
&pcie0_ep {
pinctrl-0 = <&pinctrl_pcie0>;
pinctrl-names = "default";
@@ -1058,12 +1063,17 @@ &pcie1 {
<&pcie_ref_clk>;
clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
"ref", "extref";
+ /* This property is deprecated, use reset-gpios from the Root Port node. */
reset-gpio = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
vpcie3v3aux-supply = <®_slot_pwr>;
supports-clkreq;
status = "okay";
};
+&pcie1_port0 {
+ reset-gpio = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
+};
+
&pcie1_ep {
pinctrl-0 = <&pinctrl_pcie1>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx943.dtsi b/arch/arm64/boot/dts/freescale/imx943.dtsi
index cf5b3dbb47ff7..01152fd0efa5e 100644
--- a/arch/arm64/boot/dts/freescale/imx943.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx943.dtsi
@@ -255,6 +255,17 @@ pcie1: pcie@4c380000 {
power-domains = <&scmi_devpd IMX94_PD_HSIO_TOP>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie1_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie1_ep: pcie-ep@4c380000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 03/11] of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array() fails
From: Wandun @ 2026-06-04 1:48 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, alex, saravanak, akpm, bhe,
rppt, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy, quic_obabatun
In-Reply-To: <CAL_JsqJOC1ko1Len3Dyc5SNKrHmhQn9uiDAkFfVbYa2wAfFUTg@mail.gmail.com>
On 6/4/26 01:44, Rob Herring wrote:
> On Wed, Jun 3, 2026 at 1:44 AM Wandun <chenwandun1@gmail.com> wrote:
>>
>>
>> On 6/3/26 00:24, Rob Herring wrote:
>>> On Wed, May 27, 2026 at 11:29:09AM +0800, Wandun Chen wrote:
>>>> From: Wandun Chen <chenwandun@lixiang.com>
>>>>
>>>> The global pointer 'reserved_mem' continues to reference the
>>>> reserved_mem_array which lives in __initdata if
>>>> alloc_reserved_mem_array() fails. of_reserved_mem_lookup() is
>>>> exported for post-init use, that would dereference freed memory
>>>> and trigger a use-after-free.
>>>>
>>>> So reset reserved_mem_count to 0 when alloc_reserved_mem_array()
>>>> fails.
>>>>
>>>> Fixes: 00c9a452a235 ("of: reserved_mem: Add code to dynamically allocate reserved_mem array")
>>> Fixes should come first in a series.
>> Understood, will do in future submissions.
>>>> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
>>>> ---
>>>> drivers/of/of_reserved_mem.c | 20 ++++++++++++++------
>>>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>>>> index 313cbc57aa45..6d479381ff1f 100644
>>>> --- a/drivers/of/of_reserved_mem.c
>>>> +++ b/drivers/of/of_reserved_mem.c
>>>> @@ -69,29 +69,31 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
>>>> * the initial static array is copied over to this new array and
>>>> * the new array is used from this point on.
>>>> */
>>>> -static void __init alloc_reserved_mem_array(void)
>>>> +static bool __init alloc_reserved_mem_array(void)
>>>> {
>>>> struct reserved_mem *new_array;
>>>> size_t alloc_size, copy_size, memset_size;
>>>>
>>>> + if (!total_reserved_mem_cnt)
>>>> + return true;
>>>> +
>>>> alloc_size = array_size(total_reserved_mem_cnt, sizeof(*new_array));
>>>> if (alloc_size == SIZE_MAX) {
>>>> pr_err("Failed to allocate memory for reserved_mem array with err: %d", -EOVERFLOW);
>>>> - return;
>>>> + goto fail;
>>>> }
>>>>
>>>> new_array = memblock_alloc(alloc_size, SMP_CACHE_BYTES);
>>>> if (!new_array) {
>>>> pr_err("Failed to allocate memory for reserved_mem array with err: %d", -ENOMEM);
>>>> - return;
>>>> + goto fail;
>>>> }
>>>>
>>>> copy_size = array_size(reserved_mem_count, sizeof(*new_array));
>>>> if (copy_size == SIZE_MAX) {
>>>> memblock_free(new_array, alloc_size);
>>>> - total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
>>>> pr_err("Failed to allocate memory for reserved_mem array with err: %d", -EOVERFLOW);
>>> These prints could be moved to 'fail'. Perhaps instead of just printing
>>> an error value, you can return the error value instead of boolean.
>> Will do, consolidating pr_err() under 'fail' and changing the return type
>> to int.
>>> If you respin just this patch, I can pick it up for 7.2.
>> Before I respin, I'd like to flag a dependency:
>> patch 05/07 in this series build on the signature change introduced by this
>> patch ("the void -> bool return type change of alloc_reserved_mem_array()")
>>
>> Could you let me know which of the following you'd prefer:
>> a) Take patch 03 alone via your tree as you suggested, after it lands, I'll
>> respin the remaining patches of this series.
> I would go with this option. AIUI, this series isn't going to land in
> 7.2, so ultimately you will rebase on v7.2-rc1 which will have the
> fix.
OK, will send v4.
Best regards,
Wandun
>
>> b) Keep patch 03 in the v4 respin of the full series, reordered to the front
>> per your earlier comment.
>
> Rob
^ permalink raw reply
* Re: [PATCH] regulator: dt-bindings: mt6311: Convert to DT schema
From: Rob Herring @ 2026-06-04 1:47 UTC (permalink / raw)
To: Ninad Naik
Cc: lgirdwood, broonie, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, me, linux-kernel-mentees, skhan
In-Reply-To: <20260531165712.729635-1-ninadnaik07@gmail.com>
On Sun, May 31, 2026 at 10:27:12PM +0530, Ninad Naik wrote:
> Convert mediatek,mt6311 to DT schema.
>
> Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
> ---
> .../regulator/mediatek,mt6311-regulator.yaml | 72 +++++++++++++++++++
> .../bindings/regulator/mt6311-regulator.txt | 35 ---------
> 2 files changed, 72 insertions(+), 35 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
> delete mode 100644 Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
> new file mode 100644
> index 000000000000..a51db46b0f41
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6311-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek MT6311 Regulator
> +
> +maintainers:
> + - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> +
> +description: |
Don't need '|' if no formatting.
> + The MediaTek MT6311 is an I2C power management IC that provides one step-down
> + converter and one low-dropout regulator. The regulators are named VDVFS and
> + VBIASN, respectively.
> +
> +properties:
> + compatible:
> + const: mediatek,mt6311-regulator
> +
> + reg:
> + description: I2C slave address.
> + maxItems: 1
> +
> + regulators:
> + type: object
> + description: List of regulators provided by this controller.
> +
> + patternProperties:
> + "^(VDVFS|VBIASN)$":
> + type: object
> + $ref: regulator.yaml#
> + description: |
> + Regulator nodes.
Drop. That's obvious with the $ref.
> + unevaluatedProperties: false
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - regulators
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mt6311: pmic@6b {
Drop unused label.
> + compatible = "mediatek,mt6311-regulator";
> + reg = <0x6b>;
> +
> + regulators {
> + mt6311_vcpu_reg: VDVFS {
Drop unused label.
> + regulator-name = "VDVFS";
> + regulator-min-microvolt = <600000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-ramp-delay = <10000>;
> + };
> +
> + mt6311_ldo_reg: VBIASN {
Drop unused label.
> + regulator-name = "VBIASN";
> + regulator-min-microvolt = <200000>;
> + regulator-max-microvolt = <800000>;
> + };
> + };
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
> deleted file mode 100644
> index 84d544d8c1b1..000000000000
> --- a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
> +++ /dev/null
> @@ -1,35 +0,0 @@
> -Mediatek MT6311 Regulator
> -
> -Required properties:
> -- compatible: "mediatek,mt6311-regulator"
> -- reg: I2C slave address, usually 0x6b.
> -- regulators: List of regulators provided by this controller. It is named
> - to VDVFS and VBIASN.
> - The definition for each of these nodes is defined using the standard binding
> - for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
> -
> -The valid names for regulators are:
> -BUCK:
> - VDVFS
> -LDO:
> - VBIASN
> -
> -Example:
> - mt6311: pmic@6b {
> - compatible = "mediatek,mt6311-regulator";
> - reg = <0x6b>;
> -
> - regulators {
> - mt6311_vcpu_reg: VDVFS {
> - regulator-name = "VDVFS";
> - regulator-min-microvolt = < 600000>;
> - regulator-max-microvolt = <1400000>;
> - regulator-ramp-delay = <10000>;
> - };
> - mt6311_ldo_reg: VBIASN {
> - regulator-name = "VBIASN";
> - regulator-min-microvolt = <200000>;
> - regulator-max-microvolt = <800000>;
> - };
> - };
> - };
> --
> 2.54.0
>
>
^ permalink raw reply
* [PATCHv2] thermal/drivers/exynos: fix clock ordering race and shared IRQ handling
From: Rosen Penev @ 2026-06-04 1:42 UTC (permalink / raw)
To: linux-pm
Cc: Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Peter Griffin,
Alim Akhtar, open list:SAMSUNG THERMAL DRIVER,
moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES,
open list
Fix two pre-existing issues in exynos_tmu_probe/remove:
1. Clock ordering race: The driver manually unprepares clocks in
exynos_tmu_remove() and the probe error path, but the IRQ handler and
thermal zone are devm-managed and remain active until after the manual
cleanup. If the shared IRQ fires or the thermal zone is polled in that
window, clk_enable() is called on an unprepared clock, which is illegal.
Replace devm_clk_get() + manual clk_prepare() with devm_clk_get_prepared(),
and devm_clk_get() + manual clk_prepare_enable() with
devm_clk_get_enabled(), so clock unprepare is tied to the devm lifetime
and happens after the IRQ and thermal zone are released. Remove the
now-redundant manual cleanup from the error path and remove function.
2. Shared IRQ handling: The driver requests a shared IRQ (IRQF_SHARED) with
NULL as the hardirq handler, causing irq_default_primary_handler to wake
the threaded handler for every interrupt on the shared line and, combined
with IRQF_ONESHOT, mask the line until the thread completes. Replace the
NULL handler with a hardirq handler that reads the TMU interrupt status
register and returns IRQ_NONE when the TMU is not the interrupt source,
so other devices on the shared line are not delayed. Also return IRQ_NONE
from the threaded handler as a safety net if the interrupt was already
handled or cleared between the hardirq and threaded handler.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v2: fixed sashiko comments and moved TODO.
drivers/thermal/samsung/exynos_tmu.c | 104 ++++++++++++---------------
1 file changed, 46 insertions(+), 58 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 47a99b3c5395..11b2f1e2670c 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -196,7 +196,7 @@ struct exynos_tmu_data {
void (*tmu_control)(struct platform_device *pdev, bool on);
int (*tmu_read)(struct exynos_tmu_data *data);
void (*tmu_set_emulation)(struct exynos_tmu_data *data, int temp);
- void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
+ u32 (*tmu_clear_irqs)(struct exynos_tmu_data *data);
};
/*
@@ -756,28 +756,53 @@ static int exynos7_tmu_read(struct exynos_tmu_data *data)
EXYNOS7_TMU_TEMP_MASK;
}
-static irqreturn_t exynos_tmu_threaded_irq(int irq, void *id)
+static u32 exynos_tmu_intstat_offset(struct exynos_tmu_data *data)
+{
+ if (data->soc == SOC_ARCH_EXYNOS5260)
+ return EXYNOS5260_TMU_REG_INTSTAT;
+ if (data->soc == SOC_ARCH_EXYNOS7)
+ return EXYNOS7_TMU_REG_INTPEND;
+ if (data->soc == SOC_ARCH_EXYNOS5433)
+ return EXYNOS5433_TMU_REG_INTPEND;
+ return EXYNOS_TMU_REG_INTSTAT;
+}
+
+static irqreturn_t exynos_tmu_irq(int irq, void *id)
{
struct exynos_tmu_data *data = id;
- thermal_zone_device_update(data->tzd, THERMAL_EVENT_UNSPECIFIED);
+ if (!readl(data->base + exynos_tmu_intstat_offset(data)))
+ return IRQ_NONE;
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t exynos_tmu_threaded_irq(int irq, void *id)
+{
+ struct exynos_tmu_data *data = id;
mutex_lock(&data->lock);
clk_enable(data->clk);
/* TODO: take action based on particular interrupt */
- data->tmu_clear_irqs(data);
+
+ if (!data->tmu_clear_irqs(data)) {
+ clk_disable(data->clk);
+ mutex_unlock(&data->lock);
+ return IRQ_NONE;
+ }
clk_disable(data->clk);
mutex_unlock(&data->lock);
+ thermal_zone_device_update(data->tzd, THERMAL_EVENT_UNSPECIFIED);
+
return IRQ_HANDLED;
}
-static void exynos4210_tmu_clear_irqs(struct exynos_tmu_data *data)
+static u32 exynos4210_tmu_clear_irqs(struct exynos_tmu_data *data)
{
- unsigned int val_irq;
- u32 tmu_intstat, tmu_intclear;
+ u32 val_irq, tmu_intstat, tmu_intclear;
if (data->soc == SOC_ARCH_EXYNOS5260) {
tmu_intstat = EXYNOS5260_TMU_REG_INTSTAT;
@@ -803,6 +828,8 @@ static void exynos4210_tmu_clear_irqs(struct exynos_tmu_data *data)
* support FALL IRQs at all).
*/
writel(val_irq, data->base + tmu_intclear);
+
+ return val_irq;
}
static const struct of_device_id exynos_tmu_match[] = {
@@ -1036,43 +1063,22 @@ static int exynos_tmu_probe(struct platform_device *pdev)
if (ret)
return ret;
- data->clk = devm_clk_get(dev, "tmu_apbif");
+ data->clk = devm_clk_get_prepared(dev, "tmu_apbif");
if (IS_ERR(data->clk))
return dev_err_probe(dev, PTR_ERR(data->clk), "Failed to get clock\n");
- data->clk_sec = devm_clk_get(dev, "tmu_triminfo_apbif");
- if (IS_ERR(data->clk_sec)) {
+ data->clk_sec = devm_clk_get_prepared(dev, "tmu_triminfo_apbif");
+ if (IS_ERR(data->clk_sec))
if (data->soc == SOC_ARCH_EXYNOS5420_TRIMINFO)
return dev_err_probe(dev, PTR_ERR(data->clk_sec),
"Failed to get triminfo clock\n");
- } else {
- ret = clk_prepare(data->clk_sec);
- if (ret) {
- dev_err(dev, "Failed to get clock\n");
- return ret;
- }
- }
-
- ret = clk_prepare(data->clk);
- if (ret) {
- dev_err(dev, "Failed to get clock\n");
- goto err_clk_sec;
- }
switch (data->soc) {
case SOC_ARCH_EXYNOS5433:
case SOC_ARCH_EXYNOS7:
- data->sclk = devm_clk_get(dev, "tmu_sclk");
- if (IS_ERR(data->sclk)) {
- ret = dev_err_probe(dev, PTR_ERR(data->sclk), "Failed to get sclk\n");
- goto err_clk;
- } else {
- ret = clk_prepare_enable(data->sclk);
- if (ret) {
- dev_err(dev, "Failed to enable sclk\n");
- goto err_clk;
- }
- }
+ data->sclk = devm_clk_get_enabled(dev, "tmu_sclk");
+ if (IS_ERR(data->sclk))
+ return dev_err_probe(dev, PTR_ERR(data->sclk), "Failed to get sclk\n");
break;
default:
break;
@@ -1081,55 +1087,37 @@ static int exynos_tmu_probe(struct platform_device *pdev)
ret = exynos_tmu_initialize(pdev);
if (ret) {
dev_err(dev, "Failed to initialize TMU\n");
- goto err_sclk;
+ return ret;
}
data->tzd = devm_thermal_of_zone_register(dev, 0, data,
&exynos_sensor_ops);
- if (IS_ERR(data->tzd)) {
- ret = dev_err_probe(dev, PTR_ERR(data->tzd), "Failed to register sensor\n");
- goto err_sclk;
- }
+ if (IS_ERR(data->tzd))
+ return dev_err_probe(dev, PTR_ERR(data->tzd), "Failed to register sensor\n");
ret = exynos_thermal_zone_configure(pdev);
if (ret) {
dev_err(dev, "Failed to configure the thermal zone\n");
- goto err_sclk;
+ return ret;
}
- ret = devm_request_threaded_irq(dev, data->irq, NULL,
+ ret = devm_request_threaded_irq(dev, data->irq, exynos_tmu_irq,
exynos_tmu_threaded_irq,
IRQF_TRIGGER_RISING
| IRQF_SHARED | IRQF_ONESHOT,
dev_name(dev), data);
if (ret) {
dev_err(dev, "Failed to request irq: %d\n", data->irq);
- goto err_sclk;
+ return ret;
}
exynos_tmu_control(pdev, true);
return 0;
-
-err_sclk:
- clk_disable_unprepare(data->sclk);
-err_clk:
- clk_unprepare(data->clk);
-err_clk_sec:
- if (!IS_ERR(data->clk_sec))
- clk_unprepare(data->clk_sec);
- return ret;
}
static void exynos_tmu_remove(struct platform_device *pdev)
{
- struct exynos_tmu_data *data = platform_get_drvdata(pdev);
-
exynos_tmu_control(pdev, false);
-
- clk_disable_unprepare(data->sclk);
- clk_unprepare(data->clk);
- if (!IS_ERR(data->clk_sec))
- clk_unprepare(data->clk_sec);
}
#ifdef CONFIG_PM_SLEEP
--
2.54.0
^ permalink raw reply related
* [PATCH 2/2] watchdog: sama5d4: use platform_get_irq_optional()
From: Rosen Penev @ 2026-06-04 1:05 UTC (permalink / raw)
To: linux-watchdog
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
In-Reply-To: <20260604010542.23177-1-rosenp@gmail.com>
irq_of_parse_and_map() requires irq_dispose_mapping() on failure. Don't
bother with it as platform_get_irq_optional() doesn't need it.
Also handle EPROBE_DEFER.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/watchdog/sama5d4_wdt.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index b7a8cfed335d..030029d50257 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -11,7 +11,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_irq.h>
#include <linux/platform_device.h>
#include <linux/reboot.h>
#include <linux/watchdog.h>
@@ -245,7 +244,7 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
struct watchdog_device *wdd;
struct sama5d4_wdt *wdt;
void __iomem *regs;
- u32 irq = 0;
+ int irq = 0;
u32 reg;
int ret;
@@ -281,8 +280,11 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
return ret;
if (wdt->need_irq) {
- irq = irq_of_parse_and_map(dev->of_node, 0);
- if (!irq) {
+ irq = platform_get_irq_optional(pdev, 0);
+ if (irq == -EPROBE_DEFER)
+ return irq;
+
+ if (irq < 0) {
dev_warn(dev, "failed to get IRQ from DT\n");
wdt->need_irq = false;
}
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] watchdog: sama5d4: fix shared IRQ and hardcoded timeout issues
From: Rosen Penev @ 2026-06-04 1:05 UTC (permalink / raw)
To: linux-watchdog
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
In-Reply-To: <20260604010542.23177-1-rosenp@gmail.com>
Fix three pre-existing issues in the sama5d4 watchdog driver:
1. Unsafe IRQF_SHARED | IRQF_NO_SUSPEND combination: The watchdog
interrupt is a dedicated peripheral line, not shared with other
devices. Drop IRQF_SHARED to avoid the documented unsafe interaction
where IRQF_NO_SUSPEND keeps the line enabled during suspend while
other sharing devices may be powered down.
2. Unconditional IRQ_HANDLED on shared line: The handler returned
IRQ_HANDLED even when the status register indicated no watchdog
interrupt was pending. Return IRQ_NONE in that case so the kernel
can properly detect spurious interrupts on the line.
3. Hardcoded 16-second timeout: sama5d4_wdt_init() unconditionally
used WDT_DEFAULT_TIMEOUT (16s) for the hardware timeout, ignoring
any timeout configured via device tree (watchdog_init_timeout) or
userspace. Pass wdd->timeout to sama5d4_wdt_init() so the
configured timeout is honored during probe and resume.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/watchdog/sama5d4_wdt.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index 704b786cc2ec..b7a8cfed335d 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -169,11 +169,12 @@ static irqreturn_t sama5d4_wdt_irq_handler(int irq, void *dev_id)
else
reg = wdt_read(wdt, AT91_WDT_SR);
- if (reg) {
- pr_crit("Atmel Watchdog Software Reset\n");
- emergency_restart();
- pr_crit("Reboot didn't succeed\n");
- }
+ if (!reg)
+ return IRQ_NONE;
+
+ pr_crit("Atmel Watchdog Software Reset\n");
+ emergency_restart();
+ pr_crit("Reboot didn't succeed\n");
return IRQ_HANDLED;
}
@@ -197,11 +198,11 @@ static int of_sama5d4_wdt_init(struct device_node *np, struct sama5d4_wdt *wdt)
return 0;
}
-static int sama5d4_wdt_init(struct sama5d4_wdt *wdt)
+static int sama5d4_wdt_init(struct sama5d4_wdt *wdt, unsigned int timeout)
{
u32 reg, val;
- val = WDT_SEC2TICKS(WDT_DEFAULT_TIMEOUT);
+ val = WDT_SEC2TICKS(timeout);
/*
* When booting and resuming, the bootloader may have changed the
* watchdog configuration.
@@ -289,8 +290,8 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
if (wdt->need_irq) {
ret = devm_request_irq(dev, irq, sama5d4_wdt_irq_handler,
- IRQF_SHARED | IRQF_IRQPOLL |
- IRQF_NO_SUSPEND, pdev->name, pdev);
+ IRQF_IRQPOLL | IRQF_NO_SUSPEND,
+ pdev->name, pdev);
if (ret) {
dev_err(dev, "cannot register interrupt handler\n");
return ret;
@@ -305,7 +306,7 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
set_bit(WDOG_HW_RUNNING, &wdd->status);
}
- ret = sama5d4_wdt_init(wdt);
+ ret = sama5d4_wdt_init(wdt, wdd->timeout);
if (ret)
return ret;
@@ -358,7 +359,7 @@ static int sama5d4_wdt_resume_early(struct device *dev)
* This should only be done when the registers are lost on suspend but
* there is no way to get this information right now.
*/
- sama5d4_wdt_init(wdt);
+ sama5d4_wdt_init(wdt, wdt->wdd.timeout);
if (watchdog_active(&wdt->wdd))
sama5d4_wdt_start(&wdt->wdd);
--
2.54.0
^ permalink raw reply related
* [PATCH 0/2] watchdog: sama5d4: fix IRQ and timeout bugs, use platform_get_irq_optional
From: Rosen Penev @ 2026-06-04 1:05 UTC (permalink / raw)
To: linux-watchdog
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Wim Van Sebroeck, Guenter Roeck,
moderated list:ARM/Microchip (AT91) SoC support, open list
This series fixes three pre-existing issues in the sama5d4 watchdog
driver (unsafe IRQF_SHARED, incorrect IRQ_HANDLED return, ignored
device-tree timeout), then simplifies interrupt acquisition by
switching from irq_of_parse_and_map() to platform_get_irq_optional().
Rosen Penev (2):
watchdog: sama5d4: fix shared IRQ and hardcoded timeout issues
watchdog: sama5d4: use platform_get_irq_optional()
drivers/watchdog/sama5d4_wdt.c | 33 ++++++++++++++++++---------------
1 file changed, 18 insertions(+), 15 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v1 2/2] soc: aspeed: add host-side PCIe BMC device driver
From: Andrew Jeffery @ 2026-06-04 0:46 UTC (permalink / raw)
To: Grégoire Layet, Andrew Lunn
Cc: joel, jacky_chou, yh_chung, ninad, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAFi2wKY7ECbxSbtsO1W9KEKFET67yKg+C64jtQHFY05DRzhfKg@mail.gmail.com>
On Wed, 2026-06-03 at 15:43 +0200, Grégoire Layet wrote:
>
> For the rest of the driver (shared memory, doorbell and mailbox), you are right,
> it makes more sense to implement rpmsg or virtio than just raw shared
> memory binding.
> These are software-defined communication channels and not hardware-emulated,
> so they would fit better as rpmsg or virtio drivers.
> I took the SDK driver as a starting point without questioning its structure.
> I have verified the VUART was working correctly with the shared
> memory, doorbell and mailbox setup removed.
> I can split this into VUART only and defer the rest for a separate
> rpmsg/virtio work.
>
> So I propose for v2:
> - Remove the shared memory device, the sysfs doorbell and the mailbox
> from this series.
> - Retain only the required configuration and initialisation on the BMC
> side driver.
> This should mainly be SCU and PCIe device configuration but other
> initialisation will be reviewed to determine what is required.
> - The shared memory, doorbell and mailbox features could then be
> addressed in a separate future series, likely as virtio based driver.
>
> Would that be acceptable?
That sounds good to me.
From a brief inspection the driver also had support for both the 2600
and 2700. Something to consider is just supporting one of those for
now, and adding support for the other in later patches.
Andrew
^ permalink raw reply
* Re: [PATCH v1 2/2] soc: aspeed: add host-side PCIe BMC device driver
From: Andrew Jeffery @ 2026-06-04 0:44 UTC (permalink / raw)
To: Andrew Lunn, Grégoire Layet
Cc: joel, jacky_chou, yh_chung, ninad, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <77464543-f793-4441-9fce-8666ba1c3d66@lunn.ch>
On Wed, 2026-06-03 at 16:30 +0200, Andrew Lunn wrote:
> On Wed, Jun 03, 2026 at 03:43:36PM +0200, Grégoire Layet wrote:
> > > How virtual is this? Is this directly accessing the hardware via
> > > shared memory? Or is there software on the BMC which traps these
> > > reads/writes and responds?
> >
> > The VUART is virtual because there is no physical UART link between
> > the host and the BMC.
> > Instead, the AST2600 exposes a 16550-compatible register set on both
> > sides (BMC APB and PCIe host MMIO).
> > The data flows using an internal 16 byte FIFO shared between the two
> > register views.
> > So it's hardware emulated and there is no software in the data path.
> >
> > The AST2600 has four VUARTs, two of which are accessible via PCIe MMIO.
> > This is based on the following section of the AST2600 datasheet:
> > III.48 VUART and III.64 PCI2VUART.
> >
> > Because the silicon presents a standard 16550A interface in hardware,
> > the existing 8250 driver works without modification.
>
> So tell us about security.
>
> Is only this UART exposed in the shared memory?
>
No, however the BMC PCI interface provides a PCI-to-LPC bridge, so PCI
accesses can drive cycles in to e.g LPC IO devices exposed by the BMC.
> So the memory window
> is 8 bytes wide? Or are there other peripherals also exposed? How do
> we know the aspeed is not using the UART itself?
>
For the "regular" SuperIO-controlled UARTs this is a concern, but it's
not a concern for the VUARTs. Each VUART has a pair of 8250 register
sets, one accessible from the BMC, the other accessible to the host,
where both interfaces share the FIFOs to propagate data.
> If two drivers are
> using it, are we going to crash one or the other system?
By the above, not for the VUARTs.
>
> https://en.wikipedia.org/wiki/Core_War
>
> The advantage of rpmsg is that the aspeed would advertise what
> services it is willing to expose. The security issues are different,
> implementation bugs vs exposing bits of hardware to an attacker.
From my understanding rpmsg seems like a reasonable fit for the mailbox
functionality.
Andrew
^ permalink raw reply
* ❌ FAIL: Test report for for-kernelci (7.1.0-rc6, upstream-arm-next, ec7ef10b)
From: cki-project @ 2026-06-04 0:03 UTC (permalink / raw)
To: yoyang, linux-arm-kernel, catalin.marinas, will
Hi, we tested your kernel and here are the results:
Overall result: FAILED
Merge: OK
Compile: OK
Test: FAILED
Kernel information:
Commit message: Merge branch 'for-next/core' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2574758120
One or more kernel tests failed:
Unrecognized or new issues:
xfstests - btrfs
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2574758120_aarch64_kernel_kcidb_tool_21407599_9
Non-passing ran subtests:
❌ FAIL generic/301
We also see the following known issues which are not related to your changes:
Issue: [upstream] Hardware - Firmware test suite - auto-waive failures
URL: https://gitlab.com/cki-project/infrastructure/-/issues/779
Affected tests:
Hardware - Firmware test suite [aarch64]
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH 4/5] soc: qcom: ubwc: Add Shikra UBWC config
From: Dmitry Baryshkov @ 2026-06-03 23:12 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-4-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:29PM +0530, Nabige Aala wrote:
> Add UBWC configuration for the Shikra platform. Shikra has no UBWC
> support and no highest_bank_bit setting, so use no_ubwc_data.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> drivers/soc/qcom/ubwc_config.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/qcom/ubwc_config.c b/drivers/soc/qcom/ubwc_config.c
> index 3fe47d8f0f63..01dca97e2671 100644
> --- a/drivers/soc/qcom/ubwc_config.c
> +++ b/drivers/soc/qcom/ubwc_config.c
> @@ -278,6 +278,7 @@ static const struct of_device_id qcom_ubwc_configs[] __maybe_unused = {
> { .compatible = "qcom,sdm660", .data = &msm8937_data },
> { .compatible = "qcom,sdm670", .data = &sdm670_data, },
> { .compatible = "qcom,sdm845", .data = &sdm845_data, },
> + { .compatible = "qcom,shikra", .data = &no_ubwc_data, },
qcm2290_data
> { .compatible = "qcom,sm4250", .data = &sm6115_data, },
> { .compatible = "qcom,sm6115", .data = &sm6115_data, },
> { .compatible = "qcom,sm6125", .data = &sm6125_data, },
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 5/5] iommu/arm-smmu: Add qcom,shikra-mdss to Qualcomm SMMU client tables
From: Dmitry Baryshkov @ 2026-06-03 23:11 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-5-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:30PM +0530, Nabige Aala wrote:
> Register the Shikra MDSS display subsystem in both the SMMU ACTLR
> client table (for TLB prefetch tuning) and the SMMU client match table.
>
> Shikra MDSS uses qcom,shikra-mdss as its sole compatible string, so
> explicit entries are required — there is no fallback to qcom,qcm2290-mdss
> to fall back on. The prefetch settings mirror qcm2290-mdss
> (PREFETCH_SHALLOW | CPRE | CMTLB) as Shikra shares the same display
> hardware block.
>
> No entry is needed in qcom_smmu_impl_of_match: Shikra's apps_smmu
> carries qcom,smmu-500 as a fallback and is covered by the catch-all
> entry there.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 3 +++
> 1 file changed, 3 insertions(+)
>
NAK, use qcm2290 as a fallback. You won't need this patch.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/5] arm64: defconfig: Enable ILI7807S DSI panel driver
From: Dmitry Baryshkov @ 2026-06-03 23:09 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-3-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:28PM +0530, Nabige Aala wrote:
> Enable the ILI7807S 1080x1920 video-mode DSI panel driver as a module,
> used on the Shikra CQM EVK board.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/5] drm/msm/mdss: Add Shikra support
From: Dmitry Baryshkov @ 2026-06-03 23:09 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-2-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:27PM +0530, Nabige Aala wrote:
> Add Mobile Display Subsystem (MDSS) support for the Shikra platform.
> Shikra uses the same MDSS and DPU 6.5 hardware as QCM2290, so it
> reuses the same AHB clock rate configuration (data_76k8) and DPU
> catalog. Register qcom,shikra-dpu in the DPU KMS match table pointing
> to dpu_qcm2290_cfg.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
> drivers/gpu/drm/msm/msm_mdss.c | 1 +
> 2 files changed, 2 insertions(+)
>
This points out that the previous comment was correct. Drop this patch
and use compat strings.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: display: msm: qcm2290: Add Shikra MDSS
From: Dmitry Baryshkov @ 2026-06-03 23:08 UTC (permalink / raw)
To: Nabige Aala
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD), linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, iommu, linux-arm-kernel
In-Reply-To: <20260603-shikra-display-v1-1-aeac1b94faa7@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:29:26PM +0530, Nabige Aala wrote:
> Shikra SoC uses the same MDSS/DPU/DSI hardware as QCM2290 (DPU 6.5),
> sharing the same register layout, DSI controller and 14nm DSI PHY.
> Add qcom,shikra-mdss to the qcm2290-mdss binding compatible enum
> rather than introducing a separate binding file.
Why are you introducing the sole compat string instead of using Agatti
one as a fallback?
>
> Register qcom,shikra-dsi-ctrl in dsi-controller-main.yaml alongside
> qcom,qcm2290-dsi-ctrl, and update the qcm2290-mdss patternProperties
> to accept both SoC-specific DPU and DSI controller compatibles.
>
> Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
> ---
> .../bindings/display/msm/dsi-controller-main.yaml | 1 +
> .../bindings/display/msm/qcom,qcm2290-dpu.yaml | 4 ++-
> .../bindings/display/msm/qcom,qcm2290-mdss.yaml | 34 +++++++++++++++++-----
> 3 files changed, 31 insertions(+), 8 deletions(-)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
From: Oliver Upton @ 2026-06-03 23:07 UTC (permalink / raw)
To: Hyunwoo Kim
Cc: maz, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm, stable
In-Reply-To: <aiAZfdeyanIvP8SD@v4bel>
On Wed, Jun 03, 2026 at 09:09:33PM +0900, Hyunwoo Kim wrote:
> walk_s1() and kvm_walk_nested_s2() expect to be called while holding
> kvm->srcu to guard against memslot changes. While this is generally
> the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the
> respective walkers without taking kvm->srcu.
>
> Fix by acquiring kvm->srcu prior to the table walk in both instances.
>
> Cc: stable@vger.kernel.org
> Fixes: 50f77dc87f13 ("KVM: arm64: Populate level on S1PTW SEA injection")
> Fixes: be04cebf3e78 ("KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W}")
> Suggested-by: Oliver Upton <oupton@kernel.org>
> Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Reviewed-by: Oliver Upton <oupton@kernel.org>
--
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: Add #{address,size}-cells to Chromium-based /firmware
From: Dmitry Baryshkov @ 2026-06-03 22:59 UTC (permalink / raw)
To: Brian Norris
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Heiko Stuebner, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Konrad Dybcio,
devicetree, Doug Anderson, linux-arm-kernel, Tzung-Bi Shih,
chrome-platform, linux-rockchip, Julius Werner, Alim Akhtar,
cros-qcom-dts-watchers, linux-arm-msm, linux-tegra,
linux-samsung-soc, linux-kernel
In-Reply-To: <20260428200712.2660635-8-briannorris@chromium.org>
On Tue, Apr 28, 2026 at 01:06:59PM -0700, Brian Norris wrote:
> Chromium/Depthcharge bootloaders may dynamically add a few device nodes
> to a system's DTB under a /firmware node. A typical DT looks something
> like the following:
>
> / {
> firmware {
> ranges;
>
> coreboot {
> compatible = "coreboot";
> reg = <...>;
> ...;
> };
> };
> };
>
> Notably, the /firmware node has an empty 'ranges', but does not have
> address/size-cells.
>
> Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating
> non-translatable addresses") started requiring #address-cells for a
> device's parent if we want to use the reg resource in a device node.
> This leads to errors like the following:
>
> [ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
>
> Add appropriate #{address,size}-cells to work around the problem.
>
> Note that Google has also patched the Depthcharge bootloader source to
> add {address,size}-cells [1], but bootloader updates are typically
> delivered only via Google OS updates. Not all users install Google
> software updates, and even if they do, Google may not produce updated
> binaries for all/older devices.
>
> [1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/
> https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
> #size-cells for firmware node")
>
> Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
> Fixes: 6e5773d52f4a ("of/address: Fix WARN when attempting translating non-translatable addresses")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v1 1/2] arm64: dts: imx8mm-var-som-symphony: add wakeup sources
From: Stefano Radaelli @ 2026-06-03 22:53 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780527068.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Mark the Symphony carrier board GPIO keys and capacitive touchscreen as
wakeup sources.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 857325ef4461..090752014ee2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -55,18 +55,21 @@ key-back {
label = "Back";
gpios = <&pca9534 1 GPIO_ACTIVE_LOW>;
linux,code = <KEY_BACK>;
+ wakeup-source;
};
key-home {
label = "Home";
gpios = <&pca9534 2 GPIO_ACTIVE_LOW>;
linux,code = <KEY_HOME>;
+ wakeup-source;
};
key-menu {
label = "Menu";
gpios = <&pca9534 3 GPIO_ACTIVE_LOW>;
linux,code = <KEY_MENU>;
+ wakeup-source;
};
};
@@ -187,6 +190,7 @@ ft5x06_ts: touchscreen@38 {
touchscreen-size-y = <480>;
touchscreen-inverted-x;
touchscreen-inverted-y;
+ wakeup-source;
};
rtc@68 {
--
2.47.3
^ permalink raw reply related
* [PATCH v1 2/2] arm64: dts: imx8mm-var-som-symphony: keep RGB_SEL low
From: Stefano Radaelli @ 2026-06-03 22:54 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780527068.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Keep the RGB_SEL line driven low on the Symphony carrier board.
This avoids leaving the line floating and ensures the board remains in
the expected display configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 090752014ee2..fd0a1862ce90 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -168,6 +168,14 @@ pca6408: gpio@21 {
reg = <0x21>;
gpio-controller;
#gpio-cells = <2>;
+
+ /* RGB_SEL */
+ lvds-brg-enable-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "rgb_sel";
+ };
};
st33ktpm2xi2c: tpm@2e {
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/2] arm64: dts: imx8mm-var-som-symphony: minor board updates
From: Stefano Radaelli @ 2026-06-03 22:53 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
This series contains minor updates for the Variscite Symphony carrier
board based on the current hardware configuration.
It updates the RGB_SEL handling and marks the relevant input devices as
wakeup sources.
Stefano Radaelli (2):
arm64: dts: imx8mm-var-som-symphony: add wakeup sources
arm64: dts: imx8mm-var-som-symphony: keep RGB_SEL low
.../boot/dts/freescale/imx8mm-var-som-symphony.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
base-commit: be580423d3f84b84a2f549df91e66bc4f54eda02
--
2.47.3
^ permalink raw reply
* Re: [PATCH v7 10/11] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Daniel Mentz @ 2026-06-03 22:18 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Nicolin Chen, iommu, Will Deacon, Joerg Roedel, Robin Murphy,
Jason Gunthorpe, Mostafa Saleh, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <ahi3uY9YZZtR1Lq5@google.com>
On Thu, May 28, 2026 at 2:46 PM Pranjal Shrivastava <praan@google.com> wrote:
>
> On Thu, May 28, 2026 at 01:28:15PM -0700, Nicolin Chen wrote:
> > On Wed, May 27, 2026 at 10:14:06PM +0000, Pranjal Shrivastava wrote:
> > > TLB and CFG invalidations are
> > > elided if the SMMU is suspended by observing the CMDQ_PROD_STOP_FLAG via
> > > the arm_smmu_can_elide() helper.
> >
> > All the arm_smmu_can_elide() call sites here would eventually elide
> > the commands in arm_smmu_cmdq_issue_cmdlist() that is already gated
> > by CMDQ_PROD_STOP_FLAG? It doesn't seem necessary to gate again?
>
> While issue_cmdlist() would eventually elide these commands, the
> can_elide() check is necessary to return early during suspension.
>
> This avoids unnecessary stack allocation, cmd building, and spinlock
> contention on the cmdq->lock for threads that are anyway about to be
> elided.
>
> By dropping these requests immediately, we significantly reduce cacheline
> bouncing and contention during unmap storms. Furthermore, the early check
> also allows us to specifically trigger the WARN_ON_ONCE() for broken
> devlinks.
Hi Pranjal,
Have you observed unmap storms in a real-world use case, or is this a
preemptive optimization? I would not expect a high rate of map/unmap
operations while the SMMU is suspended. If a client device calls
iommu_map/iommu_unmap (directly or indirectly), it suggests the client
device is RPM_ACTIVE, meaning the SMMU should be active as well.
I am in favor of removing arm_smmu_can_elide().
^ permalink raw reply
* Re: [PATCH v3 2/2] kconfig: Remove the architecture specific config for Propeller
From: Rong Xu @ 2026-06-03 22:15 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Will Deacon, Yabin Cui, Han Shen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Kees Cook,
Nicolas Schier, Linus Walleij, Arnd Bergmann, Mathieu Desnoyers,
Miguel Ojeda, Peter Zijlstra, Jinjie Ruan, Lukas Bulwahn,
linux-kernel, Juergen Gross, Helge Deller, Ryan Roberts,
Marc Zyngier, Ard Biesheuvel, Vincent Donnefort, Alice Ryhl, x86,
linux-arm-kernel
In-Reply-To: <20260603015354.GD1940387@ax162>
On Tue, Jun 2, 2026 at 6:54 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Tue, Jun 02, 2026 at 10:52:48AM -0700, Rong Xu wrote:
> > On Tue, Jun 2, 2026 at 2:43 AM Will Deacon <will@kernel.org> wrote:
> > > I still don't think it has anything to do with the arch. If the compiler
> > > supports the option, then we can use it. The arch code in the kernel
> > > doesn't need to do anything, right? So can you just check if the
> > > compiler accepts the option using a 'depends on $(cc-option, ...)' line?
> >
> > Yes, arch code in the kernel does not need to do anything—it is just a marker.
> >
> > I understand your concern. I can use (cc-options,...) in PROPELLER_CLANG config.
> > But I will not use -fbasic-block-address-map for backward compatiliby reason.
> > I would use "-fbasic-block-sections=list=/dev/null".
> >
> > I'll send the updated patch shortly.
>
> Technically, an architecture needs to add the section generated by this
> compiler option to their linker script to avoid an orphan section
> warning (or error from CONFIG_WERROR) if enabled, as has been done in
> this series.
>
> I worry that moving to a dynamic check will cause build breakage if an
> LLVM target gains support for Propeller without having their kernel
> image linker script adjusted. Maybe that will not happen very often and
> even if it does, I do not mind taking on the maintenance burden of
> fixing it but there is a cost of moving to a dynamic check like this.
>
This is true.
That said, these orphan sections usually won't impact correctness. The
linker will group these together even withgout the link script change,
even though it generates a lot of warnings.
With moving to a dynamic check, correct usage of this feature remains
the user's responsibility -- I think this is Will's point from the
very beginning.
As noted in your previous response, the dynamic check is primarily
intended to prevent "allmodconfig" build failures.
I am comfortable with either the arch_kconfig or dynamic_check
approach. Once a preferred solution is decided, please let me know so
I can submit v4 for review.
Thanks,
-Rong
> --
> Cheers,
> Nathan
^ permalink raw reply
* Re: [PATCH net next] net: axienet: Use dedicated ethtool_ops for the dmaengine path
From: Jacob Keller @ 2026-06-03 22:02 UTC (permalink / raw)
To: Suraj Gupta, andrew+netdev, davem, edumazet, kuba, pabeni,
michal.simek, sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
In-Reply-To: <20260601124454.3384601-1-suraj.gupta2@amd.com>
On 6/1/2026 5:44 AM, Suraj Gupta wrote:
> The dmaengine path shares ethtool_ops with the legacy AXI DMA path,
> including .get_coalesce/.set_coalesce that poke XAXIDMA_*_CR_OFFSET
> directly. In dmaengine mode lp->dma_regs is not mapped by axienet, so
> those ethtool calls touch unmapped/unrelated memory and report values
> unrelated to the channel actually in use.
>
> .get_ringparam/.set_ringparam only touch lp->rx_bd_num/lp->tx_bd_num,
> fields used only by the legacy path for BD ring sizing. In dmaengine
> mode the descriptor ring is owned by the dmaengine provider and these
> fields are not consulted, so reporting them is misleading.
>
> No dmaengine API exists today to query or program either coalescing
> or ring size on behalf of the client, so neither can be exposed
> meaningfully in dmaengine mode.
>
> Add axienet_ethtool_dmaengine_ops without the coalesce and ringparam
> hooks. Also move the ethtool_ops assignment from early probe into the
> if/else alongside netdev_ops, so the legacy and dmaengine paths pick
> their respective ops in one place. No functional change for the
> legacy DMA path.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 27 ++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 263c4b67fd5a..fcf517069d16 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -2536,6 +2536,25 @@ static const struct ethtool_ops axienet_ethtool_ops = {
> .get_rmon_stats = axienet_ethtool_get_rmon_stats,
> };
>
> +static const struct ethtool_ops axienet_ethtool_dmaengine_ops = {
> + .get_drvinfo = axienet_ethtools_get_drvinfo,
> + .get_regs_len = axienet_ethtools_get_regs_len,
> + .get_regs = axienet_ethtools_get_regs,
> + .get_link = ethtool_op_get_link,
> + .get_pauseparam = axienet_ethtools_get_pauseparam,
> + .set_pauseparam = axienet_ethtools_set_pauseparam,
> + .get_link_ksettings = axienet_ethtools_get_link_ksettings,
> + .set_link_ksettings = axienet_ethtools_set_link_ksettings,
> + .nway_reset = axienet_ethtools_nway_reset,
> + .get_ethtool_stats = axienet_ethtools_get_ethtool_stats,
> + .get_strings = axienet_ethtools_get_strings,
> + .get_sset_count = axienet_ethtools_get_sset_count,
> + .get_pause_stats = axienet_ethtools_get_pause_stats,
> + .get_eth_mac_stats = axienet_ethtool_get_eth_mac_stats,
> + .get_eth_ctrl_stats = axienet_ethtool_get_eth_ctrl_stats,
> + .get_rmon_stats = axienet_ethtool_get_rmon_stats,
> +};
> +
> static struct axienet_local *pcs_to_axienet_local(struct phylink_pcs *pcs)
> {
> return container_of(pcs, struct axienet_local, pcs);
> @@ -2792,7 +2811,6 @@ static int axienet_probe(struct platform_device *pdev)
>
> SET_NETDEV_DEV(ndev, &pdev->dev);
> ndev->features = NETIF_F_SG;
> - ndev->ethtool_ops = &axienet_ethtool_ops;
>
> /* MTU range: 64 - 9000 */
> ndev->min_mtu = 64;
> @@ -3021,10 +3039,13 @@ static int axienet_probe(struct platform_device *pdev)
> lp->use_dmaengine = 1;
> }
>
> - if (lp->use_dmaengine)
> + if (lp->use_dmaengine) {
> ndev->netdev_ops = &axienet_netdev_dmaengine_ops;
> - else
> + ndev->ethtool_ops = &axienet_ethtool_dmaengine_ops;
> + } else {
> ndev->netdev_ops = &axienet_netdev_ops;
> + ndev->ethtool_ops = &axienet_ethtool_ops;
> + }
> /* Check for Ethernet core IRQ (optional) */
> if (lp->eth_irq <= 0)
> dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");
^ permalink raw reply
* [PATCH] clk: rockchip: don't COMPILE_TEST builds on M68K
From: Heiko Stuebner @ 2026-06-03 21:37 UTC (permalink / raw)
To: heiko
Cc: rosenp, linux-arm-kernel, linux-rockchip, linux-clk,
kernel test robot
Rockchip clock drivers use hash-tables with enums as inputs.
M68K does interesting things in its __hash_32() implementation, casting
that u32 input to an u16 and therefore triggering warnings like:
drivers/clk/rockchip/clk-rk3528.c: note: in included file (through include/linux/hash.h, include/linux/slab.h):
arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (1e8e8 becomes e8e8)
As M68K should never ever need Rockchip clock drivers, simply disable
compile-tests for M68K.
Fixes: 7edfb7fb58ee ("clk: rockchip: allow COMPILE_TEST builds")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605191434.PQkj2Rki-lkp@intel.com/
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/clk/rockchip/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/Kconfig b/drivers/clk/rockchip/Kconfig
index 85133498f013..8b49fe6f46fb 100644
--- a/drivers/clk/rockchip/Kconfig
+++ b/drivers/clk/rockchip/Kconfig
@@ -4,6 +4,7 @@
config COMMON_CLK_ROCKCHIP
bool "Rockchip clock controller common support"
depends on ARCH_ROCKCHIP || COMPILE_TEST
+ depends on !M68K
default ARCH_ROCKCHIP
help
Say y here to enable common clock controller for Rockchip platforms.
--
2.47.3
^ permalink raw reply related
* [PATCH v1 3/4] iommu: Avoid copying the user array twice in the full-array copy helper
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
iommu_copy_struct_from_full_user_array() copies a whole user array into a
kernel buffer. In the common case, where user entry_len equals destination
entry size, it takes a fast path and copies the whole array with a single
copy_from_user().
That fast path does not return, so it falls through into the item-by-item
copy_struct_from_user() loop and copies every entry a second time. For an
equal entry_len that loop is just a copy_from_user() of the same bytes, so
the whole array is copied twice for no benefit.
Return right after the bulk copy. The per-item loop then runs only on the
slow path, where entry_len differs and each entry needs size adaption.
Fixes: 4f2e59ccb698 ("iommu: Add iommu_copy_struct_from_full_user_array helper")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index e587d4ac4d331..6957144263793 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -547,6 +547,7 @@ iommu_copy_struct_from_full_user_array(void *kdst, size_t kdst_entry_size,
user_array->entry_num *
user_array->entry_len))
return -EFAULT;
+ return 0;
}
/* Copy item by item */
--
2.43.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