* [PATCH 0/3] Add driver support for ESWIN EIC7700 HSP clock and reset generator
From: dongxuyang @ 2026-04-03 9:34 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk, devicetree,
linux-kernel, p.zabel, huangyifeng, dongxuyang
Cc: ningyu, linmin, pinkesh.vaghela
From: Xuyang Dong <dongxuyang@eswincomputing.com>
Add support for the ESWIN EIC7700 HSP (high-speed peripherals). The drivers
provide basic functionality to manage and control the clock and reset
signals for EIC7700 HSP, including mmc, USB, ethernet, SATA and DMAC.
The clock and reset registers are mapped to overlapping I/O address ranges.
This causes a resource conflict when two drivers attempt to request the
same region. Use the auxiliary device framework: the main driver
allocates the shared register region and passes it to auxiliary
devices, avoiding resource contention and duplicate remapping.
Features:
Implements support for the ESWIN EIC7700 HSP clock and reset controller.
Provide API to manage clock and reset signals for the EIC7700 HSP.
Supported chips:
ESWIN EIC7700 series SoC.
Test:
Test this patch on the Sifive HiFive Premier P550 (which used the EIC7700
SoC), include USB and other peripherals. All the drivers of these modules
use the clock module and reset module.
This patch depends on ESWIN EIC7700 clock controller patch [1], [2] and [3].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20260331&id=8add6d87dc69c0620c7e60bdc6be6b3b0092d9fa
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20260331&id=cd44f127c1d42833a32ba0a0965255ee6184f8c1
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20260331&id=858f6273cf003e97c817903a07d8001b483fe40b
Xuyang Dong (3):
dt-bindings: clock: Add ESWIN eic7700 HSP clock and reset generator
clk: eswin: Add eic7700 HSP clock driver
reset: eswin: Add eic7700 HSP reset driver
.../bindings/clock/eswin,eic7700-hspcrg.yaml | 63 ++++
MAINTAINERS | 3 +
drivers/clk/eswin/Kconfig | 12 +
drivers/clk/eswin/Makefile | 1 +
drivers/clk/eswin/clk-eic7700-hsp.c | 339 ++++++++++++++++++
drivers/reset/Kconfig | 13 +
drivers/reset/Makefile | 1 +
drivers/reset/reset-eic7700-hsp.c | 151 ++++++++
.../dt-bindings/clock/eswin,eic7700-hspcrg.h | 33 ++
.../dt-bindings/reset/eswin,eic7700-hspcrg.h | 21 ++
10 files changed, 637 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
create mode 100644 drivers/clk/eswin/clk-eic7700-hsp.c
create mode 100644 drivers/reset/reset-eic7700-hsp.c
create mode 100644 include/dt-bindings/clock/eswin,eic7700-hspcrg.h
create mode 100644 include/dt-bindings/reset/eswin,eic7700-hspcrg.h
--
2.34.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: clock: Add ESWIN eic7700 HSP clock and reset generator
From: dongxuyang @ 2026-04-03 9:35 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk, devicetree,
linux-kernel, p.zabel, huangyifeng, dongxuyang
Cc: ningyu, linmin, pinkesh.vaghela
In-Reply-To: <20260403093459.612-1-dongxuyang@eswincomputing.com>
From: Xuyang Dong <dongxuyang@eswincomputing.com>
Add bindings for the high-speed peripherals clock and reset generator
on the ESWIN EIC7700 HSP.
Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
---
.../bindings/clock/eswin,eic7700-hspcrg.yaml | 63 +++++++++++++++++++
MAINTAINERS | 3 +
.../dt-bindings/clock/eswin,eic7700-hspcrg.h | 33 ++++++++++
.../dt-bindings/reset/eswin,eic7700-hspcrg.h | 21 +++++++
4 files changed, 120 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
create mode 100644 include/dt-bindings/clock/eswin,eic7700-hspcrg.h
create mode 100644 include/dt-bindings/reset/eswin,eic7700-hspcrg.h
diff --git a/Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml b/Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
new file mode 100644
index 000000000000..b0acac559df1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/eswin,eic7700-hspcrg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ESWIN EIC7700 HSP Clock and Reset Generator
+
+maintainers:
+ - Xuyang Dong <dongxuyang@eswincomputing.com>
+
+description:
+ Clock and reset generator for the ESWIN EIC7700 HSP (high-speed peripherals).
+
+properties:
+ compatible:
+ const: eswin,eic7700-hspcrg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: HSP configuration top clock
+ - description: MMC top clock
+ - description: SATA top clock
+
+ clock-names:
+ items:
+ - const: hsp_cfg
+ - const: hsp_mmc
+ - const: hsp_sata
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/eswin,eic7700-hspcrg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/eswin,eic7700-hspcrg.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@50440000 {
+ compatible = "eswin,eic7700-hspcrg";
+ reg = <0x50440000 0x2000>;
+ clocks = <&clock 171>, <&clock 254>, <&clock 187>;
+ clock-names = "hsp_cfg", "hsp_mmc", "hsp_sata";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 76e91d47d2f4..bcbb9578c043 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9506,8 +9506,11 @@ M: Yifeng Huang <huangyifeng@eswincomputing.com>
M: Xuyang Dong <dongxuyang@eswincomputing.com>
S: Maintained
F: Documentation/devicetree/bindings/clock/eswin,eic7700-clock.yaml
+F: Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
F: drivers/clk/eswin/
F: include/dt-bindings/clock/eswin,eic7700-clock.h
+F: include/dt-bindings/clock/eswin,eic7700-hspcrg.h
+F: include/dt-bindings/reset/eswin,eic7700-hspcrg.h
ET131X NETWORK DRIVER
M: Mark Einon <mark.einon@gmail.com>
diff --git a/include/dt-bindings/clock/eswin,eic7700-hspcrg.h b/include/dt-bindings/clock/eswin,eic7700-hspcrg.h
new file mode 100644
index 000000000000..1d1ff15c1154
--- /dev/null
+++ b/include/dt-bindings/clock/eswin,eic7700-hspcrg.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd..
+ * All rights reserved.
+ *
+ * Device Tree binding constants for EIC7700 HSP clock controller.
+ *
+ * Authors: Xuyang Dong <dongxuyang@eswincomputing.com>
+ */
+
+#ifndef _DT_BINDINGS_ESWIN_EIC7700_HSPCRG_CLOCK_H_
+#define _DT_BINDINGS_ESWIN_EIC7700_HSPCRG_CLOCK_H_
+
+#define EIC7700_HSP_CLK_FAC_CFG_DIV2 0
+#define EIC7700_HSP_CLK_FAC_CFG_DIV4 1
+#define EIC7700_HSP_CLK_FAC_MMC_DIV10 2
+#define EIC7700_HSP_CLK_MUX_EMMC_3MUX1 3
+#define EIC7700_HSP_CLK_MUX_SD0_3MUX1 4
+#define EIC7700_HSP_CLK_MUX_SD1_3MUX1 5
+#define EIC7700_HSP_CLK_MUX_EMMC_CQE_2MUX1 6
+#define EIC7700_HSP_CLK_MUX_SD0_CQE_2MUX1 7
+#define EIC7700_HSP_CLK_MUX_SD1_CQE_2MUX1 8
+#define EIC7700_HSP_CLK_GATE_MSHC0_TMR 9
+#define EIC7700_HSP_CLK_GATE_EMMC 10
+#define EIC7700_HSP_CLK_GATE_MSHC1_TMR 11
+#define EIC7700_HSP_CLK_GATE_SD0 12
+#define EIC7700_HSP_CLK_GATE_MSHC2_TMR 13
+#define EIC7700_HSP_CLK_GATE_SD1 14
+#define EIC7700_HSP_CLK_GATE_USB0 15
+#define EIC7700_HSP_CLK_GATE_USB1 16
+#define EIC7700_HSP_CLK_GATE_SATA 17
+
+#endif /* _DT_BINDINGS_ESWIN_EIC7700_HSPCRG_CLOCK_H_ */
diff --git a/include/dt-bindings/reset/eswin,eic7700-hspcrg.h b/include/dt-bindings/reset/eswin,eic7700-hspcrg.h
new file mode 100644
index 000000000000..413fcd08c701
--- /dev/null
+++ b/include/dt-bindings/reset/eswin,eic7700-hspcrg.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd..
+ * All rights reserved.
+ *
+ * Device Tree binding constants for EIC7700 HSP reset controller.
+ *
+ * Authors: Xuyang Dong <dongxuyang@eswincomputing.com>
+ */
+
+#ifndef _DT_BINDINGS_ESWIN_EIC7700_HSPCRG_RESET_H_
+#define _DT_BINDINGS_ESWIN_EIC7700_HSPCRG_RESET_H_
+
+#define EIC7700_HSP_RST_SATA_P0 0
+#define EIC7700_HSP_RST_SATA_PHY 1
+#define EIC7700_HSP_RST_USB0 2
+#define EIC7700_HSP_RST_USB1 3
+#define EIC7700_HSP_RST_USB0_PHY 4
+#define EIC7700_HSP_RST_USB1_PHY 5
+
+#endif /* _DT_BINDINGS_ESWIN_EIC7700_HSPCRG_RESET_H_ */
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] clk: eswin: Add eic7700 HSP clock driver
From: dongxuyang @ 2026-04-03 9:36 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk, devicetree,
linux-kernel, p.zabel, huangyifeng, dongxuyang
Cc: ningyu, linmin, pinkesh.vaghela
In-Reply-To: <20260403093459.612-1-dongxuyang@eswincomputing.com>
From: Xuyang Dong <dongxuyang@eswincomputing.com>
Add driver for the ESWIN EIC7700 high-speed peripherals system
clock controller and register an auxiliary device for system
reset controller which is named as "hsp-reset".
Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
---
drivers/clk/eswin/Kconfig | 12 +
drivers/clk/eswin/Makefile | 1 +
drivers/clk/eswin/clk-eic7700-hsp.c | 339 ++++++++++++++++++++++++++++
3 files changed, 352 insertions(+)
create mode 100644 drivers/clk/eswin/clk-eic7700-hsp.c
diff --git a/drivers/clk/eswin/Kconfig b/drivers/clk/eswin/Kconfig
index 0406ec499ec9..e6cc2a407bac 100644
--- a/drivers/clk/eswin/Kconfig
+++ b/drivers/clk/eswin/Kconfig
@@ -13,3 +13,15 @@ config COMMON_CLK_EIC7700
SoC. The clock controller generates and supplies clocks to various
peripherals within the SoC.
Say yes here to support the clock controller on the EIC7700 SoC.
+
+config COMMON_CLK_EIC7700_HSP
+ tristate "EIC7700 HSP Clock Driver"
+ depends on ARCH_ESWIN || COMPILE_TEST
+ select AUXILIARY_BUS
+ select COMMON_CLK_EIC7700
+ select RESET_EIC7700_HSP if RESET_CONTROLLER
+ help
+ This driver provides support for clock controller on ESWIN EIC7700
+ HSP. The clock controller generates and supplies clocks to high
+ speed peripherals within the SoC.
+ Say yes here to support the clock controller on the EIC7700 HSP.
diff --git a/drivers/clk/eswin/Makefile b/drivers/clk/eswin/Makefile
index 4a7c2af82164..21a09a3396df 100644
--- a/drivers/clk/eswin/Makefile
+++ b/drivers/clk/eswin/Makefile
@@ -6,3 +6,4 @@
obj-$(CONFIG_COMMON_CLK_ESWIN) += clk.o
obj-$(CONFIG_COMMON_CLK_EIC7700) += clk-eic7700.o
+obj-$(CONFIG_COMMON_CLK_EIC7700_HSP) += clk-eic7700-hsp.o
diff --git a/drivers/clk/eswin/clk-eic7700-hsp.c b/drivers/clk/eswin/clk-eic7700-hsp.c
new file mode 100644
index 000000000000..65ad9e762ee9
--- /dev/null
+++ b/drivers/clk/eswin/clk-eic7700-hsp.c
@@ -0,0 +1,339 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd..
+ * All rights reserved.
+ *
+ * ESWIN EIC7700 HSP Clock Driver
+ *
+ * Authors: Xuyang Dong <dongxuyang@eswincomputing.com>
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/clock/eswin,eic7700-hspcrg.h>
+
+#include "common.h"
+
+#define EIC7700_HSP_SATA_REG 0x300
+#define EIC7700_HSP_MSHC0_REG 0x510
+#define EIC7700_HSP_MSHC1_REG 0x610
+#define EIC7700_HSP_MSHC2_REG 0x710
+#define EIC7700_HSP_USB0_REG 0x800
+#define EIC7700_HSP_USB0_REF_REG 0x83c
+#define EIC7700_HSP_USB1_REG 0x900
+#define EIC7700_HSP_USB1_REF_REG 0x93c
+
+#define USB_REF_XTAL24M 0x2a
+#define EIC7700_HSP_NR_CLKS (EIC7700_HSP_CLK_GATE_SATA + 1)
+
+struct eic7700_hsp_clk_gate {
+ struct clk_hw hw;
+ unsigned int id;
+ void __iomem *reg;
+ void __iomem *ref_reg;
+ const char *name;
+ const struct clk_parent_data *parent_data;
+ unsigned long flags;
+ unsigned long offset;
+ unsigned long ref_offset;
+ u8 bit_idx;
+ u8 gate_flags;
+ spinlock_t *lock; /* protect register read-modify-write cycle */
+};
+
+static inline struct eic7700_hsp_clk_gate *to_gate_clk(struct clk_hw *hw)
+{
+ return container_of(hw, struct eic7700_hsp_clk_gate, hw);
+}
+
+#define EIC7700_HSP_GATE(_id, _name, _pdata, _flags, _offset, _idx, \
+ _ref_offset) \
+ { \
+ .id = _id, \
+ .name = _name, \
+ .parent_data = _pdata, \
+ .flags = _flags, \
+ .offset = _offset, \
+ .ref_offset = _ref_offset, \
+ .bit_idx = _idx, \
+ }
+
+static void hsp_clk_gate_endisable(struct clk_hw *hw, int enable)
+{
+ struct eic7700_hsp_clk_gate *gate = to_gate_clk(hw);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(gate->lock, flags);
+
+ reg = readl(gate->reg);
+
+ if (enable)
+ reg |= BIT(gate->bit_idx);
+ else
+ reg &= ~BIT(gate->bit_idx);
+
+ /*
+ * Hardware bug: The reference clock is 24MHz, but the reference clock
+ * register reset to an incorrect default value.
+ * Workaround: Rewrite the correct value before enabling/disabling
+ * the gate clock.
+ */
+ writel(USB_REF_XTAL24M, gate->ref_reg);
+ writel(reg, gate->reg);
+
+ spin_unlock_irqrestore(gate->lock, flags);
+}
+
+static int hsp_clk_gate_enable(struct clk_hw *hw)
+{
+ hsp_clk_gate_endisable(hw, 1);
+
+ return 0;
+}
+
+static void hsp_clk_gate_disable(struct clk_hw *hw)
+{
+ hsp_clk_gate_endisable(hw, 0);
+}
+
+static int hsp_clk_gate_is_enabled(struct clk_hw *hw)
+{
+ struct eic7700_hsp_clk_gate *gate = to_gate_clk(hw);
+ u32 reg;
+
+ reg = readl(gate->reg);
+
+ reg &= BIT(gate->bit_idx);
+
+ return reg ? 1 : 0;
+}
+
+static const struct clk_ops hsp_clk_gate_ops = {
+ .enable = hsp_clk_gate_enable,
+ .disable = hsp_clk_gate_disable,
+ .is_enabled = hsp_clk_gate_is_enabled,
+};
+
+static struct clk_hw *
+hsp_clk_register_gate(struct device *dev, unsigned int id, const char *name,
+ const struct clk_parent_data *parent_data,
+ unsigned long flags, void __iomem *reg,
+ void __iomem *ref_reg, u8 bit_idx, u8 clk_gate_flags,
+ spinlock_t *lock)
+{
+ struct eic7700_hsp_clk_gate *gate;
+ struct clk_init_data init;
+ struct clk_hw *hw;
+ int ret;
+
+ gate = devm_kzalloc(dev, sizeof(*gate), GFP_KERNEL);
+ if (!gate)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = &hsp_clk_gate_ops;
+ init.flags = flags;
+ init.parent_data = parent_data;
+ init.num_parents = 1;
+
+ gate->id = id;
+ gate->reg = reg;
+ gate->ref_reg = ref_reg;
+ gate->bit_idx = bit_idx;
+ gate->gate_flags = clk_gate_flags;
+ gate->lock = lock;
+ gate->hw.init = &init;
+
+ hw = &gate->hw;
+ ret = devm_clk_hw_register(dev, hw);
+ if (ret)
+ hw = ERR_PTR(ret);
+
+ return hw;
+}
+
+static struct clk_parent_data hsp_cfg[] = {
+ { .fw_name = "hsp_cfg" }
+};
+
+static struct clk_parent_data hsp_mmc[] = {
+ { .fw_name = "hsp_mmc" }
+};
+
+static struct clk_parent_data hsp_usb_sata[] = {
+ { .fw_name = "hsp_sata" }
+};
+
+static struct eswin_fixed_factor_clock eic7700_hsp_factor_clks[] = {
+ ESWIN_FACTOR(EIC7700_HSP_CLK_FAC_CFG_DIV2, "factor_hsp_cfg_div2",
+ hsp_cfg, 1, 2, 0),
+ ESWIN_FACTOR(EIC7700_HSP_CLK_FAC_CFG_DIV4, "factor_hsp_cfg_div4",
+ hsp_cfg, 1, 4, 0),
+ ESWIN_FACTOR(EIC7700_HSP_CLK_FAC_MMC_DIV10, "factor_hsp_mmc_div10",
+ hsp_mmc, 1, 10, 0),
+};
+
+static struct eswin_gate_clock eic7700_hsp_gate_clks[] = {
+ ESWIN_GATE(EIC7700_HSP_CLK_GATE_SATA, "gate_clk_hsp_sata", hsp_usb_sata,
+ CLK_SET_RATE_PARENT, EIC7700_HSP_SATA_REG, 28, 0),
+ ESWIN_GATE(EIC7700_HSP_CLK_GATE_MSHC0_TMR, "gate_clk_hsp_mshc0_tmr",
+ hsp_mmc, CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC0_REG, 8, 0),
+ ESWIN_GATE(EIC7700_HSP_CLK_GATE_MSHC1_TMR, "gate_clk_hsp_mshc1_tmr",
+ hsp_mmc, CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC1_REG, 8, 0),
+ ESWIN_GATE(EIC7700_HSP_CLK_GATE_MSHC2_TMR, "gate_clk_hsp_mshc2_tmr",
+ hsp_mmc, CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC2_REG, 8, 0),
+};
+
+static struct eic7700_hsp_clk_gate eic7700_hsp_spec_gate_clks[] = {
+ EIC7700_HSP_GATE(EIC7700_HSP_CLK_GATE_USB0, "gate_clk_hsp_usb0",
+ hsp_usb_sata, CLK_SET_RATE_PARENT,
+ EIC7700_HSP_USB0_REG, 28, EIC7700_HSP_USB0_REF_REG),
+ EIC7700_HSP_GATE(EIC7700_HSP_CLK_GATE_USB1, "gate_clk_hsp_usb1",
+ hsp_usb_sata, CLK_SET_RATE_PARENT,
+ EIC7700_HSP_USB1_REG, 28, EIC7700_HSP_USB1_REF_REG),
+};
+
+static const struct clk_parent_data mux_mmc_3mux1_p[] = {
+ { .fw_name = "hsp_cfg" },
+ { .hw = &eic7700_hsp_factor_clks[0].hw },
+ { .hw = &eic7700_hsp_factor_clks[1].hw },
+};
+
+static const struct clk_parent_data mux_mmc_2mux1_p[] = {
+ { .fw_name = "hsp_mmc" },
+ { .hw = &eic7700_hsp_factor_clks[2].hw },
+};
+
+static u32 mux_mmc_3mux1_tbl[] = { 0x0, 0x1, 0x3 };
+
+static struct eswin_mux_clock eic7700_hsp_mux_clks[] = {
+ ESWIN_MUX_TBL(EIC7700_HSP_CLK_MUX_EMMC_3MUX1, "mux_hsp_emmc_3mux1",
+ mux_mmc_3mux1_p, ARRAY_SIZE(mux_mmc_3mux1_p),
+ CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC0_REG, 16, 2, 0,
+ mux_mmc_3mux1_tbl),
+ ESWIN_MUX_TBL(EIC7700_HSP_CLK_MUX_SD0_3MUX1, "mux_hsp_sd0_3mux1",
+ mux_mmc_3mux1_p, ARRAY_SIZE(mux_mmc_3mux1_p),
+ CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC1_REG, 16, 2, 0,
+ mux_mmc_3mux1_tbl),
+ ESWIN_MUX_TBL(EIC7700_HSP_CLK_MUX_SD1_3MUX1, "mux_hsp_sd1_3mux1",
+ mux_mmc_3mux1_p, ARRAY_SIZE(mux_mmc_3mux1_p),
+ CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC2_REG, 16, 2, 0,
+ mux_mmc_3mux1_tbl),
+ ESWIN_MUX(EIC7700_HSP_CLK_MUX_EMMC_CQE_2MUX1, "mux_hsp_emmc_cqe_2mux1",
+ mux_mmc_2mux1_p, ARRAY_SIZE(mux_mmc_2mux1_p),
+ CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC0_REG, 0, 1, 0),
+ ESWIN_MUX(EIC7700_HSP_CLK_MUX_SD0_CQE_2MUX1, "mux_hsp_sd0_cqe_2mux1",
+ mux_mmc_2mux1_p, ARRAY_SIZE(mux_mmc_2mux1_p),
+ CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC1_REG, 0, 1, 0),
+ ESWIN_MUX(EIC7700_HSP_CLK_MUX_SD1_CQE_2MUX1, "mux_hsp_sd1_cqe_2mux1",
+ mux_mmc_2mux1_p, ARRAY_SIZE(mux_mmc_2mux1_p),
+ CLK_SET_RATE_PARENT, EIC7700_HSP_MSHC2_REG, 0, 1, 0),
+};
+
+static struct eswin_clk_info eic7700_hsp_clks[] = {
+ ESWIN_GATE_TYPE(EIC7700_HSP_CLK_GATE_EMMC, "gate_clk_hsp_emmc",
+ EIC7700_HSP_CLK_MUX_EMMC_3MUX1,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ EIC7700_HSP_MSHC0_REG, 24, 0),
+ ESWIN_GATE_TYPE(EIC7700_HSP_CLK_GATE_SD0, "gate_clk_hsp_sd0",
+ EIC7700_HSP_CLK_MUX_SD0_3MUX1,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ EIC7700_HSP_MSHC1_REG, 24, 0),
+ ESWIN_GATE_TYPE(EIC7700_HSP_CLK_GATE_SD1, "gate_clk_hsp_sd1",
+ EIC7700_HSP_CLK_MUX_SD1_3MUX1,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ EIC7700_HSP_MSHC2_REG, 24, 0),
+};
+
+static int eic7700_hsp_clk_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct auxiliary_device *adev;
+ struct eswin_clock_data *data;
+ struct clk_hw *hw;
+ int i, ret;
+
+ data = eswin_clk_init(pdev, EIC7700_HSP_NR_CLKS);
+ if (IS_ERR(data))
+ return dev_err_probe(dev, PTR_ERR(data),
+ "failed to get clk data!\n");
+
+ ret = eswin_clk_register_fixed_factor
+ (dev, eic7700_hsp_factor_clks,
+ ARRAY_SIZE(eic7700_hsp_factor_clks), data);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to register fixed factor clock\n");
+
+ ret = eswin_clk_register_gate(dev, eic7700_hsp_gate_clks,
+ ARRAY_SIZE(eic7700_hsp_gate_clks), data);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to register gate clock\n");
+
+ ret = eswin_clk_register_mux(dev, eic7700_hsp_mux_clks,
+ ARRAY_SIZE(eic7700_hsp_mux_clks),
+ data);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to register mux clock\n");
+
+ ret = eswin_clk_register_clks(dev, eic7700_hsp_clks,
+ ARRAY_SIZE(eic7700_hsp_clks), data);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to register clock\n");
+
+ for (i = 0; i < ARRAY_SIZE(eic7700_hsp_spec_gate_clks); i++) {
+ struct eic7700_hsp_clk_gate *gate;
+
+ gate = &eic7700_hsp_spec_gate_clks[i];
+ hw = hsp_clk_register_gate(dev, gate->id, gate->name,
+ gate->parent_data, gate->flags,
+ data->base + gate->offset,
+ data->base + gate->ref_offset,
+ gate->bit_idx, 0, &data->lock);
+ if (IS_ERR(hw))
+ return dev_err_probe(dev, PTR_ERR(hw),
+ "failed to register gate clock\n");
+
+ data->clk_data.hws[gate->id] = hw;
+ }
+
+ ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
+ &data->clk_data);
+ if (ret)
+ return dev_err_probe(dev, ret, "add clk provider failed\n");
+
+ adev = devm_auxiliary_device_create(dev, "hsp-reset",
+ (__force void *)data->base);
+ if (!adev)
+ return dev_err_probe(dev, -ENODEV,
+ "register hsp-reset device failed\n");
+
+ return 0;
+}
+
+static const struct of_device_id eic7700_hsp_clock_dt_ids[] = {
+ { .compatible = "eswin,eic7700-hspcrg", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, eic7700_hsp_clock_dt_ids);
+
+static struct platform_driver eic7700_hsp_clock_driver = {
+ .probe = eic7700_hsp_clk_probe,
+ .driver = {
+ .name = "eic7700-hsp-clock",
+ .of_match_table = eic7700_hsp_clock_dt_ids,
+ },
+};
+
+module_platform_driver(eic7700_hsp_clock_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Xuyang Dong <dongxuyang@eswincomputing.com>");
+MODULE_DESCRIPTION("ESWIN EIC7700 HSP clock controller driver");
--
2.34.1
^ permalink raw reply related
* [PATCH 3/3] reset: eswin: Add eic7700 HSP reset driver
From: dongxuyang @ 2026-04-03 9:36 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk, devicetree,
linux-kernel, p.zabel, huangyifeng, dongxuyang
Cc: ningyu, linmin, pinkesh.vaghela
In-Reply-To: <20260403093459.612-1-dongxuyang@eswincomputing.com>
From: Xuyang Dong <dongxuyang@eswincomputing.com>
Add auxiliary driver to support ESWIN EIC7700 high-speed peripherals
system. The reset controller is created using the auxiliary device
framework and set up in the clock driver.
Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
---
drivers/reset/Kconfig | 13 +++
drivers/reset/Makefile | 1 +
drivers/reset/reset-eic7700-hsp.c | 151 ++++++++++++++++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 drivers/reset/reset-eic7700-hsp.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 7ce151f6a7e4..50bb0cd069ba 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -83,6 +83,19 @@ config RESET_EIC7700
The driver supports eic7700 series chips and provides functionality for
asserting and deasserting resets on the chip.
+config RESET_EIC7700_HSP
+ tristate "EIC7700 HSP Reset controller"
+ depends on ARCH_ESWIN || COMPILE_TEST
+ depends on COMMON_CLK_EIC7700_HSP
+ select AUXILIARY_BUS
+ default COMMON_CLK_EIC7700_HSP
+ help
+ This enables the HSP reset controller driver for ESWIN SoCs. This
+ driver is specific to ESWIN SoCs and should only be enabled if using
+ such hardware.
+ The driver supports EIC7700 series chips and provides functionality
+ for asserting and deasserting resets on the chip.
+
config RESET_EYEQ
bool "Mobileye EyeQ reset controller"
depends on MACH_EYEQ5 || MACH_EYEQ6H || COMPILE_TEST
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index fc0cc99f8514..c8baaab75508 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
obj-$(CONFIG_RESET_BRCMSTB) += reset-brcmstb.o
obj-$(CONFIG_RESET_BRCMSTB_RESCAL) += reset-brcmstb-rescal.o
obj-$(CONFIG_RESET_EIC7700) += reset-eic7700.o
+obj-$(CONFIG_RESET_EIC7700_HSP) += reset-eic7700-hsp.o
obj-$(CONFIG_RESET_EYEQ) += reset-eyeq.o
obj-$(CONFIG_RESET_GPIO) += reset-gpio.o
obj-$(CONFIG_RESET_HSDK) += reset-hsdk.o
diff --git a/drivers/reset/reset-eic7700-hsp.c b/drivers/reset/reset-eic7700-hsp.c
new file mode 100644
index 000000000000..fe9822078bcc
--- /dev/null
+++ b/drivers/reset/reset-eic7700-hsp.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd..
+ * All rights reserved.
+ *
+ * ESWIN EIC7700 HSP Reset Driver
+ *
+ * Authors: Xuyang Dong <dongxuyang@eswincomputing.com>
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+#include <dt-bindings/reset/eswin,eic7700-hspcrg.h>
+
+/**
+ * struct eic7700_hsp_reset_data - reset controller information structure
+ * @rcdev: reset controller entity
+ * @regmap: regmap handle containing the memory-mapped reset registers
+ */
+struct eic7700_hsp_reset_data {
+ struct reset_controller_dev rcdev;
+ struct regmap *regmap;
+};
+
+static const struct regmap_config eic7700_hsp_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .max_register = 0x1ffc,
+ .reg_stride = 4,
+};
+
+struct eic7700_hsp_reg {
+ u32 reg;
+ u32 bit;
+ bool active_low;
+};
+
+static inline struct eic7700_hsp_reset_data *
+to_eic7700_hsp_reset(struct reset_controller_dev *rcdev)
+{
+ return container_of(rcdev, struct eic7700_hsp_reset_data, rcdev);
+}
+
+static const struct eic7700_hsp_reg eic7700_hsp_reset[] = {
+ [EIC7700_HSP_RST_SATA_P0] = {0x340, BIT(0), false},
+ [EIC7700_HSP_RST_SATA_PHY] = {0x340, BIT(1), false},
+ [EIC7700_HSP_RST_USB0] = {0x800, BIT(24), true},
+ [EIC7700_HSP_RST_USB1] = {0x900, BIT(24), true},
+ [EIC7700_HSP_RST_USB0_PHY] = {0x800, BIT(25), false},
+ [EIC7700_HSP_RST_USB1_PHY] = {0x900, BIT(25), false},
+};
+
+static int eic7700_hsp_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct eic7700_hsp_reset_data *data = to_eic7700_hsp_reset(rcdev);
+ int ret;
+
+ if (eic7700_hsp_reset[id].active_low)
+ ret = regmap_clear_bits(data->regmap, eic7700_hsp_reset[id].reg,
+ eic7700_hsp_reset[id].bit);
+ else
+ ret = regmap_set_bits(data->regmap, eic7700_hsp_reset[id].reg,
+ eic7700_hsp_reset[id].bit);
+
+ return ret;
+}
+
+static int eic7700_hsp_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct eic7700_hsp_reset_data *data = to_eic7700_hsp_reset(rcdev);
+ int ret;
+
+ if (eic7700_hsp_reset[id].active_low)
+ ret = regmap_set_bits(data->regmap, eic7700_hsp_reset[id].reg,
+ eic7700_hsp_reset[id].bit);
+ else
+ ret = regmap_clear_bits(data->regmap, eic7700_hsp_reset[id].reg,
+ eic7700_hsp_reset[id].bit);
+
+ return ret;
+}
+
+static int eic7700_hsp_reset_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ int ret;
+
+ ret = eic7700_hsp_reset_assert(rcdev, id);
+ if (ret)
+ return ret;
+
+ usleep_range(10, 15);
+
+ return eic7700_hsp_reset_deassert(rcdev, id);
+}
+
+static const struct reset_control_ops eic7700_hsp_reset_ops = {
+ .reset = eic7700_hsp_reset_reset,
+ .assert = eic7700_hsp_reset_assert,
+ .deassert = eic7700_hsp_reset_deassert,
+};
+
+static int eic7700_hsp_reset_probe(struct auxiliary_device *adev,
+ const struct auxiliary_device_id *id)
+{
+ struct eic7700_hsp_reset_data *data;
+ struct device *dev = &adev->dev;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->regmap = devm_regmap_init_mmio
+ (dev, (__force void __iomem *)adev->dev.platform_data,
+ &eic7700_hsp_regmap_config);
+ if (IS_ERR(data->regmap))
+ return dev_err_probe(dev, PTR_ERR(data->regmap),
+ "failed to get regmap!\n");
+
+ data->rcdev.owner = THIS_MODULE;
+ data->rcdev.ops = &eic7700_hsp_reset_ops;
+ data->rcdev.of_node = dev->parent->of_node;
+ data->rcdev.of_reset_n_cells = 1;
+ data->rcdev.dev = dev;
+ data->rcdev.nr_resets = ARRAY_SIZE(eic7700_hsp_reset);
+
+ return devm_reset_controller_register(dev, &data->rcdev);
+}
+
+static const struct auxiliary_device_id eic7700_hsp_reset_dt_ids[] = {
+ { .name = "clk_eic7700_hsp.hsp-reset", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(auxiliary, eic7700_hsp_reset_dt_ids);
+
+static struct auxiliary_driver eic7700_hsp_reset_driver = {
+ .probe = eic7700_hsp_reset_probe,
+ .id_table = eic7700_hsp_reset_dt_ids,
+};
+
+module_auxiliary_driver(eic7700_hsp_reset_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Xuyang Dong <dongxuyang@eswincomputing.com>");
+MODULE_DESCRIPTION("ESWIN EIC7700 HSP Reset Controller Driver");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 11/15] media: qcom: Switch to generic PAS TZ APIs
From: Jorge Ramirez @ 2026-04-03 9:37 UTC (permalink / raw)
To: Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <20260327131043.627120-12-sumit.garg@kernel.org>
On 27/03/26 18:40:39, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
OP-TEE based PAS service relies on the linux driver to configure the
iommu (just as it is done on the no_tz case). This generic patch does
not cover that requirement.
Because of that, it is probably better if the commit message doesnt
mention OP-TEE and instead maybe indicate that PAS wll support TEEs that
implement the same restrictions that QTEE (ie, iommu configuration).
I can send an RFC for OP-TEE support based on the integration work being
carried out here [1]
[1] https://github.com/OP-TEE/optee_os/pull/7721#discussion_r3016923507
>
> Along with that pass proper PAS ID to set_remote_state API. As per testing
> the SCM backend just ignores it while OP-TEE makes use of it to for proper
> book keeping purpose.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/Kconfig | 25 ++++++++++---------
> .../media/platform/qcom/iris/iris_firmware.c | 9 ++++---
> drivers/media/platform/qcom/venus/Kconfig | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 11 ++++----
> 4 files changed, 25 insertions(+), 21 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel
From: Coiby Xu @ 2026-04-03 9:36 UTC (permalink / raw)
To: Sourabh Jain
Cc: kexec, linux-arm-kernel, linuxppc-dev, devicetree,
Arnaud Lefebvre, Baoquan he, Dave Young, Kairui Song, Pingfan Liu,
Andrew Morton, Krzysztof Kozlowski, Rob Herring, Thomas Staudt,
Will Deacon, Christophe Leroy (CS GROUP), Catalin Marinas,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Saravana Kannan, open list
In-Reply-To: <51761fcf-955f-45e2-97a5-2b49d8e79d04@linux.ibm.com>
On Thu, Apr 02, 2026 at 04:24:14PM +0530, Sourabh Jain wrote:
>
>
>On 25/02/26 11:33, Coiby Xu wrote:
>>CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted
>>device dump target by addressing two challenges [1],
>> - Kdump kernel may not be able to decrypt the LUKS partition. For some
>> machines, a system administrator may not have a chance to enter the
>> password to decrypt the device in kdump initramfs after the 1st kernel
>> crashes
>>
>> - LUKS2 by default use the memory-hard Argon2 key derivation function
>> which is quite memory-consuming compared to the limited memory reserved
>> for kdump.
>>
>>To also enable this feature for ARM64 and PowerPC, the missing piece is
>>to let the kdump kernel know where to find the dm-crypt keys which are
>>randomly stored in memory reserved for kdump. Introduce a new device
>>tree property dmcryptkeys [2] as similar to elfcorehdr to pass the
>>memory address of the stored info of dm-crypt keys to the kdump kernel.
>>Since this property is only needed by the kdump kernel, it won't be
>>exposed to user space.
>>
>>[1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
>>[2] https://github.com/devicetree-org/dt-schema/pull/181
>>
>>Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
>>Cc: Baoquan he <bhe@redhat.com>
>>Cc: Dave Young <dyoung@redhat.com>
>>Cc: Kairui Song <ryncsn@gmail.com>
>>Cc: Pingfan Liu <kernelfans@gmail.com>
>>Cc: Andrew Morton <akpm@linux-foundation.org>
>>Cc: Krzysztof Kozlowski <krzk@kernel.org>
>>Cc: Rob Herring <robh@kernel.org>
>>Cc: Thomas Staudt <tstaudt@de.ibm.com>
>>Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
>>Cc: Will Deacon <will@kernel.org>
>>Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
>>Signed-off-by: Coiby Xu <coxu@redhat.com>
>>---
>> arch/arm64/kernel/machine_kexec_file.c | 4 ++++
>> arch/powerpc/kexec/elf_64.c | 4 ++++
>> drivers/of/fdt.c | 21 +++++++++++++++++++++
>> drivers/of/kexec.c | 19 +++++++++++++++++++
>> 4 files changed, 48 insertions(+)
>>
>>diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>>index fba260ad87a9..e31fabed378a 100644
>>--- a/arch/arm64/kernel/machine_kexec_file.c
>>+++ b/arch/arm64/kernel/machine_kexec_file.c
>>@@ -134,6 +134,10 @@ int load_other_segments(struct kimage *image,
>> kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
>> image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
>>+
>>+ ret = crash_load_dm_crypt_keys(image);
>>+ if (ret)
>>+ goto out_err;
>> }
>> #endif
>>diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
>>index 5d6d616404cf..ea50a072debf 100644
>>--- a/arch/powerpc/kexec/elf_64.c
>>+++ b/arch/powerpc/kexec/elf_64.c
>>@@ -79,6 +79,10 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>> goto out;
>> }
>>+ ret = crash_load_dm_crypt_keys(image);
>>+ if (ret)
>>+ goto out;
>>+
>> /* Setup cmdline for kdump kernel case */
>> modified_cmdline = setup_kdump_cmdline(image, cmdline,
>> cmdline_len);
>>diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>>index 331646d667b9..2967e4aff807 100644
>>--- a/drivers/of/fdt.c
>>+++ b/drivers/of/fdt.c
>>@@ -866,6 +866,26 @@ static void __init early_init_dt_check_for_elfcorehdr(unsigned long node)
>> elfcorehdr_addr, elfcorehdr_size);
>> }
>>+static void __init early_init_dt_check_for_dmcryptkeys(unsigned long node)
>>+{
>>+ const char *prop_name = "linux,dmcryptkeys";
>>+ const __be32 *prop;
>>+
>>+ if (!IS_ENABLED(CONFIG_CRASH_DM_CRYPT))
>>+ return;
>>+
>>+ pr_debug("Looking for dmcryptkeys property... ");
>>+
>>+ prop = of_get_flat_dt_prop(node, prop_name, NULL);
>>+ if (!prop)
>>+ return;
>>+
>>+ dm_crypt_keys_addr = dt_mem_next_cell(dt_root_addr_cells, &prop);
>>+
>>+ /* Property only accessible to crash dump kernel */
>>+ fdt_delprop(initial_boot_params, node, prop_name);
>>+}
>>+
>> static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
>> /*
>>@@ -1097,6 +1117,7 @@ int __init early_init_dt_scan_chosen(char *cmdline)
>> early_init_dt_check_for_initrd(node);
>> early_init_dt_check_for_elfcorehdr(node);
>>+ early_init_dt_check_for_dmcryptkeys(node);
>> rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
>> if (rng_seed && l > 0) {
>>diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
>>index c4cf3552c018..fbd253f0d3c5 100644
>>--- a/drivers/of/kexec.c
>>+++ b/drivers/of/kexec.c
>>@@ -423,6 +423,25 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
>> if (ret)
>> goto out;
>>+ if (image->dm_crypt_keys_addr != 0) {
>>+ ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
>>+ "linux,dmcryptkeys",
>>+ image->dm_crypt_keys_addr,
>>+ image->dm_crypt_keys_sz);
>>+
>>+ if (ret)
>>+ goto out;
>>+
>>+ /*
>>+ * Avoid dmcryptkeys from being stomped on in kdump kernel by
>>+ * setting up memory reserve map.
>>+ */
>>+ ret = fdt_add_mem_rsv(fdt, image->dm_crypt_keys_addr,
>>+ image->dm_crypt_keys_sz);
>>+ if (ret)
>>+ goto out;
>>+ }
>>+
>> #ifdef CONFIG_CRASH_DUMP
>> /* add linux,usable-memory-range */
>> ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
>
>The above changes look good to me.
>
>Feel free to add:
>Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Thanks for reviewing the patch!
>
>But while reading crash_load_dm_crypt_keys() I noticed a possibility of a
>double free at the address pointed by `keys_header`:
>
>In crash_load_dm_crypt_keys()/crash_dump_dm_crypt.c
> snip...
>
> kbuf.buffer = keys_header;
>
> snip....
>
> r = kexec_add_buffer(&kbuf);
> if (r) {
> pr_err("Failed to call kexec_add_buffer, ret=%d\n", r);
> kvfree((void *)kbuf.buffer); <---
>First Free
> return r;
> }
>
>Since `keys_header` is not reset, the next call to build_keys_header()
>will cause a double free at `keys_header`.
>
>static int build_keys_header(void)
>{
>
> snip...
>
> if (keys_header != NULL)
> kvfree(keys_header);
>
> snip...
>}
>
>What do you think?
>
>- Sourabh Jain
Good catch! I'll send a patch to address this issue. Thanks!
--
Best regards,
Coiby
^ permalink raw reply
* Re: [PATCH v5 2/3] riscv: dts: spacemit: Define the P1 PMIC regulators for OrangePi RV2
From: Chukun Pan @ 2026-04-03 9:40 UTC (permalink / raw)
To: gaohan
Cc: alex, amadeus, aou, conor+dt, devicetree, dlan, krzk+dt,
linux-kernel, linux-riscv, palmer, pjw, rabenda.cn, robh,
spacemit
In-Reply-To: <6376799689e094253fb1dc0e3e27b491be46e9db.1775148159.git.gaohan@iscas.ac.cn>
Hi,
> @@ -91,6 +110,94 @@ &i2c8 {
> pinctrl-0 = <&i2c8_cfg>;
> pinctrl-names = "default";
> status = "okay";
Perhaps the previous i2c8 enabling patch could be merged with this one.
For the floating sections, I suggest marking them as "not connected":
```
regulators {
buck1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
buck2 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
buck3_1v8: buck3 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1800000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
buck4_3v3: buck4 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3300000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
buck5: buck5 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
buck6 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
regulator-always-on;
};
aldo1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3400000>;
regulator-boot-on;
};
aldo2 {
/* not connected */
};
aldo3 {
/* not connected */
};
aldo4 {
/* not connected */
};
dldo1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3400000>;
regulator-boot-on;
};
dldo2 {
/* not connected */
};
dldo3 {
/* not connected */
};
dldo4 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3400000>;
regulator-always-on;
};
dldo5 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3400000>;
};
dldo6 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3400000>;
regulator-always-on;
};
dldo7 {
/* not connected */
};
};
```
Thanks,
Chukun
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-03 9:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <ab6a06c1-2d7d-4032-8d38-063470cd45c0@lunn.ch>
On 3/26/26 13:18, Andrew Lunn wrote:
>> + mutex_lock(&dev->alu_mutex);
>> +
>> + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, 0x6F, indir_reg);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val);
>> +
>> + mutex_unlock(&dev->alu_mutex);
>
> What address space are these registers in? Normally workarounds for a
> PHY would be in the PHY driver. But that assumes the registers are
> accessible from the PHY driver.
>
> Andrew
Hi Andrew,
These registers belong to the KSZ87xx switch address space, accessed
through the switch’s indirect access mechanism. In particular, the
offsets used here correspond to entries within the TABLE_LINK_MD_V
indirect table of the KSZ8-family switches.
In the next revision I will switch to using ksz8_ind_write8(), and I
will also replace the remaining magic values with proper register macros.
Best regards,
Fidelio
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel
From: Coiby Xu @ 2026-04-03 9:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Sourabh Jain, kexec, linux-arm-kernel, linuxppc-dev, devicetree,
Arnaud Lefebvre, Baoquan he, Dave Young, Kairui Song, Pingfan Liu,
Krzysztof Kozlowski, Rob Herring, Thomas Staudt, Will Deacon,
Christophe Leroy (CS GROUP), Catalin Marinas, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Saravana Kannan, open list
In-Reply-To: <20260402233118.08ea88a6836bd10f01031cce@linux-foundation.org>
On Thu, Apr 02, 2026 at 11:31:18PM -0700, Andrew Morton wrote:
>On Thu, 2 Apr 2026 16:24:14 +0530 Sourabh Jain <sourabhjain@linux.ibm.com> wrote:
>
>> But while reading crash_load_dm_crypt_keys() I noticed a possibility of a
>> double free at the address pointed by `keys_header`:
>>
>> In crash_load_dm_crypt_keys()/crash_dump_dm_crypt.c
>> snip...
>>
>> kbuf.buffer = keys_header;
>>
>> snip....
>>
>> r = kexec_add_buffer(&kbuf);
>> if (r) {
>> pr_err("Failed to call kexec_add_buffer, ret=%d\n", r);
>> kvfree((void *)kbuf.buffer); <---
>> First Free
>> return r;
>> }
>>
>> Since `keys_header` is not reset, the next call to build_keys_header()
>> will cause a double free at `keys_header`.
>>
>> static int build_keys_header(void)
>> {
>>
>> snip...
>>
>> if (keys_header != NULL)
>> kvfree(keys_header);
>>
>> snip...
>> }
>>
>> What do you think?
>
>It looks that way to me.
Thanks for confirming it! I'll send a patch after finishing the testing.
--
Best regards,
Coiby
^ permalink raw reply
* Re: [PATCH v2 10/10] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Liu Ying @ 2026-04-03 9:48 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <DHIJ00VZ2O0H.1550LBTEFNT83@bootlin.com>
Hi Luca,
On Thu, Apr 02, 2026 at 10:28:45AM +0200, Luca Ceresoli wrote:
> Hello Liu,
>
> On Thu Apr 2, 2026 at 6:55 AM CEST, Liu Ying wrote:
>> Hi Luca,
>>
>> On Mon, Mar 30, 2026 at 09:25:51PM +0200, Luca Ceresoli wrote:
>>> Convert this driver to DRM_BRIDGE_ATTACH_NO_CONNECTOR and to the
>>> drm_bridge_connector framework which is the current DRM bridge best
>>> practice.
>>>
>>> Tested-by: Martyn Welch <martyn.welch@collabora.com>
>>> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
>>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
>>> @@ -86,11 +88,23 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
>>> "Failed to initialize encoder for endpoint%u\n",
>>> of_ep.id);
>>>
>>> - ret = drm_bridge_attach(encoder, bridge, NULL, 0);
>>> + ret = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>>
>> It seems that only analogix-anx6345.c, analogix-anx78xx.c and analogix_dp_core.c
>> don't allow DRM_BRIDGE_ATTACH_NO_CONNECTOR, since they error out when attaching
>> the bridge with the flag:
>>
>> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
>> DRM_ERROR("Fix bridge driver to make connector optional!");
>> return -EINVAL;
>> }
>>
>> Looks like i.MX8MP platforms don't use these drivers.
>
> Exactly. I have checked all the drivers involved with the i.MX8MP and all
> of the support DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Great...
>
> While converting all drivers is surely a good goal, converting all of them
> at once is not realistically doable. So the approach I took was to convert
> one specifically (lcdif_drv.c) plus all those which would break because
> they are used with the LCDIF.
>
>> But, are we completely safe here by adding the flag? You also mentioned
>> "pitfalls" in commit mesg, which makes me a bit more worried.
>
> I mentioned potential pitfalls in the cover letter mainly because of the DT
> overlay insertion patch, which is somewhat tricky as it impacts many
> boards.
>
> Additionally it's not easy to spot all usages of this component by parsing
> dozens of dts files, so I might have missed some.
>
> So overall every patch sent has a potential for pitfalls, but for the
> reasons above I think this series has a bit more.
>
> Does this reassure you? :)
... your check makes me a bit relaxed.
>
>>> if (ret)
>>> return dev_err_probe(dev, ret,
>>> "Failed to attach bridge for endpoint%u\n",
>>> of_ep.id);
>>> +
>>> + connector = drm_bridge_connector_init(lcdif->drm, encoder);
>>
>> Also, kernel doc of drm_bridge_connector.c says:
>>
>> * To make use of this helper, all bridges in the chain shall report bridge
>> * operation flags (&drm_bridge->ops) and bridge output type
>> * (&drm_bridge->type), as well as the DRM_BRIDGE_ATTACH_NO_CONNECTOR attach
>> * flag (none of the bridges shall create a DRM connector directly).
>>
>> Are you sure that we are safe to use this helper?
>
> Yes. I have checked all in-tree dts[i] files for all the 3 LCDIFs.
>
> For the LCDIF3, the pipeline is:
>
> LCDIF3 -> fsl,imx8mp-hdmi-pvi -> fsl,imx8mp-hdmi-tx -> HDMI connector
>
> And the involved bridges are:
>
> * fsl,imx8mp-hdmi-pvi has ops = 0 (it doesn't set it) because it
> implements none the optional features mentioned by those flags, and it
> honors the DRM_BRIDGE_ATTACH_NO_CONNECTOR by propagating it
>
> * fsl,imx8mp-hdmi-tx is implemented based on dw-hdmi, which sets ops as
> appropriate and also propagates the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
>
> * display-connector (enabled via the DT overlay if needed) sets ops and
> makes DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory
>
> The LCDIF2 involves the panel-bridge, display-connector and lvds-decoder
> which also set ops as needed and propagate DRM_BRIDGE_ATTACH_NO_CONNECTOR
> or make it mandatory.
For now, LCDIF2 with LDB only supports LVDS panel, so display-connector and
lvds-decoder are not enabled yet, though they can be in DT.
>
> The same applies to the drivers used with the LCDIF1: adv7511, tc358767 and
> the panel bridge.
>
> I assume this answers your doubts. Let me know if it doesn't.
Your description here for each LCDIF is helpful for reviewer to understand
there will be no regression introduced by this commit, so I think it'd be
good to put it in commit message - it reflects your thought about avoiding
any regression and that it's not that easy to switch to the bridge connector
helper(as an example for other DRM drivers to do the switch).
With that done, I'll provide my R-b. Thanks.
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com/
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v11 0/4] crypto: spacc - Add SPAcc Crypto Driver
From: Ruud Derwig @ 2026-04-03 9:48 UTC (permalink / raw)
To: Tony He
Cc: Pavitrakumar Managutte, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
herbert@gondor.apana.org.au, robh@kernel.org, conor+dt@kernel.org,
manjunath.hadli@vayavyalabs.com, adityak@vayavyalabs.com,
navami.telsang@vayavyalabs.com, bhoomikak@vayavyalabs.com
In-Reply-To: <CAAUX2SX3wjsj8JLkej4oKR=77BQK2AEmc2tAqe8eCJqO=gaizg@mail.gmail.com>
Hi Tony,
> My concern is that the main bottleneck may not be the crypto
> throughput itself, but the per-packet overhead, such as
> ...
> Could you please confirm whether this understanding is correct?
System performance depends on many factors, CPU speed, memory
architecture etc. Trade-off between packet size and overheads differ,
but indeed should be taken into account when deciding to offload or
not. Note that besides performance, other factors like security level
(e.g. side-channel attack resistance, key management), or functional
safety (automotive and other safety critical domains) should be
considered as well.
Ruud.
^ permalink raw reply
* [PATCH 0/3] Add support for Renesas CAN-FD Bus-Off recovery mode selection
From: Biju @ 2026-04-03 9:49 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: Biju Das, Fabrizio Castro, linux-can, devicetree,
linux-renesas-soc, linux-kernel, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
The CAN-FD IP supports the below Bus-Off recovery modes:
1) ISO11898-1 compliant
2) Entry to Channel Halt mode automatically at bus-off entry
3) Entry to Channel Halt mode automatically at bus-off end
4) Entry to Channel Halt mode (in bus-off state) by program request
Add support for Bus-Off recovery mode selection via the
renesas,bus-off-recovery-mode device tree property. If the property is
absent, it defaults to RCANFD_CCTR_BOM_BENTRY (entry to Channel Halt mode
automatically at bus-off entry) for backward compatibility.
Testing:
CANBUS-OFF trigger on RZ/G3E SMARC EVK:-
Enable
CONFIG_EXPERT=y
CONFIG_GPIO_SYSFS=y
echo 556 > /sys/class/gpio/export
echo 557 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio556/direction
echo out > /sys/class/gpio/gpio557/direction
echo 1 > /sys/class/gpio/gpio556/value
echo 1 > /sys/class/gpio/gpio557/value
ip link set can0 down
ip link set can1 down
ip link set can0 up type can bitrate 1000000 dbitrate 4000000 fd on restart-ms 100
ip link set can1 up type can bitrate 1000000 dbitrate 4000000 fd on restart-ms 100
Set the switches SW_GPIO8_CAN0_STB and SW_GPIO9_CAN1_STB to STANDBY mode
candump can0 &
cansend can1 123#1122334455667788
This will trigger BUS-OFF as CAN is in STANDBY mode
Then, Set the switches SW_GPIO8_CAN0_STB and SW_GPIO9_CAN1_STB to
NORMAL mode, the messages started receiving after bus-off errors.
With BOM=0, after bus recovery, Bus-Off recovery interrupt is triggered
by CAN-FD IP.
Biju Das (3):
dt-bindings: can: renesas,rcar-canfd: Document
renesas,bus-off-recovery-mode property
can: rcar_canfd: Add support for Bus-Off recovery mode selection
can: rcar_canfd: Handle Bus-Off recovery interrupt
.../bindings/net/can/renesas,rcar-canfd.yaml | 11 ++++++++++
drivers/net/can/rcar/rcar_canfd.c | 20 +++++++++++++------
2 files changed, 25 insertions(+), 6 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/3] dt-bindings: can: renesas,rcar-canfd: Document renesas,bus-off-recovery-mode property
From: Biju @ 2026-04-03 9:49 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: Biju Das, Fabrizio Castro, linux-can, devicetree,
linux-renesas-soc, linux-kernel, Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260403095003.104542-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Document renesas,bus-off-recovery-mode property in the Renesas R-Car
CAN FD controller binding. This optional u32 property allows selection of
the bus-off recovery behaviour, supporting four modes:
0: ISO11898-1 compliant recovery
1: Automatic entry to Channel Halt mode at bus-off entry (default)
2: Automatic entry to Channel Halt mode at bus-off end
3: Entry to Channel Halt mode in bus-off state via program request
The default value of 1 ensures backward compatibility when the property is
omitted.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
.../bindings/net/can/renesas,rcar-canfd.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index b9d9dd7a7967..4190e514a7fd 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -154,6 +154,17 @@ properties:
communication in Classical CAN frame format is disabled. Specify this
property to put the controller in FD-Only mode.
+ renesas,bus-off-recovery-mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1, 2, 3 ]
+ default: 1
+ description: |
+ Bus-Off recovery mode selection. Valid values are:
+ <0> : ISO11898-1 compliant
+ <1> : Entry to halt mode automatically at bus-off entry (default)
+ <2> : Entry to halt mode automatically at bus-off end
+ <3> : Entry to halt mode (in bus-off state) by program request
+
assigned-clocks:
description:
Reference to the CANFD clock. The CANFD clock is a div6 clock and can be
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 3/3] riscv: dts: spacemit: Enable USB3.0/PCIe on OrangePi RV2
From: Chukun Pan @ 2026-04-03 9:50 UTC (permalink / raw)
To: gaohan
Cc: alex, amadeus, aou, conor+dt, devicetree, dlan, krzk+dt,
linux-kernel, linux-riscv, palmer, pjw, rabenda.cn, robh,
spacemit
In-Reply-To: <cfe646a5549a2b3fc8a4335c3ab4918599615369.1775148159.git.gaohan@iscas.ac.cn>
Hi,
> + pcie_vcc_3v3: regulator-pcie-vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "pcie_vcc3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio K1_GPIO(116) GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
I would like to maintain the same property order as the
regulator below, and add vin-supply:
```
pcie_vcc3v3: pcie-vcc3v3 {
compatible = "regulator-fixed";
enable-active-high;
gpios = <&gpio K1_GPIO(116) GPIO_ACTIVE_HIGH>;
regulator-name = "pcie_vcc3v3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_5v0>;
};
```
> +&pcie1 {
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
> +&pcie2 {
> + vpcie3v3-supply = <&pcie_vcc_3v3>;
I think vpcie3v3-supply is not needed here. [1]
> + hub_2_0: hub@1 {
> + compatible = "usb5e3,610";
> + reg = <0x1>;
> + peer-hub = <&hub_3_0>;
> + vdd-supply = <&vcc5v0_usb30>;
vdd-supply = <&vcc_5v0>;
Please refer to the schematic. [2]
[1] https://lore.kernel.org/linux-pci/u53qfrubgrcamiz35ox6lcdpp5bbzfwcsic466z5r6yyx6xz3n@c64nw2pegtfe/
[2] https://drive.google.com/drive/folders/1pcI_U0C3VJKTCg8A1zj08CwNbohnONSR
Thanks,
Chukun
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: imx8m-kontron: Revert reading SD_VSEL signal
From: Peng Fan (OSS) @ 2026-04-03 9:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Frieder Schrempf
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
V2:
Add Fixes tag
For the regulator patch listed below, directly reverting it is not a good
idea, I will work a new fix patch for it. The regulator fix patch
is orthogonal with this patchset.
When MUX is configured as SDHC VSELECT, enabling SION is not able
to read back the SD_VSEL value. SION is used for force input path,
not to redirect the PAD value to GPIO(the other mux).
This has been confirmed by reading i.MX8MP RTL. we have not check
i.MX8MM RTL, but it should be same.
Not sure whether need to add Fixes commit for the patches, just revert
patches.
For the U-Boot support, either drop vqmmc-supply or switch to use gpio
control to replace vselect control.
And below patch should also be revisited.
commit 3ce6f4f943ddd9edc03e450a2a0d89cb025b165b
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
Date: Wed Dec 18 16:27:27 2024 +0100
regulator: pca9450: Fix control register for LDO5
To supporting read back signal, need the MUX set as GPIO and support
in/out, not set mux as VSELECT.
TBH: I have not test setting MUX as GPIO, anyway we need to fix DT.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v2:
- Add Fixes tag
- For the regulator patch listed below, directly reverting it is not a good
idea, I will work a new fix patch for it. The regulator fix patch
is orthogonal with this patchset.
- Link to v1: https://lore.kernel.org/r/20260401-imx8m-ldo5-v1-0-1b1c1381babd@nxp.com
---
Peng Fan (2):
Revert "arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal"
Revert "arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL signal"
arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 10 +++-------
arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 7 +++----
arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi | 7 +++----
3 files changed, 9 insertions(+), 15 deletions(-)
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260329-imx8m-ldo5-90e369066213
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* [PATCH v2 1/2] Revert "arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal"
From: Peng Fan (OSS) @ 2026-04-03 9:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Frieder Schrempf
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260403-imx8m-ldo5-v2-0-53bb33d6b810@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
This reverts commit 8472751c4d96b558d60d0f6aede6b24b64bcb3c9.
The board uses SDHC VSELECT to automatically switch between 1.8v and
3.3v. It does not use GPIO to control the PMIC SD_VSEL signal.
The original commit intends to read back SD_VSEL value from GPIO,
but it is wrong. When MUX is configured as SDHC VSELECT, it is
impossible to read back the value from GPIO controller. Setting SION
could only enable the input path for the mux function. It could not
redirect the input to GPIO.
And value "0x40000d0" is wrong, SION is BIT30, not BIT26.
Fixes: 8472751c4d96b ("arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 10 +++-------
arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 7 +++----
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
index e756fe5db56b6a19c309fcbb94475629e5f2b2a0..dd59af0ebaae55ede743d4187b1165041d655cf2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts
@@ -254,10 +254,6 @@ &pwm2 {
status = "okay";
};
-®_nvcc_sd {
- sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
-};
-
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
@@ -466,7 +462,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0
MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19
- MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x40000d0
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0
>;
};
@@ -479,7 +475,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4
MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19
- MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x40000d0
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0
>;
};
@@ -492,7 +488,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6
MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19
- MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x40000d0
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0
>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
index 96987910609f1b0083f5ae0c957f0baf10bfa826..4fb13d8ecfd45a8587e169b7d0a08e811745b5a9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi
@@ -342,7 +342,6 @@ reg_nvcc_sd: LDO5 {
regulator-name = "NVCC_SD (LDO5)";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
- sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
};
};
};
@@ -795,7 +794,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 /* SDIO_A_D1 */
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 /* SDIO_A_D2 */
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 /* SDIO_A_D3 */
MX8MM_IOMUXC_SD2_WP_USDHC2_WP 0x400000d6 /* SDIO_A_WP */
- MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x40000090
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x90
>;
};
@@ -808,7 +807,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 /* SDIO_A_D1 */
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 /* SDIO_A_D2 */
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 /* SDIO_A_D3 */
MX8MM_IOMUXC_SD2_WP_USDHC2_WP 0x400000d6 /* SDIO_A_WP */
- MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x40000090
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x90
>;
};
@@ -821,7 +820,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 /* SDIO_A_D1 */
MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 /* SDIO_A_D2 */
MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 /* SDIO_A_D3 */
MX8MM_IOMUXC_SD2_WP_USDHC2_WP 0x400000d6 /* SDIO_A_WP */
- MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x40000090
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x90
>;
};
--
2.37.1
^ permalink raw reply related
* [PATCH v2 2/2] Revert "arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL signal"
From: Peng Fan (OSS) @ 2026-04-03 9:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Frieder Schrempf
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260403-imx8m-ldo5-v2-0-53bb33d6b810@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
This reverts commit 39e4189d9d63a0b6fc15458ce0136e99ecdfb1b8.
The board uses SDHC VSELECT to automatically switch between 1.8v and
3.3v. It does not use GPIO to control the PMIC SD_VSEL signal.
The original commit intends to read back SD_VSEL value from GPIO,
but it is wrong. When MUX is configured as SDHC VSELECT, it is
impossible to read back the value from GPIO controller. Setting SION
could only enable the input path for the mux function. It could not
redirect the input to GPIO.
Fixes: 39e4189d9d63a ("arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL signal")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi
index bc1a261bb000ed0e8071d214111c12689bc394d0..ea69c639b30b8f7e05bb103074c6481d88560c53 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi
@@ -311,7 +311,6 @@ reg_nvcc_sd: LDO5 {
regulator-name = "NVCC_SD (LDO5)";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
- sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
};
};
};
@@ -815,7 +814,7 @@ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d0 /* SDIO_A_D0 */
MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d0 /* SDIO_A_D1 */
MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d0 /* SDIO_A_D2 */
MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d0 /* SDIO_A_D3 */
- MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x400001d0
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x1d0
>;
};
@@ -827,7 +826,7 @@ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4 /* SDIO_A_D0 */
MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4 /* SDIO_A_D1 */
MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4 /* SDIO_A_D2 */
MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4 /* SDIO_A_D3 */
- MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x400001d0
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x1d0
>;
};
@@ -839,7 +838,7 @@ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d6 /* SDIO_A_D0 */
MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d6 /* SDIO_A_D1 */
MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d6 /* SDIO_A_D2 */
MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d6 /* SDIO_A_D3 */
- MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x400001d0
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x1d0
>;
};
--
2.37.1
^ permalink raw reply related
* [PATCH v7 0/2] Add Genesys logic GL3590 HUB support
From: Swati Agarwal @ 2026-04-03 10:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Matthias Kaehlcke, Alexey Charkov,
Dmitry Baryshkov, Mike Looijmans, Pin-yen Lin,
J . Neuschäfer, Chaoyi Chen, Krzysztof Kozlowski
Cc: linux-usb, devicetree, linux-kernel, Swati Agarwal
Add Genesys logic GL3590 HUB support.
Changes in v7:
Split Driver and DT patch for USB1 controller and USB1 HUB support
Minor nit in commit text of DT binding patch
Added false status for vdd12 supply wherevr applicable
Changes in v6:
- Removed vdd12-supply property status for all hubs.
- Added connections between genesys hub, HD3 port controller and type-C
connector as follows.
GL3590 USB HD3SS3220 Type‑C USB TYPE‑C
HUB Port Controller Connector
HS HUB HS con
|------------------------------------|
SS HUB HD3-out SBU con
|--------------------|
HD3-in SS con
|---------------------|
Changes in v5:
Updated comment description in DT.
Updated vdd-supply status for other hubs in bindings.
Changes in v4:
Updated power supply property for hub.
Updated details for all 4 ports of hub.
Changes in v3:
Updated binding properties for genesys hub.
Changes in v2:
Add Genesys Logic GL3590 hub support.
Rename hd3ss3220_ instance for primary port controller.
Link to v6:
https://lore.kernel.org/all/20260318040644.3591478-1-swati.agarwal@oss.qualcomm.com/
Link to v5:
https://lore.kernel.org/all/20260122092852.887624-1-swati.agarwal@oss.qualcomm.com/
Link to v4:
https://lore.kernel.org/all/20260120103312.2174727-1-swati.agarwal@oss.qualcomm.com/
Link to v3:
https://lore.kernel.org/all/20251220063537.3639535-1-swati.agarwal@oss.qualcomm.com/
Link to v2:
https://lore.kernel.org/all/20251216120749.94007-1-swati.agarwal@oss.qualcomm.com/
Link to v1:
https://lore.kernel.org/all/20251203-swati-v1-1-250efcb4e6a7@oss.qualcomm.com/
Swati Agarwal (2):
dt-bindings: usb: Add Genesys Logic GL3590 hub
usb: misc: onboard_usb_hub: Add Genesys Logic GL3590 hub support
.../bindings/usb/genesys,gl850g.yaml | 18 ++++++++++++++++++
drivers/usb/misc/onboard_usb_dev.c | 1 +
drivers/usb/misc/onboard_usb_dev.h | 8 ++++++++
3 files changed, 27 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v7 1/2] dt-bindings: usb: Add Genesys Logic GL3590 hub
From: Swati Agarwal @ 2026-04-03 10:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Matthias Kaehlcke, Alexey Charkov,
Dmitry Baryshkov, Mike Looijmans, Pin-yen Lin,
J . Neuschäfer, Chaoyi Chen, Krzysztof Kozlowski
Cc: linux-usb, devicetree, linux-kernel, Swati Agarwal
In-Reply-To: <20260403100435.3477729-1-swati.agarwal@oss.qualcomm.com>
Add the binding for the USB3.2 Genesys Logic GL3590 hub.
GL3590 hub requires 1.2V and 3.3V supplies for operation.
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
---
.../bindings/usb/genesys,gl850g.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
index 9a94b2a74a1e..e8b8c03f87a0 100644
--- a/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
+++ b/Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
@@ -15,6 +15,7 @@ properties:
- usb5e3,608
- usb5e3,610
- usb5e3,620
+ - usb5e3,625
- usb5e3,626
reg: true
@@ -26,6 +27,10 @@ properties:
description:
The regulator that provides 3.3V or 5.0V core power to the hub.
+ vdd12-supply:
+ description:
+ The regulator that provides 1.2V power to the hub.
+
peer-hub: true
ports:
@@ -56,6 +61,7 @@ allOf:
properties:
peer-hub: false
vdd-supply: false
+ vdd12-supply: false
- if:
properties:
@@ -68,6 +74,18 @@ allOf:
properties:
peer-hub: true
vdd-supply: true
+ vdd12-supply: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - usb5e3,625
+ then:
+ properties:
+ peer-hub: true
+ vdd-supply: true
unevaluatedProperties: false
--
2.34.1
^ permalink raw reply related
* [PATCH v7 2/2] usb: misc: onboard_usb_hub: Add Genesys Logic GL3590 hub support
From: Swati Agarwal @ 2026-04-03 10:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Matthias Kaehlcke, Alexey Charkov,
Dmitry Baryshkov, Mike Looijmans, Pin-yen Lin,
J . Neuschäfer, Chaoyi Chen, Krzysztof Kozlowski
Cc: linux-usb, devicetree, linux-kernel, Swati Agarwal
In-Reply-To: <20260403100435.3477729-1-swati.agarwal@oss.qualcomm.com>
Add support for the GL3590 4 ports USB3.2 hub.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
---
drivers/usb/misc/onboard_usb_dev.c | 1 +
drivers/usb/misc/onboard_usb_dev.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/usb/misc/onboard_usb_dev.c b/drivers/usb/misc/onboard_usb_dev.c
index 7cdbdfe07a76..11508ed4df25 100644
--- a/drivers/usb/misc/onboard_usb_dev.c
+++ b/drivers/usb/misc/onboard_usb_dev.c
@@ -665,6 +665,7 @@ static const struct usb_device_id onboard_dev_id_table[] = {
{ USB_DEVICE(VENDOR_ID_GENESYS, 0x0608) }, /* Genesys Logic GL850G USB 2.0 HUB */
{ USB_DEVICE(VENDOR_ID_GENESYS, 0x0610) }, /* Genesys Logic GL852G USB 2.0 HUB */
{ USB_DEVICE(VENDOR_ID_GENESYS, 0x0620) }, /* Genesys Logic GL3523 USB 3.1 HUB */
+ { USB_DEVICE(VENDOR_ID_GENESYS, 0x0625) }, /* Genesys Logic GL3590 USB 3.2 HUB */
{ USB_DEVICE(VENDOR_ID_MICROCHIP, 0x2412) }, /* USB2412 USB 2.0 HUB */
{ USB_DEVICE(VENDOR_ID_MICROCHIP, 0x2514) }, /* USB2514B USB 2.0 HUB */
{ USB_DEVICE(VENDOR_ID_MICROCHIP, 0x2517) }, /* USB2517 USB 2.0 HUB */
diff --git a/drivers/usb/misc/onboard_usb_dev.h b/drivers/usb/misc/onboard_usb_dev.h
index ac1aa3e122ad..3523f8f8a149 100644
--- a/drivers/usb/misc/onboard_usb_dev.h
+++ b/drivers/usb/misc/onboard_usb_dev.h
@@ -101,6 +101,13 @@ static const struct onboard_dev_pdata genesys_gl852g_data = {
.is_hub = true,
};
+static const struct onboard_dev_pdata genesys_gl3590_data = {
+ .reset_us = 50,
+ .num_supplies = 2,
+ .supply_names = { "vdd", "vdd12" },
+ .is_hub = true,
+};
+
static const struct onboard_dev_pdata usb_a_conn_data = {
.num_supplies = 1,
.supply_names = { "vbus" },
@@ -146,6 +153,7 @@ static const struct of_device_id onboard_dev_match[] = {
{ .compatible = "usb5e3,608", .data = &genesys_gl850g_data, },
{ .compatible = "usb5e3,610", .data = &genesys_gl852g_data, },
{ .compatible = "usb5e3,620", .data = &genesys_gl852g_data, },
+ { .compatible = "usb5e3,625", .data = &genesys_gl3590_data, },
{ .compatible = "usb5e3,626", .data = &genesys_gl852g_data, },
{ .compatible = "usbbda,179", .data = &realtek_rtl8188etv_data, },
{ .compatible = "usbbda,411", .data = &realtek_rts5411_data, },
--
2.34.1
^ permalink raw reply related
* Devicetree spec: Specifying /cpus/cpu@* unit address format?
From: Vivian Wang @ 2026-04-03 10:06 UTC (permalink / raw)
To: devicetree-spec
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Alexandre Ghiti, Chen Wang, Inochi Amaoto,
devicetree, linux-riscv, sophgo
(Also posted at: https://github.com/devicetree-org/devicetree-specification/issues/86 )
Hi all,
Presently, there seems to be some confusion in the community about the
format of unit addresses for "/cpus/cpu@*" nodes for a CPU with ID > 9, e.g.
cpu@??? {
reg = <10>;
/* reg = <0xa>; */ /* This should be equivalent */
}
Should this be a decimal "cpu@10", or hexadecimal "cpu@a"? I can't find
any explicit specification.
* Most other nodes specify a hex unit address
* I could not find anything specifying this generically
o AFAICT, there's no /cpus in IEEE 1275
o ePAPR doesn't say anything about this
o Presently, DTSpec doesn't say anything about this.
* dt-schema says it's ^cpu@[0-9a-f]+$, seemingly intending to use
hexadecimal, but not forbidding decimal. [1]
* Of the `/cpus` schemas in Linux
(Documentation/devicetree/bindings/{arm,mips,riscv,loongarch}/cpus.yaml),
none mention the node unit address
As of current usage:
* Of all the DTS files in (mainline) Linux, most either use hex, or
have reg < 9 for all CPUs.
o AFAICT from grepping, arm and arm64 consistently uses hex.
o Most riscv SoCs have <= 9 CPUs. The two that don't use decimal:
arch/riscv/boot/dts/sophgo/{sg2042,sg2044}-cpus.dtsi
o No other arch has in-tree DTS with CPU reg > 9
* Of all the dt-bindings examples in Linux, only one uses decimal, but
it seems to be unintentional:
Documentation/devicetree/bindings/opp/opp-v2.yaml
* QEMU generates decimal for multiple archs in e.g.
`hw/{arm,riscv}/virt.c` and other places (grep -R "cpu@")
* Spike (RISC-V emulator) generates decimal [3]
It could be a good idea to have this standardized, like all other unit
addresses.
DTSpec says:
The binding for a particular bus may specify additional, more specific
requirements for the format of reg and the unit-address.
Since /cpus and /cpus/cpu@* are generically defined in DTSpec and
specialized for various architectures, I believe this is the right place
to start standardizing this. Even if arch-specific definitions are
required, at least DTSpec can give a recommendation on whether to use
decimal or hexadecimal.
Thanks,
Vivian "dramforever" Wang
[1]: https://github.com/devicetree-org/dt-schema/blob/v2025.12/dtschema/schemas/cpus.yaml#L52-L54
[2]: https://github.com/riscv-software-src/riscv-isa-sim/blob/5eeeb91efa966936ef7b980f5e8dd00ffbe70786/riscv/dts.cc#L61
^ permalink raw reply
* [PATCH v7 0/2] Enable secondary USB controller in host mode
From: Swati Agarwal @ 2026-04-03 10:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Swati Agarwal
Enable secondary USB controller in host mode.
Changes in v7:
Split Driver and DT patch for USB1 controller and USB1 HUB support
Changes in v6:
- Removed vdd12-supply property status for all hubs.
- Added connections between genesys hub, HD3 port controller and type-C
connector as follows.
GL3590 USB HD3SS3220 Type‑C USB TYPE‑C
HUB Port Controller Connector
HS HUB HS con
|------------------------------------|
SS HUB HD3-out SBU con
|--------------------|
HD3-in SS con
|---------------------|
Changes in v5:
Updated comment description in DT.
Updated vdd-supply status for other hubs in bindings.
Changes in v4:
Updated power supply property for hub.
Updated details for all 4 ports of hub.
Changes in v3:
Updated binding properties for genesys hub.
Changes in v2:
Add Genesys Logic GL3590 hub support.
Rename hd3ss3220_ instance for primary port controller.
Link to v6:
https://lore.kernel.org/all/20260318040644.3591478-1-swati.agarwal@oss.qualcomm.com/
Link to v5:
https://lore.kernel.org/all/20260122092852.887624-1-swati.agarwal@oss.qualcomm.com/
Link to v4:
https://lore.kernel.org/all/20260120103312.2174727-1-swati.agarwal@oss.qualcomm.com/
Link to v3:
https://lore.kernel.org/all/20251220063537.3639535-1-swati.agarwal@oss.qualcomm.com/
Link to v2:
https://lore.kernel.org/all/20251216120749.94007-1-swati.agarwal@oss.qualcomm.com/
Link to v1:
https://lore.kernel.org/all/20251203-swati-v1-1-250efcb4e6a7@oss.qualcomm.com/
Swati Agarwal (2):
arm64: dts: qcom: lemans-evk: Rename hd3ss3220_ instance for primary
port controller
arm64: dts: qcom: lemans-evk: Enable secondary USB controller in host
mode
arch/arm64/boot/dts/qcom/lemans-evk.dts | 214 +++++++++++++++++++++++-
1 file changed, 210 insertions(+), 4 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v7 1/2] arm64: dts: qcom: lemans-evk: Rename hd3ss3220_ instance for primary port controller
From: Swati Agarwal @ 2026-04-03 10:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Swati Agarwal,
Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260403100753.3477925-1-swati.agarwal@oss.qualcomm.com>
Rename the hd3ss3220_ instance to improve clarity and simplify usage when
adding a secondary port controller.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans-evk.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
index c665db6a4595..522d407c9925 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -63,7 +63,7 @@ port@1 {
reg = <1>;
usb0_con_ss_ep: endpoint {
- remote-endpoint = <&hd3ss3220_in_ep>;
+ remote-endpoint = <&hd3ss3220_0_in_ep>;
};
};
};
@@ -551,7 +551,7 @@ ports {
port@0 {
reg = <0>;
- hd3ss3220_in_ep: endpoint {
+ hd3ss3220_0_in_ep: endpoint {
remote-endpoint = <&usb0_con_ss_ep>;
};
};
@@ -559,7 +559,7 @@ hd3ss3220_in_ep: endpoint {
port@1 {
reg = <1>;
- hd3ss3220_out_ep: endpoint {
+ hd3ss3220_0_out_ep: endpoint {
remote-endpoint = <&usb_0_dwc3_ss>;
};
};
@@ -989,7 +989,7 @@ &usb_0_dwc3_hs {
};
&usb_0_dwc3_ss {
- remote-endpoint = <&hd3ss3220_out_ep>;
+ remote-endpoint = <&hd3ss3220_0_out_ep>;
};
&usb_0_hsphy {
--
2.34.1
^ permalink raw reply related
* [PATCH v7 2/2] arm64: dts: qcom: lemans-evk: Enable secondary USB controller in host mode
From: Swati Agarwal @ 2026-04-03 10:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Swati Agarwal
In-Reply-To: <20260403100753.3477925-1-swati.agarwal@oss.qualcomm.com>
Enable secondary USB controller in host mode on lemans EVK Platform.
Secondary USB controller is connected to a Genesys Logic USB HUB GL3590
having 4 ports. The ports of hub that are present on lemans EVK standalone
board are used as follows:-
1) port-1 is connected to HD3SS3220 Type-C port controller.
2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART
for Bluetooth. This port is to be used only if user optionally replaces the
WiFi card with the NFA765 chip which uses USB for Bluetooth.
Remaining 2 ports will become functional when the interface plus mezzanine
board is stacked on top of corekit:
3) port-2 is connected to another hub which is present on the mezz through
which 4 type-A ports are connected.
4) port-3 is used for the M.2 B key for a 5G card when the mezz is
connected.
Secondary USB Controller
↓
GL3590 USB Hub (4 ports)
|
|-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
|
|-- Port 2 → Mezzanine USB Hub (when mezz attached)
|
|-- Port 3 → M.2 B‑Key Slot (when mezz attached)
|
|-- Port 4 → M.2 E‑Key Slot
(Default: BT via UART;
USB only if NFA765 module is installed)
Mark the second USB controller as host only capable and add the HD3SS3220
Type-C port controller along with Type-C connector for controlling vbus
supply.
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans-evk.dts | 206 ++++++++++++++++++++++++
1 file changed, 206 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
index 522d407c9925..f0010c4e69c2 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -69,6 +69,44 @@ usb0_con_ss_ep: endpoint {
};
};
+ connector-1 {
+ compatible = "usb-c-connector";
+ label = "USB1-Type-C";
+ data-role = "host";
+ power-role = "source";
+
+ vbus-supply = <&usb1_vbus>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb1_con_hs_ep: endpoint {
+ remote-endpoint = <&usb_hub_2_1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb1_con_ss_ep: endpoint {
+ remote-endpoint = <&hd3ss3220_1_in_ep>;
+ };
+
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb1_con_sbu_ep: endpoint {
+ };
+ };
+ };
+ };
+
connector-2 {
compatible = "gpio-usb-b-connector", "usb-b-connector";
label = "micro-USB";
@@ -161,6 +199,15 @@ usb0_vbus: regulator-usb0-vbus {
enable-active-high;
};
+ usb1_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb1_vbus";
+ gpio = <&expander1 3 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ };
+
usb2_vbus: regulator-usb2-vbus {
compatible = "regulator-fixed";
regulator-name = "usb2_vbus";
@@ -565,6 +612,39 @@ hd3ss3220_0_out_ep: endpoint {
};
};
};
+
+ usb-typec@47 {
+ compatible = "ti,hd3ss3220";
+ reg = <0x47>;
+
+ interrupts-extended = <&pmm8654au_2_gpios 6 IRQ_TYPE_EDGE_FALLING>;
+
+ id-gpios = <&tlmm 51 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&usb1_id>, <&usb1_intr>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hd3ss3220_1_in_ep: endpoint {
+ remote-endpoint = <&usb1_con_ss_ep>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ hd3ss3220_1_out_ep: endpoint {
+ remote-endpoint = <&usb_hub_3_1>;
+ };
+ };
+ };
+ };
};
&i2c18 {
@@ -749,6 +829,14 @@ usb0_intr_state: usb0-intr-state {
power-source = <0>;
};
+ usb1_intr: usb1-intr-state {
+ pins = "gpio6";
+ function = "normal";
+ input-enable;
+ bias-pull-up;
+ power-source = <0>;
+ };
+
usb2_id: usb2-id-state {
pins = "gpio11";
function = "normal";
@@ -949,6 +1037,12 @@ usb_id: usb-id-state {
function = "gpio";
bias-pull-up;
};
+
+ usb1_id: usb1-id-state {
+ pins = "gpio51";
+ function = "gpio";
+ bias-pull-up;
+ };
};
&uart0 {
@@ -1007,6 +1101,118 @@ &usb_0_qmpphy {
status = "okay";
};
+&usb_1 {
+ dr_mode = "host";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+
+ usb_hub_2_x: hub@1 {
+ compatible = "usb5e3,610";
+ reg = <1>;
+
+ peer-hub = <&usb_hub_3_x>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb_hub_2_1: endpoint {
+ remote-endpoint = <&usb1_con_hs_ep>;
+ };
+ };
+
+ /*
+ * Port-2 and port-3 are not connected to anything on corekit.
+ */
+ port@2 {
+ reg = <2>;
+
+ usb_hub_2_2: endpoint {
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ usb_hub_2_3: endpoint {
+ };
+ };
+
+ /*
+ * Port-4 is connected to M.2 E key connector on corekit.
+ */
+ port@4 {
+ reg = <4>;
+
+ usb_hub_2_4: endpoint {
+ };
+ };
+ };
+ };
+
+ usb_hub_3_x: hub@2 {
+ compatible = "usb5e3,625";
+ reg = <2>;
+
+ peer-hub = <&usb_hub_2_x>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb_hub_3_1: endpoint {
+ remote-endpoint = <&hd3ss3220_1_out_ep>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb_hub_3_2: endpoint {
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ usb_hub_3_3: endpoint {
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ usb_hub_3_4: endpoint {
+ };
+ };
+ };
+ };
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vreg_l7a>;
+ vdda18-supply = <&vreg_l6c>;
+ vdda33-supply = <&vreg_l9a>;
+
+ status = "okay";
+};
+
+&usb_1_qmpphy {
+ vdda-phy-supply = <&vreg_l1c>;
+ vdda-pll-supply = <&vreg_l7a>;
+
+ status = "okay";
+};
+
&usb_2 {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 0/3] Add CAMSS support for SM6350
From: Vladimir Zapolskiy @ 2026-04-03 10:09 UTC (permalink / raw)
To: Luca Weiss
Cc: Bryan O'Donoghue, Konrad Dybcio, Bryan O'Donoghue,
Conor Dooley, Robert Foss, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, linux-media, devicetree, linux-kernel,
Krzysztof Kozlowski, Todor Tomov, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Bjorn Andersson
In-Reply-To: <DHJD7P2TXQTH.1TQ4YQQ21A6CS@fairphone.com>
Hi Luca.
On 4/3/26 11:09, Luca Weiss wrote:
> Hi Vladimir,
>
> On Tue Mar 31, 2026 at 12:49 AM CEST, Vladimir Zapolskiy wrote:
>> Hi Luca,
>>
>> On 2/16/26 10:54, Luca Weiss wrote:
>>> Add bindings, driver and dts to support the Camera Subsystem on the
>>> SM6350 SoC.
>>>
>>> These patches were tested on a Fairphone 4 smartphone with WIP sensor
>>> drivers (Sony IMX576 and IMX582), the camera pipeline works properly as
>>> far as I can tell.
>>>
>>> Though when stopping the camera stream, the following clock warning
>>> appears in dmesg. But it does not interfere with any functionality,
>>> starting and stopping the stream works and debugcc is showing 426.4 MHz
>>> while the clock is on, and 'off' while it's off.
>>>
>>> Any suggestion how to fix this, is appreciated.
>>
>> I've looked at CAMCC recently, and I do notice that SM6350 CAMCC does not
>> set '.use_rpm = true' flag for whatever reason.
>>
>> If you find a free minute, can you test the change below?..
>
> Unfortunately that change does not resolve the "gcc_camera_axi_clk
> status stuck at 'on'" warning.
>
> fairphone-fp4:~$ cat /sys/bus/platform/drivers/sm6350-camcc/ad00000.clock-controller/power/runtime_status
> active
>
> fairphone-fp4:~$ cat /sys/bus/platform/drivers/sm6350-camcc/ad00000.clock-controller/power/runtime_status
> suspended
>
So it seems to be a technically deeper issue, once given insights by Imran
likely to be very relevant:
https://lore.kernel.org/linux-arm-msm/caa870e2-3795-40bc-9f0e-c93e313c8c6e@oss.qualcomm.com/
>>
>> ----8<----
>> diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c
>> index 7df12c1311c6..ba880e4edcaf 100644
>> --- a/drivers/clk/qcom/camcc-sm6350.c
>> +++ b/drivers/clk/qcom/camcc-sm6350.c
>> @@ -1880,6 +1880,7 @@ static const struct qcom_cc_desc camcc_sm6350_desc = {
>> .num_clks = ARRAY_SIZE(camcc_sm6350_clocks),
>> .gdscs = camcc_sm6350_gdscs,
>> .num_gdscs = ARRAY_SIZE(camcc_sm6350_gdscs),
>> + .use_rpm = true,
>> };
>>
>> static const struct of_device_id camcc_sm6350_match_table[] = {
>> ----8<----
>>
>> This change could be considered to be included in any case, I believe.
>
> I guess this change is now the way to enable pm_runtime, I had this
> series 3 years ago in February 2023:
> https://lore.kernel.org/linux-arm-msm/20230213-sm6350-camcc-runtime_pm-v3-0-d35e0d833cc4@fairphone.com/
>
> But I never followed up due to me not understanding pm_runtime well and
> no direct need for it.
>
> But I guess reviving that with use_rpm = true, add power-domains &
> required-opps to dt-bindings and sm6350.dtsi should be a good idea?
>
It should be, if SM6350 CAMCC is known to belong to an on-SoC power domain,
then devm_pm_runtime_enable() will be called on .probe to embed the
controller driver into the runtime PM framework, see commit c0b6627369bc.
Power domain management of devices is handled inside the runtime PM.
--
Best wishes,
Vladimir
^ 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