* Re: [PATCH v2 05/13] KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ
From: Oliver Upton @ 2026-06-29 17:22 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Jonathan Cameron,
Chengwen Feng, Kees Cook, Mikołaj Lenczewski, James Morse,
Zeng Heng, mrigendrachaubey, Thomas Huth, Ryan Roberts,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark, Fuad Tabba,
Raghavendra Rao Ananta, Lorenzo Pieralisi, Sascha Bischoff,
Anshuman Khandual, Tian Zheng, linux-arm-kernel, linux-kernel,
kvmarm, linux-acpi, acpica-devel, kvm
In-Reply-To: <20260629111820.1873540-6-leo.bras@arm.com>
On Mon, Jun 29, 2026 at 12:17:53PM +0100, Leonardo Bras wrote:
> Find via ACPI [1] the Id for HACDBSIRQ, initialize it as a per-cpu IRQ
> and make sure any cpu able to run virtualization has it active.
>
> Introduce a per-cpu structure used by the HACDBSIRQ handler to keep track
> of entries size and the status of HACDBS. Size is used to detect end of
> processing in case the number of entries being processed is different of
> the supported entries size.
>
> Status may look easily replaceable by checking HACDBS registers now, but
> will make the OFF/IDLE detection easier in next patches.
>
> Signed-off-by: Leonardo Bras <leo.bras@arm.com>
>
> [1] https://github.com/tianocore/edk2/issues/12409
Reference the ACPI specification instead please. Any link you want to
include in a changelog should use the Link: footer, the linkage to the
inline citation will be obvious.
If we need to initialize the IRQ I'd really like to see device tree
bindings for HACDBSIRQ as well. Pretty much any system us plebs can get
our hands on is gonna be DT anyway.
> +static irqreturn_t hacdbsirq_handler(int irq, void *pcpu)
> +{
> + u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
> + unsigned long err = FIELD_GET(HACDBSCONS_EL2_ERR_REASON, cons);
> +
> + switch (err) {
> + case HACDBSCONS_EL2_ERR_REASON_NOF:
> + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> + break;
> + case HACDBSCONS_EL2_ERR_REASON_IPAHACF:
> + /* When size not a power of two >= 4k, exit with reserved TTLW */
> + int index = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
> +
> + if (index >= this_cpu_read(hacdbs_pcp.size)) {
> + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> + break;
> + }
> + fallthrough;
> + case HACDBSCONS_EL2_ERR_REASON_STRUCTF:
> + case HACDBSCONS_EL2_ERR_REASON_IPAF:
> + this_cpu_write(hacdbs_pcp.status, HACDBS_ERROR);
> + break;
> + }
> +
> + return IRQ_HANDLED;
> +}
I have a pretty extreme distaste for creating a state machine between
the callsite and the IRQ handler. The callsite should poll HACDBS for
completion. The thread has nothing better to do anyway.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH v2 06/13] KVM: arm64: dirty_bit: Add base FEAT_HACDBS cleaning routine
From: Oliver Upton @ 2026-06-29 17:36 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Jonathan Cameron,
Chengwen Feng, Kees Cook, Mikołaj Lenczewski, James Morse,
Zeng Heng, mrigendrachaubey, Thomas Huth, Ryan Roberts,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark, Fuad Tabba,
Raghavendra Rao Ananta, Lorenzo Pieralisi, Sascha Bischoff,
Anshuman Khandual, Tian Zheng, linux-arm-kernel, linux-kernel,
kvmarm, linux-acpi, acpica-devel, kvm
In-Reply-To: <20260629111820.1873540-7-leo.bras@arm.com>
On Mon, Jun 29, 2026 at 12:17:54PM +0100, Leonardo Bras wrote:
> Introduce the basic cleaning routine that is going to be used for both
> dirty-bitmap and dirty-ring routines.
>
> It sets the required registers with the input buffer, and wait for
> HACDBSIRQ to happen, which means either the task is done, or there was some
> error during processing.
>
> It is ran with preemption disabled, as a task being scheduled in could
> change the translation registers used by HACDBS and end up corrupting the
> current dirty-bit tracking and the sched-in task's S2 pagetables.
>
> Signed-off-by: Leonardo Bras <leo.bras@arm.com>
> ---
> arch/arm64/kvm/dirty_bit.c | 81 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 81 insertions(+)
>
> diff --git a/arch/arm64/kvm/dirty_bit.c b/arch/arm64/kvm/dirty_bit.c
> index 789da8712b1b..e4283828b780 100644
> --- a/arch/arm64/kvm/dirty_bit.c
> +++ b/arch/arm64/kvm/dirty_bit.c
> @@ -1,36 +1,117 @@
> // SPDX-License-Identifier: GPL-2.0-only
> /*
> * Copyright (C) 2026 ARM Ltd.
> * Author: Leonardo Bras <leo.bras@arm.com>
> */
>
> #include <asm/kvm_dirty_bit.h>
> +#include <asm/kvm_mmu.h>
> #include <linux/kconfig.h>
> #include <linux/acpi.h>
>
> DEFINE_PER_CPU(struct hacdbs, hacdbs_pcp) = {
> .status = HACDBS_OFF,
> .size = 0,
> };
>
> /* HDBSS entry field definitions */
> #define HDBSS_ENTRY_VALID BIT(0)
> #define HDBSS_ENTRY_TTWL_SHIFT (1)
> #define HDBSS_ENTRY_TTWL_MASK (GENMASK(3, 1))
> #define HDBSS_ENTRY_TTWL(x) \
> (((x) << HDBSS_ENTRY_TTWL_SHIFT) & HDBSS_ENTRY_TTWL_MASK)
> #define HDBSS_ENTRY_TTWL_RESV HDBSS_ENTRY_TTWL(-4)
> #define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
>
> static __ro_after_init int hacdbsirq = -1;
>
> +static void hacdbs_start(u64 *hw_entries, int size)
> +{
> + u64 br;
> + /* Each entry is 8 bytes */
> + int size_b = size * sizeof(hw_entries[0]);
> + int size_p2 = max(roundup_pow_of_two(size_b), PAGE_SIZE);
> +
> + /* If not using the full size of the array, put a stop entry at the end */
> + if (size_b < size_p2)
> + hw_entries[size] = HDBSS_ENTRY_VALID | HDBSS_ENTRY_TTWL_RESV;
> +
> + sysreg_clear_set_s(SYS_HACDBSCONS_EL2,
> + HACDBSCONS_EL2_ERR_REASON | HACDBSCONS_EL2_INDEX, 0);
> +
> + br = (virt_to_phys(hw_entries) & HACDBSBR_EL2_BADDR_MASK) |
> + FIELD_PREP(HACDBSBR_EL2_SZ, ilog2(size_p2) - 12) |
> + FIELD_PREP(HACDBSBR_EL2_EN, 1);
> +
> + this_cpu_write(hacdbs_pcp.status, HACDBS_RUNNING);
> + this_cpu_write(hacdbs_pcp.size, size);
> + write_sysreg_s(br, SYS_HACDBSBR_EL2);
> + isb();
> +}
> +
> +static int hacdbs_stop(void)
> +{
> + write_sysreg_s(0, SYS_HACDBSBR_EL2);
> + isb();
> +
> + if (this_cpu_read(hacdbs_pcp.status) == HACDBS_ERROR) {
> + /* In case of error, HACDBSCONS_EL2.INDEX should point the faulty entry */
> + u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
> + int idx = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
> +
> + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> +
> + return idx;
> + }
> +
> + return this_cpu_read(hacdbs_pcp.size);
> +}
> +
> +/*
> + * Clears dirty-bits for an array of pages (hw_entries) using HACDBS
> + * Returns the number of items cleaned from the array. If returns value < size,
> + * there was an error in the processing.
> + */
> +static int dirty_bit_clear(struct kvm *kvm, u64 *hw_entries, int size)
> +{
> + u64 hcr_el2;
> + int ret;
> +
> + preempt_disable();
> +
> + hcr_el2 = read_sysreg(HCR_EL2);
> + write_sysreg(hcr_el2 | HCR_EL2_VM, HCR_EL2);
sysreg_clear_set_hcr(). I'm pretty sure all the speculative AT errata
depend on HCR_EL2.VM being set _after_ the stage-2 MMU has been loaded.
> + __load_stage2(&kvm->arch.mmu);
Pretty sure you need an ISB here to ensure loading the MMU is ordered
with enabling HACDBS.
> + hacdbs_start(hw_entries, size);
> +
> + do {
> + wfi();
> + } while (this_cpu_read(hacdbs_pcp.status) == HACDBS_RUNNING);
This is exactly why I said you should just poll hardware instead. It is
entirely possible that the IRQ arrives before you WFI.
> + ret = hacdbs_stop();
> +
> + write_sysreg(hcr_el2, HCR_EL2);
write_sysreg_hcr()
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH v3] clk: mvebu: ap-cpu: fix missing clk_put() in ap_cpu_clock_probe()
From: Brian Masney @ 2026-06-29 17:14 UTC (permalink / raw)
To: Wentao Liang
Cc: andrew, gregory.clement, sebastian.hesselbarth, mturquette, sboyd,
linux-arm-kernel, linux-clk, linux-kernel
In-Reply-To: <20260617014126.1716291-1-vulab@iscas.ac.cn>
Hi Wentao,
On Wed, Jun 17, 2026 at 01:41:26AM +0000, Wentao Liang wrote:
> The function ap_cpu_clock_probe() calls of_clk_get() to obtain a
> reference to the parent clock for each CPU cluster, but it never
> releases it with clk_put(). The returned clk is used only to read
> the parent's name via __clk_get_name(), and the reference is leaked
> on every successful cluster initialization as well as on the error
> path when devm_clk_hw_register() fails.
>
> Rather than adding clk_put() calls, replace the of_clk_get() +
> __clk_get_name() pattern with of_clk_get_parent_name(), which is
> the intended API for this use case and handles the reference
> counting internally. This matches the pattern already used by the
> sibling drivers clk-cpu.c and clk-corediv.c.
>
> Fixes: f756e362d9384 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> v3: Replace incorrect Fixes tag.
> v2: Replace of_clk_get() + __clk_get_name() with of_clk_get_parent_name()
> as suggested by Brian Masney, instead of adding clk_put() calls.
> Also correct the Fixes: tag to point to the original commit that
> introduced the leak.
> ---
> drivers/clk/mvebu/ap-cpu-clk.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/mvebu/ap-cpu-clk.c b/drivers/clk/mvebu/ap-cpu-clk.c
> index a8175908e353..1cf63c7a0bc3 100644
> --- a/drivers/clk/mvebu/ap-cpu-clk.c
> +++ b/drivers/clk/mvebu/ap-cpu-clk.c
> @@ -288,7 +288,6 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
> char *clk_name = "cpu-cluster-0";
> struct clk_init_data init;
> const char *parent_name;
> - struct clk *parent;
> u64 cpu;
>
> cpu = of_get_cpu_hwid(dn, 0);
> @@ -304,13 +303,12 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
> if (ap_cpu_data->hws[cluster_index])
> continue;
>
> - parent = of_clk_get(np, cluster_index);
> - if (IS_ERR(parent)) {
> - dev_err(dev, "Could not get the clock parent\n");
> + parent_name = of_clk_get_parent_name(np, cluster_index);
> + if (!parent_name) {
> + dev_err(dev, "Could not get the clock parent name\n");
> of_node_put(dn);
> return -EINVAL;
> }
> - parent_name = __clk_get_name(parent);
> clk_name[12] += cluster_index;
> ap_cpu_clk[cluster_index].clk_name =
> ap_cp_unique_name(dev, np->parent, clk_name);
> @@ -328,11 +326,9 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
> ret = devm_clk_hw_register(dev, &ap_cpu_clk[cluster_index].hw);
> if (ret) {
> of_node_put(dn);
> - clk_put(parent);
> return ret;
> }
> ap_cpu_data->hws[cluster_index] = &ap_cpu_clk[cluster_index].hw;
> - clk_put(parent);
> }
This doesn't apply against Linus's latest tree. It looks like it's just
this last chunk that's the issue. What version of the kernel did you develop
this against? The last change to this driver upstream was from me in August
2025.
Please submit a new version that applies cleanly upstream.
Brian
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Bartosz Golaszewski @ 2026-06-29 17:06 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260625115718.1678991-2-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:17 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
> runtime from the underlying chip's can_sleep:
>
> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
>
> can_sleep describes only the value path (->get/->set). Under the same
> lock, however, the proxy may call gpiod_set_config() and
> gpiod_direction_*(), which can reach pinctrl paths that take a mutex
> (e.g. gpiod_set_config() -> gpiochip_generic_config() ->
> pinctrl_gpio_set_config()), independent of can_sleep. On a controller
> with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
> the sleeping pinctrl call ran from atomic context. Reproduced on an
> Amlogic A113X board with the workaround from commit 28f240683871
> ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
> original Khadas VIM3 report hit the same path:
>
> BUG: sleeping function called from invalid context
> __mutex_lock
> pinctrl_get_device_gpio_range
> pinctrl_gpio_set_config
> gpiochip_generic_config
> gpiod_set_config
> gpio_shared_proxy_set_config <- voting spinlock held
> ...
> mmc_pwrseq_simple_probe
>
> The spinlock existed to take the value vote from atomic context, but the
> vote and the (possibly sleeping) control operations share the same state
> and lock, so this scheme cannot serialize config under a mutex and still
> offer atomic value access. Always serialize the shared descriptor with a
> mutex instead and mark the proxy a sleeping gpiochip, driving the
> underlying GPIO through the cansleep value accessors: those are valid
> for both sleeping and non-sleeping chips, so value access keeps working
> on fast controllers, at the cost of no longer being atomic.
>
> This is observable: consumers gating on gpiod_cansleep() take their
> sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
> emergency-restart reset handler; its normal reset is unaffected), and
> consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
> fail to probe. Such atomic users do not share a pin through the proxy,
> whose purpose is voting on shared reset/enable lines. The same narrowing
> already applies on Amlogic since that workaround, and rockchip
> addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
> rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
> addresses the locking error once, for every controller.
>
> The lock type was added by commit a060b8c511ab ("gpiolib: implement
> low-level, shared GPIO support"); the sleeping call under it arrived with
> the proxy driver.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
> ---
> v1 -> v2: open-code the descriptor mutex; drop the gpio_shared_desc_lock
> guard and the gpio_shared_lockdep_assert() helper, use
> guard(mutex) and lockdep_assert_held() directly; move the
> mutex rationale from the header to the can_sleep assignment in
> probe.
>
> v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-2-v@baodeep.com/
>
> drivers/gpio/gpio-shared-proxy.c | 66 +++++++++++++-------------------
> drivers/gpio/gpiolib-shared.c | 9 +----
> drivers/gpio/gpiolib-shared.h | 28 +-------------
> 3 files changed, 29 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpio/gpio-shared-proxy.c b/drivers/gpio/gpio-shared-proxy.c
> index 6941e4be6cf1..0cd52015b731 100644
> --- a/drivers/gpio/gpio-shared-proxy.c
> +++ b/drivers/gpio/gpio-shared-proxy.c
> @@ -9,8 +9,10 @@
> #include <linux/err.h>
> #include <linux/gpio/consumer.h>
> #include <linux/gpio/driver.h>
> +#include <linux/lockdep.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/mutex.h>
> #include <linux/string_choices.h>
> #include <linux/types.h>
>
> @@ -32,7 +34,7 @@ gpio_shared_proxy_set_unlocked(struct gpio_shared_proxy_data *proxy,
I was about to apply it but then realized that it can be simplified further.
The set_func() argument in gpio_shared_proxy_set_unlocked() is no longer
needed and can be replaced with a direct call to gpiod_set_value_cansleep().
Would you mind sending a v3 with that included?
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v1] ARM: imx: avic: Fix OF node reference leaks
From: Frank.Li @ 2026-06-29 17:05 UTC (permalink / raw)
To: Sascha Hauer, Russell King, Pengutronix Kernel Team, Yuho Choi
Cc: Frank Li, Fabio Estevam, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20260615174535.701013-1-dbgh9129@gmail.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 15 Jun 2026 13:45:35 -0400, Yuho Choi wrote:
> of_find_compatible_node() returns a device node with its reference count
> incremented. mxc_init_irq() looks up the i.MX25 CCM node for of_iomap()
> and the AVIC node for irq_domain_create_legacy(), but does not release
> either temporary reference.
>
> of_iomap() does not consume the node reference, and
> irq_domain_create_legacy() takes its own fwnode reference for the domain.
> Drop the temporary OF node references after each use.
>
> [...]
Applied, thanks!
[1/1] ARM: imx: avic: Fix OF node reference leaks
commit: b24c12e1bad863d27141e4e9c19d25eebd68c4a6
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH V1] arm64: dts: imx8mq-evk: add uart3 and bluetooth node
From: Frank.Li @ 2026-06-29 17:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam,
Sherry Sun (OSS)
Cc: Frank Li, imx, devicetree, linux-arm-kernel, linux-kernel,
sherry.sun
In-Reply-To: <20260616105201.3214395-1-sherry.sun@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 16 Jun 2026 18:52:00 +0800, Sherry Sun (OSS) wrote:
> Add uart3 and bluetooth node.
Applied, thanks!
[1/1] arm64: dts: imx8mq-evk: add uart3 and bluetooth node
commit: 4f36d5cd0dce934994da4b4be5776abd74c837ab
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v4] arm64: dts: imx94: Add Root Port node and PERST property
From: Frank Li @ 2026-06-29 16:59 UTC (permalink / raw)
To: hongxing.zhu
Cc: sherry.sun, robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam,
kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
In-Reply-To: <20260616072334.1107262-1-hongxing.zhu@oss.nxp.com>
On Tue, Jun 16, 2026 at 03:23:34PM +0800, hongxing.zhu@oss.nxp.com wrote:
> From: Richard Zhu <hongxing.zhu@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.
> Move the regulator to Root Port nodes as well, because that the PCI
> pwrctrl framework had been integrated into pci-imx6 driver.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Reviewed-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx94.dtsi | 11 +++++++++++
> arch/arm64/boot/dts/freescale/imx943-evk.dts | 14 ++++++++++----
> arch/arm64/boot/dts/freescale/imx943.dtsi | 11 +++++++++++
use two patch, one patch only change chip's dtsi, the other one update
boards's dts
Frank
> 3 files changed, 32 insertions(+), 4 deletions(-)
> ---
> Changes in v4:
> Add the description of regualtor changes into commit message too.
>
> Changes in v3:
> - Move the regulator to Root Port node as well, since [2] had been
> settled.
> - Collect Reviewed-by tag issued by Sherry.
>
> Changes in v2:
> - Delete reset-gpio properties in PCIe bridge node.
> - Correct the "reset-gpio" property to "reset-gpios".
>
> 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
> [2] https://lore.kernel.org/imx/20260520084904.2424253-1-sherry.sun@oss.nxp.com/
>
> 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..674410e541cba 100644
> --- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> @@ -1034,12 +1034,15 @@ &pcie0 {
> <&pcie_ref_clk>;
> clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
> "ref", "extref";
> - reset-gpio = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
> - vpcie3v3aux-supply = <®_m2_wlan>;
> supports-clkreq;
> status = "okay";
> };
>
> +&pcie0_port0 {
> + reset-gpios = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
> + vpcie3v3aux-supply = <®_m2_wlan>;
> +};
> +
> &pcie0_ep {
> pinctrl-0 = <&pinctrl_pcie0>;
> pinctrl-names = "default";
> @@ -1058,12 +1061,15 @@ &pcie1 {
> <&pcie_ref_clk>;
> clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
> "ref", "extref";
> - reset-gpio = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
> - vpcie3v3aux-supply = <®_slot_pwr>;
> supports-clkreq;
> status = "okay";
> };
>
> +&pcie1_port0 {
> + reset-gpios = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
> + vpcie3v3aux-supply = <®_slot_pwr>;
> +};
> +
> &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
* Re: [PATCH] firmware: ti_sci: undo list publication on populate failure
From: Nishanth Menon @ 2026-06-29 16:57 UTC (permalink / raw)
To: Tero Kristo, Santosh Shilimkar, linux-arm-kernel, linux-kernel,
Pengpeng Hou
Cc: Nishanth Menon
In-Reply-To: <20260616004741.1726-1-pengpeng@iscas.ac.cn>
Hi Pengpeng Hou,
On Tue, 16 Jun 2026 08:47:41 +0800, Pengpeng Hou wrote:
> ti_sci_probe() publishes the controller on the global ti_sci_list before
> creating child devices. If of_platform_populate() fails after creating
> some children, the probe error path leaves the children around and leaves
> the failed controller visible through ti_sci_get_handle().
>
> Depopulate any children created by the failed populate call and remove
> the controller from the global list before returning the probe error.
>
> [...]
I have applied the following to branch ti-drivers-soc-next on [1].
Thank you!
[1/1] firmware: ti_sci: undo list publication on populate failure
commit: f52ddaf5e771c753663a719834848fde92b219f8
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v1] MAINTAINERS: Add git tree for TI K3 ARCHITECTURE
From: Nishanth Menon @ 2026-06-29 16:57 UTC (permalink / raw)
To: Vignesh Raghavendra, Tero Kristo, linux-arm-kernel, linux-kernel,
Francesco Dolcini
Cc: Nishanth Menon, Francesco Dolcini
In-Reply-To: <20260615132640.161584-1-francesco@dolcini.it>
Hi Francesco Dolcini,
On Mon, 15 Jun 2026 15:26:38 +0200, Francesco Dolcini wrote:
> Add git tree for TI K3 architecture.
I have applied the following to branch ti-k3-maintainer-next on [1].
Thank you!
[1/1] MAINTAINERS: Add git tree for TI K3 ARCHITECTURE
commit: 4fb6763ec70d49f592cc6e684bfc5f17a7db7133
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
From: Frank.Li @ 2026-06-29 16:54 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel
Cc: Frank Li, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260611-imx8mp-frdm-hdmi-ddc-v1-1-b4e4c9bb0729@pengutronix.de>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 11 Jun 2026 10:18:59 +0200, Philipp Zabel wrote:
> Configure HDMI DDC SCL/SDA pins to support reading EDID.
Applied, thanks!
[1/1] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
commit: d701830f981856dd41149182c5d98ba996bf2d68
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] soc: ti: knav_dma: remove debugfs file on teardown
From: Nishanth Menon @ 2026-06-29 16:54 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: Santosh Shilimkar, linux-kernel, linux-arm-kernel
In-Reply-To: <20260615091200.2373-1-pengpeng@iscas.ac.cn>
On 17:12-20260615, Pengpeng Hou wrote:
> knav_dma_probe() creates the global knav_dma debugfs file whose show
> callback walks the global kdev list. knav_dma_remove() tears down the DMA
> instances and runtime PM but leaves that debugfs file and global ready
> state behind.
>
> Save the debugfs dentry, remove it before destroying the DMA state, and
> clear the global ready pointer state during remove.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/soc/ti/knav_dma.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
> index e5f5e3142fc4..9277c525ac21 100644
> --- a/drivers/soc/ti/knav_dma.c
> +++ b/drivers/soc/ti/knav_dma.c
> @@ -125,6 +125,7 @@ struct knav_dma_chan {
> ch->channel : ch->flow)
>
> static struct knav_dma_pool_device *kdev;
> +static struct dentry *knav_dma_debugfs;
Similar comment as previous patch to consider moving this to
knav_dma_pool_device.
>
> static bool device_ready;
> bool knav_dma_device_ready(void)
> @@ -740,8 +741,9 @@ static int knav_dma_probe(struct platform_device *pdev)
> goto err_put_sync;
> }
>
> - debugfs_create_file("knav_dma", S_IFREG | S_IRUGO, NULL, NULL,
> - &knav_dma_debug_fops);
> + knav_dma_debugfs = debugfs_create_file("knav_dma", 0444,
0444 is worth mentioning in the commit message.
> + NULL, NULL,
> + &knav_dma_debug_fops);
>
> device_ready = true;
> return ret;
> @@ -758,6 +760,10 @@ static void knav_dma_remove(struct platform_device *pdev)
> {
> struct knav_dma_device *dma;
>
> + device_ready = false;
> + debugfs_remove(knav_dma_debugfs);
> + knav_dma_debugfs = NULL;
> +
> list_for_each_entry(dma, &kdev->list, list) {
> if (atomic_dec_return(&dma->ref_count) == 0)
> knav_dma_hw_destroy(dma);
> @@ -765,6 +771,7 @@ static void knav_dma_remove(struct platform_device *pdev)
>
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> + kdev = NULL;
Also worth stating in the commit message.
> }
>
> static struct of_device_id of_match[] = {
> --
> 2.50.1 (Apple Git-155)
>
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Bartosz Golaszewski @ 2026-06-29 16:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Magnus Damm, Maxime Ripard, Christophe Roullier, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <CAMuHMdVUBgG0EFB16OxHisbxx-sBvDKvBPNZdpyDnmBrnX4ptQ@mail.gmail.com>
On Mon, Jun 29, 2026 at 4:58 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Bartosz,
>
> On Mon, 29 Jun 2026 at 16:07, Bartosz Golaszewski <brgl@kernel.org> wrote:
> > On Mon, 29 Jun 2026 15:51:31 +0200, Geert Uytterhoeven
> > <geert@linux-m68k.org> said:
> > > On Mon, 29 Jun 2026 at 13:29, Bartosz Golaszewski
> > > <bartosz.golaszewski@oss.qualcomm.com> wrote:
> > >> Describe the SGMII/SerDes PHY present on the Qualcomm sa8255p platforms.
> > >> This is essentially the same hardware as sa8775p rev3 but the PHY is
> > >> managed by firmware over SCMI.
> > >
> > > So why can't it be reuse the DT bindings, and be compatible with
> > > qcom,sa8775p-dwmac-sgmii-phy?
> > >
> > >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > >
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-dwmac-sgmii-phy.yaml
> > >
> > >> + power-domains:
> > >> + maxItems: 1
> > >> +
> > >> + power-domain-names:
> > >> + items:
> > >> + - const: serdes
> > >
> > >> +examples:
> > >> + - |
> > >> + phy@8901000 {
> > >> + compatible = "qcom,sa8255p-dwmac-sgmii-phy";
> > >> + reg = <0x08901000 0xe10>;
> > >> + #phy-cells = <0>;
> > >> + power-domains = <&scmi7_dvfs 0>;
> > >> + power-domain-names = "serdes";
> > >
> > > Ah, this uses power-domains, while the existing bindings for
> > > qcom,sa8775p-dwmac-sgmii-phy use a clock.
> > > I guess the clock is the correct hardware description?
> > >
> > > Adding to my list of examples for backing a hardware-to-SCMI remapping
> > > driver...
> > >
> >
> > Russell King asked me to put the PHY logic for SCMI pm domains into the PHY
> > driver instead of the MAC driver where it was previously. Instead of cramming
> > both HLOS and firmware handling into the same driver, I figured it makes more
> > sense to have a dedicated, cleaner driver as the two share very little code (if
> > any).
>
> I think you are mixing up DT bindings and driver implementation?
>
Ah indeed, but the bindings don't share a lot of content either.
Bartosz
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Kiryl Shutsemau @ 2026-06-29 16:53 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <akKVKhOsv6EJVFv4@arm.com>
On Mon, Jun 29, 2026 at 04:54:18PM +0100, Catalin Marinas wrote:
> Have you tried SDEI_EVENT_COMPLETE_AND_RESUME instead? Just COMPLETE
> won't return to the kernel. We have sdei_handler_abort() to complete the
> event and, hopefully, you can continue with the CPU_OFF. It's a work
> around the TF-A non-compliance but I think this is useful even if you
> don't issue the CPU_OFF (e.g. no CPU hotplug, just the park loop).
Tried it. The result is the opposite of what I expected, and it argues
against doing the complete at all under QEMU's TF-A.
Same A/B harness as before -- a CPU wedged with interrupts masked is
stopped via the SDEI rung; I only vary how its handler ends. kdump
capture kernel boot under QEMU:
- park, event left uncompleted (current series): boots to a shell
- sdei_handler_abort() then CPU_OFF: hangs at SDEI re-init
- sdei_handler_abort() then park (no CPU_OFF): hangs at SDEI re-init
- CPU_OFF, event left uncompleted: hangs at SDEI re-init
The third line is the surprising one: completing the event via
sdei_handler_abort() and then just parking -- no CPU_OFF at all -- breaks
the capture kernel too, at the same point as CPU_OFF does. The only
variant that boots is the one that leaves the event uncompleted and
parks. So here it's completing the event that the capture kernel trips
over, not the dangling dispatch -- backwards from the non-compliance
theory, where completing should be the safe thing and "useful even
without CPU_OFF".
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
From: Frank Li @ 2026-06-29 16:52 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Daniel Baluta, Josua Mayer, Dario Binacchi,
Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <4a43b387ebc5c0d715a2a736094b7544e68018f8.1780998600.git.stefano.r@variscite.com>
On Tue, Jun 09, 2026 at 11:51:20AM +0200, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add device tree support for the Variscite Sonata carrier board with the
> DART-MX8M-PLUS system on module.
>
> The Sonata board includes
> - uSD Card support
> - USB ports and OTG
> - Additional Gigabit Ethernet interface
> - Uart, SPI and I2C interfaces
> - HDMI support
> - GPIO Expanders
> - RTC module
> - TPM module
> - CAN peripherals
>
> Link: https://variscite.com/carrier-boards/sonata-board/
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
> ---
> v4->v5:
> - Fix nodes order
>
> v3->v4:
> - Add snvs nodes
>
> v2->v3:
> -
>
> v1->v2:
> - Fixed model name
> - Added new usdhc2 regulator pinctrl
> - Adjusted irq edges
>
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../dts/freescale/imx8mp-var-dart-sonata.dts | 731 ++++++++++++++++++
> 2 files changed, 732 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 03988f0eae30..818e57f54475 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -448,6 +448,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtb
>
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-ultra-mach-sbc.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-var-dart-sonata.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-var-som-symphony.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-venice-gw71xx-2x.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-venice-gw72xx-2x.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts
> new file mode 100644
> index 000000000000..283864b2d4b3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts
> @@ -0,0 +1,731 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Variscite Sonata carrier board for DART-MX8M-PLUS
> + *
> + * Link: https://variscite.com/carrier-boards/sonata-board/
> + *
> + * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> +#include "imx8mp-var-dart.dtsi"
> +
> +/ {
> + model = "Variscite DART-MX8M-PLUS on Sonata-Board";
> + compatible = "variscite,var-dart-mx8mp-sonata",
> + "variscite,var-dart-mx8mp",
> + "fsl,imx8mp";
> +
> + chosen {
> + stdout-path = &uart1;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + button-home {
> + label = "Home";
> + linux,code = <KEY_HOME>;
> + gpios = <&pca6408_1 4 GPIO_ACTIVE_LOW>;
> + wakeup-source;
> + };
> +
> + button-up {
> + label = "Up";
> + linux,code = <KEY_UP>;
> + gpios = <&pca6408_1 5 GPIO_ACTIVE_LOW>;
> + wakeup-source;
> + };
> +
> + button-down {
> + label = "Down";
> + linux,code = <KEY_DOWN>;
> + gpios = <&pca6408_1 6 GPIO_ACTIVE_LOW>;
> + wakeup-source;
> + };
> +
> + button-back {
> + label = "Back";
> + linux,code = <KEY_BACK>;
> + gpios = <&pca6408_1 7 GPIO_ACTIVE_LOW>;
> + wakeup-source;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_leds>;
> +
> + led-emmc {
> + gpios = <&gpio4 18 GPIO_ACTIVE_HIGH>;
> + label = "eMMC";
> + linux,default-trigger = "mmc2";
> + };
> + };
> +
> + native-hdmi-connector {
> + compatible = "hdmi-connector";
> + label = "HDMI OUT";
> + type = "a";
> +
> + port {
> + hdmi_in: endpoint {
> + remote-endpoint = <&hdmi_tx_out>;
> + };
> + };
> + };
> +
> + clk40m: oscillator {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <40000000>;
> + clock-output-names = "can_osc";
> + };
> +
> + pcie0_refclk: pcie0-refclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <100000000>;
> + };
> +
> + reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_vmmc_usdhc2>;
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + startup-delay-us = <100>;
> + off-on-delay-us = <12000>;
> + };
> +
> + sound-hdmi {
> + compatible = "fsl,imx-audio-hdmi";
> + model = "audio-hdmi";
> + audio-cpu = <&aud2htx>;
> + hdmi-out;
> + };
> +
> + sound-xcvr {
> + compatible = "fsl,imx-audio-card";
> + model = "imx-audio-xcvr";
> +
> + pri-dai-link {
> + link-name = "XCVR PCM";
> +
> + cpu {
> + sound-dai = <&xcvr>;
> + };
> + };
> + };
> +};
> +
> +&aud2htx {
> + status = "okay";
> +};
> +
> +&ecspi1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi1>;
> + cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>,
> + <&gpio1 12 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +
> + ads7846: touchscreen@0 {
> + compatible = "ti,ads7846";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_restouch>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
> + spi-max-frequency = <1500000>;
> + pendown-gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
> + ti,x-min = /bits/ 16 <125>;
> + ti,x-max = /bits/ 16 <4008>;
> + ti,y-min = /bits/ 16 <282>;
> + ti,y-max = /bits/ 16 <3864>;
> + ti,x-plate-ohms = /bits/ 16 <180>;
> + ti,pressure-max = /bits/ 16 <255>;
> + ti,debounce-max = /bits/ 16 <10>;
> + ti,debounce-tol = /bits/ 16 <3>;
> + ti,debounce-rep = /bits/ 16 <1>;
> + ti,settle-delay-usec = /bits/ 16 <150>;
> + ti,keep-vref-on;
> + wakeup-source;
> + };
> +
> + can0: can@1 {
> + compatible = "microchip,mcp251xfd";
> + reg = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_can>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> + microchip,rx-int-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
> + clocks = <&clk40m>;
> + spi-max-frequency = <20000000>;
> + };
> +};
> +
> +&eqos {
> + mdio {
> + ethphy1: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <10000>;
> + reset-deassert-us = <20000>;
> + vddio-supply = <®_phy_vddio>;
> +
> + leds {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@0 {
> + reg = <0>;
> + color = <LED_COLOR_ID_YELLOW>;
> + function = LED_FUNCTION_LAN;
> + linux,default-trigger = "netdev";
> + };
> +
> + led@1 {
> + reg = <1>;
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_LAN;
> + linux,default-trigger = "netdev";
> + };
> + };
> + };
> + };
> +};
> +
> +ðphy0 {
> + leds {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@0 {
> + reg = <0>;
> + color = <LED_COLOR_ID_YELLOW>;
> + function = LED_FUNCTION_LAN;
> + linux,default-trigger = "netdev";
> + };
> +
> + led@1 {
> + reg = <1>;
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_LAN;
> + linux,default-trigger = "netdev";
> + };
> + };
> +};
> +
> +&fec {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_fec>;
> + /*
> + * The required RGMII TX and RX 2ns delays are implemented directly
> + * in hardware via passive delay elements on the SOM PCB.
> + * No delay configuration is needed in software via PHY driver.
> + */
> + phy-mode = "rgmii";
> + phy-handle = <ðphy1>;
> + status = "okay";
> +};
> +
> +&flexcan1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan1>;
> + status = "okay";
> +};
> +
> +&flexcan2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan2>;
> + status = "okay";
> +};
> +
> +&hdmi_pai {
> + status = "okay";
> +};
> +
> +&hdmi_pvi {
> + status = "okay";
> +};
> +
> +&hdmi_tx {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hdmi>;
> + status = "okay";
> +
> + ports {
> + port@1 {
> + hdmi_tx_out: endpoint {
> + remote-endpoint = <&hdmi_in>;
> + };
> + };
> + };
> +};
> +
> +&hdmi_tx_phy {
> + status = "okay";
> +};
> +
> +&i2c2 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default", "gpio";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + pinctrl-1 = <&pinctrl_i2c2_gpio>;
> + scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + status = "okay";
> +
> + pca9534: gpio@22 {
> + compatible = "nxp,pca9534";
> + reg = <0x22>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + eth10g-en-hog {
> + gpio-hog;
> + gpios = <5 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "eth10g_sel";
> + };
> +
> + pcie2-en-hog {
> + gpio-hog;
> + gpios = <6 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "pcie2_sel";
> + };
> +
> + /* RGB_SEL */
> + lvds-brg-enable-hog {
> + gpio-hog;
> + gpios = <7 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "rgb_sel";
> + };
Please provide comments it is safe for these hogs, gpio driver may probe
later than ether net\pcie.
If it is on-boards signal mux, please use
https://lore.kernel.org/imx/20260504-pinctrl-mux-v6-2-8ea858ba3a5b@nxp.com/
which already in 7.2
Frank
> + };
> +
> + /* Capacitive touch controller */
> + ft5x06_ts: touchscreen@38 {
> + compatible = "edt,edt-ft5206";
> + reg = <0x38>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_captouch>;
> + reset-gpios = <&pca6408_2 4 GPIO_ACTIVE_LOW>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + touchscreen-inverted-x;
> + touchscreen-inverted-y;
> + wakeup-source;
> + };
> +
> + typec@3d {
> + compatible = "nxp,ptn5150";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_extcon>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
> +
> + port {
> + typec_dr_sw: endpoint {
> + remote-endpoint = <&usb3_drd_sw>;
> + };
> + };
> + };
> +
> + rtc@68 {
> + compatible = "dallas,ds1337";
> + reg = <0x68>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_rtc>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
> + wakeup-source;
> + };
> +};
> +
> +&i2c3 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default", "gpio";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + pinctrl-1 = <&pinctrl_i2c3_gpio>;
> + scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + status = "okay";
> +};
> +
> +&i2c4 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default", "gpio";
> + pinctrl-0 = <&pinctrl_i2c4>;
> + pinctrl-1 = <&pinctrl_i2c4_gpio>;
> + scl-gpios = <&gpio5 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + sda-gpios = <&gpio5 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + status = "okay";
> +
> + pca6408_1: gpio@20 {
> + compatible = "nxp,pcal6408";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pca6408>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + pca6408_2: gpio@21 {
> + compatible = "nxp,pcal6408";
> + reg = <0x21>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + st33ktpm2xi2c: tpm@2e {
> + compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
> + reg = <0x2e>;
> + label = "tpm";
> + reset-gpios = <&pca9534 0 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +&lcdif3 {
> + status = "okay";
> +};
> +
> +&pcie {
> + reset-gpios = <&pca6408_2 3 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> + clocks = <&pcie0_refclk>;
> + clock-names = "ref";
> + status = "okay";
> +};
> +
> +&pwm1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm1>;
> + status = "okay";
> +};
> +
> +&snvs_pwrkey {
> + status = "okay";
> +};
> +
> +&snvs_rtc {
> + status = "disabled";
> +};
> +
> +/* Console */
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "okay";
> +};
> +
> +/* Header */
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + status = "okay";
> +};
> +
> +/* Header */
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + status = "okay";
> +};
> +
> +&usb3_0 {
> + status = "okay";
> +};
> +
> +&usb3_1 {
> + status = "okay";
> +};
> +
> +&usb_dwc3_0 {
> + dr_mode = "otg";
> + hnp-disable;
> + srp-disable;
> + adp-disable;
> + usb-role-switch;
> + snps,dis-u1-entry-quirk;
> + snps,dis-u2-entry-quirk;
> + status = "okay";
> +
> + port {
> + usb3_drd_sw: endpoint {
> + remote-endpoint = <&typec_dr_sw>;
> + };
> + };
> +};
> +
> +&usb_dwc3_1 {
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> +&usb3_phy0 {
> + fsl,phy-tx-vref-tune-percent = <122>;
> + fsl,phy-tx-preemp-amp-tune-microamp = <1800>;
> + fsl,phy-tx-vboost-level-microvolt = <1156>;
> + fsl,phy-comp-dis-tune-percent = <115>;
> + fsl,phy-pcs-tx-deemph-3p5db-attenuation-db = <33>;
> + fsl,phy-pcs-tx-swing-full-percent = <100>;
> + status = "okay";
> +};
> +
> +&usb3_phy1 {
> + fsl,phy-tx-preemp-amp-tune-microamp = <1800>;
> + fsl,phy-tx-vref-tune-percent = <116>;
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> + cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
> + vmmc-supply = <®_usdhc2_vmmc>;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&xcvr {
> + #sound-dai-cells = <0>;
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_can: cangrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_GPIO1_IO06__GPIO1_IO06 0x1c6
> + MX8MP_IOMUXC_SPDIF_RX__GPIO5_IO04 0x16
> + >;
> + };
> +
> + pinctrl_captouch: captouchgrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_GPIO1_IO14__GPIO1_IO14 0x16
> + >;
> + };
> +
> + pinctrl_ecspi1: ecspi1grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x12
> + MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x12
> + MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x12
> + MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09 0x12
> + MX8MP_IOMUXC_GPIO1_IO12__GPIO1_IO12 0x12
> + >;
> + };
> +
> + pinctrl_extcon: extcongrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_GPIO1_IO10__GPIO1_IO10 0x10
> + >;
> + };
> +
> + pinctrl_fec: fecgrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SAI1_RXD4__ENET1_RGMII_RD0 0x90
> + MX8MP_IOMUXC_SAI1_RXD5__ENET1_RGMII_RD1 0x90
> + MX8MP_IOMUXC_SAI1_RXD6__ENET1_RGMII_RD2 0x90
> + MX8MP_IOMUXC_SAI1_RXD7__ENET1_RGMII_RD3 0x1d0
> + MX8MP_IOMUXC_SAI1_TXC__ENET1_RGMII_RXC 0x90
> + MX8MP_IOMUXC_SAI1_TXFS__ENET1_RGMII_RX_CTL 0x90
> + MX8MP_IOMUXC_SAI1_TXD0__ENET1_RGMII_TD0 0x00
> + MX8MP_IOMUXC_SAI1_TXD1__ENET1_RGMII_TD1 0x00
> + MX8MP_IOMUXC_SAI1_TXD2__ENET1_RGMII_TD2 0x00
> + MX8MP_IOMUXC_SAI1_TXD3__ENET1_RGMII_TD3 0x00
> + MX8MP_IOMUXC_SAI1_TXD4__ENET1_RGMII_TX_CTL 0x00
> + MX8MP_IOMUXC_SAI1_TXD5__ENET1_RGMII_TXC 0x00
> + >;
> + };
> +
> + pinctrl_flexcan1: flexcan1grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SAI2_RXC__CAN1_TX 0x154
> + MX8MP_IOMUXC_SAI2_TXC__CAN1_RX 0x154
> + >;
> + };
> +
> + pinctrl_flexcan2: flexcan2grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SAI2_MCLK__CAN2_RX 0x154
> + MX8MP_IOMUXC_SAI2_TXD0__CAN2_TX 0x154
> + >;
> + };
> +
> + pinctrl_gpio_leds: ledgrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SAI1_TXD6__GPIO4_IO18 0xc6
> + >;
> + };
> +
> + pinctrl_hdmi: hdmigrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c2
> + MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c2
> + MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x10
> + MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x10
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c2
> + MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001c2
> + >;
> + };
> +
> + pinctrl_i2c2_gpio: i2c2gpiogrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_I2C2_SCL__GPIO5_IO16 0x1c2
> + MX8MP_IOMUXC_I2C2_SDA__GPIO5_IO17 0x1c2
> + >;
> + };
> +
> + pinctrl_i2c3: i2c3grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001c2
> + MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001c2
> + >;
> + };
> +
> + pinctrl_i2c3_gpio: i2c3gpiogrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_I2C3_SCL__GPIO5_IO18 0x1c2
> + MX8MP_IOMUXC_I2C3_SDA__GPIO5_IO19 0x1c2
> + >;
> + };
> +
> + pinctrl_i2c4: i2c4grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_I2C4_SCL__I2C4_SCL 0x400001c2
> + MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c2
> + >;
> + };
> +
> + pinctrl_i2c4_gpio: i2c4gpiogrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_I2C4_SCL__GPIO5_IO20 0x1c2
> + MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21 0x1c2
> + >;
> + };
> +
> + pinctrl_pca6408: pca6408grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x1c6
> + >;
> + };
> +
> + pinctrl_pwm1: pwm1grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_GPIO1_IO01__PWM1_OUT 0x116
> + >;
> + };
> +
> + pinctrl_restouch: restouchgrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07 0xc0
> + >;
> + };
> +
> + pinctrl_rtc: rtcgrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO15 0x1c0
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x40
> + MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x40
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x40
> + MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x40
> + >;
> + };
> +
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_UART3_RXD__UART3_DCE_RX 0x40
> + MX8MP_IOMUXC_UART3_TXD__UART3_DCE_TX 0x40
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x190
> + MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d0
> + MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d0
> + MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d0
> + MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d0
> + MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d0
> + MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc0
> + >;
> + };
> +
> + pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194
> + MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4
> + MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4
> + MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4
> + MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4
> + MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4
> + MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc0
> + >;
> + };
> +
> + pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x196
> + MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d6
> + MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d6
> + MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d6
> + MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d6
> + MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d6
> + MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc0
> + >;
> + };
> +
> + pinctrl_vmmc_usdhc2: regvmmc-usdhc2grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x40
> + >;
> + };
> +
> + pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c4
> + >;
> + };
> +};
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH 0/6] treewide: remove unnecessary invalid range checks in memblock iteration loops
From: Sang-Heon Jeon @ 2026-06-29 16:48 UTC (permalink / raw)
To: Mike Rapoport
Cc: Albert Ou, Andrew Morton, Andrey Ryabinin, Catalin Marinas,
Huacai Chen, Muchun Song, Oscar Salvador, Palmer Dabbelt,
Paul Walmsley, Will Deacon, Alexander Potapenko, Alexandre Ghiti,
Andrey Konovalov, David Hildenbrand, Dmitry Vyukov, kasan-dev,
linux-arm-kernel, linux-mm, linux-riscv, loongarch,
Vincenzo Frascino, WANG Xuerui
In-Reply-To: <akJafRKJJBd5Jrv0@kernel.org>
On Mon, Jun 29, 2026 at 8:44 PM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Fri, Jun 26, 2026 at 07:59:22PM +0900, Sang-Heon Jeon wrote:
> > On Fri, Jun 26, 2026 at 5:23 PM Mike Rapoport <rppt@kernel.org> wrote:
> > >
> > > On Sun, Jun 21, 2026 at 11:59:10PM +0900, Sang-Heon Jeon wrote:
> > > > The memblock API guarantees that for_each_mem_range() and
> > > > for_each_mem_pfn_range() never return an invalid range, meaning start is
> > > > always less than end.
> > > >
> > > > Several memblock callers still have unnecessary invalid range checks in
> > > > their loop bodies, so remove them.
> > > >
> > > > Sang-Heon Jeon (6):
> > > > arm64: mm: remove unreachable invalid range check in
> > > > kasan_init_shadow()
> > > > LoongArch: remove unreachable invalid range check in kasan_init()
> > > > riscv: remove unreachable invalid range check in
> > > > create_linear_mapping_page_table()
> > > > riscv: remove unreachable invalid range check in kasan_init()
> > > > mm: remove unnecessary empty range check in
> > > > early_calculate_totalpages()
> > > > mm/hugetlb: remove unnecessary empty range check in
> > > > hugetlb_bootmem_set_nodes()
> > >
> > > I queued this for inclusion into memblock tree.
> >
> > Thank you, Mike.
> >
> > Could you please review and queue this patch [1] as well? It does the
> > same kind of clean up, I just missed it at the time.
>
> Can you please resend them all as a single set?
Thanks for considering, Mike.
I've sent v2 patch series [1] that includes the missing patches.
[1] https://lore.kernel.org/all/20260629163736.1606688-1-ekffu200098@gmail.com/#t
> > [1] https://lore.kernel.org/all/20260626032902.703944-1-ekffu200098@gmail.com/
> >
> > > > arch/arm64/mm/kasan_init.c | 3 ---
> > > > arch/loongarch/mm/kasan_init.c | 3 ---
> > > > arch/riscv/mm/init.c | 2 --
> > > > arch/riscv/mm/kasan_init.c | 3 ---
> > > > mm/hugetlb.c | 3 +--
> > > > mm/mm_init.c | 3 +--
> > > > 6 files changed, 2 insertions(+), 15 deletions(-)
> > > >
> > > > --
> > > > 2.43.0
> > > >
> > >
> > > --
> > > Sincerely yours,
> > > Mike.
> >
> > Best Regards,
> > Sang-Heon Jeon
>
> --
> Sincerely yours,
> Mike.
Best Regards,
Sang-Heon Jeon
^ permalink raw reply
* Re: [PATCH v5 06/14] arm64: dts: imx8mp-var-som-symphony: enable PCIe
From: Stefano Radaelli @ 2026-06-29 16:40 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <akKdkWos2E25M_q8@lizhi-Precision-Tower-5810>
Hi Frank,
On Mon, Jun 29, 2026 at 12:30:09PM -0400, Frank Li wrote:
>
> You have to provide all clocks, otherwise, whole clocks and clock-names will
> by overwrite with one clock "ref".
>
> suppose CHECK_DTBS should report warning about clocks items.
>
> Frank
>
thanks for checking.
In this case the SoC dtsi does not provide any clocks or clock-names for
the PCIe PHY node, so this is not overriding an existing clock list. It
only adds the external reference clock used by the board.
This follows the same pattern used by the i.MX8MP EVK, where the PCIe
PHY node only provides the external "ref" clock together with
fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>.
This is also why CHECK_DTBS does not report any warnings for this node.
$: sed -n '/^&pcie_phy {/,/^};/p' arch/arm64/boot/dts/freescale/imx8mp-evk.dts
&pcie_phy {
fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
clocks = <&pcie0_refclk>;
clock-names = "ref";
status = "okay";
};
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH rc v6 7/7] iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP_ADOPT in probe()
From: Pranjal Shrivastava @ 2026-06-29 16:40 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, jgg, joro, kees, baolu.lu, kevin.tian,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <8f43bbe920466359465f2083cfd09a15ee8e5ff1.1779265413.git.nicolinc@nvidia.com>
On Wed, May 20, 2026 at 10:03:24AM -0700, Nicolin Chen wrote:
> arm_smmu_device_hw_probe() runs before arm_smmu_init_structures(), so it's
> natural to decide whether the kdump kernel must adopt the crashed kernel's
> stream table.
>
> Given that memremap is used to adopt the old stream table, set this option
> only on a coherent SMMU.
>
> And make sure SMMU isn't in Service Failure Mode.
>
> Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
> Cc: stable@vger.kernel.org # v6.12+
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 31 +++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 851bcebfdb3d4..fb34c3ffee9fe 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -5353,6 +5353,33 @@ static void arm_smmu_get_httu(struct arm_smmu_device *smmu, u32 reg)
> hw_features, fw_features);
> }
>
> +static void arm_smmu_device_hw_probe_kdump(struct arm_smmu_device *smmu)
> +{
> + u32 gerror, gerrorn, active;
> +
> + /* No adoption if SMMU is disabled (i.e., there is no in-flight DMA) */
> + if (!(readl_relaxed(smmu->base + ARM_SMMU_CR0) & CR0_SMMUEN))
> + return;
> +
> + /* For now, only support a coherent SMMU that works with MEMREMAP_WB */
> + if (!(smmu->features & ARM_SMMU_FEAT_COHERENCY)) {
> + dev_warn(smmu->dev,
> + "kdump: non-coherent SMMU unsupported; reset to block all DMAs\n");
> + return;
> + }
We seem to be checking it here right at the beginning, let's remove the
redundant checks downstream?
> +
> + gerror = readl_relaxed(smmu->base + ARM_SMMU_GERROR);
> + gerrorn = readl_relaxed(smmu->base + ARM_SMMU_GERRORN);
> + active = gerror ^ gerrorn;
> + if (active & GERROR_SFM_ERR) {
> + dev_warn(smmu->dev,
> + "kdump: SMMU in Service Failure Mode, must reset\n");
> + return;
> + }
> +
> + smmu->options |= ARM_SMMU_OPT_KDUMP_ADOPT;
> +}
> +
> static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> {
> u32 reg;
> @@ -5567,6 +5594,10 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
>
> dev_info(smmu->dev, "oas %lu-bit (features 0x%08x)\n",
> smmu->oas, smmu->features);
> +
> + if (is_kdump_kernel())
> + arm_smmu_device_hw_probe_kdump(smmu);
> +
> return 0;
> }
Apart from that nit,
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v3 0/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
From: Frank.Li @ 2026-06-29 16:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan, Liu Ying
Cc: Frank Li, devicetree, imx, linux-arm-kernel, linux-kernel,
Marco Felsch
In-Reply-To: <20260610-imx93-ldb-v3-0-c9b65d742753@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Wed, 10 Jun 2026 17:26:20 +0800, Liu Ying wrote:
> This patch series aims to add DY1212W-4856 [1] LVDS panel to i.MX93 11x11
> EVK board.
>
> Patch 1 allows LVDS Display Bridge (LDB) child node in i.MX93 mediamix
> blk-ctrl DT binding.
> Patch 2 adds LDB child node to mediamix blk-ctrl node in imx93.dtsi.
> Patch 3 adds a DT overlay to support the DY1212W-4856 LVDS panel on
> i.MX93 11x11 EVK board.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: soc: imx: fsl,imx93-media-blk-ctrl: Allow LVDS Display Bridge child node
commit: 5436de7dc33aacfaa25befabb6eed9e81d146a7b
[2/3] arm64: dts: imx93: Add LVDS Display Bridge support
commit: 42feaaac68f46e7aeb41d065b555d36c486a7afa
[3/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
commit: d7c5180b7e235a4021bc32722dd7542857eceb0b
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v2 5/8] ARM: remove unreachable invalid range check in kasan_init()
From: Sang-Heon Jeon @ 2026-06-29 16:37 UTC (permalink / raw)
To: rppt, Andrey Ryabinin, Russell King
Cc: linux-mm, Sang-Heon Jeon, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, kasan-dev, linux-arm-kernel, linux-kernel,
Vincenzo Frascino
In-Reply-To: <20260629163736.1606688-1-ekffu200098@gmail.com>
kasan_init() maps each memblock region with for_each_mem_range(), which
guarantees pa_start < pa_end. Then it skips any region with
pa_start >= arm_lowmem_limit, so pa_start < arm_lowmem_limit is guaranteed
as well.
When pa_end <= arm_lowmem_limit, pa_start < pa_end means start < end, so
the start >= end check is unreachable.
When pa_end > arm_lowmem_limit, end is clamped to __va(arm_lowmem_limit),
and pa_start < arm_lowmem_limit means start < end, so the check is
unreachable as well.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
---
arch/arm/mm/kasan_init.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index c6625e808bf8..1f7c74c5df9e 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -262,12 +262,6 @@ void __init kasan_init(void)
&pa_start, &pa_end, &arm_lowmem_limit);
end = __va(arm_lowmem_limit);
}
- if (start >= end) {
- pr_info("Skipping invalid memory block %pa-%pa (virtual %p-%p)\n",
- &pa_start, &pa_end, start, end);
- continue;
- }
-
create_mapping(start, end);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/8] arm64: mm: remove unreachable invalid range check in kasan_init_shadow()
From: Sang-Heon Jeon @ 2026-06-29 16:37 UTC (permalink / raw)
To: rppt, Andrey Ryabinin, Catalin Marinas, Will Deacon
Cc: linux-mm, Sang-Heon Jeon, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, kasan-dev, linux-arm-kernel, linux-kernel,
Vincenzo Frascino
In-Reply-To: <20260629163736.1606688-1-ekffu200098@gmail.com>
kasan_init_shadow() maps each memblock region with for_each_mem_range()
and breaks the loop when start >= end. for_each_mem_range() never returns
an invalid range, so start < end always.
Therefore the start >= end check is unreachable, so remove it.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
---
arch/arm64/mm/kasan_init.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 3fcad956fdf7..45fbdce684c8 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -353,9 +353,6 @@ static void __init kasan_init_shadow(void)
void *start = (void *)__phys_to_virt(pa_start);
void *end = (void *)__phys_to_virt(pa_end);
- if (start >= end)
- break;
-
kasan_map_populate((unsigned long)kasan_mem_to_shadow(start),
(unsigned long)kasan_mem_to_shadow(end),
early_pfn_to_nid(virt_to_pfn(start)));
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/8] treewide: remove unnecessary invalid range checks in memblock iteration loops
From: Sang-Heon Jeon @ 2026-06-29 16:37 UTC (permalink / raw)
To: rppt, Albert Ou, Andrew Morton, Andrey Ryabinin, Catalin Marinas,
Huacai Chen, Madhavan Srinivasan, Michael Ellerman, Muchun Song,
Oscar Salvador, Palmer Dabbelt, Paul Walmsley, Russell King,
Will Deacon
Cc: linux-mm, Sang-Heon Jeon, Alexander Potapenko, Alexandre Ghiti,
Andrey Konovalov, Christophe Leroy (CS GROUP), David Hildenbrand,
Dmitry Vyukov, kasan-dev, linux-arm-kernel, linux-kernel,
linuxppc-dev, linux-riscv, loongarch, Nicholas Piggin,
Vincenzo Frascino, WANG Xuerui
The memblock API guarantees that for_each_mem_range() and
for_each_mem_pfn_range() never return an invalid range, meaning start is
always less than end.
Several memblock callers still have unnecessary invalid range checks in
their loop bodies, so remove them.
Patches 1-6 cover for_each_mem_range() callers. memblock never stores a
zero-size region, so the range it returns always has start < end. Some
callers apply __va() or __phys_to_virt() before comparing, but these keep
start < end too, so the check is unreachable.
Patches 7-8 cover for_each_mem_pfn_range() callers. __next_mem_pfn_range()
skips any region that contains no whole page, so it only ever returns
start_pfn < end_pfn and the check is unnecessary.
For reference, commit 36ca7f4be809 ("arm64: mm: Remove bogus stop
condition from map_mem() loop") did a similar cleanup in arm64 map_mem().
All these checks are in different trees, so I split the change into one
patch per arch/subsystem. The patches are independent and can be applied
separately.
---
Changes from v1 [1]
- Add review-by, tested-by tags from v1
- Add missing simliar patches(5,6) to patch series
- Change base to rppt/for-next
[1] https://lore.kernel.org/all/20260621145919.1453-1-ekffu200098@gmail.com/
---
Sang-Heon Jeon (8):
arm64: mm: remove unreachable invalid range check in
kasan_init_shadow()
LoongArch: remove unreachable invalid range check in kasan_init()
riscv: remove unreachable invalid range check in
create_linear_mapping_page_table()
riscv: remove unreachable invalid range check in kasan_init()
ARM: remove unreachable invalid range check in kasan_init()
powerpc64/kasan: Remove unreachable invalid range check in
kasan_init_phys_region()
mm: remove unnecessary empty range check in
early_calculate_totalpages()
mm/hugetlb: remove unnecessary empty range check in
hugetlb_bootmem_set_nodes()
arch/arm/mm/kasan_init.c | 6 ------
arch/arm64/mm/kasan_init.c | 3 ---
arch/loongarch/mm/kasan_init.c | 3 ---
arch/powerpc/mm/kasan/init_book3e_64.c | 3 ---
arch/powerpc/mm/kasan/init_book3s_64.c | 3 ---
arch/riscv/mm/init.c | 2 --
arch/riscv/mm/kasan_init.c | 3 ---
mm/hugetlb.c | 3 +--
mm/mm_init.c | 3 +--
9 files changed, 2 insertions(+), 27 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: (subset) [PATCH v5 00/14] arm64: dts: imx8mp-var-som-symphony: align DTS with hardware revision
From: Frank.Li @ 2026-06-29 16:34 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel, Stefano Radaelli
Cc: Frank Li, pierluigi.p, Stefano Radaelli, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 08 Jun 2026 16:41:01 +0200, Stefano Radaelli wrote:
> This series updates the i.MX8MP VAR-SOM and Symphony device trees to
> better align them with the current hardware configuration.
>
> It adds the missing board peripherals and completes the related pinctrl,
> GPIO and bus configuration.
>
> v4->v5:
> - Add the SION (Software Input On) bit for the I2C recovery pins
> - Remove regulator-always-on and duplicated vddio node
>
> [...]
Applied, thanks!
[01/14] arm64: dts: imx8mp-var-som-symphony: add input keys
commit: 5a7946c9753b159ea2aa6d2441c7916497696558
[02/14] arm64: dts: imx8mp-var-som-symphony: enable USB support
commit: 41dc722afe74974c36c963b3a140c8eb2935e972
[03/14] arm64: dts: imx8mp-var-som-symphony: add TPM support
commit: f9aa2804d9e7b969395a65d5464f8031ebc74dac
[04/14] arm64: dts: imx8mp-var-som-symphony: add external RTC
commit: 5b4d6e1e0ff4ad63997ab725499272b117ed3475
[05/14] arm64: dts: imx8mp-var-som-symphony: enable header UARTs
commit: b1c9dd9559059a5c7ccbee70a0f383ac19404927
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v5 06/14] arm64: dts: imx8mp-var-som-symphony: enable PCIe
From: Frank Li @ 2026-06-29 16:30 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <26b5b602c3995a5a74f64b84576ab4d54ace23ee.1780929317.git.stefano.r@variscite.com>
On Mon, Jun 08, 2026 at 04:41:07PM +0200, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add the PCIe reference clock and enable the PCIe controller and PHY on
> the Symphony carrier board.
>
> Describe the PERST# reset GPIO and configure the PHY to use an external
> reference clock input.
>
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
> ---
> v4->v5:
> -
>
> v3->v4:
> - Add pcie reset-gpios instead of deprecated one
>
> v2->v3:
> -
>
> v1->v2:
> - Adjust PCIe controller configuration
>
> .../dts/freescale/imx8mp-var-som-symphony.dts | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
> index fdac4ceb4c19..698f02fc39a5 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
> @@ -48,6 +48,12 @@ led-0 {
> };
> };
>
> + pcie0_refclk: pcie0-refclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <100000000>;
> + };
> +
> reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
> compatible = "regulator-fixed";
> regulator-name = "VSD_3V3";
> @@ -146,6 +152,18 @@ rtc@68 {
> };
> };
>
> +&pcie {
> + reset-gpios = <&pcal6408 1 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + clocks = <&pcie0_refclk>;
> + clock-names = "ref";
You have to provide all clocks, otherwise, whole clocks and clock-names will
by overwrite with one clock "ref".
suppose CHECK_DTBS should report warning about clocks items.
Frank
> + fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> + status = "okay";
> +};
> +
> &snvs_pwrkey {
> status = "okay";
> };
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH rc v6 6/7] iommu/arm-smmu-v3: Skip RMR bypass for kdump adoption
From: Pranjal Shrivastava @ 2026-06-29 16:28 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, jgg, joro, kees, baolu.lu, kevin.tian,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <88e75018e94adc2eb3db8c1fd97c3cc738c170bb.1779265413.git.nicolinc@nvidia.com>
On Wed, May 20, 2026 at 10:03:23AM -0700, Nicolin Chen wrote:
> RMR bypass STEs are installed during SMMUv3 probe for StreamIDs listed by
> IORT RMR nodes. A normal boot switches the driver to a fresh stream table
> whose initial STEs abort, so those RMR SIDs need bypass entries before it
> becomes live. This preserves firmware/guest-owned traffic, including vSMMU
> guest MSI cases built around RMR-described SIDs.
>
> ARM_SMMU_OPT_KDUMP_ADOPT is the opposite case: the driver keeps SMMUEN set
> and adopts the crashed kernel's stream table, so RMR SIDs already have the
> only translation state known to be safe for active in-flight DMA. Replacing
> an adopted STE with bypass can turn translated DMA into physical DMA, then
> point it at the wrong memory.
>
> arm_smmu_make_bypass_ste() also rewrites the STE in place after clearing it
> first. While the table is live, a concurrent hardware STE fetch can observe
> V=0 or mixed old/new state.
>
> Leaving the adopted STE unmodified keeps the kdump kernel using the crashed
> kernel's translation. That gives the endpoint driver a chance to probe and
> quiesce the device.
>
> If the old STE was already abort or invalid, installing bypass would create
> new DMA permission; leaving it alone is a safer failure mode. Later domain
> setup still gets the RMR direct mappings through the reserved-region path.
>
> Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
> Cc: stable@vger.kernel.org # v6.12+
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* [PATCH v5 2/2] dt-bindings: mmc: st,sdhci: Convert to DT schema
From: Charan Pedumuru @ 2026-06-29 16:26 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
In-Reply-To: <20260629-st-mmc-v5-0-3cf0e639bff8@gmail.com>
Convert STMicroelectronics sdhci-st MMC/SD controller binding from
text format to YAML DT schema.
Changes during conversion:
- Preserve optional 'icn' clock and 'top-mmc-delay' register region
via minItems: 1 on their respective properties.
- Conditionally require reg-names when two reg entries are present
via an allOf if/then block, preventing silent runtime failure in
devm_platform_ioremap_resource_byname().
- Constrain max-frequency to enum [200000000, 100000000, 50000000]
with a default of 50000000, matching the driver's behaviour in
sdhci-st.c.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 105 ++++++++++++++++++++
2 files changed, 105 insertions(+), 110 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
deleted file mode 100644
index ccf82b4ee838..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-* STMicroelectronics sdhci-st MMC/SD controller
-
-This file documents the differences between the core properties in
-Documentation/devicetree/bindings/mmc/mmc.txt and the properties
-used by the sdhci-st driver.
-
-Required properties:
-- compatible: Must be "st,sdhci" and it can be compatible to "st,sdhci-stih407"
- to set the internal glue logic used for configuring the MMC
- subsystem (mmcss) inside the FlashSS (available in STiH407 SoC
- family).
-
-- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory)
- See: Documentation/devicetree/bindings/resource-names.txt
-- clocks: Phandle to the clock.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-- interrupts: One mmc interrupt should be described here.
-- interrupt-names: Should be "mmcirq".
-
-- pinctrl-names: A pinctrl state names "default" must be defined.
-- pinctrl-0: Phandle referencing pin configuration of the sd/emmc controller.
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-- reg: This must provide the host controller base address and it can also
- contain the FlashSS Top register for TX/RX delay used by the driver
- to configure DLL inside the flashSS, if so reg-names must also be
- specified.
-
-Optional properties:
-- reg-names: Should be "mmc" and "top-mmc-delay". "top-mmc-delay" is optional
- for eMMC on stih407 family silicon to configure DLL inside FlashSS.
-
-- non-removable: Non-removable slot. Also used for configuring mmcss in STiH407 SoC
- family.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- bus-width: Number of data lines.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- max-frequency: Can be 200MHz, 100MHz or 50MHz (default) and used for
- configuring the CCONFIG3 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- resets: Phandle and reset specifier pair to softreset line of HC IP.
- See: Documentation/devicetree/bindings/reset/reset.txt
-
-- vqmmc-supply: Phandle to the regulator dt node, mentioned as the vcc/vdd
- supply in eMMC/SD specs.
-
-- sd-uhs-sdr50: To enable the SDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-sdr104: To enable the SDR104 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-ddr50: To enable the DDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-Example:
-
-/* Example stih416e eMMC configuration */
-
-mmc0: sdhci@fe81e000 {
- compatible = "st,sdhci";
- reg = <0xfe81e000 0x1000>;
- interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_a1_ls 1>;
- bus-width = <8>
-
-/* Example SD stih407 family configuration */
-
-mmc1: sdhci@9080000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09080000 0x7ff>;
- reg-names = "mmc";
- interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sd1>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_1>;
- resets = <&softreset STIH407_MMC1_SOFTRESET>;
- bus-width = <4>;
-};
-
-/* Example eMMC stih407 family configuration */
-
-mmc0: sdhci@9060000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
- reg-names = "mmc", "top-mmc-delay";
- interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_0>;
- vqmmc-supply = <&vmmc_reg>;
- max-frequency = <200000000>;
- bus-width = <8>;
- non-removable;
- sd-uhs-sdr50;
- sd-uhs-sdr104;
- sd-uhs-ddr50;
-};
diff --git a/Documentation/devicetree/bindings/mmc/st,sdhci.yaml b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
new file mode 100644
index 000000000000..798af599d374
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/st,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics SDHCI-ST MMC/SD Controller
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+description:
+ The STMicroelectronics SDHCI-ST MMC/SD host controller is compliant with
+ the SD Host Controller Interface (SDHCI) specification and is used to
+ interface with MMC, SD and SDIO cards. The ST SDHCI controller extends the
+ standard SDHCI capabilities with platform-specific configurations such as
+ additional register regions, clock inputs, and delay control mechanisms
+ required for signal timing adjustments to support high-speed modes across
+ different ST SoCs.
+
+allOf:
+ - $ref: mmc-controller.yaml#
+ - if:
+ properties:
+ reg:
+ minItems: 2
+ required:
+ - reg
+ then:
+ required:
+ - reg-names
+
+properties:
+ compatible:
+ oneOf:
+ - const: st,sdhci
+ - items:
+ - const: st,sdhci-stih407
+ - const: st,sdhci
+
+ reg:
+ minItems: 1
+ items:
+ - description: MMC controller base registers
+ - description: FlashSS Top registers for TX/RX DLL delay configuration
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: mmc
+ - const: top-mmc-delay
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Clock for the MMC controller
+ - description: Interconnect (ICN) clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: mmc
+ - const: icn
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: mmcirq
+
+ resets:
+ maxItems: 1
+
+ max-frequency:
+ enum: [200000000, 100000000, 50000000]
+ default: 50000000
+
+required:
+ - reg
+ - compatible
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ mmc@9060000 {
+ compatible = "st,sdhci-stih407", "st,sdhci";
+ reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
+ reg-names = "mmc", "top-mmc-delay";
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mmcirq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0>;
+ clock-names = "mmc", "icn";
+ clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
+ <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
+ bus-width = <8>;
+ };
+...
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox