* Re: [PATCH 4/7] net: stmmac: dwmac-rk: Enable refout clock for RGMII
From: Andrew Lunn @ 2026-06-24 15:39 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-4-5aef608a3f64@gmail.com>
On Wed, Jun 24, 2026 at 04:44:41PM +0800, Yanan He wrote:
> Some Rockchip GMAC integrations use clk_mac_refout as an external PHY
> reference clock even when the MAC is configured for RGMII.
>
> RV1126 boards can route CLK_GMAC_ETHERNET_OUT to the external PHY as a
> 25 MHz reference clock. If the driver does not acquire and enable this
> clock in RGMII mode, the common clock framework may disable it as unused
> and the PHY can lose its reference clock.
>
> Enable the refout clock handling for RGMII in addition to RMII.
>
> Signed-off-by: Yanan He <grumpycat921013@gmail.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index 8d7042e68926..f6fdc0c5b475 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -1112,7 +1112,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
> bsp_priv->clk_enabled = false;
>
> bsp_priv->num_clks = ARRAY_SIZE(rk_clocks);
> - if (phy_iface == PHY_INTERFACE_MODE_RMII)
> + if (phy_iface == PHY_INTERFACE_MODE_RMII ||
> + phy_iface == PHY_INTERFACE_MODE_RGMII)
Apart from Heiko commenting that this patch is completely wrong, there
are 4 RGMII modes, not one. You should of used
phy_interface_mode_is_rgmii().
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 06/37] drm/display: bridge-connector: use a drm_bridge_connector internally, not a drm_connector
From: Luca Ceresoli @ 2026-06-24 15:39 UTC (permalink / raw)
To: Maxime Ripard, 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: <20260624-chicken-of-infinite-enthusiasm-8b0e3f@houat>
On Wed Jun 24, 2026 at 1:47 PM CEST, Maxime Ripard wrote:
> On Fri, Jun 12, 2026 at 02:57:39PM +0200, Luca Ceresoli wrote:
>> On Mon Jun 8, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
>> > On Tue, May 19, 2026 at 12:37:23PM +0200, Luca Ceresoli wrote:
>> >> Currently drm_bridge_connector_init() always returns the added connector or
>> >> errors out. When adding bridge hotplug the bridge-connector can be
>> >> successfully initialized without creating a connector, which can be added
>> >> later when the pipeline will be complete.
>> >>
>> >> For this the internal function drm_bridge_connector_add_connector() must be
>> >> able to return a valid drm_bridge_connector even without any drm_connector.
>> >>
>> >> In preparation to support bridge hotplug, change its return value to be the
>> >> same drm_bridge_connector pointer it gets as input, or a PTR_ERR.
>> >>
>> >> No functional changes, just changing an internal API.
>> >>
>> >> Note the return value could now become an int (0 or negative error) because
>> >> returning the same value received as input does not carry any added
>> >> value. However this would be change a lot of lines, so leave such change as
>> >> a future cleanup.
>> >
>> > You just created that function and changed "a lot of lines" already, so
>> > I'm not sure that argument holds.
>>
>> Do you refer to the previous patch?
>>
>> My comment is more about the following patches. It means I separated
>> changes moving code to a subfunction from changes to the the return value
>> in separate patches, so that each patch is trivial to review for
>> correctness.
>>
>> Makes sense?
>
> What confused me is that I took it as "I'm not going to do that work
> (yet?)". If you do it later on, I'd drop the "future cleanup" part, or
> rephrase it.
Ah, I see the issue. I really meant "this change [returning int] is done in
a following commit".
I guess I'll just drop the whole paragraph.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v15 11/11] arm64: Inline el0_svc_common()
From: Ada Couprie Diaz @ 2026-06-24 15:36 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-12-ruanjinjie@huawei.com>
On 11/05/2026 10:21, Jinjie Ruan wrote:
> After converting arm64 to Generic Entry framework, the compiler no longer
> inlines el0_svc_common() into its caller do_el0_svc(). This introduces
> a small but measurable overhead in the critical system call path.
>
> Manually forcing el0_svc_common() to be inlined restores the
> performance. Benchmarking with perf bench syscall basic on a
> Kunpeng 920 platform (based on v6.19-rc1) shows a ~1% performance
> uplift.
>
> Inlining this function reduces function prologue/epilogue overhead
> and allows for better compiler optimization in the hot system call
> dispatch path.
>
> | Metric | W/O this patch | With this patch | Change |
> | ---------- | -------------- | --------------- | --------- |
> | Total time | 2.195 [sec] | 2.171 [sec] | ↓1.1% |
> | usecs/op | 0.219575 | 0.217192 | ↓1.1% |
> | ops/sec | 4,554,260 | 4,604,225 | ↑1.1% |
>
> 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 v2] arm64: mm: Defer read-only remap of data/bss linear alias
From: Will Deacon @ 2026-06-24 15:35 UTC (permalink / raw)
To: linux-arm-kernel, Ard Biesheuvel
Cc: catalin.marinas, kernel-team, Will Deacon, linux-kernel,
Kevin Brodsky, Ard Biesheuvel, Fuad Tabba
In-Reply-To: <20260623202817.2225495-2-ardb+git@google.com>
On Tue, 23 Jun 2026 22:28:18 +0200, Ard Biesheuvel wrote:
> Since commit
>
> f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
>
> the linear alias of the .data and .bss regions is remapped read-only
> early during the boot. (Note that a subsequent patch to unmap this
> region entirely was reverted just before the v7.2 merge window, and will
> be brought back in an improved form for the v7.3 cycle)
>
> [...]
Applied to arm64 (for-next/core), thanks!
[1/1] arm64: mm: Defer read-only remap of data/bss linear alias
https://git.kernel.org/arm64/c/36fa5ffa6034
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH 15/37] drm/display: bridge-connector: allocate the connector dynamically
From: Luca Ceresoli @ 2026-06-24 15:34 UTC (permalink / raw)
To: Maxime Ripard, 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: <20260624-judicious-enigmatic-hippo-b13ffe@houat>
Hi Maxime,
thanks for the feedback.
On Wed Jun 24, 2026 at 1:48 PM CEST, Maxime Ripard wrote:
> On Fri, Jun 12, 2026 at 02:44:43PM +0200, Luca Ceresoli wrote:
>> On Mon Jun 8, 2026 at 1:46 PM CEST, Maxime Ripard wrote:
>> > On Tue, May 19, 2026 at 12:37:32PM +0200, Luca Ceresoli wrote:
>> >> Currently the drm_bridge_connector has an embedded drm_connector, so their
>> >> allocation lifetimes are tied to each other. This is insufficient to
>> >> support DRM bridge hotplugging, which requires the connector to be added
>> >> and removed dynamically at runtime multiple times based on hotplug/unplug
>> >> events while the drm_bridge_connector is persistent.
>> >>
>> >> Moreover the drm_connector is exposed to user space and thus an ongoing
>> >> operation (e.g. an ioctl) might last for an arbitrarily long time even
>> >> after the hardware gets removed. This means a new connector might have to
>> >> be added when the previous one is still referenced by user space.
>> >>
>> >> In preparation to handle hotplug, allocate the drm-connector dynamically,
>> >> to allow:
>> >>
>> >> * creating and destroying a connector multiple times during a single
>> >> drm_bridge_connector lifetime
>> >> * creating a new connector even though the previous one is still in use
>> >> and thus still refcounted and not yet freed
>> >>
>> >> This commit does not introduce the actions in the two bullets (it will
>> >> happen in a later commit), it only moves to dynamic APIs for connector
>> >> allocation and init.
>> >>
>> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> >
>> > I think this patch should be split in half, with the switch to using
>> > destroy first, and then the actual move to the dynamically allocated
>> > connector API.
>>
>> Is it doable? drm_connector_dynamic_init() mandates a .destroy callback,
>> drm_connector_init() forbids it.
>
> drmm_connector_init forbids it. drm_connector_init mandates it.
Something bogus in my reply, sorry. :)
So you mean splitting in:
* first patch: move from drmm_connector[_hdmi]_init() to
drm_connector[_hdmi]_init() and add a .destroy
* second patch: move from drm_connector[_hdmi]_init() to
drm_connector[_hdmi]_dynamic_init() +
drm_connector_dynamic_register/unregister()
?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v1] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Mark Brown @ 2026-06-24 12:01 UTC (permalink / raw)
To: Nicolas Frattaroli, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Uwe Kleine-König (The Capable Hub)
Cc: Heiko Stuebner, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624083708.254517-2-u.kleine-koenig@baylibre.com>
On Wed, 24 Jun 2026 10:37:07 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
https://git.kernel.org/broonie/sound/c/83d53eca7e55
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a 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.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v15 10/11] arm64: entry: Convert to generic entry
From: Ada Couprie Diaz @ 2026-06-24 15:32 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-11-ruanjinjie@huawei.com>
On 11/05/2026 10:21, Jinjie Ruan wrote:
> Implement the generic entry framework for arm64 to handle system call
> entry and exit. This follows the migration of x86, RISC-V, and LoongArch,
> consolidating architecture-specific syscall tracing and auditing into
> the common kernel entry infrastructure.
If I understand correctly, as Syscall User Dispatch is gated being
`CONFIG_GENERIC_ENTRY` only and handled via ptrace, this patch
effectively enables Syscall User Dispatch for arm64.
I think it would be great to mention it here explicitly !
>
> [Background]
> Arm64 has already adopted generic IRQ entry. Completing the conversion
> to the generic syscall entry framework reduces architectural divergence,
> simplifies maintenance, and allows arm64 to automatically benefit from
> improvements in the common entry code.
>
> [Changes]
>
> 1. Kconfig and Infrastructure:
> - Select GENERIC_ENTRY and remove GENERIC_IRQ_ENTRY (now implied).
>
> - Migrate struct thread_info to use the syscall_work field instead
> of TIF flags for syscall-related tasks.
>
> 2. Thread Info and Flags:
> - Remove definitions for TIF_SYSCALL_TRACE, TIF_SYSCALL_AUDIT,
> TIF_SYSCALL_TRACEPOINT, TIF_SECCOMP, and TIF_SYSCALL_EMU.
>
> - Replace _TIF_SYSCALL_WORK and _TIF_SYSCALL_EXIT_WORK with the
> generic SYSCALL_WORK bitmask.
>
> - Map single-step state to SYSCALL_EXIT_TRAP in debug-monitors.c.
>
> 3. Architecture-Specific Hooks (asm/entry-common.h):
> - Implement arch_ptrace_report_syscall_entry() and _exit() by
> porting the existing arm64 logic to the generic interface.
>
> - Add arch_syscall_is_vdso_sigreturn() to asm/syscall.h to
> support Syscall User Dispatch (SUD).
Related to the above : I feel this is missing an important information.
Given that SUD is only controlled by `CONFIG_GENERIC_ENTRY`,
converting to generic entry _requires_ supporting SUD, so we do it here.
I think this would be important to mention, as I otherwise felt like this
change did not belong in this patch.
General question that follows : does it make sense to require an arch
to support Syscall User Dispatch to be able to convert to generic entry ?
(I assume not really, given that only `arch_syscall_is_vdso_sigreturn()` is
required on the arch side, but I am curious)
>
> 4. Cleanup and Refactoring:
> - Remove redundant arm64-specific syscall tracing functions from
> ptrace.c, including syscall_trace_enter(), syscall_exit_work(),
> and related audit/step helpers.
>
> - Update el0_svc_common() in syscall.c to use the generic
> syscall_work checks and entry/exit call sites.
>
> [Why this matters]
> - Unified Interface: Aligns arm64 with the modern kernel entry standard.
>
> - Improved Maintainability: Bug fixes in kernel/entry/common.c now
> apply to arm64 automatically.
>
> - Feature Readiness: Simplifies the implementation of future
> cross-architecture syscall features.
>
> [Compatibility]
> This conversion maintains full ABI compatibility with existing
> userspace. The ptrace register-saving behavior, seccomp filtering, and
> syscall tracing semantics remain identical to the previous implementation.
I agree, would it make sense to mention that there is no change related
to RSEQ as arm64 does not have `HAVE_GENERIC_TIF_BITS` ? As that is
part of generic entry, but is indeed a no-op for us.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Suggested-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> [...]
> diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
> index 29307642f4c9..e67643a70405 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -385,11 +385,18 @@ void user_enable_single_step(struct task_struct *task)
>
> if (!test_and_set_ti_thread_flag(ti, TIF_SINGLESTEP))
> set_regs_spsr_ss(task_pt_regs(task));
> +
> + /*
> + * Ensure that a trap is triggered once stepping out of a system
> + * call prior to executing any user instruction.
> + */
I was a bit confused by the comment in isolation at first : we already
have a signal that we are stepping and would need a trap, `TIF_SINGLESTEP`.
Would it make sense to mention here that this is for/handled by the generic
entry code ?
Something along the lines of "[...], as the generic entry code does not
check for `TIF_SINGLESTEP`.", or "Ensure that the generic entry code
triggers a trap [...]", if you think its useful ?
> + set_task_syscall_work(task, SYSCALL_EXIT_TRAP);
> }
> NOKPROBE_SYMBOL(user_enable_single_step);
>
> void user_disable_single_step(struct task_struct *task)
> {
> clear_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP);
> + clear_task_syscall_work(task, SYSCALL_EXIT_TRAP);
> }
> NOKPROBE_SYMBOL(user_disable_single_step);
Apart from my minor nitpicks :
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Thanks,
Ada
^ permalink raw reply
* Re: [PATCH] mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout
From: Vladimir Zapolskiy @ 2026-06-24 15:29 UTC (permalink / raw)
To: Pengpeng Hou, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Piotr Wojtaszczyk
Cc: linux-mtd, linux-arm-kernel, linux-kernel
In-Reply-To: <20260624144127.69075-1-pengpeng@iscas.ac.cn>
On 6/24/26 17:41, Pengpeng Hou wrote:
> lpc32xx_xmit_dma() waits for the DMA completion callback but ignores
> wait_for_completion_timeout(). A timed out DMA transfer is therefore
> unmapped and reported as successful to the NAND read/write path.
>
> Return -ETIMEDOUT when the completion wait expires. Terminate the DMA
> channel before unmapping the scatterlist so the timed out transfer cannot
> continue to access the buffer after the error is returned.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/mtd/nand/raw/lpc32xx_slc.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c
> index 3ca30e7dc..10c808020 100644
> --- a/drivers/mtd/nand/raw/lpc32xx_slc.c
> +++ b/drivers/mtd/nand/raw/lpc32xx_slc.c
> @@ -430,6 +430,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
> struct dma_async_tx_descriptor *desc;
> int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
> int res;
> + unsigned long time_left;
>
> host->dma_slave_config.direction = dir;
> host->dma_slave_config.src_addr = dma;
> @@ -467,12 +468,19 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
> dmaengine_submit(desc);
> dma_async_issue_pending(host->dma_chan);
>
> - wait_for_completion_timeout(&host->comp, msecs_to_jiffies(1000));
> + time_left = wait_for_completion_timeout(&host->comp,
> + msecs_to_jiffies(1000));
> + if (!time_left) {
> + dmaengine_terminate_sync(host->dma_chan);
> + res = -ETIMEDOUT;
> + } else {
> + res = 0;
> + }
>
> dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
> DMA_BIDIRECTIONAL);
>
> - return 0;
> + return res;
> out1:
> dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
> DMA_BIDIRECTIONAL);
Thank you for the change.
Reviewed-by: Vladimir Zapolskiy <vz@kernel.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 19/37] drm/bridge: samsung-dsim: move drm_bridge_add() call to probe
From: Maxime Ripard @ 2026-06-24 15:28 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: <DJ63DNXUOW46.1DI6982PGPFRR@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 4791 bytes --]
On Thu, Jun 11, 2026 at 10:54:14AM +0200, Luca Ceresoli wrote:
> On Mon Jun 8, 2026 at 1:58 PM CEST, Maxime Ripard wrote:
> > On Tue, May 19, 2026 at 12:37:36PM +0200, Luca Ceresoli wrote:
> >> This bridge driver calls drm_bridge_add() in the DSI host .attach callback
> >> instead of in the probe function.
> >>
> >> This works for current use cases but is problematic for supporting hotplug
> >> of DRM bridges. The problematic case is when this DSI host is always
> >> present while its DSI device is hot-pluggable. In such case with the
> >> current code the DRM card will not be populated until after the DSI device
> >> attaches to the host, which could happen a very long time after booting, or
> >> even not happen at all.
> >>
> >> The reason is that the previous pipeline component (the encoder in this
> >> case) when probing cannot find the samsung-dsim bridge. What happens is:
> >>
> >> [1 and 2 can happen in any order, same result]
> >> 1) samsung-dsim probes (does not drm_bridge_add() itself)
> >> 2) The lcdif starts probing multiple times, but
> >> lcdif_probe
> >> -> lcdif_load
> >> -> lcdif_attach_bridge
> >> -> devm_drm_of_get_bridge() returns -EPROBE_DEFER because
> >> the samsung-dsim is not in the global bridge_list
> >> (deferred probe pending: imx-lcdif: Cannot connect bridge)
> >>
> >> The samsung-dsim will not drm_bridge_add() itself until a DSI device will
> >> try to mipi_dsi_attach() to the DSI Host, which can happen arbitratily late
> >> on hot-pluggable hardware.
> >>
> >> As a preliminary step to supporting hotplug move drm_bridge_add() at probe
> >> time, so that the samsung-dsim DSI host bridge is available during boot,
> >> even without a connected DSI device. This results in:
> >>
> >> 1) samsung-dsim probes (and adds to drm_bridge_add() itself)
> >> 2) The lcdif starts probing multiple times, but
> >> lcdif_probe
> >> -> lcdif_load
> >> -> lcdif_attach_bridge
> >> -> devm_drm_of_get_bridge() --> OK, returns samsung-dsim ptr
> >>
> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> >
> > We should probably amend
> > https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
> >
> > To mention this use case here
>
> Right. I haven't updated the docs for this v1 because I was not sure the
> overall approach would be acked. Now Dmitry acked it overall, and I kind of
> infer you are not against, so I'll look into updating the docs in v2.
>
> However I find that section of the docs a bit hard to read especially from
> a newcomer perspective.
It's a complex problem, so I don't think we should expect the target
audience to be newcomers. But maybe we can indeed improve it.
> A better understanding on my side would help in doing the right change as
> far as this patch is concerned, and as a bonus in improving the section
> overall (that would probably be a separate series).
>
> So I have a couple questions to start from:
>
> * Do I understand correctly that using the component framework is legacy,
> not recommended for new DRM development, and that converting existing
> code to stop using it is welcome?
No. It's not legacy or deprecated. And about the conversion, I guess
it's on a case-by-case basis? It's not encouraged or discouraged anyway.
> * The first bullet quotes "The upstream driver [...] isn’t a MIPI-DSI
> host". If the upstream driver of a MIPI DSI link isn't a MIPI DSI host,
> what else could it be? What are the use cases here?
Nowhere is it said that we're considering a MIPI-DSI link here, so the
use case is any bridge that isn't using MIPI-DSI at all.
> * If read literally, none of the 4 bullets after "Indeed, there’s multiple
> cases that needs to be considered" covers this driver (it does not use
> the component framework, it does not use DCS, and the upstream device is
> a DSI host). However the 3 bullets after "The ideal pattern to cover the
> last item" appear to cover what this driver does. Do we need a fifth
> bullet for drivers like this one? Or...?
You tell me :)
How does hotplugging, say, a MIPI-DSI device bridge controlled over I2C,
or a MIPI-DSI host bridge, affect the probing sequence, and can we end
up in endless probe deferrals?
> * To me it looks like the "bridge" word in this section is always used to
> refer to the DSI device. Would it make sense to replace "bridge" ->
> "[DSI ]device" in this section?
Not necessarily, and from a KMS point of view, MIPI-DSI doesn't exist,
only bridge do.
> (especially as the DSI host is also a DRM bridge)
It doesn't have to be.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* RE: [PATCH v2] spi: imx: reconfigure for PIO when DMA cannot be started
From: Carlos Song @ 2026-06-24 15:27 UTC (permalink / raw)
To: Javier Fernandez Pastrana, Mark Brown, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-spi@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
In-Reply-To: <20260624151958.18626-1-javier.pastrana@linutronix.de>
> -----Original Message-----
> From: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
> Sent: Wednesday, June 24, 2026 11:20 PM
> To: Mark Brown <broonie@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha
> Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Carlos Song
> <carlos.song@nxp.com>; linux-spi@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: javier.pastrana@linutronix.de; stable@vger.kernel.org
> Subject: [EXT] [PATCH v2] spi: imx: reconfigure for PIO when DMA cannot be
> started
>
> [Some people who received this message don't often get email from
> javier.pastrana@linutronix.de. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Caution: This is an external email. Please take care when clicking links or opening
> attachments. When in doubt, report the message using the 'Report this email'
> button
>
>
> When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA:
> spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and
> spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the
> SDMA watermarks.
>
> If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single()
> returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and falls
> back to PIO. The dynamic-burst DMA path uses its own bounce buffers instead of
> the SPI core's mapping, so xfer->{tx,rx}_sg_mapped are not set and the core's
> DMA->PIO retry is skipped; the driver falls back to PIO internally. But none of the
> DMA-mode configuration is undone, so the PIO transfer runs with CTRL.SMC set,
> the wrong burst length and dynamic_burst cleared, and the transferred data is
> corrupted.
>
> This is easily hit on i.MX8MP boards that describe ECSPI DMA in the device tree
> but run SDMA on ROM firmware (no external sdma-imx7d.bin):
> every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then returns
> shifted TPM2_GetCapability data, is flagged "field failure mode", /dev/tpmrm0 is
> never created.
>
> Set controller->fallback before re-running spi_imx_setupxfer() so the ECSPI is
> reconfigured exactly like a normal PIO transfer. With
> controller->fallback set, spi_imx_setupxfer() sees spi_imx_can_dma()
> return false, so it clears spi_imx->usedma and reprograms the controller (clears
> CTRL.SMC, restores dynamic_burst and the PIO burst length). No explicit
> spi_imx->usedma = false is needed: setupxfer() already updates it from the
> can_dma() result.
>
> Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA
> mode")
> Cc: stable@vger.kernel.org
> Signed-off-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
Hi,
LGTM. Thank you!
Acked-by: Carlos Song <carlos.song@nxp.com>
> ---
> v2: drop redundant spi_imx->usedma = false; spi_imx_setupxfer() already
> clears it via spi_imx_can_dma() (Carlos Song)
>
> drivers/spi/spi-imx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index
> 480d1e8b281f..1837cc7b0b96 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -2152,7 +2152,8 @@ static int spi_imx_transfer_one(struct spi_controller
> *controller,
> if (spi_imx->usedma) {
> ret = spi_imx_dma_transfer(spi_imx, transfer);
> if (transfer->error & SPI_TRANS_FAIL_NO_START) {
> - spi_imx->usedma = false;
> + controller->fallback = true;
> + spi_imx_setupxfer(spi, transfer);
> if (spi_imx->target_mode)
> return spi_imx_pio_transfer_target(spi,
> transfer);
> else
> --
> 2.47.3
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Xueyuan Chen @ 2026-06-24 14:49 UTC (permalink / raw)
To: david
Cc: xueyuan.chen21, dave.hansen, akpm, linux-mm, linux-kernel,
linux-arm-kernel, x86, catalin.marinas, will, tglx, mingo, bp,
dave.hansen, luto, peterz, hpa, ljs, liam, vbabka, rppt, surenb,
mhocko, ziy, baolin.wang, npache, ryan.roberts, dev.jain, baohua,
lance.yang, yang, jannh
In-Reply-To: <f679fc68-5ff6-4715-9a07-9eb3074b2d1e@kernel.org>
On Fri, Jun 19, 2026 at 01:09:09PM +0200, David Hildenbrand (Arm) wrote:
Hi, David
[...]
>Having a new direct-map specific function with clear semantics might indeed
>avoid even messing with that.
>
>So, yeah, given that we have
>
> set_direct_map_invalid_noflush
> set_direct_map_default_noflush
> set_direct_map_valid_noflush
>
>Let's add a
>
> set_direct_map_ro()
>
>Or (my preference)
>
> change_direct_map_ro()
>
>But given the existing naming scheme ... maybe just set_direct_map_ro() and
>we'll clean this up another day.
>
>
>Now, should there also be a "_noflush" in there, or who is supposed to flush the
>TLB (or don't we flush at all, because it's used early during boot so far)?
>
>In any case, for this function we should add excessive documentation and define
>clear semantics.
>
After talking with Lance, we're leaning toward a direct-map helper:
set_direct_map_ro_noflush(const void *addr, unsigned long nr_pages)
Contract should be pretty explicit: direct/linear map only, no alias
handling, no TLB flush. If a caller needs stale entries gone, it has
to flush itself.
Huge zero folio only uses this early during boot so far, so noflush
should be OK. Will document that.
Thanks,
Xueyuan
^ permalink raw reply
* [PATCH v2] spi: imx: reconfigure for PIO when DMA cannot be started
From: Javier Fernandez Pastrana @ 2026-06-24 15:19 UTC (permalink / raw)
To: Mark Brown, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Carlos Song, linux-spi, imx, linux-arm-kernel,
linux-kernel
Cc: javier.pastrana, stable
When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA:
spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and
spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the
SDMA watermarks.
If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single()
returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and
falls back to PIO. The dynamic-burst DMA path uses its own bounce
buffers instead of the SPI core's mapping, so xfer->{tx,rx}_sg_mapped
are not set and the core's DMA->PIO retry is skipped; the driver falls
back to PIO internally. But none of the DMA-mode configuration is
undone, so the PIO transfer runs with CTRL.SMC set, the wrong burst
length and dynamic_burst cleared, and the transferred data is corrupted.
This is easily hit on i.MX8MP boards that describe ECSPI DMA in the
device tree but run SDMA on ROM firmware (no external sdma-imx7d.bin):
every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then
returns shifted TPM2_GetCapability data, is flagged "field failure
mode", /dev/tpmrm0 is never created.
Set controller->fallback before re-running spi_imx_setupxfer() so the
ECSPI is reconfigured exactly like a normal PIO transfer. With
controller->fallback set, spi_imx_setupxfer() sees spi_imx_can_dma()
return false, so it clears spi_imx->usedma and reprograms the controller
(clears CTRL.SMC, restores dynamic_burst and the PIO burst length). No
explicit spi_imx->usedma = false is needed: setupxfer() already updates
it from the can_dma() result.
Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode")
Cc: stable@vger.kernel.org
Signed-off-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
---
v2: drop redundant spi_imx->usedma = false; spi_imx_setupxfer() already
clears it via spi_imx_can_dma() (Carlos Song)
drivers/spi/spi-imx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 480d1e8b281f..1837cc7b0b96 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -2152,7 +2152,8 @@ static int spi_imx_transfer_one(struct spi_controller *controller,
if (spi_imx->usedma) {
ret = spi_imx_dma_transfer(spi_imx, transfer);
if (transfer->error & SPI_TRANS_FAIL_NO_START) {
- spi_imx->usedma = false;
+ controller->fallback = true;
+ spi_imx_setupxfer(spi, transfer);
if (spi_imx->target_mode)
return spi_imx_pio_transfer_target(spi, transfer);
else
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-24 15:16 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <25d7d3a1-58e0-4f25-a73a-59a978130c47@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 11:08:32PM +0800, Jie Gan wrote:
[...]
> > Why does it fail ? power management ? hw broken ? Is it really AMBA or
> > do you pretend that to be an AMBA device by faking the CID/PID?
>
> The CID reads as 0 from the register, which I suspect is a hardware design
> issue. I have not yet confirmed this with the hardware team. As a
> workaround, I provided a fake periphid via a DT property to bypass
> amba_read_periphid.
>
>
> Leo commented in other thread:
> >>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't >>it
> >>be registered as a platform device instead?
>
> The platform driver is intended for the interconnect TraceNoC device and is
> not designed to allocate an ATID. The issue is that the TPDM device borrows
> the ATID from the TraceNoC device, resulting in the ATID always being 0 when
> associated with an interconnect NoC device.
>
> However, I believe it is acceptable to allocate an ATID for the itNoC device
> and the issue can be fixed with this way.
I think so.
^ permalink raw reply
* Re: [PATCH 26/37] drm: event-notifier: add mechanism to notify about hotplug events
From: Maxime Ripard @ 2026-06-24 15:09 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: <DJ4EWMIX84PN.3VTENLJT2FWDH@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
On Tue, Jun 09, 2026 at 11:30:52AM +0200, Luca Ceresoli wrote:
> On Mon Jun 8, 2026 at 2:13 PM CEST, Maxime Ripard wrote:
> > On Tue, May 19, 2026 at 12:37:43PM +0200, Luca Ceresoli wrote:
> >> In preparation for supporting DRM bridge hotplug, add an event notifier to
> >> allow interested parties to be notified about events they need to react to.
> >>
> >> For the initial implementation of bridge hotplug, two events are needed:
> >> bridge detach (happening in drm_bridge.c) and MIPI device attach to MIPI
> >> host (happening in drm_mipi_dsi.c).
> >>
> >> For this reason implement the event notifier in a new common file that
> >> event producers can easily use to send events.
> >>
> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> >
> > So, you claim in the commit message that it's about a hotplug event, but
> > the only events are the bridge being attached and detached, so not a
> > hotplug event?
> >
> > And why a bridge would want to be notified that itself (or another?)
> > bridge is being attached or detached?
> >
> > You need documentation, and a more descriptive commit message.
>
> Yes.
>
> But before that I need a decision about the scope we want to give to this
> notifier. It is a very generic module, with basically no dependencies, so
> people will try to add more unrelated events and we'd need to set a
> boundary.
>
> Options:
>
> * Should it be for hotplug-related events only?
> * Should it be for any DRM event that needs notifications?
> * Something else?
>
> I'm happy to write that in the docs and commit message once it's agreed, so
> any comments would be welcome right now.
At the end of the day, you'd be the first user of it, so you get to make
the rules, but they should be written down :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 15:08 UTC (permalink / raw)
To: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <471d7a92-3629-4274-a303-8906d3626037@arm.com>
On 6/24/2026 9:51 PM, Suzuki K Poulose wrote:
> On 24/06/2026 14:48, Jie Gan wrote:
>>
>>
>> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>>> 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?
>>>
>>
>> For an AMBA device, the periphid is mandatory for probing. In the
>> amba_match function, AMBA attempts to read the periphid from the CID/
>> PID registers if the arm,primecell-periphid property is absent in the
>> device tree. If this read fails, it returns -EPROBE_DEFER, and the
>> probe ultimately fails.
>
> Why does it fail ? power management ? hw broken ? Is it really AMBA or
> do you pretend that to be an AMBA device by faking the CID/PID?
The CID reads as 0 from the register, which I suspect is a hardware
design issue. I have not yet confirmed this with the hardware team. As a
workaround, I provided a fake periphid via a DT property to bypass
amba_read_periphid.
Leo commented in other thread:
>>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't
>>it
>>be registered as a platform device instead?
The platform driver is intended for the interconnect TraceNoC device and
is not designed to allocate an ATID. The issue is that the TPDM device
borrows the ATID from the TraceNoC device, resulting in the ATID always
being 0 when associated with an interconnect NoC device.
However, I believe it is acceptable to allocate an ATID for the itNoC
device and the issue can be fixed with this way.
Thanks,
Jie
>
> Suzuki
>
>
>> Most AMBA devices expose valid CID/PID registers, so specifying
>> arm,primecell-periphid in the device tree is usually unnecessary.
>> However, for the TraceNoC device in this case, AMBA cannot reliably
>> read the periphid from the corresponding registers.
>>
>>> And is this required for all TNOC devices?
>>
>> So far, the TNOC device has been added to sm8750, Glymur, and
>> Kaanapali platforms, and all exhibit probe failures due to the same
>> root cause.
>>
>> I prefer to fix it on Kaanapali first.
>>
>> Thanks,
>> Jie
>>
>>>
>>> Konrad
>>
>
^ permalink raw reply
* Re: [PATCH 6.1 337/522] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
From: Ryan Roberts @ 2026-06-24 15:05 UTC (permalink / raw)
To: Will Deacon, Ben Hutchings
Cc: Anshuman Khandual, Catalin Marinas, David Hildenbrand (Arm),
patches, linux-arm-kernel, linux-kernel, Sasha Levin,
Greg Kroah-Hartman, stable, mark.rutland
In-Reply-To: <ajqXWqiAol6Shdd6@willie-the-truck>
On 23/06/2026 15:25, Will Deacon wrote:
> On Sun, Jun 21, 2026 at 05:02:27PM +0200, Ben Hutchings wrote:
>> On Tue, 2026-06-16 at 20:28 +0530, Greg Kroah-Hartman wrote:
>>> 6.1-stable review patch. If anyone has any objections, please let me know.
>>>
>>> ------------------
>>>
>>> From: Anshuman Khandual <anshuman.khandual@arm.com>
>>>
>>> [ Upstream commit 48478b9f791376b4b89018d7afdfd06865498f65 ]
>> [...]
>>> @@ -949,15 +953,14 @@ static void unmap_hotplug_pmd_range(pud_
>>> WARN_ON(!pmd_present(pmd));
>>> if (pmd_sect(pmd)) {
>>> pmd_clear(pmdp);
>>> -
>>> - /*
>>> - * One TLBI should be sufficient here as the PMD_SIZE
>>> - * range is mapped with a single block entry.
>>> - */
>>> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>>> - if (free_mapped)
>>> + if (free_mapped) {
>>> + /* CONT blocks are not supported in the vmemmap */
>>> + WARN_ON(pmd_cont(pmd));
>>> + flush_tlb_kernel_range(addr, addr + PMD_SIZE);
>>
>> It wasn't clear to me from the commit message why this now adds PMD_SIZE
>> rather than PAGE_SIZE. It seems like this change is fine for Linux
>> 6.13+ with a CPU that supports TLB range flushing, but otherwise results
>> in unnecessarily executing multiple TLB invalidations at intervals of
>> the base page size.
>
> Hmm, the commit message also makes very little sense to me and so I don't
> understand why this patch has us doing multiple TLB invalidations when
> we run into a !cont, block mapping at the PMD level. The old comment
> (which this patch removes) should still apply afaict.
>
> Anshuman, Ryan, any ideas what's going on here?
I think this change was probably my fault; Given the API is called
flush_tlb_kernel_range() it seemed like an abuse/hack to pretend we are only
flushing the first PAGE_SIZE of the range. But as I understand it, even if the
HW shatters a block mapping into multiple TLB entries, all of the entries
relating to the block mapping will be invalidated if just one of them intersects
the TLBI range/address. So it should be safe to reapply this hack.
Although ideally I think it would be better if this API took a stride argument;
then intent is clear.
What's the best way to handle this? Submit a patch for mainline that reverts
this part, then get it backported to stable (implying this current patch will
have been applied to stable)?
Thanks,
Ryan
>
> Will
^ permalink raw reply
* Re: [PATCH v3 00/12] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Borislav Petkov @ 2026-06-24 14:59 UTC (permalink / raw)
To: Will Deacon
Cc: Jinjie Ruan, catalin.marinas, tsbogend, tglx, mingo, 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: <ajvKkLw5bL-FT5JC@willie-the-truck>
On Wed, Jun 24, 2026 at 01:16:16PM +0100, Will Deacon wrote:
> If you want to help out in the meantime, there are plenty of patches that
> need reviewing...
I would loooove it if git send-email speed and rate of sending mail is
proportional to how many other patches the sender has really reviewed...
:-P :-P :-P
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v15 09/11] arm64/ptrace: Skip syscall exit reporting for PTRACE_SYSEMU_SINGLESTEP
From: Ada Couprie Diaz @ 2026-06-24 14:55 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-10-ruanjinjie@huawei.com>
On 11/05/2026 10:21, Jinjie Ruan wrote:
> Align the syscall exit reporting logic with the generic entry
> framework by skipping the exit stop when PTRACE_SYSEMU_SINGLESTEP is
> in effect.
>
> [Rationale]
> When a tracer uses PTRACE_SYSEMU_SINGLESTEP, both _TIF_SYSCALL_EMU
> and _TIF_SINGLESTEP flags are set. Currently, arm64 reports a syscall
> exit stop whenever _TIF_SINGLESTEP is set, regardless of the
> emulation state.
>
> However, as per the generic entry implementation (see
> include/linux/entry-common.h):
> "If SYSCALL_EMU is set, then the only reason to report is when SINGLESTEP
> is set (i.e. PTRACE_SYSEMU_SINGLESTEP). This syscall instruction has been
> already reported in syscall_trace_enter()."
>
> Since PTRACE_SYSEMU intercepts and skips the actual syscall
> execution, reporting a subsequent exit stop is redundant and
> inconsistent with the expected behavior of emulated system calls.
>
> [Changes]
> - Introduce report_single_step(): Add a helper to encapsulate the
> logic for deciding whether to report a single-step stop at syscall
> exit. It returns false if _TIF_SYSCALL_EMU is set, ensuring the
> emulated syscall does not trigger a duplicate report.
>
> - Update syscall_exit_work(): Use the new helper to determine
> the stepping state instead of directly checking _TIF_SINGLESTEP.
>
> [Impact]
> - PTRACE_SINGLESTEP: Continues to report exit stops for actual
> instructions.
>
> - PTRACE_SYSEMU: Continues to skip exit stops.
>
> - PTRACE_SYSEMU_SINGLESTEP: Now correctly skips the redundant exit
> stop, aligning arm64 with the generic entry infrastructure.
>
> 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>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
^ permalink raw reply
* Re: [PATCH v15 08/11] arm64/ptrace: Define and use _TIF_SYSCALL_EXIT_WORK
From: Ada Couprie Diaz @ 2026-06-24 14:53 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-9-ruanjinjie@huawei.com>
On 11/05/2026 10:21, Jinjie Ruan wrote:
> Introduce _TIF_SYSCALL_EXIT_WORK to filter out entry-only flags
> during the syscall exit path. This aligns arm64 with the generic
> entry framework's SYSCALL_WORK_EXIT semantics.
>
> [Rationale]
> The current syscall exit path uses _TIF_SYSCALL_WORK to decide whether
> to invoke syscall_exit_work(). However, _TIF_SYSCALL_WORK includes
> flags that are only relevant during syscall entry:
>
> 1. _TIF_SECCOMP: Seccomp filtering (__secure_computing) only runs
> on entry. There is no seccomp callback for syscall exit.
>
> 2. _TIF_SYSCALL_EMU: In PTRACE_SYSEMU mode, the syscall is
> intercepted and skipped on entry. Since the syscall is never
> executed, reporting a syscall exit stop is unnecessary.
>
> [Changes]
> - Define _TIF_SYSCALL_EXIT_WORK: A new mask containing only flags
> requiring exit processing: _TIF_SYSCALL_TRACE, _TIF_SYSCALL_AUDIT,
> and _TIF_SYSCALL_TRACEPOINT.
>
> - Update exit path: Use _TIF_SYSCALL_EXIT_WORK in
> syscall_exit_to_user_mode_work() to avoid redundant calls to
> audit and ptrace reporting when only entry-flags are set.
>
> - Cleanup: Remove the has_syscall_work() helper as it is no longer
> needed. Direct flag comparison is now used to distinguish between
> entry and exit work requirements.
>
> [Impact]
> audit_syscall_exit() and report_syscall_exit() will no longer be
> triggered for seccomp-only or emu-only syscalls. This matches the
> generic entry behavior and improves efficiency by skipping unnecessary
> exit processing.
>
> 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>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Definitely not related to this series, but it feels like this brings us
quite close to being able to switch to generic TIF flags as well :
only TIF_FOREIGN_PSTATE and TIF_MTE_ASYNC_FAULT
would need to be moved to the upper 16 bits,
with TIF_RESTORE_SIGMASK and TIF_MEMDIE freeing two slots there.
Not sure how important the bit number changes would be and if any
of the extra generic bits require any arch support (TIF_POLLING_NRFLAG,
TIF_USER_RETURN_NOTIFY, TIF_RSEQ, TIF_HRTIMER_REARM)...
But again, just thinking out loud !
Thanks,
Ada
^ permalink raw reply
* [PATCH] mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout
From: Pengpeng Hou @ 2026-06-24 14:41 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Vladimir Zapolskiy, Piotr Wojtaszczyk
Cc: Pengpeng Hou, linux-mtd, linux-arm-kernel, linux-kernel
lpc32xx_xmit_dma() waits for the DMA completion callback but ignores
wait_for_completion_timeout(). A timed out DMA transfer is therefore
unmapped and reported as successful to the NAND read/write path.
Return -ETIMEDOUT when the completion wait expires. Terminate the DMA
channel before unmapping the scatterlist so the timed out transfer cannot
continue to access the buffer after the error is returned.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mtd/nand/raw/lpc32xx_slc.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/lpc32xx_slc.c b/drivers/mtd/nand/raw/lpc32xx_slc.c
index 3ca30e7dc..10c808020 100644
--- a/drivers/mtd/nand/raw/lpc32xx_slc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_slc.c
@@ -430,6 +430,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
struct dma_async_tx_descriptor *desc;
int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
int res;
+ unsigned long time_left;
host->dma_slave_config.direction = dir;
host->dma_slave_config.src_addr = dma;
@@ -467,12 +468,19 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, dma_addr_t dma,
dmaengine_submit(desc);
dma_async_issue_pending(host->dma_chan);
- wait_for_completion_timeout(&host->comp, msecs_to_jiffies(1000));
+ time_left = wait_for_completion_timeout(&host->comp,
+ msecs_to_jiffies(1000));
+ if (!time_left) {
+ dmaengine_terminate_sync(host->dma_chan);
+ res = -ETIMEDOUT;
+ } else {
+ res = 0;
+ }
dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
DMA_BIDIRECTIONAL);
- return 0;
+ return res;
out1:
dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
DMA_BIDIRECTIONAL);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] media: cec: stm32: return an error when log-address wait times out
From: Pengpeng Hou @ 2026-06-24 14:40 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Maxime Coquelin,
Alexandre Torgue
Cc: Pengpeng Hou, linux-media, linux-stm32, linux-arm-kernel,
linux-kernel
stm32_cec_adap_log_addr() waits for TXSOM to clear before disabling CEC
and updating the logical address registers. The wait result is ignored,
so a timeout can still be reported as a successful logical address
update.
Return the polling error before touching the address registers. Compute
the address mask only for valid logical addresses so the invalid-address
path does not evaluate a shift based on CEC_LOG_ADDR_INVALID.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/media/cec/platform/stm32/stm32-cec.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/media/cec/platform/stm32/stm32-cec.c b/drivers/media/cec/platform/stm32/stm32-cec.c
index 1ec0cece0..82709b5ec 100644
--- a/drivers/media/cec/platform/stm32/stm32-cec.c
+++ b/drivers/media/cec/platform/stm32/stm32-cec.c
@@ -193,18 +193,24 @@ static int stm32_cec_adap_enable(struct cec_adapter *adap, bool enable)
static int stm32_cec_adap_log_addr(struct cec_adapter *adap, u8 logical_addr)
{
struct stm32_cec *cec = adap->priv;
- u32 oar = (1 << logical_addr) << 16;
u32 val;
+ int ret;
/* Poll every 100µs the register CEC_CR to wait end of transmission */
- regmap_read_poll_timeout(cec->regmap, CEC_CR, val, !(val & TXSOM),
- 100, CEC_XFER_TIMEOUT_MS * 1000);
+ ret = regmap_read_poll_timeout(cec->regmap, CEC_CR, val, !(val & TXSOM),
+ 100, CEC_XFER_TIMEOUT_MS * 1000);
+ if (ret)
+ return ret;
+
regmap_update_bits(cec->regmap, CEC_CR, CECEN, 0);
- if (logical_addr == CEC_LOG_ADDR_INVALID)
- regmap_update_bits(cec->regmap, CEC_CFGR, OAR, 0);
- else
+ if (logical_addr == CEC_LOG_ADDR_INVALID) {
+ regmap_update_bits(cec->regmap, CEC_CFGR, OAR, 0);
+ } else {
+ u32 oar = BIT(logical_addr) << 16;
+
regmap_update_bits(cec->regmap, CEC_CFGR, oar, oar);
+ }
regmap_update_bits(cec->regmap, CEC_CR, CECEN, CECEN);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v15 07/11] arm64: syscall: Introduce syscall_exit_to_user_mode_work()
From: Ada Couprie Diaz @ 2026-06-24 14:37 UTC (permalink / raw)
To: Jinjie Ruan, mark.rutland
Cc: 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-8-ruanjinjie@huawei.com>
On 11/05/2026 10:20, Jinjie Ruan wrote:
> Refactor the system call exit path to align with the generic entry
> framework. This consolidates thread flag checking, rseq handling, and
> syscall tracing into a structure that mirrors the generic
> syscall_exit_to_user_mode_work() implementation.
>
> [Rationale]
> The generic entry code employs a hierarchical approach for
> syscall exit work:
>
> 1. syscall_exit_to_user_mode_work(): The entry point that handles
> rseq and checks if further exit work (tracing/audit) is required.
>
> 2. syscall_exit_work(): Performs the actual tracing, auditing, and
> ptrace reporting.
>
> [Changes]
> - Rename and Encapsulate: Rename syscall_trace_exit() to
> syscall_exit_work() and make it static, as it is now an internal
> helper for the exit path.
>
> - New Entry Point: Implement syscall_exit_to_user_mode_work() to
> replace the manual flag-reading logic in el0_svc_common(). This
> function now encapsulates the rseq_syscall() call and the
> conditional execution of syscall_exit_work().
>
> - Simplify el0_svc_common(): Remove the complex conditional checks
> for tracing and CONFIG_DEBUG_RSEQ at the end of the syscall path,
> delegating this responsibility to the new helper.
It is indeed simpler, however to me there are two changes to the behaviour,
which are not called out (apologies if I missed some prior discussion
when I looked for some) :
1. As pointed by the removed comment, in mainline we *always* trace on exit
if we traced on entry. This is why there are two
`has_syscall_work()` checks
on exit, with a re-read of the flags after syscall execution in between.
This change only checks once on exit after updating the flags, so if
there was work on entry but the flags got cleared, it *won't* trace
on exit.
Is this desired ? Can this change of behaviour have an impact ?
> - Helper Migration: Move has_syscall_work() to asm/syscall.h
> to allow its reuse across ptrace.c and syscall.c.
>
> - Clean up RSEQ: Remove the explicit IS_ENABLED(CONFIG_DEBUG_RSEQ)
> check in the caller, as rseq_syscall() is already a no-op when the
> config is disabled.
2. `rseq_syscall()` is indeed a no-op, but removing the explicit check here
does change the behaviour : in mainline we *always* trace on exit if
`CONFIG_DEBUG_RSEQ` is enabled, bypassing the `has_syscall_work()`
check.
This change does not bypass the `has_syscall_work()` check if
`CONFIG_DEBUG_RSEQ` is enabled, so there might be a change of behaviour.
Same questions as above : is this change desired ? Can it have an
impact ?
I understand that the change is to align with the generic entry, but it
seems
like this could have an impact that I do not really understand, so I prefer
asking !
Apart from the above everything looks OK to me, but I'd like
some confirmation that the change of behaviours either do not exist or
are OK !
Thanks,
Ada
> 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>
> ---
> v15
> - Make syscall_exit_to_user_mode_work() __always_inline to keep
> the fast-path performance as Sashiko pointed out.
> ---
> arch/arm64/include/asm/syscall.h | 18 +++++++++++++++++-
> arch/arm64/kernel/ptrace.c | 5 +----
> arch/arm64/kernel/syscall.c | 20 +-------------------
> 3 files changed, 19 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
> index 30b203ef156b..b331e09b937f 100644
> --- a/arch/arm64/include/asm/syscall.h
> +++ b/arch/arm64/include/asm/syscall.h
> @@ -8,6 +8,7 @@
> #include <uapi/linux/audit.h>
> #include <linux/compat.h>
> #include <linux/err.h>
> +#include <linux/rseq.h>
>
> typedef long (*syscall_fn_t)(const struct pt_regs *regs);
>
> @@ -121,6 +122,21 @@ static inline int syscall_get_arch(struct task_struct *task)
> }
>
> int syscall_trace_enter(struct pt_regs *regs, unsigned long flags);
> -void syscall_trace_exit(struct pt_regs *regs, unsigned long flags);
> +void syscall_exit_work(struct pt_regs *regs, unsigned long flags);
> +
> +static inline bool has_syscall_work(unsigned long flags)
> +{
> + return unlikely(flags & _TIF_SYSCALL_WORK);
> +}
> +
> +static __always_inline void syscall_exit_to_user_mode_work(struct pt_regs *regs)
> +{
> + unsigned long flags = read_thread_flags();
^-- This only reflects the post-syscall flags
> +
> + rseq_syscall(regs);
> +
> + if (has_syscall_work(flags) || flags & _TIF_SINGLESTEP)
> + syscall_exit_work(regs, flags);
> +}
>
> #endif /* __ASM_SYSCALL_H */
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 15a45eeb56da..256aa20377e1 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -28,7 +28,6 @@
> #include <linux/hw_breakpoint.h>
> #include <linux/regset.h>
> #include <linux/elf.h>
> -#include <linux/rseq.h>
>
> #include <asm/compat.h>
> #include <asm/cpufeature.h>
> @@ -2454,10 +2453,8 @@ int syscall_trace_enter(struct pt_regs *regs, unsigned long flags)
> return syscall;
> }
>
> -void syscall_trace_exit(struct pt_regs *regs, unsigned long flags)
> +void syscall_exit_work(struct pt_regs *regs, unsigned long flags)
> {
> - rseq_syscall(regs);
> -
> audit_syscall_exit(regs);
^-- This was always called if entry had work or CONFIG_DEBUG_RSEQ was enabled,
which is not the case anymore (same for the rest of the function)
>
> if (flags & _TIF_SYSCALL_TRACEPOINT)
> diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> index f6f87b042995..dac7bcc4bbdf 100644
> --- a/arch/arm64/kernel/syscall.c
> +++ b/arch/arm64/kernel/syscall.c
> @@ -54,11 +54,6 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
> syscall_set_return_value(current, regs, 0, ret);
> }
>
> -static inline bool has_syscall_work(unsigned long flags)
> -{
> - return unlikely(flags & _TIF_SYSCALL_WORK);
> -}
> -
> static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> const syscall_fn_t syscall_table[])
> {
> @@ -120,21 +115,8 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> }
>
> invoke_syscall(regs, scno, sc_nr, syscall_table);
> -
> - /*
> - * The tracing status may have changed under our feet, so we have to
> - * check again. However, if we were tracing entry, then we always trace
> - * exit regardless, as the old entry assembly did.
> - */
> - if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) {
^-- We always traced exit if CONFIG_DEBUG_RSEQ is enabled
^-- `flags` is unchanged since entry, and exit was always traced if there was work.
> - flags = read_thread_flags();
> - if (!has_syscall_work(flags) && !(flags & _TIF_SINGLESTEP))
> - return;
> - }
> -
> trace_exit:
> - flags = read_thread_flags();
> - syscall_trace_exit(regs, flags);
> + syscall_exit_to_user_mode_work(regs);
> }
>
> void do_el0_svc(struct pt_regs *regs)
^ permalink raw reply
* [PATCH] mailbox: imx: return TXDB_V2 timeout errors
From: Pengpeng Hou @ 2026-06-24 14:37 UTC (permalink / raw)
To: Jassi Brar, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: Pengpeng Hou, linux-kernel, imx, linux-arm-kernel
imx_mu_generic_tx() retries TXDB_V2 doorbell sends until the GIR bit
clears, but falls through to the common success return even when every
readl_poll_timeout() attempt failed.
Return the final timeout error after the retry loop so mailbox clients
can observe a failed doorbell send instead of treating it as successful.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mailbox/imx-mailbox.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 246a9a9e3..86a8a590b 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -253,6 +253,8 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
cp->type, ++count);
}
}
+ if (ret)
+ return ret;
break;
default:
dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [RFC PATCH 6/6] arm64: mm: support PMD page coalescing in the linear map
From: Adrian Barnaś @ 2026-06-24 14:32 UTC (permalink / raw)
To: Ryan Roberts
Cc: linux-arm-kernel, linux-mm, Catalin Marinas, Will Deacon,
David Hildenbrand, Mike Rapoport (Microsoft), Ard Biesheuvel,
Christoph Lameter, Yang Shi, Brendan Jackman
In-Reply-To: <799181c3-a1a1-4de7-bc6a-576d3282efb0@arm.com>
On Fri, Jun 19, 2026 at 02:40:40PM +0100, Ryan Roberts wrote:
>On 11/06/2026 14:01, Adrian Barnaś wrote:
>> Implement PMD block coalescing to merge fragmented linear mapping regions
>> back into huge pages when restoring the read-only attribute.
>>
>> When memory allocated with VM_ALLOW_HUGE_VMAP (such as for the execmem
>> ROX cache) has its permissions modified, the PMD block mapping is split
>> into individual PTEs. Without this change, when that memory have its RO
>> attribute subsequently cleared and set the mapping remains permanently
>> fragmented into 4K pages.
>
>I'd like to make sure I understand this correctly: So the execmem ROX cache is
>allocated using vmalloc_huge such that all it's backing memory are PMD-sized
>pages. It is initially poisoned with a faulting instruction and marked ROX. When
>a module is loaded, it's text is copied into a portion of the ROX cache and
>executed from there? To do that, the required number of (4K) pages are allocated
>from ROX cache, and the permissions are changed on that sub-region to RW,
>meaning we have to split the mapping from a PMD to (cont)PTEs in both vmalloc
>space and in the linear map. After the text is copied, the sub-region is
>switched back to ROX. But without that change, the 2M region is now mapped by
>(cont)PTEs for all of time?
That is correct.
>
>>
>> Signed-off-by: Adrian Barnaś <abarnas@google.com>
>> ---
>> arch/arm64/include/asm/mmu.h | 1 +
>> arch/arm64/mm/mmu.c | 95 ++++++++++++++++++++++++++++++++++++
>> arch/arm64/mm/pageattr.c | 7 +++
>> 3 files changed, 103 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
>> index 137a173df1ff..19158bacb2df 100644
>> --- a/arch/arm64/include/asm/mmu.h
>> +++ b/arch/arm64/include/asm/mmu.h
>> @@ -80,6 +80,7 @@ extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
>> extern void mark_linear_text_alias_ro(void);
>> extern int split_kernel_leaf_mapping(unsigned long start, unsigned long end);
>> extern void linear_map_maybe_split_to_ptes(void);
>> +void try_collapse_kernel_pmd(unsigned long addr);
>>
>> /*
>> * This check is triggered during the early boot before the cpufeature
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index a6a00accf4f9..d74226fa1c9b 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -769,6 +769,101 @@ static inline bool force_pte_mapping(void)
>>
>> static DEFINE_MUTEX(pgtable_split_lock);
>>
>> +static inline bool __pte_can_be_collapsed(pte_t pte, unsigned long pfn, pgprot_t prot)
>> +{
>> + if (!pte_valid(pte))
>> + return false;
>> + if (pte_pfn(pte) != pfn)
>> + return false;
>> + if ((pgprot_val(pte_pgprot(pte)) & ~PTE_CONT) != pgprot_val(prot))
>
>Do we want to permit differing values for access and dirty? We do for user
>space, but I think for kernel, those bits are always set? In which case, what
>you're doing is correct.
>
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static void __try_collapse_pmd(pmd_t *pmdp, pmd_t pmd, unsigned long addr)
>> +{
>> + pte_t *ptep;
>> + pte_t first_pte;
>> + unsigned long pfn;
>> + pgprot_t prot;
>> + int i;
>> +
>> + ptep = (pte_t *)pmd_page_vaddr(pmd);
>> + first_pte = __ptep_get(ptep);
>> +
>> + if (!pte_valid(first_pte))
>> + return;
>> +
>> + prot = pte_pgprot(first_pte);
>> + prot = __pgprot(pgprot_val(prot) & ~PTE_CONT);
>> + pfn = pte_pfn(first_pte);
>> +
>> + if (!IS_ALIGNED(pfn, PMD_SIZE >> PAGE_SHIFT))
>> + return;
>> +
>> + for (i = 1; i < PTRS_PER_PTE; i++) {
>> + if (!__pte_can_be_collapsed(__ptep_get(ptep + i), pfn + i, prot))
>> + return;
>> + }
>> +
>> + set_pmd(pmdp, pmd_mkhuge(pfn_pmd(pfn, prot)));
>> +
>> + __flush_tlb_kernel_pgtable(addr);
>> +
>
>nit: suggest adding the same comment that other sites has, since this is not
>obvious:
>
>/* See comment in pud_free_pmd_page for static key logic */
>
>> + if (static_branch_unlikely(&arm64_ptdump_lock_key)) {
>> + mmap_read_lock(&init_mm);
>> + mmap_read_unlock(&init_mm);
>> + }
>> +
>> + pte_free_kernel(NULL, ptep);
>
>Ooh, fun. Per my comments below we definitely have opportunity for racy pte
>table accesses (beyond ptdump). I _think_ if you fix that then this will be safe.
>
>> +}
>> +
>> +void try_collapse_kernel_pmd(unsigned long addr)
>> +{
>> + pgd_t *pgdp;
>> + p4d_t *p4dp;
>> + pud_t *pudp;
>> + pmd_t *pmdp;
>> + pmd_t pmd;
>> +
>> + /*
>> + * collapse_pmd expects exact address of block to be collapsed
>> + */
>> + if (WARN_ON(ALIGN_DOWN(addr, PMD_SIZE) != addr))
>> + return;
>> +
>> + mutex_lock(&pgtable_split_lock);
>
>I don't think this is safe in general. Let's say we have a 2M region split into
>512 x 4K PTEs. It's possible that the first 1M is one object and the second 1M
>is another object. Different CPUs could set_memory_*() on those 2 objects
>concurrently. If one of them then calls this function, we could end up
>collapsing the whole 2M while the other is trying to modify the PTEs and they
>will race.
>
>Note that splitting _is_ safe (and protected by this lock) because you'd have 2
>objects backed by the same PMD, so they would both have to split before
>modifying the PTEs.
>
>I think you'd need to ensure mutual exclusion at a higher level if doing this;
>probably execmem is the place that can ensure that no objects within a 2M region
>are racily trying to modify their permissions?
>
>> +
>> + pgdp = pgd_offset_k(addr);
>> + if (pgd_none(READ_ONCE(*pgdp)))
>
>nit: use the getters (e.g. pXdp_get()) instead of READ_ONCE().
>
>> + goto out;
>> +
>> + p4dp = p4d_offset(pgdp, addr);
>> + if (p4d_none(READ_ONCE(*p4dp)))
>> + goto out;
>> +
>> + pudp = pud_offset(p4dp, addr);
>> + if (pud_none(READ_ONCE(*pudp)))
>> + goto out;
>> +
>> + if (pud_leaf(READ_ONCE(*pudp)))
>> + goto out;
>> +
>> + pmdp = pmd_offset(pudp, addr);
>> + pmd = pmdp_get(pmdp);
>> +
>> + if (!pmd_table(pmd))
>> + goto out;
>> +
>> + lazy_mmu_mode_enable();
>> + __try_collapse_pmd(pmdp, pmd, addr);
>> + lazy_mmu_mode_disable();
>> +
>> +out:
>> + mutex_unlock(&pgtable_split_lock);
>> +}
>> +
>> int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
>> {
>> int ret;
>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>> index eaefdf90b0d5..11e0b60264c3 100644
>> --- a/arch/arm64/mm/pageattr.c
>> +++ b/arch/arm64/mm/pageattr.c
>> @@ -200,6 +200,13 @@ static int change_memory_common(unsigned long addr, int numpages,
>> if (ret)
>> return ret;
>> }
>
>The loop here in the unchanged code, calls __change_memory_common() for each
>PAGE_SIZE page in the linear alias. Perhaps it should be area->page_order aware?
>That way, if we are changing the permissions of the whole 2M chunk of vmalloc
>space and it's backed by a 2M page, then we won't split the mapping to PTEs in
>the linear map. Similarly, if we are changing permissions on a sub-region of the
>2M area, we might be able to split only as far as contpte and still have some
>performance benefit?
>
This is out of scope of execmem (as you noted we are mostly changing permision
for only a part of the block) but your sugestion seems to be valid for other
cases.
>> + /*
>> + * When setting a read-only flag on the linear region, the memory
>> + * may have been backed by a PMD before being split. Try to
>> + * collapse it back into a PMD to restore huge page performance.
>> + */
>> + if (pgprot_val(set_mask) == PTE_RDONLY && area->flags & VM_ALLOW_HUGE_VMAP)
>> + try_collapse_kernel_pmd((u64)page_address(area->pages[0]));
>
>try_collapse_kernel_pmd() requires a PMD-aligned address. VM_ALLOW_HUGE_VMAP
>doesn't guarrantee that - it only says that it's _allowed_ to be huge (and 64K
>would still be huge). vmalloc may have failed to allocate a PMD-sized page and
>reverted to something smaller (64K contpte or 4K). You need to look at
>area->page_order, I think.
>
Agree.
>You're only calling this for the linear alias. Don't you want to call it for the
>vmalloc range too? I assume the module text executes using the vmalloc address
>so you'd want it mapped by a single PMD for best performance?
>
I think it is a good idea to have them both (linear alias and vmalloc area)
mapped as PMD.
>But in general, I don't really like the idea of special-casing a collapse to pmd
>here for just execmem. I think we should either investigate a general purpose
>collapse mechanism or execmem should have extra hooks added to request specific
>collapse.>
>Thanks,
>Ryan
>
>
>> }
>>
>> /*
>
I will rethink this based on your suggestion and try to properly fix the
concurrency issues.
I am also wondering if we should avoid splitting linear aliases altogether.
I think I understand why it was done originally (to restrict writing through
linear mapping aliases for read-only vmalloc areas). However, it is not
necessary to make them writable when the vmalloc area is writable. Maybe
we should create a special case for execmem to prevent this. WDYT?
Thank you for the review,
Adrian
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-24 14:25 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Yuanfang Zhang,
Konrad Dybcio, 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 Wed, Jun 24, 2026 at 05:49:26PM +0800, 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.
> Add the arm,primecell-periphid property to bypass the AMBA bus
> check and resolve the probe issue.
tnoc.c registers both an AMBA driver and a platform driver. Shouldn't it
be registered as a platform device instead?
Thanks,
Leo
^ 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