* Re: [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 13:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-copper-albatross-of-youth-6abae8@quoll>
Hi Krzysztof,
> Please start testing your patches. This for sure fails tests.
>
> It does not look like you tested the DTS against bindings. Please run
> 'make dtbs_check W=1' (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.
You are right, I had tested my patches but wrongly. It is indeed failling.
I'm very sorry for that. Thank's for taking the time to explain.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH v15 04/11] arm64/ptrace: Expand secure_computing() in place
From: Ada Couprie Diaz @ 2026-06-24 13:43 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-5-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor syscall_trace_enter() by open-coding the seccomp check
> to align with the generic entry framework.
>
> [Background]
> The generic entry implementation expands the seccomp check in-place
> instead of using the secure_computing() wrapper. It directly tests
> SYSCALL_WORK_SECCOMP and calls the underlying __secure_computing()
> function to handle syscall filtering.
>
> [Changes]
> 1. Open-code seccomp check:
> - Instead of calling the secure_computing() wrapper, explicitly check
> the 'flags' parameter for _TIF_SECCOMP.
> - Call __secure_computing() directly if the flag is set.
>
> [Why this matters]
> - Aligns the arm64 syscall path with the generic entry implementation,
> simplifying future migration to the generic entry framework.
> - No functional changes are intended; seccomp behavior remains identical.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH] clk: rockchip: rk3588: don't disable unused I2S MCLK output gates
From: Sebastian Reichel @ 2026-06-24 13:42 UTC (permalink / raw)
To: Daniele Briguglio
Cc: Michael Turquette, Stephen Boyd, Heiko Stuebner, linux-clk,
linux-arm-kernel, linux-rockchip, linux-kernel, Diederik de Haas,
Nicolas Frattaroli, Ricardo Pardini
In-Reply-To: <20260624123914.1767374-1-hello@superkali.me>
[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]
Hi,
On Wed, Jun 24, 2026 at 02:39:14PM +0200, Daniele Briguglio wrote:
> No in-tree board references these gates yet. Boards drive the codec
> MCLK through the parent I2S*_8CH_MCLKOUT, and now that the gates are
> managed clocks, clk_disable_unused() turns them off at boot. On a board
> that relied on firmware leaving the output enabled, that cuts the MCLK
> and analog audio stops working.
>
> Mark the four gates CLK_IGNORE_UNUSED so an unreferenced gate keeps the
> state firmware left. A board that wants the kernel to own the gate can
> reference I2S*_8CH_MCLKOUT_TO_IO from DT instead.
>
> Fixes: 02b9b0bb6269 ("clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO")
> Reported-by: Diederik de Haas <diederik@cknow-tech.com>
> Closes: https://lore.kernel.org/linux-rockchip/DJGDSS875DDO.22TYPVYK5X8KZ@cknow-tech.com/
> Tested-by: Diederik de Haas <diederik@cknow-tech.com>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
> ---
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Greetings,
-- Sebastian
> drivers/clk/rockchip/clk-rk3588.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c
> index 2ba9976654c..86953f9ffee 100644
> --- a/drivers/clk/rockchip/clk-rk3588.c
> +++ b/drivers/clk/rockchip/clk-rk3588.c
> @@ -895,7 +895,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S2_2CH_MCLKOUT, "i2s2_2ch_mclkout", i2s2_2ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(30), 2, 1, MFLAGS),
> GATE_GRF(I2S2_2CH_MCLKOUT_TO_IO, "i2s2_2ch_mclkout_to_io", "i2s2_2ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
>
> COMPOSITE(CLK_I2S3_2CH_SRC, "clk_i2s3_2ch_src", gpll_aupll_p, 0,
> RK3588_CLKSEL_CON(30), 8, 1, MFLAGS, 3, 5, DFLAGS,
> @@ -912,7 +912,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S3_2CH_MCLKOUT, "i2s3_2ch_mclkout", i2s3_2ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(32), 2, 1, MFLAGS),
> GATE_GRF(I2S3_2CH_MCLKOUT_TO_IO, "i2s3_2ch_mclkout_to_io", "i2s3_2ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
> GATE(PCLK_ACDCDIG, "pclk_acdcdig", "pclk_audio_root", 0,
> RK3588_CLKGATE_CON(7), 11, GFLAGS),
> GATE(HCLK_I2S0_8CH, "hclk_i2s0_8ch", "hclk_audio_root", 0,
> @@ -942,7 +942,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S0_8CH_MCLKOUT, "i2s0_8ch_mclkout", i2s0_8ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(28), 2, 2, MFLAGS),
> GATE_GRF(I2S0_8CH_MCLKOUT_TO_IO, "i2s0_8ch_mclkout_to_io", "i2s0_8ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
>
> GATE(HCLK_PDM1, "hclk_pdm1", "hclk_audio_root", 0,
> RK3588_CLKGATE_CON(9), 6, GFLAGS),
> @@ -2229,7 +2229,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> MUX(I2S1_8CH_MCLKOUT, "i2s1_8ch_mclkout", i2s1_8ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_PMU_CLKSEL_CON(9), 2, 2, MFLAGS),
> GATE_GRF(I2S1_8CH_MCLKOUT_TO_IO, "i2s1_8ch_mclkout_to_io", "i2s1_8ch_mclkout",
> - 0, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
> + CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
> GATE(PCLK_PMU1, "pclk_pmu1", "pclk_pmu0_root", CLK_IS_CRITICAL,
> RK3588_PMU_CLKGATE_CON(1), 0, GFLAGS),
> GATE(CLK_DDR_FAIL_SAFE, "clk_ddr_fail_safe", "clk_pmu0", CLK_IGNORE_UNUSED,
>
> base-commit: 7edfb7fb58ee058298e18fde76a6077ef17d19d8
> --
> 2.47.3
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v15 03/11] arm64/ptrace: Use syscall_get_nr() helper for syscall_trace_enter()
From: Ada Couprie Diaz @ 2026-06-24 13:42 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-4-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Use syscall_get_nr() to get syscall number for syscall_trace_enter().
> This aligns arm64's internal tracing logic with the generic
> entry framework.
>
> [Changes]
> 1. Use syscall_get_nr() helper:
> - Replace direct regs->syscallno access with
> syscall_get_nr(current, regs).
> - This helper is functionally equivalent to direct access on arm64.
>
> 2. Re-read syscall number after tracepoint:
> - Re-fetch the syscall number after trace_sys_enter() as it may have
> been modified by BPF or ftrace probes, matching generic entry behavior.
>
> [Why this matters]
> - Aligns arm64 with the generic entry interface.
> - Makes future migration to generic entry framework.
This is missing what it makes the future migration . Easier, possible ?
(Same in patch 02, but I missed it !)
> - Properly handles syscall number modifications by tracers.
> - Uses standard architecture-independent helpers.
>
> No functional changes intended.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Otherwise,
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v15 02/11] arm64/ptrace: Refactor syscall_trace_enter/exit() to accept flags parameter
From: Ada Couprie Diaz @ 2026-06-24 13:38 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-3-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor syscall_trace_enter() and syscall_trace_exit() to move thread
> flag reading to the caller. This aligns arm64's syscall trace enter/exit
> function signature with generic entry framework.
>
> [Changes]
> 1. Function signature changes:
> - syscall_trace_enter(regs) → syscall_trace_enter(regs, flags)
> - syscall_trace_exit(regs) → syscall_trace_exit(regs, flags)
>
> 2. Move flags reading to caller:
> - Previously: read_thread_flags() called inside each function.
> - Now: caller (like el0_svc_common) passes flags as parameter.
>
> 3. Update syscall.c:
> - el0_svc_common() now passes flags to tracing functions and
> re-fetches flags before entry/exit to handle potential TIF
> updates.
>
> [Why this matters]
> - Aligns arm64 with the generic entry interface.
> - Makes future migration to generic entry framework.
>
> No functional changes intended.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
I was a bit confused with some parts, but those changes were made to align
exactly on the generic entry code, so makes sense !
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v15 01/11] entry: Fix potential syscall truncation in syscall_trace_enter()
From: Ada Couprie Diaz @ 2026-06-24 13:34 UTC (permalink / raw)
To: Jinjie Ruan
Cc: mark.rutland, peterz, catalin.marinas, ldv, song, will, kees,
thuth, ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan,
broonie, luto, linux-arm-kernel, wad, yeoreum.yun, oleg,
linux-kernel, james.morse, tglx, liqiang01, linusw
In-Reply-To: <20260511092103.1974980-2-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> In syscall_trace_enter(), the current logic returns "ret ? : syscall".
> While __secure_computing() currently only returns 0 (allow) or -1 (kill),
> this "ret ? : syscall" pattern is conceptually flawed.
>
> If __secure_computing() were to return a non-zero value that isn't -1, it
> would unintentionally override the actual system call number. This logic
> is redundant because if seccomp denies the syscall, the execution path
> should already be handled by the caller based on the error return, rather
> than conflating the return code with the syscall number.
>
> Fix it by explicitly returning the syscall number. This ensures
> the syscall register remains untainted by the trace return values and
> aligns with the expectation that seccomp-related interceptions are
> handled via the -1 return status.
>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Konrad Dybcio @ 2026-06-24 13:28 UTC (permalink / raw)
To: Esteban Urrutia, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <b3541802-3035-40ee-8327-a65bd5d2dfee@proton.me>
On 6/24/26 3:26 PM, Esteban Urrutia wrote:
>
>
> On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>>> This is mentioned in the memory map description, but is not part
>>> of it.
>>>
>>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>>> probably valid
>>
>> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
>> trapping it.
> Then, should device trees delete these memory regions on a case-by-case
> basis, or be left as is?
I'd delete it and reintroduce as necessary
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Konrad Dybcio @ 2026-06-24 13:27 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260624-fix-tracenoc-probe-issue-v2-2-786520f62f21@oss.qualcomm.com>
On 6/24/26 11:49 AM, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
Why does it probe defer?
And is this required for all TNOC devices?
Konrad
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Esteban Urrutia @ 2026-06-24 13:26 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <6123a923-21dd-4f69-9ac5-02165963027c@oss.qualcomm.com>
On 6/23/26 7:03 AM, Konrad Dybcio wrote:
>> This is mentioned in the memory map description, but is not part
>> of it.
>>
>> I booted up a 8450 HDK and it doesn't even have MTE, so it's
>> probably valid
>
> i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
> trapping it.
Then, should device trees delete these memory regions on a case-by-case
basis, or be left as is?
Regards,
Esteban
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-24 12:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-original-vigorous-mayfly-dfceac@quoll>
Hi Krzysztof,
> What does that mean? How UART can be accessible over PCI bus?
It's a Virtual UART. Internally, it's two FIFOs accessible via
8250-compatible register sets on both ends.
There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
are bridged over the PCI bus.
So, from the host, you can access the 8250 register set on the PCI bus.
> > + aspeed,vuart-over-pci:
> > + type: boolean
> > + default: false
>
> There is no such syntax. Please do not introduce own style. Instead,
> look at other files how this is done.
Ack. I will remove 'default: false' for the v4.
> > + description: |
>
> Do not need '|' unless you need to preserve formatting.
Acknowledged
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: renesas: div6: Use ZT/ZTR trace clock in R-Mobile APE6 example
From: Rob Herring @ 2026-06-24 13:10 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Brian Masney, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260523192622.56605-1-marek.vasut+renesas@mailbox.org>
On Sat, May 23, 2026 at 09:25:50PM +0200, Marek Vasut wrote:
> Since commit 2abdc3dcf978 ("dt-bindings: clock: renesas,cpg-clocks:
> Document ZT/ZTR trace clock on R-Mobile APE6"), the APE6 clock node
> expects two additional "clock-output-names" entries, "zt" and "ztr".
> Update the example accordingly.
>
> Fixes: 2abdc3dcf978 ("dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile APE6")
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Applied for rc1.
Rob
^ permalink raw reply
* Re: [PATCH 30/37] drm/bridge: add drm_bridge_is_tail() to know whether a bridge completes the pipeline
From: Maxime Ripard @ 2026-06-24 13:04 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJ4DGYZ3GQZH.3AZOC0Z69W92S@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 4107 bytes --]
On Tue, Jun 09, 2026 at 10:23:24AM +0200, Luca Ceresoli wrote:
> Hi Maxime,
>
> thanks for the review of this long series!
>
> On Mon Jun 8, 2026 at 2:34 PM CEST, Maxime Ripard wrote:
> ...
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -78,6 +78,19 @@ struct drm_bridge_funcs {
> >> int (*attach)(struct drm_bridge *bridge, struct drm_encoder *encoder,
> >> enum drm_bridge_attach_flags flags);
> >>
> >> + /**
> >> + * @is_tail:
> >> + *
> >> + * Returns true if this is a tail bridge, i.e. it does not need a
> >> + * next bridge to work. E.g. a panel_bridge is a tail bridge, a
> >> + * DSI-to-LVDS bridge is not a tail bridge (no matter whether the
> >> + * next bridge is present or not).
> >
> > Why a DSI-to-LDVS bridge isn't a tail bridge? It only needs a panel
> > next, right?
>
> Uhm, good point, but I'd say it can be a tail bridge or not: in the
> ATTACH_NO_CONNECTOR case it will need a bridge (a panel_bridge most
> likely), no?
Yeah, I think it cannot (always) be a blanket statement from the driver.
For drivers that do not support ATTACH_NO_CONNECTOR, then it's always
going to be a tail, but if the driver supports it, we should use a
helper because it's going to depend on the DT, basically.
> However this is possibly irrelevant as the whole .is_tail is meant to
> disappear in v2, see below.
>
> >> + * The @is_tail callback is optional but it is required if the
> >> + * bridge is part of a pipeline with hot-pluggable components.
> >> + */
> >> + bool (*is_tail)(struct drm_bridge *bridge);
> >> +
> >
> > I don't think that's the right way to think about it, if only because
> > you never really know at the driver level if you're supposed to be last
> > or not. A DSI-to-LVDS bridge might just as well be chained with an
> > LVDS-to-eDP bridge, or feed the panel directly without any additional
> > bridge.
> >
> > I *think* that what you're trying to find out here is whether the chain
> > is complete or not.
>
> You nailed it.
>
> That was the main point discussed during the Display Next Hackfest 2026
> (see the report [0]) and we all agreed the .is_tail along with the
> -EPROBE_DEFER changes (patches 20+35) are not a good approach.
>
> This is actually the most crucial aspect of the whole work still not having
> no well-defined solution.
Ok
> > I think you can get the same information by checking
> > whether you have a connector for that bridge chain. If you don't, you
> > know the chain isn't complete, and if you do, it's supposed to be.
>
> There's a checken-egg problem here. Knowing whether the pipeline is
> complete or not is needed to know whether we have to create a
> connector. See patch 36:
>
> + if (drm_bridge_connector_pipeline_is_complete(bridge_connector))
> + drm_bridge_connector_add_connector(bridge_connector);
>
> So the question is still open, what I need the most right now is comments
> on the overall architecture of this aspecs. Maybe replying to [0] can be
> more effective than here.
>
> In a nutshell what we need is:
>
> * when a bridge needs a following element (a bridge, or a panel which
> however might/should have a panel_bridge), but that element is not
> present, instead of deferring the whole card probe the card should be
> allowed to probe but without a connector
>
> * when something is added to an incomplete pipeline we need to know
> whether the pipeline has become complete (in order to create the
> connector)
>
> How to implement this is still an open point. I'll welcome proposals in
> addition to the ones in [0].
Thanks for the notes, I think I largely agree with the discussion.
Reading through it, I thought it would be nice for a new callback called
get_next_bridge or something that would return either an error, NULL or a
(refcounted) pointer to the next bridge in the chain. And have some kind
of special error (ENODEV?) when the bridge should be there but isn't
(and thus the chain isn't complete).
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v9 04/12] reset: realtek: Add RTD1625-ISO reset controller driver
From: Philipp Zabel @ 2026-06-24 13:03 UTC (permalink / raw)
To: Yu-Chun Lin, mturquette, sboyd, robh, krzk+dt, conor+dt, cylee12,
afaerber, jyanchou, bmasney
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang
In-Reply-To: <20260624112940.3475605-5-eleanor.lin@realtek.com>
On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> From: Cheng-Yu Lee <cylee12@realtek.com>
>
> Add support for the ISO (Isolation) domain reset controller on the Realtek
> RTD1625 SoC.
>
> The reset controller shares the same register space with the ISO clock
> controller. To handle this shared register space, the reset driver is
> implemented as an auxiliary driver. It will be instantiated and probed via
> the auxiliary bus by the RTD1625-ISO clock controller driver.
>
> Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> Changes in v9:
> - Extract reset-related code from the previous clock driver patch
> (formerly patch 9 in v8).
> ---
> drivers/reset/realtek/Makefile | 2 +-
> drivers/reset/realtek/reset-rtd1625-iso.c | 99 +++++++++++++++++++++++
> 2 files changed, 100 insertions(+), 1 deletion(-)
> create mode 100644 drivers/reset/realtek/reset-rtd1625-iso.c
>
> diff --git a/drivers/reset/realtek/Makefile b/drivers/reset/realtek/Makefile
> index c3f605ffb11c..9007c9d5683b 100644
> --- a/drivers/reset/realtek/Makefile
> +++ b/drivers/reset/realtek/Makefile
> @@ -1,3 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_RESET_RTK_COMMON) += reset-rtk-common.o
> -obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> +obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o reset-rtd1625-iso.o
Is there any benefit to these two being separate modules?
I suggest you merge them into one: reset-rtd1625.o
> diff --git a/drivers/reset/realtek/reset-rtd1625-iso.c b/drivers/reset/realtek/reset-rtd1625-iso.c
> new file mode 100644
> index 000000000000..78eaabb408f0
> --- /dev/null
> +++ b/drivers/reset/realtek/reset-rtd1625-iso.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Realtek Semiconductor Corporation
> + */
> +
> +#include <dt-bindings/reset/realtek,rtd1625.h>
> +#include <linux/auxiliary_bus.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include "reset-rtk-common.h"
> +
> +#define RTD1625_ISO_RSTN_MAX 29
> +#define RTD1625_ISO_S_RSTN_MAX 5
These are not necessary, just use ARRAY_SIZE() for nr_resets.
> +
> +static const struct rtk_reset_desc rtd1625_iso_reset_descs[] = {
> + [RTD1625_ISO_RSTN_VFD] = { .ofs = 0x88, .bit = 0 },
> + [RTD1625_ISO_RSTN_CEC0] = { .ofs = 0x88, .bit = 2 },
> + [RTD1625_ISO_RSTN_CEC1] = { .ofs = 0x88, .bit = 3 },
> + [RTD1625_ISO_RSTN_CBUSTX] = { .ofs = 0x88, .bit = 5 },
> + [RTD1625_ISO_RSTN_CBUSRX] = { .ofs = 0x88, .bit = 6 },
> + [RTD1625_ISO_RSTN_USB3_PHY2_XTAL_POW] = { .ofs = 0x88, .bit = 7 },
> + [RTD1625_ISO_RSTN_UR0] = { .ofs = 0x88, .bit = 8 },
> + [RTD1625_ISO_RSTN_GMAC] = { .ofs = 0x88, .bit = 9 },
> + [RTD1625_ISO_RSTN_GPHY] = { .ofs = 0x88, .bit = 10 },
> + [RTD1625_ISO_RSTN_I2C_0] = { .ofs = 0x88, .bit = 11 },
> + [RTD1625_ISO_RSTN_I2C_1] = { .ofs = 0x88, .bit = 12 },
> + [RTD1625_ISO_RSTN_CBUS] = { .ofs = 0x88, .bit = 13 },
> + [RTD1625_ISO_RSTN_USB_DRD] = { .ofs = 0x88, .bit = 14 },
> + [RTD1625_ISO_RSTN_USB_HOST] = { .ofs = 0x88, .bit = 15 },
> + [RTD1625_ISO_RSTN_USB_PHY_0] = { .ofs = 0x88, .bit = 16 },
> + [RTD1625_ISO_RSTN_USB_PHY_1] = { .ofs = 0x88, .bit = 17 },
> + [RTD1625_ISO_RSTN_USB_PHY_2] = { .ofs = 0x88, .bit = 18 },
> + [RTD1625_ISO_RSTN_USB] = { .ofs = 0x88, .bit = 19 },
> + [RTD1625_ISO_RSTN_TYPE_C] = { .ofs = 0x88, .bit = 20 },
> + [RTD1625_ISO_RSTN_USB_U3_HOST] = { .ofs = 0x88, .bit = 21 },
> + [RTD1625_ISO_RSTN_USB3_PHY0_POW] = { .ofs = 0x88, .bit = 22 },
> + [RTD1625_ISO_RSTN_USB3_P0_MDIO] = { .ofs = 0x88, .bit = 23 },
> + [RTD1625_ISO_RSTN_USB3_PHY1_POW] = { .ofs = 0x88, .bit = 24 },
> + [RTD1625_ISO_RSTN_USB3_P1_MDIO] = { .ofs = 0x88, .bit = 25 },
> + [RTD1625_ISO_RSTN_VTC] = { .ofs = 0x88, .bit = 26 },
> + [RTD1625_ISO_RSTN_USB3_PHY2_POW] = { .ofs = 0x88, .bit = 27 },
> + [RTD1625_ISO_RSTN_USB3_P2_MDIO] = { .ofs = 0x88, .bit = 28 },
> + [RTD1625_ISO_RSTN_USB_PHY_3] = { .ofs = 0x88, .bit = 29 },
> + [RTD1625_ISO_RSTN_USB_PHY_4] = { .ofs = 0x88, .bit = 30 },
> +};
> +
> +static const struct rtk_reset_desc rtd1625_iso_s_reset_descs[] = {
> + [RTD1625_ISO_S_RSTN_ISOM_MIS] = { .ofs = 0x310, .bit = 0, .write_en = 1 },
> + [RTD1625_ISO_S_RSTN_GPIOM] = { .ofs = 0x310, .bit = 2, .write_en = 1 },
> + [RTD1625_ISO_S_RSTN_TIMER7] = { .ofs = 0x310, .bit = 4, .write_en = 1 },
> + [RTD1625_ISO_S_RSTN_IRDA] = { .ofs = 0x310, .bit = 6, .write_en = 1 },
> + [RTD1625_ISO_S_RSTN_UR10] = { .ofs = 0x310, .bit = 8, .write_en = 1 },
> +};
> +
> +static int rtd1625_iso_reset_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
> + struct device *dev = &adev->dev;
> + struct device *parent = dev->parent;
> + struct rtk_reset_data *data;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + if (of_device_is_compatible(parent->of_node, "realtek,rtd1625-iso-s-clk")) {
> + data->descs = rtd1625_iso_s_reset_descs;
> + data->rcdev.nr_resets = RTD1625_ISO_S_RSTN_MAX;
> + } else {
> + data->descs = rtd1625_iso_reset_descs;
> + data->rcdev.nr_resets = RTD1625_ISO_RSTN_MAX;
> + }
No need to parse OF compatible again. Store these in a struct, point
auxiliary_device_id::driver_data to it, and use that here.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v9 02/12] reset: Add Realtek basic reset support
From: Philipp Zabel @ 2026-06-24 13:02 UTC (permalink / raw)
To: Yu-Chun Lin, mturquette, sboyd, robh, krzk+dt, conor+dt, cylee12,
afaerber, jyanchou, bmasney
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang
In-Reply-To: <20260624112940.3475605-3-eleanor.lin@realtek.com>
On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> From: Cheng-Yu Lee <cylee12@realtek.com>
>
> Define the reset operations backed by a regmap-based register interface
> and prepare the reset controller to be registered through the reset
> framework.
>
> Since the reset controllers on Realtek SoCs often share the same register
> space with the clock controllers, this common framework is designed to
> extract the regmap and device tree node from the parent device
> (e.g., an auxiliary device parent).
>
> Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> Changes in v8:
> - Rename common.[ch] to reset-rtk-common.[ch].
> ---
> MAINTAINERS | 1 +
> drivers/reset/Kconfig | 1 +
> drivers/reset/Makefile | 1 +
> drivers/reset/realtek/Kconfig | 8 +++
> drivers/reset/realtek/Makefile | 2 +
> drivers/reset/realtek/reset-rtk-common.c | 90 ++++++++++++++++++++++++
> drivers/reset/realtek/reset-rtk-common.h | 29 ++++++++
> 7 files changed, 132 insertions(+)
> create mode 100644 drivers/reset/realtek/Kconfig
> create mode 100644 drivers/reset/realtek/Makefile
> create mode 100644 drivers/reset/realtek/reset-rtk-common.c
> create mode 100644 drivers/reset/realtek/reset-rtk-common.h
>
[...]
> diff --git a/drivers/reset/realtek/reset-rtk-common.c b/drivers/reset/realtek/reset-rtk-common.c
> new file mode 100644
> index 000000000000..75b27cb2a208
> --- /dev/null
> +++ b/drivers/reset/realtek/reset-rtk-common.c
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2019-2026 Realtek Semiconductor Corporation
> + */
> +
> +#include <linux/device.h>
> +#include <linux/export.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regmap.h>
> +#include "reset-rtk-common.h"
> +
> +static inline struct rtk_reset_data *to_rtk_reset_controller(struct reset_controller_dev *r)
> +{
> + return container_of(r, struct rtk_reset_data, rcdev);
> +}
> +
> +static inline const struct rtk_reset_desc *rtk_reset_get_desc(struct rtk_reset_data *data,
> + unsigned long idx)
> +{
> + return &data->descs[idx];
> +}
> +
> +static int rtk_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> + const struct rtk_reset_desc *desc;
> + u32 mask, val;
> +
> + desc = rtk_reset_get_desc(data, idx);
> + mask = desc->write_en ? (0x3U << desc->bit) : BIT(desc->bit);
> + val = desc->write_en ? (0x2U << desc->bit) : 0;
> +
> + return regmap_update_bits(data->regmap, desc->ofs, mask, val);
> +}
> +
> +static int rtk_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> + const struct rtk_reset_desc *desc;
> + u32 mask, val;
> +
> + desc = rtk_reset_get_desc(data, idx);
> + mask = desc->write_en ? (0x3U << desc->bit) : BIT(desc->bit);
> + val = mask;
> +
> + return regmap_update_bits(data->regmap, desc->ofs, mask, val);
You can use regmap_set_bits() here.
> +}
> +
> +static int rtk_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> + const struct rtk_reset_desc *desc;
> + u32 val;
unsigned int val;
> + int ret;
> +
> + desc = rtk_reset_get_desc(data, idx);
> + ret = regmap_read(data->regmap, desc->ofs, &val);
> + if (ret)
> + return ret;
> +
> + return !((val >> desc->bit) & 1);
> +}
> +
> +static const struct reset_control_ops rtk_reset_ops = {
> + .assert = rtk_reset_assert,
> + .deassert = rtk_reset_deassert,
> + .status = rtk_reset_status,
> +};
> +
> +/* The caller must initialize data->descs, data->rcdev.nr_resets and
> + * data->rcdev.owner before calling rtk_reset_controller_add().
> + */
> +int rtk_reset_controller_add(struct device *dev,
> + struct rtk_reset_data *data)
> +{
> + data->regmap = dev_get_platdata(dev);
> + data->rcdev.ops = &rtk_reset_ops;
> + data->rcdev.dev = dev;
> + data->rcdev.of_node = dev->parent->of_node;
This split rcdev initialization is more hassle than it is worth.
Please just export rtk_reset_ops and duplicate the
regmap/ops/dev/of_node assignment in the probe functions.
Alternatively, consolidate the probe function and export it from here.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: serial: 8250: aspeed: add compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 12:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-realistic-spiked-parrot-db1d9c@quoll>
Hi Krzysztof,
> Do not attach (thread) your patchsets to some other threads (unrelated
> or older versions). This buries them deep in the mailbox and might
> interfere with applying entire sets. See also:
> https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
Oh okay sorry I missed this information. Thank's for letting me know !
> This should be oneOf (by convention and actually more accurate meaning).
Acknowledged
> More important, where is documenting of the actual compatible?
Yes, you are right, I missed it. Will be added in v4.
Best regards,
Grégoire
^ permalink raw reply
* [PATCH] clk: rockchip: rk3588: don't disable unused I2S MCLK output gates
From: Daniele Briguglio @ 2026-06-24 12:39 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Heiko Stuebner
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
Diederik de Haas, Nicolas Frattaroli, Ricardo Pardini
No in-tree board references these gates yet. Boards drive the codec
MCLK through the parent I2S*_8CH_MCLKOUT, and now that the gates are
managed clocks, clk_disable_unused() turns them off at boot. On a board
that relied on firmware leaving the output enabled, that cuts the MCLK
and analog audio stops working.
Mark the four gates CLK_IGNORE_UNUSED so an unreferenced gate keeps the
state firmware left. A board that wants the kernel to own the gate can
reference I2S*_8CH_MCLKOUT_TO_IO from DT instead.
Fixes: 02b9b0bb6269 ("clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO")
Reported-by: Diederik de Haas <diederik@cknow-tech.com>
Closes: https://lore.kernel.org/linux-rockchip/DJGDSS875DDO.22TYPVYK5X8KZ@cknow-tech.com/
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Signed-off-by: Daniele Briguglio <hello@superkali.me>
---
drivers/clk/rockchip/clk-rk3588.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c
index 2ba9976654c..86953f9ffee 100644
--- a/drivers/clk/rockchip/clk-rk3588.c
+++ b/drivers/clk/rockchip/clk-rk3588.c
@@ -895,7 +895,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
MUX(I2S2_2CH_MCLKOUT, "i2s2_2ch_mclkout", i2s2_2ch_mclkout_p, CLK_SET_RATE_PARENT,
RK3588_CLKSEL_CON(30), 2, 1, MFLAGS),
GATE_GRF(I2S2_2CH_MCLKOUT_TO_IO, "i2s2_2ch_mclkout_to_io", "i2s2_2ch_mclkout",
- 0, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
+ CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
COMPOSITE(CLK_I2S3_2CH_SRC, "clk_i2s3_2ch_src", gpll_aupll_p, 0,
RK3588_CLKSEL_CON(30), 8, 1, MFLAGS, 3, 5, DFLAGS,
@@ -912,7 +912,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
MUX(I2S3_2CH_MCLKOUT, "i2s3_2ch_mclkout", i2s3_2ch_mclkout_p, CLK_SET_RATE_PARENT,
RK3588_CLKSEL_CON(32), 2, 1, MFLAGS),
GATE_GRF(I2S3_2CH_MCLKOUT_TO_IO, "i2s3_2ch_mclkout_to_io", "i2s3_2ch_mclkout",
- 0, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
+ CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
GATE(PCLK_ACDCDIG, "pclk_acdcdig", "pclk_audio_root", 0,
RK3588_CLKGATE_CON(7), 11, GFLAGS),
GATE(HCLK_I2S0_8CH, "hclk_i2s0_8ch", "hclk_audio_root", 0,
@@ -942,7 +942,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
MUX(I2S0_8CH_MCLKOUT, "i2s0_8ch_mclkout", i2s0_8ch_mclkout_p, CLK_SET_RATE_PARENT,
RK3588_CLKSEL_CON(28), 2, 2, MFLAGS),
GATE_GRF(I2S0_8CH_MCLKOUT_TO_IO, "i2s0_8ch_mclkout_to_io", "i2s0_8ch_mclkout",
- 0, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
+ CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
GATE(HCLK_PDM1, "hclk_pdm1", "hclk_audio_root", 0,
RK3588_CLKGATE_CON(9), 6, GFLAGS),
@@ -2229,7 +2229,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
MUX(I2S1_8CH_MCLKOUT, "i2s1_8ch_mclkout", i2s1_8ch_mclkout_p, CLK_SET_RATE_PARENT,
RK3588_PMU_CLKSEL_CON(9), 2, 2, MFLAGS),
GATE_GRF(I2S1_8CH_MCLKOUT_TO_IO, "i2s1_8ch_mclkout_to_io", "i2s1_8ch_mclkout",
- 0, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
+ CLK_IGNORE_UNUSED, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
GATE(PCLK_PMU1, "pclk_pmu1", "pclk_pmu0_root", CLK_IS_CRITICAL,
RK3588_PMU_CLKGATE_CON(1), 0, GFLAGS),
GATE(CLK_DDR_FAIL_SAFE, "clk_ddr_fail_safe", "clk_pmu0", CLK_IGNORE_UNUSED,
base-commit: 7edfb7fb58ee058298e18fde76a6077ef17d19d8
--
2.47.3
^ permalink raw reply related
* [PATCH v9 01/12] dt-bindings: clock: Add Realtek RTD1625 Clock & Reset Controller
From: Yu-Chun Lin @ 2026-06-24 11:29 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou, bmasney
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin, Krzysztof Kozlowski
In-Reply-To: <20260624112940.3475605-1-eleanor.lin@realtek.com>
Add DT binding schema for Realtek RTD1625 clock and reset controller
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Co-developed-by: Cheng-Yu Lee <cylee12@realtek.com>
Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v8:
- None
---
.../bindings/clock/realtek,rtd1625-clk.yaml | 58 ++++++
MAINTAINERS | 10 +
.../dt-bindings/clock/realtek,rtd1625-clk.h | 164 +++++++++++++++++
include/dt-bindings/reset/realtek,rtd1625.h | 171 ++++++++++++++++++
4 files changed, 403 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
create mode 100644 include/dt-bindings/clock/realtek,rtd1625-clk.h
create mode 100644 include/dt-bindings/reset/realtek,rtd1625.h
diff --git a/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
new file mode 100644
index 000000000000..1aceef31e148
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/realtek,rtd1625-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTD1625 Clock & Reset Controller
+
+maintainers:
+ - Cheng-Yu Lee <cylee12@realtek.com>
+ - Yu-Chun Lin <eleanor.lin@realtek.com>
+
+description: |
+ The Realtek RTD1625 Clock Controller manages and distributes clock
+ signals to various controllers and implements a Reset Controller for the
+ SoC peripherals.
+
+ Clocks and resets are referenced by unique identifiers, which are defined as
+ preprocessor macros in include/dt-bindings/clock/realtek,rtd1625-clk.h and
+ include/dt-bindings/reset/realtek,rtd1625.h.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1625-crt-clk
+ - realtek,rtd1625-iso-clk
+ - realtek,rtd1625-iso-s-clk
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@98000000 {
+ compatible = "realtek,rtd1625-crt-clk";
+ reg = <0x98000000 0x1000>;
+ clocks = <&osc27m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ba45953bb805..d9df9b120e55 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22668,6 +22668,16 @@ S: Maintained
F: Documentation/devicetree/bindings/net/dsa/realtek.yaml
F: drivers/net/dsa/realtek/*
+REALTEK SOC CLOCK AND RESET DRIVERS
+M: Cheng-Yu Lee <cylee12@realtek.com>
+M: Yu-Chun Lin <eleanor.lin@realtek.com>
+L: devicetree@vger.kernel.org
+L: linux-clk@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/clock/realtek*
+F: include/dt-bindings/clock/realtek*
+F: include/dt-bindings/reset/realtek*
+
REALTEK SPI-NAND
M: Chris Packham <chris.packham@alliedtelesis.co.nz>
S: Maintained
diff --git a/include/dt-bindings/clock/realtek,rtd1625-clk.h b/include/dt-bindings/clock/realtek,rtd1625-clk.h
new file mode 100644
index 000000000000..61ca652d6880
--- /dev/null
+++ b/include/dt-bindings/clock/realtek,rtd1625-clk.h
@@ -0,0 +1,164 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2025 Realtek Semiconductor Corp.
+ */
+#ifndef __DT_BINDINGS_RTK_CLOCK_RTD1625_H
+#define __DT_BINDINGS_RTK_CLOCK_RTD1625_H
+
+#define RTD1625_CRT_CLK_EN_MISC 0
+#define RTD1625_CRT_CLK_EN_PCIE0 1
+#define RTD1625_CRT_CLK_EN_DIP 2
+#define RTD1625_CRT_CLK_EN_GSPI 3
+#define RTD1625_CRT_CLK_EN_ISO_MISC 5
+#define RTD1625_CRT_CLK_EN_SDS 6
+#define RTD1625_CRT_CLK_EN_HDMI 7
+#define RTD1625_CRT_CLK_EN_GPU 9
+#define RTD1625_CRT_CLK_EN_VE1 10
+#define RTD1625_CRT_CLK_EN_VE2 11
+#define RTD1625_CRT_CLK_EN_MD 18
+#define RTD1625_CRT_CLK_EN_TP 19
+#define RTD1625_CRT_CLK_EN_RCIC 20
+#define RTD1625_CRT_CLK_EN_NF 21
+#define RTD1625_CRT_CLK_EN_EMMC 22
+#define RTD1625_CRT_CLK_EN_SD 23
+#define RTD1625_CRT_CLK_EN_SDIO_IP 24
+#define RTD1625_CRT_CLK_EN_MIPI_CSI 25
+#define RTD1625_CRT_CLK_EN_EMMC_IP 26
+#define RTD1625_CRT_CLK_EN_SDIO 27
+#define RTD1625_CRT_CLK_EN_SD_IP 28
+#define RTD1625_CRT_CLK_EN_TPB 30
+#define RTD1625_CRT_CLK_EN_MISC_SC1 31
+#define RTD1625_CRT_CLK_EN_MISC_I2C_3 32
+#define RTD1625_CRT_CLK_EN_ACPU 33
+#define RTD1625_CRT_CLK_EN_JPEG 34
+#define RTD1625_CRT_CLK_EN_MISC_SC0 37
+#define RTD1625_CRT_CLK_EN_HDMIRX 45
+#define RTD1625_CRT_CLK_EN_HSE 46
+#define RTD1625_CRT_CLK_EN_FAN 49
+#define RTD1625_CRT_CLK_EN_SATA_WRAP_SYS 52
+#define RTD1625_CRT_CLK_EN_SATA_WRAP_SYSH 53
+#define RTD1625_CRT_CLK_EN_SATA_MAC_SYSH 54
+#define RTD1625_CRT_CLK_EN_R2RDSC 55
+#define RTD1625_CRT_CLK_EN_TPC 56
+#define RTD1625_CRT_CLK_EN_PCIE1 57
+#define RTD1625_CRT_CLK_EN_MISC_I2C_4 58
+#define RTD1625_CRT_CLK_EN_MISC_I2C_5 59
+#define RTD1625_CRT_CLK_EN_TSIO 60
+#define RTD1625_CRT_CLK_EN_VE4 61
+#define RTD1625_CRT_CLK_EN_EDP 62
+#define RTD1625_CRT_CLK_EN_TSIO_TRX 63
+#define RTD1625_CRT_CLK_EN_PCIE2 64
+#define RTD1625_CRT_CLK_EN_EARC 66
+#define RTD1625_CRT_CLK_EN_LITE 67
+#define RTD1625_CRT_CLK_EN_MIPI_DSI 68
+#define RTD1625_CRT_CLK_EN_NPUPP 69
+#define RTD1625_CRT_CLK_EN_NPU 70
+#define RTD1625_CRT_CLK_EN_AUCPU0 71
+#define RTD1625_CRT_CLK_EN_AUCPU1 72
+#define RTD1625_CRT_CLK_EN_NSRAM 73
+#define RTD1625_CRT_CLK_EN_HDMITOP 74
+#define RTD1625_CRT_CLK_EN_AUCPU_ISO_NPU 76
+#define RTD1625_CRT_CLK_EN_KEYLADDER 77
+#define RTD1625_CRT_CLK_EN_IFCP_KLM 78
+#define RTD1625_CRT_CLK_EN_IFCP 79
+#define RTD1625_CRT_CLK_EN_MDL_GENPW 80
+#define RTD1625_CRT_CLK_EN_MDL_CHIP 81
+#define RTD1625_CRT_CLK_EN_MDL_IP 82
+#define RTD1625_CRT_CLK_EN_MDLM2M 83
+#define RTD1625_CRT_CLK_EN_MDL_XTAL 84
+#define RTD1625_CRT_CLK_EN_TEST_MUX 85
+#define RTD1625_CRT_CLK_EN_DLA 86
+#define RTD1625_CRT_CLK_EN_TPCW 88
+#define RTD1625_CRT_CLK_EN_GPU_TS_SRC 89
+#define RTD1625_CRT_CLK_EN_VI 91
+#define RTD1625_CRT_CLK_EN_LVDS1 92
+#define RTD1625_CRT_CLK_EN_LVDS2 93
+#define RTD1625_CRT_CLK_EN_AUCPU 94
+#define RTD1625_CRT_CLK_EN_UR1 96
+#define RTD1625_CRT_CLK_EN_UR2 97
+#define RTD1625_CRT_CLK_EN_UR3 98
+#define RTD1625_CRT_CLK_EN_UR4 99
+#define RTD1625_CRT_CLK_EN_UR5 100
+#define RTD1625_CRT_CLK_EN_UR6 101
+#define RTD1625_CRT_CLK_EN_UR7 102
+#define RTD1625_CRT_CLK_EN_UR8 103
+#define RTD1625_CRT_CLK_EN_UR9 104
+#define RTD1625_CRT_CLK_EN_UR_TOP 105
+#define RTD1625_CRT_CLK_EN_MISC_I2C_7 110
+#define RTD1625_CRT_CLK_EN_MISC_I2C_6 111
+#define RTD1625_CRT_CLK_EN_SPI0 112
+#define RTD1625_CRT_CLK_EN_SPI1 113
+#define RTD1625_CRT_CLK_EN_SPI2 114
+#define RTD1625_CRT_CLK_EN_LSADC0 120
+#define RTD1625_CRT_CLK_EN_LSADC1 121
+#define RTD1625_CRT_CLK_EN_ISOMIS_DMA 122
+#define RTD1625_CRT_CLK_EN_DPTX 124
+#define RTD1625_CRT_CLK_EN_NPU_MIPI_CSI 125
+#define RTD1625_CRT_CLK_EN_EDPTX 126
+#define RTD1625_CRT_CLK_HIFI 128
+#define RTD1625_CRT_CLK_NPU_MIPI_CSI 129
+#define RTD1625_CRT_CLK_NPU 130
+#define RTD1625_CRT_CLK_NPU_SYSH 132
+#define RTD1625_CRT_CLK_HIFI_SCPU 133
+#define RTD1625_CRT_CLK_GPU 134
+#define RTD1625_CRT_CLK_GPU2D 135
+#define RTD1625_CRT_CLK_MIPI_DSI_PCLK 136
+#define RTD1625_CRT_CLK_VE1 137
+#define RTD1625_CRT_CLK_VE2 138
+#define RTD1625_CRT_CLK_VE4 139
+#define RTD1625_CRT_CLK_SYS 141
+#define RTD1625_CRT_CLK_SYSH 142
+#define RTD1625_CRT_PLL_SDIO_REF 145
+#define RTD1625_CRT_PLL_CR_REF 146
+#define RTD1625_CRT_PLL_EMMC_REF 147
+#define RTD1625_CRT_CLK_MIS_SC0 148
+#define RTD1625_CRT_CLK_MIS_SC1 149
+#define RTD1625_CRT_PLL_SCPU 150
+#define RTD1625_CRT_PLL_VE1 151
+#define RTD1625_CRT_PLL_DDSA 152
+#define RTD1625_CRT_PLL_PSAUDA1 153
+#define RTD1625_CRT_PLL_PSAUDA2 154
+#define RTD1625_CRT_PLL_BUS 155
+#define RTD1625_CRT_PLL_SDIO 156
+#define RTD1625_CRT_PLL_SDIO_VP0 157
+#define RTD1625_CRT_PLL_SDIO_VP1 158
+#define RTD1625_CRT_PLL_DCSB 159
+#define RTD1625_CRT_PLL_GPU 160
+#define RTD1625_CRT_PLL_NPU 161
+#define RTD1625_CRT_PLL_VE2 162
+#define RTD1625_CRT_PLL_HIFI 163
+#define RTD1625_CRT_PLL_SD 164
+#define RTD1625_CRT_PLL_SD_VP0 165
+#define RTD1625_CRT_PLL_SD_VP1 166
+#define RTD1625_CRT_PLL_EMMC 167
+#define RTD1625_CRT_PLL_EMMC_VP0 168
+#define RTD1625_CRT_PLL_EMMC_VP1 169
+#define RTD1625_CRT_PLL_ACPU 170
+#define RTD1625_CRT_CLK_DET 171
+
+#define RTD1625_ISO_CLK_EN_USB_P4 0
+#define RTD1625_ISO_CLK_EN_USB_P3 1
+#define RTD1625_ISO_CLK_EN_MISC_CEC0 2
+#define RTD1625_ISO_CLK_EN_CBUSRX_SYS 3
+#define RTD1625_ISO_CLK_EN_CBUSTX_SYS 4
+#define RTD1625_ISO_CLK_EN_CBUS_SYS 5
+#define RTD1625_ISO_CLK_EN_CBUS_OSC 6
+#define RTD1625_ISO_CLK_EN_MISC_UR0 8
+#define RTD1625_ISO_CLK_EN_I2C0 9
+#define RTD1625_ISO_CLK_EN_I2C1 10
+#define RTD1625_ISO_CLK_EN_ETN_250M 11
+#define RTD1625_ISO_CLK_EN_ETN_SYS 12
+#define RTD1625_ISO_CLK_EN_USB_DRD 13
+#define RTD1625_ISO_CLK_EN_USB_HOST 14
+#define RTD1625_ISO_CLK_EN_USB_U3_HOST 15
+#define RTD1625_ISO_CLK_EN_USB 16
+#define RTD1625_ISO_CLK_EN_VTC 17
+#define RTD1625_ISO_CLK_EN_MISC_VFD 18
+
+#define RTD1625_ISO_S_CLK_EN_ISOM_MIS 0
+#define RTD1625_ISO_S_CLK_EN_ISOM_GPIOM 1
+#define RTD1625_ISO_S_CLK_EN_TIMER7 2
+#define RTD1625_ISO_S_CLK_EN_IRDA 3
+#define RTD1625_ISO_S_CLK_EN_UR10 4
+
+#endif /* __DT_BINDINGS_RTK_CLOCK_RTD1625_H */
diff --git a/include/dt-bindings/reset/realtek,rtd1625.h b/include/dt-bindings/reset/realtek,rtd1625.h
new file mode 100644
index 000000000000..31e7fa66ef31
--- /dev/null
+++ b/include/dt-bindings/reset/realtek,rtd1625.h
@@ -0,0 +1,171 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2025 Realtek Semiconductor Corp.
+ */
+
+#ifndef __DT_BINDINGS_RTK_RESET_RTD1625_H
+#define __DT_BINDINGS_RTK_RESET_RTD1625_H
+
+#define RTD1625_CRT_RSTN_MISC 0
+#define RTD1625_CRT_RSTN_DIP 1
+#define RTD1625_CRT_RSTN_GSPI 2
+#define RTD1625_CRT_RSTN_SDS 3
+#define RTD1625_CRT_RSTN_SDS_REG 4
+#define RTD1625_CRT_RSTN_SDS_PHY 5
+#define RTD1625_CRT_RSTN_GPU2D 6
+#define RTD1625_CRT_RSTN_DC_PHY 7
+#define RTD1625_CRT_RSTN_DCPHY_CRT 8
+#define RTD1625_CRT_RSTN_LSADC 9
+#define RTD1625_CRT_RSTN_SE 10
+#define RTD1625_CRT_RSTN_DLA 11
+#define RTD1625_CRT_RSTN_JPEG 12
+#define RTD1625_CRT_RSTN_SD 13
+#define RTD1625_CRT_RSTN_SDIO 14
+#define RTD1625_CRT_RSTN_PCR_CNT 15
+#define RTD1625_CRT_RSTN_PCIE0_STITCH 16
+#define RTD1625_CRT_RSTN_PCIE0_PHY 17
+#define RTD1625_CRT_RSTN_PCIE0 18
+#define RTD1625_CRT_RSTN_PCIE0_CORE 19
+#define RTD1625_CRT_RSTN_PCIE0_POWER 20
+#define RTD1625_CRT_RSTN_PCIE0_NONSTICH 21
+#define RTD1625_CRT_RSTN_PCIE0_PHY_MDIO 22
+#define RTD1625_CRT_RSTN_PCIE0_SGMII_MDIO 23
+#define RTD1625_CRT_RSTN_VO2 24
+#define RTD1625_CRT_RSTN_MISC_SC0 25
+#define RTD1625_CRT_RSTN_MD 26
+#define RTD1625_CRT_RSTN_LVDS1 27
+#define RTD1625_CRT_RSTN_LVDS2 28
+#define RTD1625_CRT_RSTN_MISC_SC1 29
+#define RTD1625_CRT_RSTN_I2C_3 30
+#define RTD1625_CRT_RSTN_FAN 31
+#define RTD1625_CRT_RSTN_TVE 32
+#define RTD1625_CRT_RSTN_AIO 33
+#define RTD1625_CRT_RSTN_VO 34
+#define RTD1625_CRT_RSTN_MIPI_CSI 35
+#define RTD1625_CRT_RSTN_HDMIRX 36
+#define RTD1625_CRT_RSTN_HDMIRX_WRAP 37
+#define RTD1625_CRT_RSTN_HDMI 38
+#define RTD1625_CRT_RSTN_DISP 39
+#define RTD1625_CRT_RSTN_SATA_PHY_POW1 40
+#define RTD1625_CRT_RSTN_SATA_PHY_POW0 41
+#define RTD1625_CRT_RSTN_SATA_MDIO1 42
+#define RTD1625_CRT_RSTN_SATA_MDIO0 43
+#define RTD1625_CRT_RSTN_SATA_WRAP 44
+#define RTD1625_CRT_RSTN_SATA_MAC_P1 45
+#define RTD1625_CRT_RSTN_SATA_MAC_P0 46
+#define RTD1625_CRT_RSTN_SATA_MAC_COM 47
+#define RTD1625_CRT_RSTN_PCIE1_STITCH 48
+#define RTD1625_CRT_RSTN_PCIE1_PHY 49
+#define RTD1625_CRT_RSTN_PCIE1 50
+#define RTD1625_CRT_RSTN_PCIE1_CORE 51
+#define RTD1625_CRT_RSTN_PCIE1_POWER 52
+#define RTD1625_CRT_RSTN_PCIE1_NONSTICH 53
+#define RTD1625_CRT_RSTN_PCIE1_PHY_MDIO 54
+#define RTD1625_CRT_RSTN_HDMITOP 55
+#define RTD1625_CRT_RSTN_I2C_4 56
+#define RTD1625_CRT_RSTN_I2C_5 57
+#define RTD1625_CRT_RSTN_TSIO 58
+#define RTD1625_CRT_RSTN_VI 59
+#define RTD1625_CRT_RSTN_EDP 60
+#define RTD1625_CRT_RSTN_VE1_MMU 61
+#define RTD1625_CRT_RSTN_VE1_MMU_FUNC 62
+#define RTD1625_CRT_RSTN_HSE_MMU 63
+#define RTD1625_CRT_RSTN_HSE_MMU_FUNC 64
+#define RTD1625_CRT_RSTN_MDLM2M 65
+#define RTD1625_CRT_RSTN_ISO_GSPI 66
+#define RTD1625_CRT_RSTN_SOFT_NPU 67
+#define RTD1625_CRT_RSTN_SPI2EMMC 68
+#define RTD1625_CRT_RSTN_EARC 69
+#define RTD1625_CRT_RSTN_VE1 70
+#define RTD1625_CRT_RSTN_PCIE2_STITCH 71
+#define RTD1625_CRT_RSTN_PCIE2_PHY 72
+#define RTD1625_CRT_RSTN_PCIE2 73
+#define RTD1625_CRT_RSTN_PCIE2_CORE 74
+#define RTD1625_CRT_RSTN_PCIE2_POWER 75
+#define RTD1625_CRT_RSTN_PCIE2_NONSTICH 76
+#define RTD1625_CRT_RSTN_PCIE2_PHY_MDIO 77
+#define RTD1625_CRT_RSTN_DCPHY_UMCTL2 78
+#define RTD1625_CRT_RSTN_MIPI_DSI 79
+#define RTD1625_CRT_RSTN_HIFM 80
+#define RTD1625_CRT_RSTN_NSRAM 81
+#define RTD1625_CRT_RSTN_AUCPU0_REG 82
+#define RTD1625_CRT_RSTN_MDL_GENPW 83
+#define RTD1625_CRT_RSTN_MDL_CHIP 84
+#define RTD1625_CRT_RSTN_MDL_IP 85
+#define RTD1625_CRT_RSTN_TEST_MUX 86
+#define RTD1625_CRT_RSTN_ISO_BIST 87
+#define RTD1625_CRT_RSTN_MAIN_BIST 88
+#define RTD1625_CRT_RSTN_MAIN2_BIST 89
+#define RTD1625_CRT_RSTN_VE1_BIST 90
+#define RTD1625_CRT_RSTN_VE2_BIST 91
+#define RTD1625_CRT_RSTN_DCPHY_BIST 92
+#define RTD1625_CRT_RSTN_GPU_BIST 93
+#define RTD1625_CRT_RSTN_DISP_BIST 94
+#define RTD1625_CRT_RSTN_NPU_BIST 95
+#define RTD1625_CRT_RSTN_CAS_BIST 96
+#define RTD1625_CRT_RSTN_VE4_BIST 97
+#define RTD1625_CRT_RSTN_EMMC 98
+#define RTD1625_CRT_RSTN_GPU 99
+#define RTD1625_CRT_RSTN_VE2 100
+#define RTD1625_CRT_RSTN_UR1 101
+#define RTD1625_CRT_RSTN_UR2 102
+#define RTD1625_CRT_RSTN_UR3 103
+#define RTD1625_CRT_RSTN_UR4 104
+#define RTD1625_CRT_RSTN_UR5 105
+#define RTD1625_CRT_RSTN_UR6 106
+#define RTD1625_CRT_RSTN_UR7 107
+#define RTD1625_CRT_RSTN_UR8 108
+#define RTD1625_CRT_RSTN_UR9 109
+#define RTD1625_CRT_RSTN_UR_TOP 110
+#define RTD1625_CRT_RSTN_I2C_7 111
+#define RTD1625_CRT_RSTN_I2C_6 112
+#define RTD1625_CRT_RSTN_SPI0 113
+#define RTD1625_CRT_RSTN_SPI1 114
+#define RTD1625_CRT_RSTN_SPI2 115
+#define RTD1625_CRT_RSTN_LSADC0 116
+#define RTD1625_CRT_RSTN_LSADC1 117
+#define RTD1625_CRT_RSTN_ISOMIS_DMA 118
+#define RTD1625_CRT_RSTN_AUDIO_ADC 119
+#define RTD1625_CRT_RSTN_DPTX 120
+#define RTD1625_CRT_RSTN_AUCPU1_REG 121
+#define RTD1625_CRT_RSTN_EDPTX 122
+
+/* ISO reset */
+#define RTD1625_ISO_RSTN_VFD 0
+#define RTD1625_ISO_RSTN_CEC0 1
+#define RTD1625_ISO_RSTN_CEC1 2
+#define RTD1625_ISO_RSTN_CBUSTX 3
+#define RTD1625_ISO_RSTN_CBUSRX 4
+#define RTD1625_ISO_RSTN_USB3_PHY2_XTAL_POW 5
+#define RTD1625_ISO_RSTN_UR0 6
+#define RTD1625_ISO_RSTN_GMAC 7
+#define RTD1625_ISO_RSTN_GPHY 8
+#define RTD1625_ISO_RSTN_I2C_0 9
+#define RTD1625_ISO_RSTN_I2C_1 10
+#define RTD1625_ISO_RSTN_CBUS 11
+#define RTD1625_ISO_RSTN_USB_DRD 12
+#define RTD1625_ISO_RSTN_USB_HOST 13
+#define RTD1625_ISO_RSTN_USB_PHY_0 14
+#define RTD1625_ISO_RSTN_USB_PHY_1 15
+#define RTD1625_ISO_RSTN_USB_PHY_2 16
+#define RTD1625_ISO_RSTN_USB 17
+#define RTD1625_ISO_RSTN_TYPE_C 18
+#define RTD1625_ISO_RSTN_USB_U3_HOST 19
+#define RTD1625_ISO_RSTN_USB3_PHY0_POW 20
+#define RTD1625_ISO_RSTN_USB3_P0_MDIO 21
+#define RTD1625_ISO_RSTN_USB3_PHY1_POW 22
+#define RTD1625_ISO_RSTN_USB3_P1_MDIO 23
+#define RTD1625_ISO_RSTN_VTC 24
+#define RTD1625_ISO_RSTN_USB3_PHY2_POW 25
+#define RTD1625_ISO_RSTN_USB3_P2_MDIO 26
+#define RTD1625_ISO_RSTN_USB_PHY_3 27
+#define RTD1625_ISO_RSTN_USB_PHY_4 28
+
+/* ISO_S reset */
+#define RTD1625_ISO_S_RSTN_ISOM_MIS 0
+#define RTD1625_ISO_S_RSTN_GPIOM 1
+#define RTD1625_ISO_S_RSTN_TIMER7 2
+#define RTD1625_ISO_S_RSTN_IRDA 3
+#define RTD1625_ISO_S_RSTN_UR10 4
+
+#endif /* __DT_BINDINGS_RTK_RESET_RTD1625_H */
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v7 3/4] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-06-24 12:35 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
Aksh Garg, linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <slfaxyt6p5mwsqmxvmriy6npilpjhjxv5ruegj4hnivj6zufkl@o6adjy5jmzfy>
[-- Attachment #1: Type: text/plain, Size: 8181 bytes --]
On Thu, Jun 18, 2026 at 09:26:33AM +0200, Manivannan Sadhasivam wrote:
> On Wed, Jun 17, 2026 at 06:01:30PM +0200, Thierry Reding wrote:
[...]
> > +static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
> > +{
> > + struct device *dev = pcie->dev;
> > + int err;
> > +
> > + pcie->wake_gpio = devm_gpiod_get_optional(dev, "wake", GPIOD_IN);
> > + if (IS_ERR(pcie->wake_gpio))
> > + return PTR_ERR(pcie->wake_gpio);
> > +
> > + if (!pcie->wake_gpio)
> > + return 0;
> > +
> > + err = gpiod_to_irq(pcie->wake_gpio);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to get wake IRQ\n");
> > +
> > + pcie->wake_irq = (unsigned int)err;
> > +
> > + err = devm_device_init_wakeup(dev);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to initialize wakeup\n");
> > +
> > + err = devm_pm_set_wake_irq(dev, pcie->wake_irq);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to set wakeup IRQ\n");
> > +
>
> I'd really like to get rid of custom WAKE# handling in the controller drivers.
> Krishna is trying to add generic WAKE# handling in the PCI core and I'd suggest
> you to take a look at the patches:
> https://lore.kernel.org/linux-pci/20260511-wakeirq_support-v10-2-c10af9c9eb8c@oss.qualcomm.com/
>
> But this also means that you need to use switch to Root Port binding to move the
> Root Port properties out of the controller node. This is something we are
> mandating for the new controllers. Not a big change though...
>
> Reference:
>
> Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml#n80
Okay, let me look into it.
[...]
> > + err = devm_pm_runtime_set_active_enabled(dev);
>
> I belive this has to come after pm_runtime_get_sync() because at this point, the
> controller is not enabled.
Okay, I'll change that.
> > + if (err < 0) {
> > + dev_err_probe(dev, err, "failed to enable runtime PM\n");
> > + goto put_bpmp;
> > + }
> > +
> > + err = pm_runtime_get_sync(dev);
> > + if (err < 0) {
> > + dev_err_probe(dev, err, "failed to power on device\n");
> > + goto put_bpmp;
> > + }
> > +
> > + /* sanity check that programmed ranges match what's in DT */
> > + if (!tegra264_pcie_check_ranges(pdev)) {
> > + err = -EINVAL;
> > + goto put_pm;
> > + }
> > +
> > + pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> > + if (IS_ERR(pcie->cfg)) {
> > + err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> > + "failed to create ECAM\n");
> > + goto put_pm;
> > + }
> > +
> > + bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> > + bridge->sysdata = pcie->cfg;
> > + pcie->ecam = pcie->cfg->win;
> > +
> > + tegra264_pcie_init(pcie);
> > +
> > + if (!pcie->link_up)
> > + return 0;
>
> So not hotplug support? Also, you do not want the driver to error out? I'm
> wondering what's the use then?
Hotplug is supported via pciehp. We skip probing the host bridge if no
link was detected because there's simply nothing attached to the port,
otherwise the link would've come up.
pcie->link_up is slightly misleading because it actually means something
along the lines of "link could be up at some point", either during probe
or after some hotplug event later on. It is only ever false if there's
no link during probe and hotplug isn't supported at all.
> > +
> > + err = pci_host_probe(bridge);
> > + if (err < 0) {
> > + dev_err_probe(dev, err, "failed to register host\n");
> > + goto free_ecam;
> > + }
> > +
> > + return 0;
> > +
> > +free_ecam:
>
> Nit: Prefix 'err' for the labels.
I don't see any benefit of adding a prefix. Seems pretty redundant, but
I also don't feel too strongly about it, so I can add it.
> > + pci_ecam_free(pcie->cfg);
> > +put_pm:
> > + pm_runtime_put_sync(dev);
> > +put_bpmp:
> > + tegra_bpmp_put(pcie->bpmp);
> > +
> > + return err;
> > +}
> > +
> > +static void tegra264_pcie_remove(struct platform_device *pdev)
> > +{
> > + struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
> > +
> > + /*
> > + * If we undo tegra264_pcie_init() then link goes down and need
> > + * controller reset to bring up the link again. Remove intention is
> > + * to clean up the root bridge and re-enumerate during bind.
>
> But the controller will be consuming power even if PCIe is not used. Do you
> really want that? Can't tegra264_pcie_init() handle the initialization? I'm
> wondering how tegra264_pcie_deinit() in tegra264_pcie_suspend() works then.
I had to clarify this with the PCI team and they indicated that
tegra264_pcie_deinit() is actually useless and maybe even harmful. The
reason is that there's a processor on these boards (BPMP) that takes
care of power sequencing and it will automatically take the PCI links
to L2 on suspend and assert PERST#.
Another reason why we don't want to reset the entire controller is that
it is already set up during early boot by UEFI and the kernel driver
does not redo the entire initialization.
So yes, I think a little bit of power consumption is the compromise that
we will have to live with. In the bigger picture it's probably not going
to be noticeable in most cases, and given that these are embedded
platforms we'll likely see fixed configurations most of the time and the
case where we remove the PCIe host controller will not be common.
> > + */
> > + pci_lock_rescan_remove();
> > + pci_stop_root_bus(pcie->bridge->bus);
> > + pci_remove_root_bus(pcie->bridge->bus);
> > + pci_unlock_rescan_remove();
> > +
> > + pm_runtime_put_sync(&pdev->dev);
> > + tegra_bpmp_put(pcie->bpmp);
> > + pci_ecam_free(pcie->cfg);
> > +}
> > +
> > +static int tegra264_pcie_suspend(struct device *dev)
> > +{
> > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > + int err;
> > +
> > + tegra264_pcie_deinit(pcie);
> > +
> > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > + err = enable_irq_wake(pcie->wake_irq);
> > + if (err < 0)
> > + dev_err(dev, "failed to enable wake IRQ: %pe\n",
> > + ERR_PTR(err));
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int tegra264_pcie_resume(struct device *dev)
> > +{
> > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > + int err;
> > +
> > + err = pinctrl_pm_select_default_state(dev);
> > + if (err < 0)
> > + dev_err(dev, "failed to configure sideband pins: %pe\n",
> > + ERR_PTR(err));
>
> Please remind me if you justified this manual pinctrl handling before.
This is just regular pinctrl PM boilerplate. There's plenty of other
drivers where we do this, too. We want this because some of the pins
get configured to non-default states on boot/resume, so doing this
here ensures they are muxed correctly.
> > +
> > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > + err = disable_irq_wake(pcie->wake_irq);
> > + if (err < 0)
> > + dev_err(dev, "failed to disable wake IRQ: %pe\n",
> > + ERR_PTR(err));
> > + }
> > +
> > + if (pcie->link_up == false)
> > + return 0;
>
> How is this possible? If 'pcie->link_up' was 'false' during probe(), then it is
> going to stay until tegra264_pcie_init() is called below.
Yes, this keeps confusing me, too. The purpose of this is to skip
initialization if we've already determined during probe that there is
never going to be a link. link_up will be false if and only if there was
no link during probe and we don't expect there ever will be a link
because there is no hotplug support.
Maybe a different name for link_up could help here? maybe_link_up
perhaps? I don't know if that's any clearer, but I also couldn't come up
with a better name.
Or maybe we should split this into two booleans, since we're essentially
trying to use one boolean to track a tristate. What we want to know is
if a link is truly up and if the controller should be kept powered for
the case where hotplug is supported.
I suppose we could do:
bool link_up; /* track the link state */
bool supports_hotplug; /* track whether port is hotpluggable */
That would make the code a bit cleaner and easier to follow.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 18/37] drm/bridge: samsung-dsim: remove the panel_bridge on host_detach
From: Maxime Ripard @ 2026-06-24 12:26 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJ5EHSOPNQZH.22I96C6QXN9KJ@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5969 bytes --]
On Wed, Jun 10, 2026 at 03:24:10PM +0200, Luca Ceresoli wrote:
> On Mon Jun 8, 2026 at 1:53 PM CEST, Maxime Ripard wrote:
> > On Tue, May 19, 2026 at 12:37:35PM +0200, Luca Ceresoli wrote:
> >> In preparation for DRM bridge hot-plugging, we need to handle the dynamic
> >> lifetime of the following bridge in case the samsung-dsim is always present
> >> and the following bridge (next_bridge) is hot-unplugged.
> >>
> >> Based on the 'if (!IS_ERR(panel))' check in samsung_dsim_host_attach(), the
> >> next_bridge could be A) a panel bridge created by this driver via
> >> devm_drm_panel_bridge_add() or B) a pre-existing bridge obtained via
> >> of_drm_find_and_get_bridge().
> >>
> >> For case B) we need to put that reference when the next_bridge is removed,
> >> which is already handled by calling drm_bridge_clear_and_put() in
> >> samsung_dsim_host_detach() and in the samsung_dsim_host_attach() error
> >> management code.
> >>
> >> In case A) we additionally have to remove the panel bridge. Currently it is
> >> created by devm_drm_panel_bridge_add(), which adds two devm actions with
> >> the refcounted panel bridge:
> >>
> >> - drm_bridge_put_void() via devm_drm_bridge_alloc() on panel->dev
> >> - devm_drm_panel_bridge_release() via devm_drm_panel_bridge_add_typed()
> >> on the consumer device (samsung-dsim)
> >>
> >> The first action is OK: being tied to panel->dev it will happen when the
> >> panel is unplugged.
> >>
> >> The second action is bound to the consumer device, so the devm semantics is
> >> not useful here when introducing hotplug. Indeed we need to drop the
> >> next_bridge in samsung_dsim_host_detach() anyway, before the driver .remove
> >> function, in order to support {add, {attach, detach} x N, remove} hotplug
> >> event sequences.
> >>
> >> Thus move to the non-devm drm_panel_bridge_add() along with the matching
> >> drm_panel_bridge_remove(), so the lifetime of the panel-bridge is tied to
> >> the host_attach/host_detach cycle and not the whole samsung-dsim device
> >> lifetime.
> >>
> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> >>
> >> ---
> >>
> >> In a previous discussion with Maxime he mentioned a plan to make every
> >> drm_panel always have a wrapping bridge. With that done, all the code
> >> handling the panel and adding the panel_bridge would become useless here
> >> (and in many other places) and could be entirely removed. This patch is a
> >> temporary solution until that happens. The best pointer I could find to
> >> that discussion is [0], but there might be more recent material I could not
> >> find at the moment.
> >>
> >> [0] https://lore.kernel.org/lkml/20250218-faithful-white-magpie-da9ac9@houat/
> >> ---
> >> drivers/gpu/drm/bridge/samsung-dsim.c | 17 ++++++++++++++---
> >> include/drm/bridge/samsung-dsim.h | 2 ++
> >> 2 files changed, 16 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> >> index 5b799619e07e..2af287221e22 100644
> >> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >> @@ -1951,14 +1951,16 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
> >> if (!remote)
> >> return -ENODEV;
> >>
> >> + dsi->panel_bridge_added = false;
> >> panel = of_drm_find_panel(remote);
> >> if (!IS_ERR(panel)) {
> >> - next_bridge = devm_drm_panel_bridge_add(dev, panel);
> >> + next_bridge = drm_panel_bridge_add(panel);
> >> if (IS_ERR(next_bridge)) {
> >> ret = PTR_ERR(next_bridge);
> >> next_bridge = NULL; // Inhibit the cleanup action on an ERR_PTR
> >> } else {
> >> drm_bridge_get(next_bridge);
> >> + dsi->panel_bridge_added = true;
> >> }
> >> } else {
> >> next_bridge = of_drm_find_and_get_bridge(remote);
> >> @@ -1989,7 +1991,7 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
> >> if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO)) {
> >> ret = samsung_dsim_register_te_irq(dsi, &device->dev);
> >> if (ret)
> >> - goto err_remove_bridge;
> >> + goto err_remove_panel_bridge;
> >> }
> >>
> >> // The next bridge can be used by host_ops->attach
> >> @@ -2011,8 +2013,12 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
> >> drm_bridge_clear_and_put(&dsi->bridge.next_bridge);
> >> if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO))
> >> samsung_dsim_unregister_te_irq(dsi);
> >> -err_remove_bridge:
> >> +err_remove_panel_bridge:
> >> drm_bridge_remove(&dsi->bridge);
> >> + if (dsi->panel_bridge_added) {
> >> + drm_panel_bridge_remove(next_bridge);
> >> + dsi->panel_bridge_added = false;
> >> + }
> >
> > This is a pretty big abstraction leak. We don't want to have that in
> > everything driver. The removal path should be the same for both cases,
> > and it's not something the driver should take care of.
>
> Yes. The comment after the '---' separator was meant to discuss this
> concern:
>
> > In a previous discussion with Maxime he mentioned a plan to make every
> > drm_panel always have a wrapping bridge. With that done, all the code
> > handling the panel and adding the panel_bridge would become useless here
> > (and in many other places) and could be entirely removed. This patch is a
> > temporary solution until that happens. The best pointer I could find to
> > that discussion is [0], but there might be more recent material I could not
> > find at the moment.
>
> Do you have any update about that plan?
I think we're pretty much there. As of 7.2, all panels will use
devm_drm_panel_alloc. It should be fairly easy now to create a bridge
for them all in devm_drm_panel_alloc, and then call drm_bridge_add in
drm_panel_add.
It's also tangentially related to https://lore.kernel.org/ksummit/0fa2fb42-0714-49f7-ba43-22928e1dd488@linaro.org/
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Daniele Briguglio @ 2026-06-24 12:20 UTC (permalink / raw)
To: Heiko Stuebner, Diederik de Haas, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <2008560.6tgchFWduM@diego>
Hi Heiko,
> Care to send a patch for that change? :-)
Will do. I was only waiting for your call on the approach before sending,
so I'll get it out shortly.
Best regards,
Daniele
^ permalink raw reply
* Re: [PATCH 00/37] drm/bridge: Convert all bridges to atomic
From: Luca Ceresoli @ 2026-06-24 12:18 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
dri-devel, Sasha Finkelstein, Janne Grunau, asahi, Benson Leung,
Guenter Roeck, chrome-platform, Francesco Dolcini,
Peter Senna Tschudin, Ian Ray, Martyn Welch,
Manikandan Muralidharan, Dharma Balasubiramani, Russell King,
Inki Dae, Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski,
Alim Akhtar, linux-arm-kernel, linux-samsung-soc, Linus Walleij,
Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, linux-mediatek, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, freedreno, Tomi Valkeinen, Alain Volmat,
Raphael Gallais-Pou
In-Reply-To: <20260617-drm-all-atomic-bridges-v1-0-b63e6316166b@kernel.org>
On Wed Jun 17, 2026 at 12:14 PM CEST, Maxime Ripard wrote:
> Hi,
>
> Over the years, most of the bridges have been converted to atomic
> modesetting and hooks, but not all of them. This forces us to maintain
> two different code path in quite a few places, which is pretty
> bothersome. The switch to atomic modesetting for legacy bridges though
> is pretty trivial, and we don't have a lot of drivers still using the
> legacy path.
>
> This series converts all bridges to atomic modesetting and drops the
> legacy codepaths where relevant.
>
> Let me know what you think,
> Maxime
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Lovely cleanup!
Apart from what Laurent pointed out, it all LGTM. Instead of spamming with
an R-by on all patches except 37, I'll just wait for v2 to send a
full-series R-by in reply to the cover letter.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 00/12] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Will Deacon @ 2026-06-24 12:16 UTC (permalink / raw)
To: Jinjie Ruan
Cc: catalin.marinas, tsbogend, tglx, mingo, bp, dave.hansen, hpa,
peterz, kees, nathan, linusw, ojeda, david.kaplan, lukas.bulwahn,
ryan.roberts, maz, timothy.hayes, lpieralisi, thuth,
menglong8.dong, oupton, yeoreum.yun, miko.lenczewski, broonie,
kevin.brodsky, james.clark, yangyicong, tabba, osandov, arnd,
anshuman.khandual, david, akpm, ljs, dev.jain, yang,
chaitanyas.prakash, kprateek.nayak, chenl311, sshegde,
thorsten.blum, chang.seok.bae, tim.c.chen, x86, linux-kernel,
linux-arm-kernel, linux-mips
In-Reply-To: <20260624092537.2916971-1-ruanjinjie@huawei.com>
On Wed, Jun 24, 2026 at 05:25:25PM +0800, Jinjie Ruan wrote:
> Support for parallel secondary CPU bringup is already utilized by x86,
> MIPS, and RISC-V. This patch brings this capability to the arm64
> architecture.
>
> Introduce CONFIG_HOTPLUG_PARALLEL_SMT to avoid primary SMT threads
> to boot first constraint.
>
> And add a 'cpu' parameter to update_cpu_boot_status() to allow updating
> the boot status at a per-CPU granularity during parallel bringup.
>
> Rework the global `secondary_data` and `__early_cpu_boot_status` accessed
> during early boot into per-CPU arrays to allow secondary CPUs to boot
> in parallel.
>
> And reuse `__cpu_logical_map` array in the early boot code in head.S
> to resolve each secondary CPU's logical ID concurrently.
>
> This series includes a subset of the refactoring patches proposed
> by Will Deacon, with further adjustments.
Sheesh, Jinjie, what are you doing?
I said yesterday that I would dust off the old series after the merge
window:
https://lore.kernel.org/all/ajqYaklhIyvaNLlk@willie-the-truck/
"Please just give me a week or so to rebase my changes and send them out
for discussion"
but instead, you've posted patches from me that are missing a bunch of
fixes that need to be folded back in:
https://web.git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=cpu-hotplug&id=2d5b8df5d4e2bbc142e3b4f21cabbca96e3da79d
so now you're asking people to review incomplete patches from somebody
else.
Please just give me the time I asked for. If you want to help out in the
meantime, there are plenty of patches that need reviewing...
Will
^ permalink raw reply
* Re: [PATCH 5/7] soc: aspeed: Add eSPI flash channel support
From: Markus Elfring @ 2026-06-24 12:14 UTC (permalink / raw)
To: YH Chung, linux-aspeed, openbmc, linux-arm-kernel, devicetree,
Andrew Jeffery, Conor Dooley, Joel Stanley, Krzysztof Kozlowski,
Philipp Zabel, Rob Herring, Ryan Chen
Cc: LKML, Maciej Lawniczak
In-Reply-To: <20260313-upstream_espi-v1-5-9504428e1f43@aspeedtech.com>
…
> +++ b/drivers/soc/aspeed/espi/aspeed-espi.c
…
> +static void aspeed_espi_flash_rx_work(struct work_struct *work)
> +{
> + struct aspeed_espi_flash *flash = container_of(work, struct aspeed_espi_flash, rx_work);
> + struct aspeed_espi *espi = container_of(flash, struct aspeed_espi, flash);
> +
> + mutex_lock(&flash->tx_mtx);
> + aspeed_espi_flash_handle_lun(espi);
> + mutex_unlock(&flash->tx_mtx);
> +}
…
Under which circumstances would you become interested to apply a statement
like “guard(mutex)(&flash->tx_mtx);”?
https://elixir.bootlin.com/linux/v7.1.1/source/include/linux/mutex.h#L253
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 5/7] soc: aspeed: Add eSPI flash channel support
From: Markus Elfring @ 2026-06-24 12:02 UTC (permalink / raw)
To: YH Chung, linux-aspeed, openbmc, linux-arm-kernel, devicetree,
Andrew Jeffery, Conor Dooley, Joel Stanley, Krzysztof Kozlowski,
Philipp Zabel, Rob Herring, Ryan Chen
Cc: LKML, Maciej Lawniczak
In-Reply-To: <20260313-upstream_espi-v1-5-9504428e1f43@aspeedtech.com>
…
> +++ b/drivers/soc/aspeed/espi/aspeed-espi-comm.h
> @@ -0,0 +1,62 @@
…
> +/*
> + * eSPI cycle type encoding
> + *
> + * Section 5.1 Cycle Types and Packet Format,
> + * Intel eSPI Interface Base Specification, Rev 1.0, Jan. 2016.
> + */
> +#define ESPI_FLASH_READ 0x00
> +#define ESPI_FLASH_WRITE 0x01
> +#define ESPI_FLASH_ERASE 0x02
…
How do you think about to use an enumeration for such data?
https://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactically_similar_languages
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v6 9/9] arm64: dts: freescale: imx95: Add video codec node
From: Francesco Dolcini @ 2026-06-24 11:50 UTC (permalink / raw)
To: Nas Chung
Cc: mchehab, hverkuil, robh, krzk+dt, conor+dt, shawnguo, s.hauer,
linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, jackson.lee, lafley.kim, marek.vasut
In-Reply-To: <20260624072043.238-10-nas.chung@chipsnmedia.com>
On Wed, Jun 24, 2026 at 04:20:43PM +0900, Nas Chung wrote:
> Add the Chips and Media wave633 video codec node on IMX95 SoCs.
>
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> ---
> .../boot/dts/freescale/imx95-19x19-evk.dts | 11 ++++++
> arch/arm64/boot/dts/freescale/imx95.dtsi | 36 +++++++++++++++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
> index 041fd838fabb..7edd1c69966a 100644
> --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
> @@ -76,6 +76,11 @@ linux_cma: linux,cma {
> linux,cma-default;
> reusable;
> };
> +
> + vpu_boot: memory@a0000000 {
> + reg = <0 0xa0000000 0 0x100000>;
> + no-map;
> + };
> };
>
> flexcan1_phy: can-phy0 {
> @@ -1142,3 +1147,9 @@ &tpm6 {
> pinctrl-0 = <&pinctrl_tpm6>;
> status = "okay";
> };
> +
> +&vpu {
> + memory-region = <&vpu_boot>;
> + sram = <&sram1>;
Can the `sram` node moved to imx95.dtsi or not?
Francesco
^ 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