* Re: [PATCH v15 07/11] arm64: syscall: Introduce syscall_exit_to_user_mode_work()
From: Jinjie Ruan @ 2026-06-25 9:18 UTC (permalink / raw)
To: Ada Couprie Diaz, mark.rutland
Cc: catalin.marinas, will, oleg, tglx, peterz, luto, kees, wad,
yeoreum.yun, linusw, kevin.brodsky, ldv, thuth, james.morse, song,
anshuman.khandual, broonie, ryan.roberts, pengcan, liqiang01,
linux-arm-kernel, linux-kernel
In-Reply-To: <768cc347-c42f-411d-90c3-bfaa39afeaf7@arm.com>
On 6/24/2026 10:37 PM, Ada Couprie Diaz wrote:
> 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 ?
Hi, Ada,
After rework, `syscall_exit_to_user_mode_work()` will be executed
unconditionally, regardless of whether the conditions below evaluate to
true or false. You can see how this is handled in the finer-grained
refactoring split which will be shown in v16.
if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ))
>> - 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 ?
This should not introduce any functional changes.
Except for "audit", the internal code execution of
`syscall_trace_exit()` is gated by the "_TIF_SYSCALL_TRACEPOINT,
_TIF_SYSCALL_TRACE, or _TIF_SINGLESTEP" TIF flags.
And gating audit_syscall_exit() behind `_TIF_SYSCALL_AUDIT` introduces
no functional changes.
The `SYSCALL_AUDIT` flag and its context are
statically allocated via audit_alloc() at fork and only freed via
audit_free() at do_exit(). Since the flag remains persistent and static
throughout syscall execution, checking the `_TIF_SYSCALL_AUDIT` flag is
completely equivalent to evaluating audit_context() in
audit_syscall_exit().
I probably moved too fast with this refactoring. I'll split this into
smaller, more granular steps in v16 to make the logic clearer and easier
to follow."
>
> 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 !
Thank you for the review.
>
> 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)
As explained above, thank you!
>
>> 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.
As explained above, thank you!
Best regards,
Jinjie
>
>> - 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] ARM: dts: st: spear13xx: Drop unused/incorrect usbh0_id and usbh1_id
From: Krzysztof Kozlowski @ 2026-06-25 9:13 UTC (permalink / raw)
To: Viresh Kumar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, soc, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
"usbh0_id" and "usbh1_id" properties were never documented and never
used by Linux drivers, thus should be safe to drop to fix dtbs_check
warnings like:
st/spear1310-evb.dtb: usb@e4800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh0_id' was unexpected)
st/spear1310-evb.dtb: usb@e5800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh1_id' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm/boot/dts/st/spear13xx.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 0bb88f2d4ef5..cf98160ba268 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -178,7 +178,6 @@ usb@e4800000 {
compatible = "st,spear600-ehci", "usb-ehci";
reg = <0xe4800000 0x1000>;
interrupts = <0 64 0x4>;
- usbh0_id = <0>;
status = "disabled";
};
@@ -186,7 +185,6 @@ usb@e5800000 {
compatible = "st,spear600-ehci", "usb-ehci";
reg = <0xe5800000 0x1000>;
interrupts = <0 66 0x4>;
- usbh1_id = <1>;
status = "disabled";
};
@@ -194,7 +192,6 @@ usb@e4000000 {
compatible = "st,spear600-ohci", "usb-ohci";
reg = <0xe4000000 0x1000>;
interrupts = <0 65 0x4>;
- usbh0_id = <0>;
status = "disabled";
};
@@ -202,7 +199,6 @@ usb@e5000000 {
compatible = "st,spear600-ohci", "usb-ohci";
reg = <0xe5000000 0x1000>;
interrupts = <0 67 0x4>;
- usbh1_id = <1>;
status = "disabled";
};
--
2.53.0
^ permalink raw reply related
* [PATCH] arm64: dts: hisilicon: hi3798cv200: Drop unused clock-names and reset-names
From: Krzysztof Kozlowski @ 2026-06-25 9:13 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Neither Linux drivers nor DT bindings ever described or used clock-names
and reset-names for this SoC. The binding allows clock-names only for
atmel,at91sam9g45-ehci and atmel,at91rm9200-ohci, but not for HiSilicon.
reset-names were never allowed.
Drop them from DTS to fix dtbs_check warnings:
hi3798cv200-poplar.dtb: usb@9880000 (generic-ohci): False schema does not allow ['bus', 'clk12', 'clk48']
hi3798cv200-poplar.dtb: usb@9880000 (generic-ohci): Unevaluated properties are not allowed ('reset-names' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 2f4ad5da5e33..e5010c9d4c39 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -633,9 +633,7 @@ ohci: usb@9880000 {
clocks = <&crg HISTB_USB2_BUS_CLK>,
<&crg HISTB_USB2_12M_CLK>,
<&crg HISTB_USB2_48M_CLK>;
- clock-names = "bus", "clk12", "clk48";
resets = <&crg 0xb8 12>;
- reset-names = "bus";
phys = <&usb2_phy1_port0>;
phy-names = "usb";
status = "disabled";
@@ -648,11 +646,9 @@ ehci: usb@9890000 {
clocks = <&crg HISTB_USB2_BUS_CLK>,
<&crg HISTB_USB2_PHY_CLK>,
<&crg HISTB_USB2_UTMI_CLK>;
- clock-names = "bus", "phy", "utmi";
resets = <&crg 0xb8 12>,
<&crg 0xb8 16>,
<&crg 0xb8 13>;
- reset-names = "bus", "phy", "utmi";
phys = <&usb2_phy1_port0>;
phy-names = "usb";
status = "disabled";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)
From: Stefan Eichenberger @ 2026-06-25 9:11 UTC (permalink / raw)
To: Vincent Jardin
Cc: Oleksij Rempel, Pengutronix Kernel Team, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Wolfram Sang, Kaushal Butala,
Shawn Guo, Stefan Eichenberger, linux-i2c, imx, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <20260525-for-upstream-i2c-lx2160-fix-v1-v2-2-26a3cc8cd055@free.fr>
On Mon, May 25, 2026 at 06:43:16PM +0200, Vincent Jardin wrote:
> SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the
> interrupt-driven block-read state machine rejects it as -EPROTO. Worse,
> it returns without a NACK+STOP: the next receive cycle has already
> started, so the target keeps holding SDA and the bus stays stuck until a
> power cycle of this i2c controller.
>
> Accept count=0: NACK the in-flight dummy byte (TXAK) and set msg->len to
> 2 so i2c_imx_isr_read_continue() emits STOP via its normal last-byte
> path. The dummy byte is discarded; block-read callers only consume
> buf[0..count-1].
>
> Reading I2DR has likewise already armed the next byte on the
> count > I2C_SMBUS_BLOCK_MAX error path, so NACK it (TXAK) before aborting
> with -EPROTO; otherwise the failing transfer's STOP cannot complete and
> the bus stays held.
>
> The atomic path regressed earlier (v3.16) and is fixed separately; this
> patch covers only the v6.13 state-machine rework.
>
> Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode")
> Cc: <stable@vger.kernel.org> # v6.13+
> Signed-off-by: Vincent Jardin <vjardin@free.fr>
> ---
> drivers/i2c/busses/i2c-imx.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 14107e1ad413..8db8d2e10f5c 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1061,11 +1061,28 @@ static inline enum imx_i2c_state i2c_imx_isr_read_continue(struct imx_i2c_struct
> static inline void i2c_imx_isr_read_block_data_len(struct imx_i2c_struct *i2c_imx)
> {
> u8 len = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
> + unsigned int temp;
>
> if (len == 0 || len > I2C_SMBUS_BLOCK_MAX) {
> + /*
> + * SMBus 3.1 6.5.7: support count byte of 0.
> + * I2C_SMBUS_BLOCK_MAX case should not hold the SDA either.
> + * So NACK it (TXAK) to not hold the bus.
> + */
> + temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> + temp |= I2CR_TXAK;
> + imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> +
> + if (len == 0) {
> + i2c_imx->msg->buf[i2c_imx->msg_buf_idx++] = 0;
> + i2c_imx->msg->len = 2;
> + return;
> + }
> +
> i2c_imx->isr_result = -EPROTO;
> i2c_imx->state = IMX_I2C_STATE_FAILED;
> wake_up(&i2c_imx->queue);
> + return;
> }
> i2c_imx->msg->len += len;
> i2c_imx->msg->buf[i2c_imx->msg_buf_idx++] = len;
>
> --
> 2.43.0
>
Reviewed-by: Stefan Eichenberger <eichest@gmail.com>
^ 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-25 9:10 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: <b9ca9e36-a851-4a98-a739-ca99dd534d6d@kernel.org>
Hi Krzysztof,
> > It's a Virtual UART. Internally, it's two FIFOs accessible via
> > 8250-compatible register sets on both ends.
>
> I do not know what is Virtual UART...
Yes the name of ASPEED is a bit weird, it means that it is not a real
UART. It is two 8250-compatible register sets, and the data path is
handled by two hardware FIFOs (one per direction).
> > 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.
>
> You mean these appear (or are) as PCI devices?
Yes but not as a UART devices.
The two VUART are accessible under the same PCIe BMC device, at the
VUART addresses configured on the BMC. They are accessible on the BAR1
of the PCIe BMC device.
There is a 2 bit left shift between the addresses of the registers on
the BMC LPC bus and the addresses accessible over the PCI device.
0x3F8 on the BMC is accessible at BAR1 0xFE0 over the PCI device.
The PCIe BMC Device is one PCI device where you can access several
peripherals. It's not one PCI device per VUART.
For example, you can also enable the KCS channel 4 and it will be also
accessible via the BAR1 of the PCI BMC device. KCS is a protocol used
for IPMI.
Only these two peripherals can be accessed over the PCI BMC device and
they need to be enabled.
The host cannot access everything on the LPC bus of the BMC.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH] ARM: enable interrupts when arm_notify_die() is handling user mode errors
From: Russell King @ 2026-06-25 9:05 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Xie Yuanbin, clrkwllms, rostedt, linusw, arnd, linux-arm-kernel,
linux-kernel, linux-rt-devel, liaohua4, lilinjie8
In-Reply-To: <20260625085034.tvyGSmaP@linutronix.de>
On Thu, Jun 25, 2026 at 10:50:34AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-06-25 15:35:22 [+0800], Xie Yuanbin wrote:
> > For lastest linux-next kernel, with default multi_v7_defconfig, and
> > setting CONFIG_PREEMPT_RT=y, CONFIG_DEBUG_ATOMIC_SLEEP=y, and
> > CONFIG_PERF_EVENTS=n. When the user program executes bkpt
> > instruction, the following WARN will be triggered:
> > ```log
> > [ 3.677825] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
> > [ 3.678002] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 84, name: test
> > [ 3.678036] preempt_count: 0, expected: 0
> > [ 3.678078] RCU nest depth: 0, expected: 0
> > [ 3.678864] CPU: 0 UID: 0 PID: 84 Comm: test Tainted: G W 7.1.0-next-20260623 #45 PREEMPT_RT
> > [ 3.679067] Tainted: [W]=WARN
> > [ 3.679088] Hardware name: Generic DT based system
> > [ 3.679198] Call trace:
> > [ 3.679695] unwind_backtrace from show_stack+0x10/0x14
> > [ 3.680363] show_stack from dump_stack_lvl+0x50/0x5c
> > [ 3.680377] dump_stack_lvl from __might_resched+0x160/0x174
> > [ 3.680393] __might_resched from rt_spin_lock+0x38/0x138
> > [ 3.680425] rt_spin_lock from force_sig_info_to_task+0x1c/0x11c
> > [ 3.680438] force_sig_info_to_task from force_sig_fault+0x44/0x64
> > [ 3.680450] force_sig_fault from do_PrefetchAbort+0x94/0x9c
> > [ 3.680461] do_PrefetchAbort from ret_from_exception+0x0/0x20
> > [ 3.680513] Exception stack(0xf0ab5fb0 to 0xf0ab5ff8)
> > [ 3.680653] 5fa0: 00000000 bed32e94 bed32e9c 00037954
> > [ 3.680672] 5fc0: 00000002 00000001 bed32e94 0009d590 00000000 bed32e9c 00000002 00000000
> > [ 3.680682] 5fe0: bed32d48 bed32d38 00037a00 00037958 60000010 ffffffff
> > ```
>
> I don't think this required information as it is obvious. At the very
> least you could trim it the needed parts if considered needed.
>
> > When PREEMPT_RT is enabled, force_sig_info() requires interrupts to be
> > enabled. Enable interrupts when arm_notify_die() is handling user mode
> > errors to fix the issue.
> >
> > Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT")
> >
> > Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
>
> So I did test the 32bit case on arm64 while testing/ backporting the
> breakpoint handling there but apparently did not try it on real
> arm32.
>
> For "asm("BKPT #0");" the SIGTRAP is not raised instead I get just
> | 8<--- cut here ---
> | Unhandled prefetch abort: debug event (0x222) at 0x00000000
>
> on the kernel side and a "Bus error" on userland side.
>
> So
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> for this but actual breakpoint handling might be broken or is it just
> me? But then your stack trace looks like mine so :/
ARM Linux doesn't use BKPT. BKPT was an instruction introduced by Arm
Ltd in ARMv5TE. Prior to this, we use a UDF instruction instead (we
had to pick something!) and gdb and other tools use that as a
breapoint.
Moreover, BKPT isn't guaranteed to trap to the kernel, especially when
there is a hardware debugger connected. In that case, DDI0100E states
that use of BKPT must be according to the instructions provided with
the hardware debugger. This makes BKPT unsuitable for use.
Consequently, ARM Linux has not supported the use of BKPT - no code
was added to support this instruction, hence why the kernel prints an
Alert level message stating that the fault was unhandled.
In addition, when a hardware debugger is not being used, with the
addition of hw_breakpoint.c, what userland sees in response depends on
kernel configuration. If hw_breakpoint.c is not built (when PERF_EVENTS
is disabled), then a SIGBUS signal will be raised. If it is built, and
prior to a recent commit by LinusW, it will raise a SIGTRAP. After
LinusW's commit, it won't raise a signal, but userspace will spin on
the BKPT instruction.
The path we go through in the above case is very much an "oh damn,
we aren't handling this exception, let's try to do something that
might save the day".
Rather than throwing local_irq_enable() in random places, it would
be better to do it earlier, but I would want to review what x86 does
when it gets an exception that the kernel doesn't handle - not sure
when I'll get around to doing that though.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 1/2] i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
From: Stefan Eichenberger @ 2026-06-25 9:04 UTC (permalink / raw)
To: Vincent Jardin
Cc: Oleksij Rempel, Pengutronix Kernel Team, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Wolfram Sang, Kaushal Butala,
Shawn Guo, Stefan Eichenberger, linux-i2c, imx, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <20260525-for-upstream-i2c-lx2160-fix-v1-v2-1-26a3cc8cd055@free.fr>
Sorry for the late reply.
On Mon, May 25, 2026 at 06:43:15PM +0200, Vincent Jardin wrote:
> SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic
> (polling) path rejects it as -EPROTO. Worse, it returns without a
> NACK+STOP: the next receive cycle has already started, so the target
> keeps holding SDA and the bus stays stuck until a power cycle for
> this i2c controller.
>
> Reading I2DR to obtain the count likewise arms the next byte on the
> count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly
> and left the bus held.
>
> Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so
> the existing last-byte handling emits STOP; the dummy byte is discarded.
> A count of 0 is a valid empty block read; a count above
> I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus
> has been released.
>
> The interrupt-driven path has the same flaw from a later commit and is
> fixed separately, as it carries a different Fixes: tag and stable range.
>
> Fixes: 8e8782c71595 ("i2c: imx: add SMBus block read support")
> Cc: <stable@vger.kernel.org> # v3.16+
> Signed-off-by: Vincent Jardin <vjardin@free.fr>
> ---
> drivers/i2c/busses/i2c-imx.c | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index a208fefd3c3b..14107e1ad413 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1415,6 +1415,7 @@ static int i2c_imx_atomic_read(struct imx_i2c_struct *i2c_imx,
> int i, result;
> unsigned int temp;
> int block_data = msgs->flags & I2C_M_RECV_LEN;
> + int block_err = 0;
>
> result = i2c_imx_prepare_read(i2c_imx, msgs, false);
> if (result)
> @@ -1436,8 +1437,20 @@ static int i2c_imx_atomic_read(struct imx_i2c_struct *i2c_imx,
> */
> if ((!i) && block_data) {
> len = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
> - if ((len == 0) || (len > I2C_SMBUS_BLOCK_MAX))
> - return -EPROTO;
> + if ((len == 0) || (len > I2C_SMBUS_BLOCK_MAX)) {
> + /*
> + * SMBus 3.1 6.5.7: support count byte of 0.
> + * I2C_SMBUS_BLOCK_MAX case should not hold the SDA either.
> + */
> + if (len > I2C_SMBUS_BLOCK_MAX)
> + block_err = -EPROTO;
> + temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> + temp |= I2CR_TXAK;
> + imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> + msgs->buf[0] = 0;
> + msgs->len = 2;
> + continue;
> + }
> dev_dbg(&i2c_imx->adapter.dev,
> "<%s> read length: 0x%X\n",
> __func__, len);
> @@ -1485,7 +1498,7 @@ static int i2c_imx_atomic_read(struct imx_i2c_struct *i2c_imx,
> "<%s> read byte: B%d=0x%X\n",
> __func__, i, msgs->buf[i]);
> }
> - return 0;
> + return block_err;
> }
Reviewed-by: Stefan Eichenberger <eichest@gmail.com>
^ permalink raw reply
* [PATCH] char: mem: keep arch range checks overflow-safe
From: Yousef Alhouseen @ 2026-06-25 8:58 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman
Cc: Russell King, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel, linux-arm-kernel,
linux-sh, Yousef Alhouseen
The generic /dev/mem physical range check now avoids validating
addr + size directly, but ARM and SH provide their own
valid_phys_addr_range() implementations with the same wrapped-addition
pattern.
Use subtraction-based upper-bound checks in those overrides as well. Also
make the ARM mmap pfn check avoid overflowing the pfn plus page-count
expression.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
arch/arm/mm/mmap.c | 9 +++++++--
arch/sh/mm/mmap.c | 4 +++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 3dbb383c2..7467ce8cd 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -150,9 +150,11 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
*/
int valid_phys_addr_range(phys_addr_t addr, size_t size)
{
+ phys_addr_t end = __pa(high_memory - 1) + 1;
+
if (addr < PHYS_OFFSET)
return 0;
- if (addr + size > __pa(high_memory - 1) + 1)
+ if (addr > end || size > end - addr)
return 0;
return 1;
@@ -163,5 +165,8 @@ int valid_phys_addr_range(phys_addr_t addr, size_t size)
*/
int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
{
- return (pfn + (size >> PAGE_SHIFT)) <= (1 + (PHYS_MASK >> PAGE_SHIFT));
+ unsigned long max_pfn = 1 + (PHYS_MASK >> PAGE_SHIFT);
+ unsigned long pages = size >> PAGE_SHIFT;
+
+ return pfn <= max_pfn && pages <= max_pfn - pfn;
}
diff --git a/arch/sh/mm/mmap.c b/arch/sh/mm/mmap.c
index c442734d9..ba7aade46 100644
--- a/arch/sh/mm/mmap.c
+++ b/arch/sh/mm/mmap.c
@@ -170,9 +170,11 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
*/
int valid_phys_addr_range(phys_addr_t addr, size_t count)
{
+ phys_addr_t end = __pa(high_memory);
+
if (addr < __MEMORY_START)
return 0;
- if (addr + count > __pa(high_memory))
+ if (addr > end || count > end - addr)
return 0;
return 1;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-25 8:56 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: <a13fb65c-726b-4c99-b741-29040c4564d0@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 09:01:18AM +0800, Jie Gan wrote:
[...]
> > > 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.
>
> Hi Suzuki/Leo
>
> Which solution do you prefer to address the issue?
I will leave this to Suzuki.
> The interconnect traceNoC platform driver is intended for the itnoc device,
> implying that no TPDM devices are connected to it. So, if I modify it to
> allocate an ATID, I think it would be better to rename the “itnoc” node
> accordingly? Or it's ok to leave it as-is?
>
> BTW, the traceNoC device definitely is an AMBA device with CID/PID
> registers.
Just to share a bit thoughts on the driver's design.
I think it would be better to keep the probe function generic. The AMBA
probe should not be specific to TraceNoC, and the platform probe should
not be only dedicated to the interconnect TraceNoC. The probe function
should simply handle a device that appears on either the AMBA bus or the
platform bus.
So the question is: if allocat an ATID for all traceNoC devices, do you
still need to distinguish TraceNoC types? If no, then the code can be
unified.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v15 03/11] arm64/ptrace: Use syscall_get_nr() helper for syscall_trace_enter()
From: Jinjie Ruan @ 2026-06-25 8:51 UTC (permalink / raw)
To: Ada Couprie Diaz
Cc: catalin.marinas, will, oleg, tglx, peterz, luto, kees, wad,
mark.rutland, yeoreum.yun, linusw, kevin.brodsky, ldv, thuth,
james.morse, song, anshuman.khandual, broonie, ryan.roberts,
pengcan, liqiang01, linux-arm-kernel, linux-kernel
In-Reply-To: <5ea376d7-388a-418c-acde-9ebe1da96202@arm.com>
On 6/24/2026 9:42 PM, Ada Couprie Diaz wrote:
> 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 !)
Hi Ada,
Yes, a word was missing: 'simpler' or 'smoother'.
Best regards,
Jinjie
>> - 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] ARM: enable interrupts when arm_notify_die() is handling user mode errors
From: Sebastian Andrzej Siewior @ 2026-06-25 8:50 UTC (permalink / raw)
To: Xie Yuanbin
Cc: linux, clrkwllms, rostedt, rmk+kernel, linusw, arnd,
linux-arm-kernel, linux-kernel, linux-rt-devel, liaohua4,
lilinjie8
In-Reply-To: <20260625073522.182503-1-xieyuanbin1@huawei.com>
On 2026-06-25 15:35:22 [+0800], Xie Yuanbin wrote:
> For lastest linux-next kernel, with default multi_v7_defconfig, and
> setting CONFIG_PREEMPT_RT=y, CONFIG_DEBUG_ATOMIC_SLEEP=y, and
> CONFIG_PERF_EVENTS=n. When the user program executes bkpt
> instruction, the following WARN will be triggered:
> ```log
> [ 3.677825] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
> [ 3.678002] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 84, name: test
> [ 3.678036] preempt_count: 0, expected: 0
> [ 3.678078] RCU nest depth: 0, expected: 0
> [ 3.678864] CPU: 0 UID: 0 PID: 84 Comm: test Tainted: G W 7.1.0-next-20260623 #45 PREEMPT_RT
> [ 3.679067] Tainted: [W]=WARN
> [ 3.679088] Hardware name: Generic DT based system
> [ 3.679198] Call trace:
> [ 3.679695] unwind_backtrace from show_stack+0x10/0x14
> [ 3.680363] show_stack from dump_stack_lvl+0x50/0x5c
> [ 3.680377] dump_stack_lvl from __might_resched+0x160/0x174
> [ 3.680393] __might_resched from rt_spin_lock+0x38/0x138
> [ 3.680425] rt_spin_lock from force_sig_info_to_task+0x1c/0x11c
> [ 3.680438] force_sig_info_to_task from force_sig_fault+0x44/0x64
> [ 3.680450] force_sig_fault from do_PrefetchAbort+0x94/0x9c
> [ 3.680461] do_PrefetchAbort from ret_from_exception+0x0/0x20
> [ 3.680513] Exception stack(0xf0ab5fb0 to 0xf0ab5ff8)
> [ 3.680653] 5fa0: 00000000 bed32e94 bed32e9c 00037954
> [ 3.680672] 5fc0: 00000002 00000001 bed32e94 0009d590 00000000 bed32e9c 00000002 00000000
> [ 3.680682] 5fe0: bed32d48 bed32d38 00037a00 00037958 60000010 ffffffff
> ```
I don't think this required information as it is obvious. At the very
least you could trim it the needed parts if considered needed.
> When PREEMPT_RT is enabled, force_sig_info() requires interrupts to be
> enabled. Enable interrupts when arm_notify_die() is handling user mode
> errors to fix the issue.
>
> Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT")
>
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
So I did test the 32bit case on arm64 while testing/ backporting the
breakpoint handling there but apparently did not try it on real
arm32.
For "asm("BKPT #0");" the SIGTRAP is not raised instead I get just
| 8<--- cut here ---
| Unhandled prefetch abort: debug event (0x222) at 0x00000000
on the kernel side and a "Bus error" on userland side.
So
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
for this but actual breakpoint handling might be broken or is it just
me? But then your stack trace looks like mine so :/
Sebastian
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Konrad Dybcio @ 2026-06-25 8:47 UTC (permalink / raw)
To: Bibek Kumar Patro, Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <aaf4daee-4886-4214-a761-80545d2565ee@oss.qualcomm.com>
On 6/19/26 12:54 PM, Bibek Kumar Patro wrote:
>
>
> On 6/18/2026 2:58 PM, Konrad Dybcio wrote:
>> On 6/17/26 4:26 PM, Bibek Kumar Patro wrote:
>>>
>>>
>>> On 6/16/2026 5:51 AM, Dmitry Baryshkov wrote:
>>>> On Mon, Jun 15, 2026 at 06:36:51PM +0530, Bibek Kumar Patro wrote:
>>>>>
>>>>>
>>>>> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
>>>>>> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>>>>>>> On some SoCs the SMMU registers require an active interconnect
>>>>>>> bandwidth vote to be accessible. While other clients typically
>>>>>>> satisfy this requirement implicitly, certain corner cases (e.g.
>>>>>>> during sleep/wakeup transitions) can leave the SMMU without a
>>>>>>> vote, causing intermittent register access failures.
>>>>>>>
>>>>>>> Add support for an optional interconnect path to the arm-smmu
>>>>>>> driver and vote for bandwidth while the SMMU is active. The path
>>>>>>> is acquired from DT if present and ignored otherwise.
>>>>>>>
>>>>>>> The bandwidth vote is enabled before accessing SMMU registers
>>>>>>> during probe and runtime resume, and released during runtime
>>>>>>> suspend and on error paths.
>>>>>>>
>>>>>>> Generally, from an architectural perspective, GEM_NOC and DDR are
>>>>>>> expected to have an active vote whenever the adreno_smmu block is
>>>>>>> powered on. In most common use cases, this requirement is implicitly
>>>>>>> satisfied because other GPU-related clients (for example, the GMU
>>>>>>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>>>>>>
>>>>>>> However, there are certain corner cases, such as during sleep/wakeup
>>>>>>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>>>>>>> is powered down. If adreno_smmu is then accessed while the interconnect
>>>>>>> vote is missing, it can lead to the observed failures. Because of the
>>>>>>> precise ordering involved, this scenario is difficult to reproduce
>>>>>>> consistently.
>>>>>>> (also GDSC is involved in adreno usecases can have an independent vote)
>>>>>>>
>>>>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>>>>>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>>>>>>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>>>>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>>>>> @@ -53,6 +53,11 @@
>>>>>>> #define MSI_IOVA_BASE 0x8000000
>>>>>>> #define MSI_IOVA_LENGTH 0x100000
>>>>>>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>>>>>>> +#define ARM_SMMU_ICC_AVG_BW 0
>>>>>>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>>>>>>
>>>>>> totally random numbers, which might be different for non-Qualcomm platform.
>>>>>>
>>>>>
>>>>> Ideally, any non-zero value would be enough to keep the path active.
>>>>
>>>> This is true for Qualcomm devices. However, you are adding this to a
>>>> generic code.
>>>>
>>>>> Here 1 Would be enough to keep the path active, but might be too small to
>>>>> reliably keep the bus active.
>>>>> Other is UINT_MAX, which will reliably keep the bus active but might cause a
>>>>> power penalty.
>>>>>
>>>>> #define ARM_SMMU_ICC_PEAK_BW_HIGH UINT_MAX
>>>>>
>>>>> seems to be suitable here to reliably keep the bus active by BCM
>>>>> for both Qualcomm and non-Qualcomm platforms (with some power penalty).
>>>>>
>>>>> LMK, if you feel otherwise.
>>>>
>>>> Shift it to the qcom instance or provide platform-specific values? (My
>>>> preference would be towards the first solution).
>>>>
>>>
>>>
>>> To support platform-specific values, we may need to introduce a LUT-based approach in the driver. (Bandwidth voting values cannot be placed in device-tree property IIRC ?)
>>>
>>> Currently, all Qualcomm platforms use 0x1000 for SMMU ICC voting. I
>>
>> (you used decimal 1000)
>>
>
> It's my bad, i meant 1000 only
> (I'll check on the icc_bw calculation to get clarity on the values)
>
>>> can evaluate if this could be moved to a Qualcomm-specific
>>> implementation.
>>
>> Add a vendor hook to arm_smmu_runtime_suspend/resume and handle it within
>> the QC driver
>>
>
> Just curious, wouldn't this apply for all the arm-smmu users in addition to Qualcomm devices as i mentioned here [1].
> Vendor hook would make it Qualcomm specific.
You're proposing to use a Qualcomm-specific bandwidth value so that
fits
Konrad
>
> [1]: https://lore.kernel.org/all/984ff9c7-3eef-463c-a330-bf7acd063667@oss.qualcomm.com/
>
> Thanks & regards,
> Bibek
>
>> Konrad
>
^ permalink raw reply
* Re: [PATCH 0/6] treewide: remove unnecessary invalid range checks in memblock iteration loops
From: Mike Rapoport @ 2026-06-25 8:46 UTC (permalink / raw)
To: Sang-Heon Jeon
Cc: Albert Ou, Andrew Morton, Andrey Ryabinin, Catalin Marinas,
Huacai Chen, Mike Rapoport, Muchun Song, Oscar Salvador,
Palmer Dabbelt, Paul Walmsley, Will Deacon, Alexander Potapenko,
Alexandre Ghiti, Andrey Konovalov, David Hildenbrand,
Dmitry Vyukov, kasan-dev, linux-arm-kernel, linux-mm, linux-riscv,
loongarch, Vincenzo Frascino, WANG Xuerui
In-Reply-To: <20260621145919.1453-1-ekffu200098@gmail.com>
On Sun, 21 Jun 2026 23:59:10 +0900, Sang-Heon Jeon <ekffu200098@gmail.com> wrote:
> treewide: remove unnecessary invalid range checks in memblock iteration loops
>
> The memblock API guarantees that for_each_mem_range() and
> for_each_mem_pfn_range() never return an invalid range, meaning start is
> always less than end.
>
> Several memblock callers still have unnecessary invalid range checks in
> their loop bodies, so remove them.
>
> [...]
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC v2 PATCH] reserve_mem: add support for static memory
From: Mike Rapoport @ 2026-06-25 8:37 UTC (permalink / raw)
To: Shyam Saini
Cc: linux-mm, linux-doc, linux-kernel, akpm, tgopinath, bboscaccy,
kees, tony.luck, gpiccoli, bp, rdunlap, peterz, feng.tang,
dapeng1.mi, elver, enelsonmoore, kuba, lirongqing, ebiggers,
Catalin Marinas, Will Deacon, Ard Biesheuvel, David Hildenbrand,
linux-arm-kernel
In-Reply-To: <ajyC2eX9MKSU84Z8@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Hi Shyam,
On Wed, Jun 24, 2026 at 06:22:33PM -0700, Shyam Saini wrote:
> On 21 Jun 2026 13:36, Mike Rapoport wrote:
> > On Thu, Jun 18, 2026 at 11:23:31PM -0700, Shyam Saini wrote:
> > > reserve_mem relies on dynamic memory allocation, this limits the
> > > usecase where memory is required to be preserved across the boots.
> > > Eg: ramoops memory reservation on ACPI platforms
> > >
> > > So add support to pass a pre-determined static address and reserve
> > > memory at a specified location. This enables use case like ramoops
> > > on ACPI platforms to reliably access ramoops region with previous
> > > boot logs.
> > >
> > > Also skip the parsing of <align> when static address is passed.
> > >
> > > Example syntax for static address
> > > reserve_mem=4M@0x1E0000000:oops
> >
> > reserve_mem is best effort by design because such hacks as well as memmap=
> > cannot guarantee this memory is actually free.
> >
> > If you want to preserve ramoops reliably, use KHO with reserve_mem.
> > The first kernel will allocate memory, this memory will be preserved by KHO
> > and could be picked up by the second kernel.
>
> ok, On ARM64 DTS systems, we can reserve ramoops memory in the device tree during
> the warm reboot.
The cc list actually implied x86 ;-)
Added arm64 folks now.
> For an equivalent ARM64 ACPI platform, what is the recommended way to reserve
> and preserve that memory across the boots?
I don't think it exists, but a command line option (be it memmap= or
reserve_mem=) does not seem the right way to me.
Most of the arguments that were made against adding memmap= to arm64 [1]
apply here.
If kexec is an option, KHO provides a reliable way to preserve memory
across boots.
If kexec is not an option, we should look for a generic way to specify
something like DT's reserved_mem for ACPI/EFI systems.
[1] https://lkml.kernel.org/lkml/20201118063314.22940-1-song.bao.hua@hisilicon.com/T/
> Thanks,
> Shyam
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v7 04/30] drm/display: scdc_helper: Add HDMI 2.0 scrambling management helpers
From: Cristian Ciocaltea @ 2026-06-25 8:27 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Sandy Huang,
Heiko Stübner, Andy Yan, Daniel Stone, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260625-screeching-uptight-elephant-5bdaed@houat>
On 6/25/26 11:05 AM, Maxime Ripard wrote:
> On Tue, Jun 02, 2026 at 01:44:04AM +0300, Cristian Ciocaltea wrote:
>> +static int drm_scdc_reset_crtc(struct drm_connector *connector,
>> + struct drm_modeset_acquire_ctx *ctx)
>> +{
>> + struct drm_device *dev = connector->dev;
>> + struct drm_crtc *crtc;
>> + u8 config;
>> + int ret;
>> +
>> + if (!ctx)
>> + return 0;
>> +
>> + /*
>> + * This is normally part of .detect_ctx() call path, which already holds
>> + * connection_mutex through @ctx. However, re-acquiring it with the
>> + * same context is a no-op and makes the helper safe under any caller.
>> + */
>> + ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
>> + if (ret)
>> + return ret;
>> +
>> + if (!connector->state)
>> + return 0;
>> +
>> + crtc = connector->state->crtc;
>> + if (!crtc)
>> + return 0;
>> +
>> + ret = drm_scdc_readb(connector->ddc, SCDC_TMDS_CONFIG, &config);
>> + if (ret) {
>> + drm_scdc_dbg(connector, "Failed to read TMDS config: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if ((config & SCDC_SCRAMBLING_ENABLE) &&
>> + (config & SCDC_TMDS_BIT_CLOCK_RATIO_BY_40))
>> + return 0;
>
> I don't think we should care about the bit clock ratio here. From a
> technical standpoint, and since you ignore low rates for the scrambler
> for now, they are indeed equivalents. But semantically, scrambler can be
> enabled for any rate, and the bit clock ratio should be changed only for
> rates higher than 340MHz.
>
> This function makes sure to trigger a modeset when the scrambler is
> enabled or not. From a spec point of view, it's somewhat orthogonal to
> the bit clock ratio. From a function name point of view, it's
> misleading.
>
> So yeah, I'd just drop the check on the bit clock ratio here. Drivers
> will then get to enable either when the commit actually happens.
Ack.
Thanks,
Cristian
^ permalink raw reply
* Re: [RFC PATCH 1/6] media: mc: Implement shared media graph
From: Paul Elder @ 2026-06-25 8:23 UTC (permalink / raw)
To: Kieran Bingham, laurent.pinchart
Cc: michael.riesch, xuhf, stefan.klug, dan.scally, jacopo.mondi,
linux-media, linux-arm-kernel, linux-rockchip, linux-kernel,
hverkuil+cisco, nicolas.dufresne, ribalda, sakari.ailus
In-Reply-To: <178229758404.3075020.12553514371020830845@ping.linuxembedded.co.uk>
Hi Kieran,
Thanks for the not-necessarily-a-full review.
Quoting Kieran Bingham (2026-06-24 19:39:44)
> Hi Paul,
>
> I'm taking a first read through, some comments inline, but not
> necessarily a full review:
>
> Quoting Paul Elder (2026-06-19 06:26:28)
> > Currently, a media graph contains a main device whose driver is
> > responsible for creating the media device. We have however recently run
> > into devices that have multiple devices that can quality as a main
>
> s/quality/qualify/
>
> > device. Examples are the RK3588 which has a VICAP and two ISP
> > instances, and another example is the i.MX8MP which has an ISI and two
> > ISP instances. As there is currently no way to reconcile who the main
> > device is in the media device, these setups simple cannot be used
> > simultaneously.
>
> I'm very excited to see how we could apply this to the NXP i.MX8MP to
> resolve the ISI+ISP issue!
\o/
>
>
> > This patch extends the media controller API with a "shared media graph"
> > framework. This allows drivers to share a media device, thus enabling
> > the setups mentioned above. Instead of owning and creating a media
> > device, drivers can join-or-create a shared media device via the shared
> > media graph API. The matching is done automatically based on the
> > detected endpoints in the device tree.
>
> Sounds great! I'll read on...
>
> >
> > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > ---
> > drivers/media/mc/Makefile | 2 +-
> > drivers/media/mc/mc-shared-graph.c | 335 +++++++++++++++++++++++++++++
> > include/media/mc-shared-graph.h | 92 ++++++++
> > 3 files changed, 428 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/media/mc/mc-shared-graph.c
> > create mode 100644 include/media/mc-shared-graph.h
> >
> > diff --git a/drivers/media/mc/Makefile b/drivers/media/mc/Makefile
> > index 2b7af42ba59c..1d502fdc52ad 100644
> > --- a/drivers/media/mc/Makefile
> > +++ b/drivers/media/mc/Makefile
> > @@ -1,7 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > mc-objs := mc-device.o mc-devnode.o mc-entity.o \
> > - mc-request.o
> > + mc-request.o mc-shared-graph.o
> >
> > ifneq ($(CONFIG_USB),)
> > mc-objs += mc-dev-allocator.o
> > diff --git a/drivers/media/mc/mc-shared-graph.c b/drivers/media/mc/mc-shared-graph.c
> > new file mode 100644
> > index 000000000000..c4067e5b861d
> > --- /dev/null
> > +++ b/drivers/media/mc/mc-shared-graph.c
> > @@ -0,0 +1,335 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * mc-shared-graph.c - Media Controller Shared Graph API
> > + *
> > + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> > + */
> > +
> > +/*
> > + * This file adds the Media Controller Shared Graph API. This allows drivers
> > + * to create shared media graphs or join existing media graphs from other
> > + * drivers, so that they can all be in the same media graph. This allows us to
> > + * have more complex media graphs chaining more complex hardware together,
> > + * instead of simple async subdevs.
> > + */
> > +
> > +#include <linux/device.h>
> > +#include <linux/fwnode.h>
> > +#include <linux/kref.h>
> > +#include <linux/property.h>
> > +
> > +#include <media/media-device.h>
> > +
> > +#include <media/mc-shared-graph.h>
> > +
> > +static LIST_HEAD(media_device_shared_list);
> > +static DEFINE_MUTEX(media_device_shared_lock);
> > +
> > +struct media_device_shared_member {
> > + struct device *dev;
> > + struct fwnode_handle *fwnode;
> > + struct list_head list;
> > +};
> > +
> > +struct media_device_shared_link {
> > + struct media_entity *source;
> > + u16 source_pad;
> > + struct media_entity *sink;
> > + u16 sink_pad;
> > + u32 flags;
> > + struct list_head list;
> > +};
> > +
> > +// TODO figure out locking for when multiple drivers touch the media graph;
> > +// maybe macros for shared versions?
>
> Do you mean for when drivers are trying to change link state directly?
I meant for all the operations that act on media device. I'm not sure what
there is because I didn't really find anything significant, and I found some
action point from some meeting notes somewhere that said "deprecate media_ops"
(not assigned to me) so...
If there aren't any then it's a non-issue, but if there are then I was
wondering if we need to return the shared media device to the driver (as
opposed to a non-shared regular media device) and use shared versions of media
device functions that have locking.
>
> > +struct media_device_shared {
> > + struct media_device mdev;
> > + struct list_head members;
> > + struct list_head links;
> > +
> > + struct list_head list;
> > + struct kref refcount;
> > +
> > + struct device *removed_device;
> > +};
> > +
> > +static inline struct media_device_shared *
> > +to_media_device_shared(struct media_device *mdev)
> > +{
> > + return container_of(mdev, struct media_device_shared, mdev);
> > +}
> > +
> > +static void media_device_shared_release(struct kref *kref)
> > +{
> > + struct media_device_shared *mds =
> > + container_of(kref, struct media_device_shared, refcount);
> > +
> > + dev_dbg(mds->removed_device, "%s: releasing Media Device\n", __func__);
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + media_device_unregister(&mds->mdev);
> > + media_device_cleanup(&mds->mdev);
> > +
> > + list_del(&mds->list);
> > + mutex_unlock(&media_device_shared_lock);
> > +
> > + kfree(mds);
> > +}
> > +
> > +/* Callers should hold media_device_shared_lock when calling this function */
>
> Lets add a lockdep_assert then?
I learned something new today :)
>
>
> > +static bool __media_device_shared_find_match(struct media_device_shared *mds,
> > + struct fwnode_handle *fwnode)
> > +{
> > + struct media_device_shared_member *member;
> > + struct fwnode_handle *ep;
> > + struct fwnode_handle *remote_ep;
> > + bool match = false;
> > +
>
> is it just as easy as:
>
> lockdep_assert_held(&media_device_shared_lock);
> ?
If I understand correctly how lockdep_assert works, yes.
>
> > + // TODO: parse the device tree endpoints graph instead of finding just the
> > + // first-level neighbours
> > + fwnode_graph_for_each_endpoint(fwnode, ep) {
> > + list_for_each_entry(member, &mds->members, list) {
> > + remote_ep = fwnode_graph_get_remote_port_parent(ep);
> > + match = (member->fwnode == remote_ep);
> > + fwnode_handle_put(remote_ep);
> > +
> > + if (!match)
> > + continue;
> > +
> > + goto match_complete;
> > + }
> > + }
> > +
> > +match_complete:
> > + fwnode_handle_put(ep);
> > + return match;
> > +}
> > +
> > +/* Callers should hold media_device_shared_lock when calling this function */
>
> Lets add a lockdep check too then :D (same everywhere/anywhere it's
> needed)
>
>
> > +static struct media_device *__media_device_shared_get(struct device *dev)
> > +{
> > + struct media_device_shared *mds;
> > + struct media_device_shared_member *member;
> > + struct fwnode_handle *fwnode = dev_fwnode(dev);
> > + bool ret;
> > +
> > + dev_dbg(dev, "%s: searching for media device for %pfwf", __func__, fwnode);
> > +
> > + list_for_each_entry(mds, &media_device_shared_list, list) {
> > + ret = __media_device_shared_find_match(mds, fwnode);
> > + if (ret)
> > + break;
> > + }
> > +
> > + if (!ret)
> > + return NULL;
> > +
> > + member = kzalloc_obj(*member);
> > + if (!member)
> > + return NULL;
> > +
> > + member->dev = dev;
> > + member->fwnode = fwnode;
> > + list_add_tail(&member->list, &mds->members);
> > + kref_get(&mds->refcount);
> > +
> > + dev_dbg(dev, "%s: %pfwf joined media device of %pfwf",
> > + __func__, fwnode,
> > + list_first_entry(&mds->members, struct media_device_shared_member, list)->fwnode);
> > +
> > + return &mds->mdev;
> > +}
> > +
> > +/* Callers should hold media_device_shared_lock when calling this function */
> > +static struct media_device *__media_device_shared_create(struct device *dev)
> > +{
> > + struct media_device_shared *mds;
> > + struct media_device_shared_member *member;
> > + struct fwnode_handle *fwnode = dev_fwnode(dev);
> > + int ret;
> > +
> > + mds = kzalloc_obj(*mds);
> > + if (!mds)
> > + return NULL;
> > +
> > + member = kzalloc_obj(*member);
> > + if (!member)
> > + goto err_free_mds;
> > +
> > + media_device_init(&mds->mdev);
> > +
> > + ret = media_device_register(&mds->mdev);
> > + if (ret)
> > + goto err_free_member;
> > +
> > + INIT_LIST_HEAD(&mds->members);
> > + member->dev = dev;
> > + member->fwnode = fwnode;
> > + list_add_tail(&member->list, &mds->members);
> > +
> > + INIT_LIST_HEAD(&mds->links);
> > +
> > + kref_init(&mds->refcount);
> > + list_add_tail(&mds->list, &media_device_shared_list);
> > +
> > + // TODO figure out how to reconcile this with multiple members
>
> Aha, right - becuse the 'media_device dev' becomes whoever registers first.
> I wonder where it's actually used, and maybe that's ok ?
Yes, exactly. So far all I could find it used for was dev_err etc. In my
testing it hasn't caused any problems, since I tested both loading orders
between the rkcif and rkisp2. Maybe I missed something important and somebody
else knows better.
Although it's not very nice to have prints from the other device. Is making a
thin device an option?
>
> > + mds->mdev.dev = dev;
> > +
> > + devv_dbg(dev, "%s: Allocated media device with %pfwf at %p\n",
> > + __func__, fwnode, &mds->mdev);
> > + return &mds->mdev;
> > +
> > +err_free_member:
> > + kfree(member);
> > +err_free_mds:
> > + kfree(mds);
> > + return NULL;
> > +}
> > +
> > +// TODO figure out how to resolve the identifiers (model, driver name, etc);
> > +// atm it's racy and whoever gets it last wins
>
> Maybe that's something we need to pass or set up explicitly then, so
> it's clear it's a 'specific graph'
Yes. I have no clue where that name would come from though.
Although I thought userspace matches on the entity names of the media device?
Does the name of the graph matter? It needs to be consistent though imo.
I considered having a list of names of members, but I'm not sure how useful
that would be. We don't have a userspace API to check it, plus it can already
just list the member entities of the graph. And the driver doesn't really care
who else is in the graph, since the shared media graph machinery already
automatches based on dt endpoints.
Also imo it's also not too nice for userspace when {driver_name} refers to a
driver that doesn't exist.
>
> Would this give us a way to represent the hardware in a new form - i.e.
> thinking about IMX8MP - the existing graph wouldn't be available - so it
> wouldn't be any worry from a UABI perspective because it's just a whole
> new interface/media-device name....
Hm, maybe the media device name could just be something along the lines of
"shared-{platform_name}-media"? Although I suppose that assumes that each
platform only has one media graph and we'll run into problems when we have
multiple. Or we append the youngest register block address in the shared media
graph to the name?
>
>
>
> > +struct media_device *media_device_shared_join(struct device *dev)
> > +{
> > + struct media_device *mdev;
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + mdev = __media_device_shared_get(dev);
> > + if (!!mdev) {
> > + dev_dbg(dev, "%s: found media device for %pfwf", __func__, dev_fwnode(dev));
> > + mutex_unlock(&media_device_shared_lock);
> > + return mdev;
> > + }
> > +
> > + mdev = __media_device_shared_create(dev);
> > + if (!mdev) {
> > + dev_warn(dev, "%s: failed to create media device for %pfwf", __func__, dev_fwnode(dev));
> > + mutex_unlock(&media_device_shared_lock);
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + dev_dbg(dev, "%s: created media device for %pfwf", __func__, dev_fwnode(dev));
> > + mutex_unlock(&media_device_shared_lock);
> > + return mdev;
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_shared_join);
> > +
> > +void media_device_shared_leave(struct media_device *mdev, struct device *dev)
> > +{
> > + struct media_device_shared *mds = to_media_device_shared(mdev);
> > + struct media_device_shared_member *member;
> > + struct media_device_shared_member *member_tmp;
> > + bool removed = false;
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + list_for_each_entry_safe(member, member_tmp, &mds->members, list) {
> > + if (member->dev == dev) {
> > + list_del(&member->list);
> > + kfree(member);
> > + removed = true;
> > + }
> > + }
> > +
> > + if (!removed)
> > + dev_err(dev, "%s: %pfwf trying to leave from graph in which not a member",
> > + __func__, dev_fwnode(dev));
> > +
> > + mds->removed_device = dev;
> > + mutex_unlock(&media_device_shared_lock);
> > + kref_put(&mds->refcount, media_device_shared_release);
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_shared_leave);
> > +
> > +int media_device_shared_join_link_source(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *source,
> > + u16 source_pad, u32 flags)
> > +{
> > + struct media_device_shared *mds = to_media_device_shared(mdev);
> > + struct media_device_shared_link *link;
> > + struct media_device_shared_link *link_tmp;
> > + int ret = 0;
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + /*
> > + * TODO Figure out flags. Should we use greatest common denominator? Or
> > + * prioritize sink? Or whoever wins the race? For now we just take the flags
> > + * from the sink.
> > + *
> > + * TODO Figure out how to actually do the matching. For now we just match
> > + * whoever comes in first. This works with the simple example we're running
> > + * with now (rkcif + one rkisp2) but with setups with multiple copies of
> > + * hardware this will cause problems, like with rkcif + two rkisp2 and
> > + * imx8-isi + two rkisp1.
> > + */
> > + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> > + if (link->sink) {
> > + ret = media_create_pad_link(source, source_pad,
> > + link->sink, link->sink_pad,
> > + link->flags);
> > + list_del(&link->list);
> > + kfree(link);
> > + goto exit_join_link_source;
> > + }
> > + }
> > +
> > + link = kzalloc_obj(*link);
> > + if (!link) {
> > + ret = -ENOMEM;
> > + goto exit_join_link_source;
> > + }
> > +
> > + link->source = source;
> > + link->source_pad = source_pad;
> > + link->flags = flags;
> > + list_add_tail(&link->list, &mds->links);
> > +
> > +exit_join_link_source:
> > + mutex_unlock(&media_device_shared_lock);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_shared_join_link_source);
> > +
> > +// TODO deduplicate from above
>
> Indeed, it does look like an opportunity.
Ok this is the one exception that was an actual todo and not a topic for
discussion :)
(Unless someone has the opinion "actually we don't need to deduplicate this")
>
> > +int media_device_shared_join_link_sink(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *sink,
> > + u16 sink_pad, u32 flags)
> > +{
> > + struct media_device_shared *mds = to_media_device_shared(mdev);
> > + struct media_device_shared_link *link;
> > + struct media_device_shared_link *link_tmp;
> > + int ret = 0;
> > +
> > + mutex_lock(&media_device_shared_lock);
> > +
> > + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> > + if (link->source) {
> > + ret = media_create_pad_link(link->source, link->source_pad,
> > + sink, sink_pad,
> > + flags);
> > + list_del(&link->list);
> > + kfree(link);
> > + goto exit_join_link_sink;
> > + }
> > + }
> > +
> > + link = kzalloc_obj(*link);
> > + if (!link) {
> > + ret = -ENOMEM;
> > + goto exit_join_link_sink;
> > + }
> > +
> > + link->sink = sink;
> > + link->sink_pad = sink_pad;
> > + link->flags = flags;
> > + list_add_tail(&link->list, &mds->links);
> > +
> > +exit_join_link_sink:
> > + mutex_unlock(&media_device_shared_lock);
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(media_device_shared_join_link_sink);
> > diff --git a/include/media/mc-shared-graph.h b/include/media/mc-shared-graph.h
> > new file mode 100644
> > index 000000000000..487325163f84
> > --- /dev/null
> > +++ b/include/media/mc-shared-graph.h
> > @@ -0,0 +1,92 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * mc-shared-graph.h - Media Controller Shared Graph API
> > + *
> > + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> > + */
> > +
> > +/*
> > + * This file adds the Media Controller Shared Graph API. This allows drivers
> > + * to create shared media graphs or join existing media graphs from other
> > + * drivers, so that they can all be in the same media graph. This allows us to
> > + * have more complex media graphs chaining more complex hardware together,
> > + * instead of simple async subdevs.
> > + */
> > +
> > +#include <linux/types.h>
> > +
> > +#ifndef _MEDIA_SHARED_GRAPH_H
> > +#define _MEDIA_SHARED_GRAPH_H
> > +
> > +struct device;
> > +struct media_device;
> > +struct media_entity;
> > +
> > +#if defined(CONFIG_MEDIA_CONTROLLER)
> > +/**
> > + * media_device_shared_join() - Join or create a new shared media device
> > + *
> > + * @dev: struct &device pointer
> > + *
> > + * This is the entrance function for a device to join or create a new shared
> > + * media device. It searches for an existing shared media device based on the
> > + * neighbours in the device's device tree ports node. If found, then this
> > + * functions returns the existing shared media device and joins it. If one is
> > + * not found then one is created and initialized and returned.
> > + */
> > +struct media_device *media_device_shared_join(struct device *dev);
> > +
> > +/**
> > + * media_device_shared_leave() - Leave the shared media device.
> > + *
> > + * @mdev: struct &media_device pointer
> > + * @dev: struct &device pointer
> > + *
> > + * This function makes the device leave the shared media device. When all
> > + * members have left the media device it will be freed.
> > + */
> > +void media_device_shared_leave(struct media_device *mdev, struct device *dev);
> > +
> > +/**
> > + * media_device_shared_join_link_source() - Register a link source in the shared media device
> > + *
> > + * @mdev: The struct &media_device pointer that is part of a shared media device
> > + * @dev: struct &device pointer
> > + * @source: The link source
> > + * @source_pad: The pad
> > + * @flags: The flags
> > + *
> > + * This function registers with the shared media device the source part of a
> > + * link. When the shared media device receives the matching sink part of a link
> > + * via media_device_shared_join_link_sink() then the link will be fully created.
> > + */
> > +int media_device_shared_join_link_source(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *source,
> > + u16 source_pad, u32 flags);
> > +
> > +/**
> > + * media_device_shared_join_link_sink() - Register a link sink in the shared media device
> > + *
> > + * Same as media_device_shared_join_link_source() but for sink instead of
> > + * source.
> > + */
> > +int media_device_shared_join_link_sink(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *sink,
> > + u16 sink_pad, u32 flags);
> > +#else
> > +static inline struct media_device *media_device_shared_join(struct device *dev)
> > +{ return NULL; }
> > +static inline void media_device_shared_leave(struct media_device *mdev,
> > + struct device *dev) { }
> > +static inline int media_device_shared_join_link_source(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *source,
> > + u16 source_pad, u32 flags) { }
> > +static inline int media_device_shared_join_link_sink(struct media_device *mdev,
> > + struct device *dev,
> > + struct media_entity *sink,
> > + u16 sink_pad, u32 flags) { }
>
> Should these two stubs which return an int return an error code? -ENODEV or such ?
Ah yes they should. I missed that.
Thanks,
Paul
>
>
> > +#endif /* CONFIG_MEDIA_CONTROLLER */
> > +#endif /* _MEDIA_DEV_SHARED_GRAPH_H */
> > --
> > 2.47.2
> >
^ permalink raw reply
* Re: [PATCH v7 25/30] drm/vc4: hdmi: Convert to common HDMI 2.0 SCDC scrambling helpers
From: Cristian Ciocaltea @ 2026-06-25 8:19 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Sandy Huang,
Heiko Stübner, Andy Yan, Daniel Stone, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260625-busy-ultra-oryx-ffb3c9@houat>
On 6/25/26 10:44 AM, Maxime Ripard wrote:
> On Sat, Jun 13, 2026 at 03:41:20AM +0300, Cristian Ciocaltea wrote:
>> Hi Maxime,
>>
>> On 6/12/26 3:04 PM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Tue, Jun 02, 2026 at 01:44:25AM +0300, Cristian Ciocaltea wrote:
>>>> Replace the vc4-local scrambling implementation with the newly
>>>> introduced DRM common SCDC scrambling infrastructure:
>>>>
>>>> - Advertise source-side scrambling support by setting
>>>> connector->hdmi.scrambling_supported based on the variant's
>>>> max_pixel_clock before drmm_connector_hdmi_init().
>>>>
>>>> - Provide minimal .scrambler_{enable|disable} connector callbacks that
>>>> only toggle the VC5 HDMI_SCRAMBLER_CTL register. Sink-side SCDC
>>>> programming and periodic status monitoring are now delegated to
>>>> drm_scdc_{start|stop}_scrambling().
>>>>
>>>> - Replace vc4_hdmi_enable_scrambling() with a conditional call to
>>>> drm_scdc_start_scrambling() in post_crtc_enable, gated on
>>>> conn_state->hdmi.scrambler_needed (computed by the HDMI state helper).
>>>>
>>>> - Replace vc4_hdmi_disable_scrambling() with drm_scdc_stop_scrambling()
>>>> in post_crtc_disable.
>>>>
>>>> - Drop vc4_hdmi_reset_link() and vc4_hdmi_handle_hotplug(), switching
>>>> the .detect_ctx() path to
>>>> drm_atomic_helper_connector_hdmi_hotplug_ctx() which internally calls
>>>> drm_scdc_sync_status() to trigger a CRTC reset on reconnection.
>>>>
>>>> - Drop the local scrambling_work delayed workqueue and scdc_enabled
>>>> flag, now tracked by the common drm_connector_hdmi layer.
>>>>
>>>> - Drop vc4_hdmi_supports_scrambling() and
>>>> vc4_hdmi_mode_needs_scrambling() helpers, inlining the remaining 4KP60
>>>> warning with an explicit drm_hdmi_compute_mode_clock() check.
>>>>
>>>> - Seed connector->hdmi.scrambler_enabled = true in connector_init() to
>>>> ensure drm_scdc_stop_scrambling() runs at boot and disables any stale
>>>> scrambling state left by the bootloader.
>>>>
>>>> No functional change is expected for the supported modes.
>>>>
>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>>
>>> I'd really like it to be broken down into several patches:
>>>
>>>> ---
>>>> drivers/gpu/drm/vc4/vc4_hdmi.c | 265 ++++++-----------------------------------
>>>> drivers/gpu/drm/vc4/vc4_hdmi.h | 8 --
>>>> 2 files changed, 35 insertions(+), 238 deletions(-)
>>>>
[...]
>>>> -
>>>> - /*
>>>> - * HDMI 2.0 says that one should not send scrambled data
>>>> - * prior to configuring the sink scrambling, and that
>>>> - * TMDS clock/data transmission should be suspended when
>>>> - * changing the TMDS clock rate in the sink. So let's
>>>> - * just do a full modeset here, even though some sinks
>>>> - * would be perfectly happy if were to just reconfigure
>>>> - * the SCDC settings on the fly.
>>>> - */
>>>> - return drm_atomic_helper_reset_crtc(crtc, ctx);
>>>> -}
>>>
>>> This one doesn't look functionally equivalent to me to
>>> drm_scdc_reset_crtc: this part was, in part, making sure we would only
>>> reset the scrambler if it was enabled in the first place.
>>> drm_scdc_reset_crtc() doesn't and will always trigger a modeset on
>>> hotplug. That's unnecessary and a significant functional different.
>>
>> drm_scdc_reset_crtc() alone was not meant to be an equivalent of
>> vc4_hdmi_reset_link(), as it only checks the sink side and it serves as an
>> internal helper used exclusively by drm_scdc_sync_status().
>>
>> As a matter of fact, the latter is the one responsible for verifying if the
>> scrambler was enabled on the controller side before attempting to invoke the
>> reset logic, hence we should get the same behavior. But we don't invoke it
>> directly either, it's part of the drm_atomic_helper_connector_hdmi_hotplug_ctx()
>> call path.
>
> Oh, right, sorry.
>
>>> I'd argue that it's drm_scdc_reset_crtc() that needs to align to what
>>> vc4 was doing, not the opposite.
>>
>> The only difference consists in dropping the crtc state check:
>>
>> ret = drm_modeset_lock(&crtc->mutex, ctx);
>> if (ret)
>> return ret;
>>
>> crtc_state = crtc->state;
>> if (!crtc_state->active)
>> return 0;
>>
>> The rationale was that when CRTC is inactive, drm_atomic_helper_reset_crtc()
>> should result in a no-op commit anyway.
>
> A commit is expensive, so I'd skip it if we can.
>
>> And the one for the in-flight commit:
>>
>> if (conn_state->commit &&
>> !try_wait_for_completion(&conn_state->commit->hw_done)) {
>> mutex_unlock(&vc4_hdmi->mutex);
>> return 0;
>> }
>
> And yeah, we'll need this one too.
>
>> Both checks are also missing in drm_bridge_helper_reset_crtc(), taken as an
>> initial reference. Should we still keep any/both and sync the bridge helper
>> accordingly?
>
> Yes, but I'd expect the bridge helpers to converge / reuse your helpers
> eventually anyway?
Ack.
[...]
>>>> - vc4_hdmi_disable_scrambling(encoder);
>>>> + drm_scdc_stop_scrambling(&vc4_hdmi->connector);
>>>
>>> I don't think the names here are right. It's not *only* related to scdc
>>> but also to the HDMI controller. I'm fine with using a scdc prefix but
>>> only for the things related to scdc. This is related (in part) to the
>>> HDMI controller, so it should use a drm_connector_hdmi prefix.
>>
>> Ack. I guess we should also move these helpers out of drm_scdc_helper.c, but
>> unsure where. FWIW I'm currently working on adding HDMI 2.1 FRL support, and
>> implemented the link training in a dedicated drm_hdmi_frl_helper.c.
>>
>> Should we create drm_hdmi_scrambler_helper.c? Or maybe have a common one to
>> hold both - any suggestion for the naming?
>
> display/drm_hdmi_helper.c sounds like a great place for both?
Indeed, let's move all the stuff there.
>>>> drm_dev_exit(idx);
>>>>
>>>> @@ -1625,6 +1434,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder,
>>>> struct drm_display_info *display = &vc4_hdmi->connector.display_info;
>>>> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
>>>> bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
>>>> + struct drm_connector_state *conn_state;
>>>> unsigned long flags;
>>>> int ret;
>>>> int idx;
>>>> @@ -1693,7 +1503,10 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder,
>>>> }
>>>>
>>>> vc4_hdmi_recenter_fifo(vc4_hdmi);
>>>> - vc4_hdmi_enable_scrambling(encoder);
>>>> +
>>>> + conn_state = drm_atomic_get_new_connector_state(state, connector);
>>>> + if (conn_state && conn_state->hdmi.scrambler_needed)
>>>> + drm_scdc_start_scrambling(connector);
>>>
>>> And the nice thing with a drm_connector_hdmi_* prefix is that you don't
>>> have to shoehorn it into SCDC support anymore, so you can take a state
>>> as an argument, and do the check in the helper instead of doing it in
>>> every driver and hoping they get it right.
>>
>> I was about to consider a similar approach before deciding to let drivers manage
>> the logic, i.e. to prevent loosing flexibility later when dealing with HDMI 2.1.
>> That was mostly in the context of supporting drivers to define if/when a display
>> mode that fits in TMDS should be sent over FRL.
>>
>> Thinking again, that's not really a valid concern right now, e.g. will use TMDS
>> by default for all supported modes, and switch to FRL only when absolutely
>> required. Later we might consider extending the infrastructure to support
>> dynamic control if required.
>
> Thanks for working on FRL as well :)
>
> I agree, let's focus on getting HDMI 2.0 right, and then we'll try to
> make 2.1 the easiest to work with for drivers.
Thanks for clarifying the remaining details — I should now have everything I
need to prepare a new revision. :)
Regards,
Cristian
^ permalink raw reply
* Re: [PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver
From: Philipp Zabel @ 2026-06-25 8:17 UTC (permalink / raw)
To: Stefan Dösinger, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <7_XKp5ZWTJeJfxJieymOJA@gmail.com>
On Mi, 2026-06-24 at 23:00 +0300, Stefan Dösinger wrote:
> Hi Philipp,
>
> Am Donnerstag, 18. Juni 2026, 12:24:26 Ostafrikanische Zeit schrieb Philipp
> Zabel:
>
> > > + [ZX297520V3_UART0_RESET] = { .reg = 0x78, .mask = BIT(6) |
> BIT(7)
> > > },
> > Is this a single reset line controlled by two bits (do you know what
> > they are)? Or might these actually be two different reset controls that
> > are just always set together?
>
> I suppose I could expose both bits as separate reset controls in the binding.
> The lower bit is usually the one that actually resets the device, while the
> higher one works similarly to PCLK - it disconnects the device from the bus,
> if asserted. Depending on the device it may or may not leave any residual
> effect behind after deassert.
So it's not a separate reset.
Whether bus isolation should be controlled together with the reset or
not could be argued, but exposing this as a separate reset control via
the reset API would not be correct.
> The stumbling block is the dwc2 USB driver. It only takes one reset, so I'd
> have to add another one (or abuse the dwc2-ecc reset) and presumably add a PHY
> driver for the 3rd reset or add a dwc2-phy reset.
This on the other hand sounds like there is a separate PHY reset line?
If so, I think that should be modeled as a separate control.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v7 04/30] drm/display: scdc_helper: Add HDMI 2.0 scrambling management helpers
From: Maxime Ripard @ 2026-06-25 8:05 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Sandy Huang,
Heiko Stübner, Andy Yan, Daniel Stone, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260602-dw-hdmi-qp-scramb-v7-4-445eb54ee1ed@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
On Tue, Jun 02, 2026 at 01:44:04AM +0300, Cristian Ciocaltea wrote:
> +static int drm_scdc_reset_crtc(struct drm_connector *connector,
> + struct drm_modeset_acquire_ctx *ctx)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_crtc *crtc;
> + u8 config;
> + int ret;
> +
> + if (!ctx)
> + return 0;
> +
> + /*
> + * This is normally part of .detect_ctx() call path, which already holds
> + * connection_mutex through @ctx. However, re-acquiring it with the
> + * same context is a no-op and makes the helper safe under any caller.
> + */
> + ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> + if (ret)
> + return ret;
> +
> + if (!connector->state)
> + return 0;
> +
> + crtc = connector->state->crtc;
> + if (!crtc)
> + return 0;
> +
> + ret = drm_scdc_readb(connector->ddc, SCDC_TMDS_CONFIG, &config);
> + if (ret) {
> + drm_scdc_dbg(connector, "Failed to read TMDS config: %d\n", ret);
> + return ret;
> + }
> +
> + if ((config & SCDC_SCRAMBLING_ENABLE) &&
> + (config & SCDC_TMDS_BIT_CLOCK_RATIO_BY_40))
> + return 0;
I don't think we should care about the bit clock ratio here. From a
technical standpoint, and since you ignore low rates for the scrambler
for now, they are indeed equivalents. But semantically, scrambler can be
enabled for any rate, and the bit clock ratio should be changed only for
rates higher than 340MHz.
This function makes sure to trigger a modeset when the scrambler is
enabled or not. From a spec point of view, it's somewhat orthogonal to
the bit clock ratio. From a function name point of view, it's
misleading.
So yeah, I'd just drop the check on the bit clock ratio here. Drivers
will then get to enable either when the commit actually happens.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH] pinctrl: imx1: fix device_node leak in dt_is_flat_functions()
From: Linus Walleij @ 2026-06-25 8:04 UTC (permalink / raw)
To: Felix Gu
Cc: Dong Aisheng, Fabio Estevam, Frank Li, Jacky Bai,
Pengutronix Kernel Team, NXP S32 Linux Team, Sascha Hauer,
linux-gpio, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260523-pinctrl-imx-v1-1-73b7cb731351@gmail.com>
On Sat, May 23, 2026 at 12:27 PM Felix Gu <ustc.gu@gmail.com> wrote:
> for_each_child_of_node() holds a reference on the iterator node that
> must be released on early return. imx1_pinctrl_dt_is_flat_functions()
> has two early return paths inside the loop that skip this cleanup.
>
> Replace both loops with the scoped variant so that the reference is
> automatically dropped when the iterator goes out of scope.
>
> Fixes: 63d2059cd665 ("pinctrl: imx1: Allow parsing DT without function nodes")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Patch applied for v7.3!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Krzysztof Kozlowski @ 2026-06-25 7:58 UTC (permalink / raw)
To: Joey Lu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Arnd Bergmann, Catalin Marinas, Jacky Huang,
Shan-Chun Hung, Hui-Ping Chen, Joey Lu, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260625023958.569299-3-a0987203069@gmail.com>
On Thu, Jun 25, 2026 at 10:39:56AM +0800, Joey Lu wrote:
> properties:
> compatible:
> enum:
> - nuvoton,ma35d1-usb2-phy
>
> + reg:
> + maxItems: 1
> +
> "#phy-cells":
> - const: 0
> + const: 1
> + description:
> + The single cell selects the PHY port. 0 selects the OTG port (USB0,
> + shared with DWC2 gadget controller) and 1 selects the host-only port
> + (USB1).
>
> - clocks:
> - maxItems: 1
This is odd, considering that parent does not have clocks. So explain me
this:
1. USB PHY needed clocks.
2. You extend USB PHY to cover second part.
3. That extension for second part means that clocks are not needed.
Really, how? How is it possible in hardware?
> + nuvoton,rcalcode:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 2
You should require two values. I understand that any PHY is optional,
thus you skip the entry, so how would you provide value for PHY1 only?
> + items:
> + minimum: 0
> + maximum: 15
> + description:
> + Resistor calibration trim codes for PHY0 and PHY1 respectively.
> + Each 4-bit value is written to the RCALCODE field in USBPMISCR and
> + adjusts the PHY's internal termination resistance. Both entries are
> + optional; when absent the hardware reset default is used.
>
> - nuvoton,sys:
> - $ref: /schemas/types.yaml#/definitions/phandle
> + nuvoton,oc-active-high:
> + type: boolean
> description:
> - phandle to syscon for checking the PHY clock status.
> + When present, the over-current detect input from the VBUS power switch
> + is treated as active-high. The default (property absent) is active-low.
> + This setting is shared by both USB host ports.
>
> required:
> - compatible
> + - reg
That's ABI break which was not explained in the commit msg - neither
specifying impact nor actually providing reasons why you break ABI.
And honestly, you have no resources here except the address, so now it
is clear that this should be folded into parent. See DTS101 talk slides.
> - "#phy-cells"
> - - clocks
> - - nuvoton,sys
>
> additionalProperties: false
>
> examples:
> - |
> - #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
> + system-management@40460000 {
> + compatible = "nuvoton,ma35d1-reset", "syscon", "simple-mfd";
> + reg = <0x40460000 0x200>;
> + #reset-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
Drop. Keep only child node and make parent binding example complete.
>
> - usb_phy: usb-phy {
> - compatible = "nuvoton,ma35d1-usb2-phy";
> - clocks = <&clk USBD_GATE>;
> - nuvoton,sys = <&sys>;
> - #phy-cells = <0>;
> + usb-phy@60 {
> + compatible = "nuvoton,ma35d1-usb2-phy";
> + reg = <0x60 0x14>;
> + #phy-cells = <1>;
> + };
> };
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v7 04/30] drm/display: scdc_helper: Add HDMI 2.0 scrambling management helpers
From: Maxime Ripard @ 2026-06-25 7:53 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Sandy Huang,
Heiko Stübner, Andy Yan, Daniel Stone, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <2f5ce8eb-ef47-4238-ad68-ce62981a1845@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]
On Sat, Jun 13, 2026 at 04:30:02AM +0300, Cristian Ciocaltea wrote:
> On 6/12/26 4:43 PM, Maxime Ripard wrote:
> > On Tue, Jun 02, 2026 at 01:44:04AM +0300, Cristian Ciocaltea wrote:
> >> +/**
> >> + * drm_scdc_start_scrambling - activate scrambling and monitor SCDC status
> >> + * @connector: connector
> >> + *
> >> + * Enables scrambling and high TMDS clock ratio on both source and sink sides.
> >> + * Additionally, use a delayed work item to monitor the scrambling status on
> >> + * the sink side and retry the operation, as some displays refuse to set the
> >> + * scrambling bit right away.
> >> + *
> >> + * Returns:
> >> + * Zero if scrambling is set successfully, an error code otherwise.
> >> + */
> >> +int drm_scdc_start_scrambling(struct drm_connector *connector)
> >> +{
> >> + struct drm_display_info *info = &connector->display_info;
> >> + struct drm_connector_hdmi *hdmi = &connector->hdmi;
> >> + int ret;
> >> + u8 ver;
> >> +
> >> + if (!hdmi->scrambler_supported) {
> >> + drm_scdc_dbg(connector, "Scrambler not supported, bailing.\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + if (!info->is_hdmi ||
> >> + !info->hdmi.scdc.supported ||
> >> + !info->hdmi.scdc.scrambling.supported) {
> >> + drm_scdc_dbg(connector, "Sink doesn't support scrambling.\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + drm_scdc_dbg(connector, "Enabling scrambling\n");
> >> +
> >> + ret = drm_scdc_readb(connector->ddc, SCDC_SINK_VERSION, &ver);
> >> + if (ret) {
> >> + drm_scdc_dbg(connector, "Failed to read SCDC_SINK_VERSION: %d\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + ret = drm_scdc_writeb(connector->ddc, SCDC_SOURCE_VERSION,
> >> + min_t(u8, ver, SCDC_MAX_SOURCE_VERSION));
> >> + if (ret) {
> >> + drm_scdc_dbg(connector, "Failed to write SCDC_SOURCE_VERSION: %d\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + hdmi->scdc_cb = drm_scdc_monitor_scrambler;
> >> + WRITE_ONCE(hdmi->scrambler_enabled, true);
> >> +
> >> + ret = drm_scdc_try_scrambling_setup(connector);
> >> + if (!ret)
> >> + ret = hdmi->funcs->scrambler_enable(connector);
> >> +
> >> + if (ret) {
> >> + WRITE_ONCE(hdmi->scrambler_enabled, false);
> >> + cancel_delayed_work_sync(&hdmi->scdc_work);
> >> + hdmi->scdc_cb = NULL;
> >> +
> >> + drm_scdc_set_scrambling(connector, false);
> >> + drm_scdc_set_high_tmds_clock_ratio(connector, false);
> >> + }
> >> +
> >> + return ret;
> >> +}
> >> +EXPORT_SYMBOL(drm_scdc_start_scrambling);
> >
> > This is also pretty significantly different than what vc4 implemented. I
> > don't necessarily mind, but claiming that it's functionally equivalent
> > isn't true. I think it would be a much better strategy to turn the vc4
> > code into helpers as is because it's been merged 4 years ago and we know
> > it's solid.
>
> As explained in patch 25, I think there's been a slight misunderstanding of how
> the CRTC reset logic was actually implemented.
You're absolutely right, let me review it again. sorry.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: reset: nuvoton,ma35d1-reset: add simple-mfd and child node support
From: Krzysztof Kozlowski @ 2026-06-25 7:51 UTC (permalink / raw)
To: Joey Lu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Arnd Bergmann, Catalin Marinas, Jacky Huang,
Shan-Chun Hung, Hui-Ping Chen, Joey Lu, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260625023958.569299-2-a0987203069@gmail.com>
On Thu, Jun 25, 2026 at 10:39:55AM +0800, Joey Lu wrote:
> The MA35D1 system-management syscon node hosts the USB PHY register
> block at offset 0x60. To model usb-phy@60 as a DT child of the syscon
> node the binding must allow:
Explain why do you need child node. If you have fixed device @0x60, you do
not need DT child node at all. Compatible implies that child existence.
>
> - simple-mfd as an optional third compatible so the MFD core can
> instantiate child platform devices.
>
> - #address-cells and #size-cells (each const: 1) so child nodes can
> carry a reg property.
>
> - An open child-node pattern (patternProperties "^.*@[0-9a-f]+$")
> to pass dt-schema validation.
No. Do not explain what you did - we can read the diff. You must explain
WHY you are doing that.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> .../bindings/reset/nuvoton,ma35d1-reset.yaml | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
> index 3ce7dcecd87a..1fda7e8f4b5d 100644
> --- a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
> +++ b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
> @@ -19,6 +19,8 @@ properties:
> items:
> - const: nuvoton,ma35d1-reset
> - const: syscon
> + - const: simple-mfd
> + minItems: 2
>
> reg:
> maxItems: 1
> @@ -26,6 +28,16 @@ properties:
> '#reset-cells':
> const: 1
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
> +patternProperties:
> + "^.*@[0-9a-f]+$":
This must be specific.
> + type: object
Missing ref and additionalProps. Please look at other simple-mfd.
> +
> required:
> - compatible
> - reg
> @@ -43,4 +55,3 @@ examples:
> #reset-cells = <1>;
> };
> ...
> -
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 0/3] KVM: arm64: nv: Shadow ptdump fixes
From: Wei-Lin Chang @ 2026-06-25 7:47 UTC (permalink / raw)
To: Itaru Kitayama
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <ajty6I7ZqodP4ous@sm-arm-grace07>
Hi Itaru,
On Wed, Jun 24, 2026 at 03:02:16PM +0900, Itaru Kitayama wrote:
> Hi Wei-Lin,
>
> On Tue, Jun 23, 2026 at 03:24:40PM +0100, Wei-Lin Chang wrote:
> > Hi,
> >
> > This series fixes two bugs regarding the shadow ptdump debugfs files.
> > It is based on kvmarm/fixes + [1] ("KVM: arm64: Reassign nested_mmus
> > array behind mmu_lock").
> >
> > The first is a UAF. A nested mmu can still be accessed when the debugfs
> > file is being closed, after the nested mmus are freed. I can observe
> > this by turning on CONFIG_KASAN and closing the file after the VM is
> > destroyed. To fix this, mmu access is avoided in the .release()
> > callback.
> >
> > The second is sleeping in atomic context, found by Itaru [2] (thanks).
> > Originally the code creates a debugfs file whenever a context gets bound
> > to an s2 mmu instance, and deletes it when it gets unbound. Problem is
> > the bind/unbind is done with the mmu_lock held, and debugfs file
> > creation and deletion can sleep. This is observable by using
> > CONFIG_DEBUG_ATOMIC_SLEEP. The new approach is just have one debugfs
> > file for each s2 mmu instance, and show their state + information when
> > requested, which can be invalid, or VTCR + VTTBR + whether s2 enabled +
> > ptdump.
> >
> > The fixes are tested with CONFIG_PROVE_LOCKING,
> > CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_KASAN.
> >
> > Thanks!
> > Wei-Lin Chang
> >
> > [1]: https://lore.kernel.org/kvmarm/aiKIVVeIr1aAB1yp@v4bel/
> > [2]: https://lore.kernel.org/kvmarm/aiuF0KSvvv-ZozI1@sm-arm-grace07/
> >
> > Wei-Lin Chang (3):
> > KVM: arm64: nv: Print nested mmu info in kvm_ptdump_guest_show()
> > KVM: arm64: ptdump: Store both mmu and kvm pointers in
> > kvm_ptdump_guest_state
> > KVM: arm64: nv: Move to per nested mmu ptdump files
> >
> > arch/arm64/kvm/nested.c | 16 +++++++++++-----
> > arch/arm64/kvm/ptdump.c | 29 +++++++++++++++++++----------
> > 2 files changed, 30 insertions(+), 15 deletions(-)
> >
> > --
> > 2.43.0
>
> At end of the execution of the shadow stage 2 selftest I see:
>
> [ 569.228448] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
> [ 569.228712] Mem abort info:
> [ 569.229091] ESR = 0x0000000096000046
> [ 569.229165] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 569.229213] SET = 0, FnV = 0
> [ 569.229244] EA = 0, S1PTW = 0
> [ 569.229276] FSC = 0x06: level 2 translation fault
> [ 569.229312] Data abort info:
> [ 569.229341] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
> [ 569.229369] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> [ 569.229397] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 569.229458] user pgtable: 4k pages, 48-bit VAs, pgdp=000000006dce3000
> [ 569.229545] [0000000000000098] pgd=0800000048b63403, p4d=0800000048b63403, pud=0800000048b7f403, pmd=0000000000000
> ** replaying previous printk message **
> [ 569.229545] [0000000000000098] pgd=0800000048b63403, p4d=0800000048b63403, pud=0800000048b7f403, pmd=0000000000000000
> [ 569.236428] Internal error: Oops: 0000000096000046 [#1] SMP
> [ 569.237974] Modules linked in:
> [ 569.238644] CPU: 1 UID: 0 PID: 824 Comm: shadow_stage2 Not tainted 7.1.0-rc4+ #59 PREEMPT(full)
> [ 569.239139] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2ubuntu0.7 11/27/2025
> [ 569.239632] pstate: 61402009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> [ 569.240004] pc : down_write+0x50/0xe8
> [ 569.240450] lr : down_write+0x34/0xe8
> [ 569.240696] sp : ffff80008252ba20
> [ 569.240965] x29: ffff80008252ba20 x28: 0000000000000000 x27: 0000000040000200
> [ 569.241346] x26: 0000000000000200 x25: ffffd1bf542891a0 x24: 0000000000000001
> [ 569.241625] x23: 0000000000000098 x22: ffff000000637480 x21: ffffd1bf57abc518
> [ 569.241985] x20: 0000000000000000 x19: 0000000000000098 x18: ffff80008253d090
> [ 569.242261] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [ 569.242568] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> [ 569.242904] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffd1bf5532388c
> [ 569.243335] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
> [ 569.243638] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
> [ 569.244056] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000
> [ 569.244507] Call trace:
> [ 569.244778] down_write+0x50/0xe8 (P)
> [ 569.245094] __simple_recursive_removal+0x68/0x230
> [ 569.245322] simple_recursive_removal+0x20/0x50
> [ 569.245498] debugfs_remove+0x64/0xc0
> [ 569.245655] kvm_nested_s2_ptdump_remove_debugfs+0x20/0x48
> [ 569.245960] kvm_arch_flush_shadow_all+0x4c/0xc0
> [ 569.246100] kvm_mmu_notifier_release+0x3c/0x90
> [ 569.246344] mmu_notifier_unregister+0x68/0x148
> [ 569.246594] kvm_destroy_vm+0x130/0x2d8
> [ 569.246829] kvm_device_release+0xf8/0x170
> [ 569.246969] __fput+0xf4/0x350
> [ 569.247147] fput_close_sync+0x4c/0x138
> [ 569.247291] __arm64_sys_close+0x44/0xa0
> [ 569.247493] invoke_syscall+0xa8/0x138
> [ 569.247727] el0_svc_common.constprop.0+0x4c/0x140
> [ 569.248059] do_el0_svc+0x28/0x58
> [ 569.248236] el0_svc+0x48/0x218
> [ 569.248420] el0t_64_sync_handler+0xc0/0x108
> [ 569.248690] el0t_64_sync+0x1b4/0x1b8
> [ 569.249737] Code: b9000820 d503201f d2800000 d2800021 (c8e07e61)
> [ 569.250624] ---[ end trace 0000000000000000 ]---
> [ 569.251589] note: shadow_stage2[824] exited with preempt_count 1
> [ 569.253677] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
> [ 569.254391] Mem abort info:
> [ 569.254416] ESR = 0x0000000096000046
> [ 569.254436] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 569.254479] SET = 0, FnV = 0
> [ 569.254493] EA = 0, S1PTW = 0
> [ 569.254506] FSC = 0x06: level 2 translation fault
> [ 569.254522] Data abort info:
> [ 569.254530] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
> [ 569.254544] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> [ 569.254559] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 569.254574] user pgtable: 4k pages, 48-bit VAs, pgdp=000000006dce3000
> [ 569.254602] [0000000000000098] pgd=0800000048b63403, p4d=0800000048b63403, pud=0800000048b7f403, pmd=0000000000000000
> [ 569.254709] Internal error: Oops: 0000000096000046 [#2] SMP
> [ 569.257747] Modules linked in:
> [ 569.258124] CPU: 1 UID: 0 PID: 824 Comm: shadow_stage2 Tainted: G D 7.1.0-rc4+ #59 PREEMPT(full)
> [ 569.258642] Tainted: [D]=DIE
> [ 569.258862] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2ubuntu0.7 11/27/2025
> [ 569.259232] pstate: 60402009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 569.259549] pc : down_write+0x50/0xe8
> [ 569.259814] lr : down_write+0x34/0xe8
> [ 569.259960] sp : ffff80008252b310
> [ 569.260175] x29: ffff80008252b310 x28: 0000000000000000 x27: 0000000040000200
> [ 569.260507] x26: 0000000000000200 x25: ffffd1bf542891a0 x24: 0000000000000001
> [ 569.260891] x23: 0000000000000098 x22: ffff000000637480 x21: ffffd1bf57abc518
> [ 569.261278] x20: 0000000000000000 x19: 0000000000000098 x18: ffff80008253d138
> [ 569.261652] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [ 569.262180] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> [ 569.262572] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffd1bf5532388c
> [ 569.263299] x8 : ffff80008252b508 x7 : 0000000000000000 x6 : 0000000000000000
> [ 569.263950] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
> [ 569.264428] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000
> [ 569.264799] Call trace:
> [ 569.265039] down_write+0x50/0xe8 (P)
> [ 569.265441] __simple_recursive_removal+0x68/0x230
> [ 569.265817] simple_recursive_removal+0x20/0x50
> [ 569.266132] debugfs_remove+0x64/0xc0
> [ 569.266411] kvm_nested_s2_ptdump_remove_debugfs+0x20/0x48
> [ 569.266782] kvm_arch_flush_shadow_all+0x4c/0xc0
> [ 569.267059] kvm_mmu_notifier_release+0x3c/0x90
> [ 569.267564] __mmu_notifier_release+0x88/0x2a0
> [ 569.267736] exit_mmap+0x430/0x490
> [ 569.267943] __mmput+0x3c/0x178
> [ 569.268068] mmput+0xa4/0xd8
> [ 569.268221] do_exit+0x274/0xb00
> [ 569.268335] make_task_dead+0x98/0x1f0
> [ 569.268634] die+0x194/0x1a0
> [ 569.268893] die_kernel_fault+0x1d0/0x3c0
> [ 569.269139] __do_kernel_fault+0x280/0x290
> [ 569.269348] do_page_fault+0x128/0x7d8
> [ 569.269550] do_translation_fault+0x74/0xc0
> [ 569.269767] do_mem_abort+0x50/0xd0
> [ 569.269945] el1_abort+0x44/0x80
> [ 569.270122] el1h_64_sync_handler+0x54/0xd0
> [ 569.270306] el1h_64_sync+0x80/0x88
> [ 569.270683] down_write+0x50/0xe8 (P)
> [ 569.270997] __simple_recursive_removal+0x68/0x230
> [ 569.271217] simple_recursive_removal+0x20/0x50
> [ 569.271704] debugfs_remove+0x64/0xc0
> [ 569.271948] kvm_nested_s2_ptdump_remove_debugfs+0x20/0x48
> [ 569.272212] kvm_arch_flush_shadow_all+0x4c/0xc0
> [ 569.272510] kvm_mmu_notifier_release+0x3c/0x90
> [ 569.272731] mmu_notifier_unregister+0x68/0x148
> [ 569.272960] kvm_destroy_vm+0x130/0x2d8
> [ 569.273210] kvm_device_release+0xf8/0x170
> [ 569.273490] __fput+0xf4/0x350
> [ 569.273748] fput_close_sync+0x4c/0x138
> [ 569.274023] __arm64_sys_close+0x44/0xa0
> [ 569.274289] invoke_syscall+0xa8/0x138
> [ 569.274560] el0_svc_common.constprop.0+0x4c/0x140
> [ 569.274838] do_el0_svc+0x28/0x58
> [ 569.275066] el0_svc+0x48/0x218
> [ 569.275321] el0t_64_sync_handler+0xc0/0x108
> [ 569.275556] el0t_64_sync+0x1b4/0x1b8
> [ 569.275844] Code: b9000820 d503201f d2800000 d2800021 (c8e07e61)
> [ 569.276068] ---[ end trace 0000000000000000 ]---
> [ 569.277042] note: shadow_stage2[824] exited with preempt_count 1
> [ 569.277234] Fixing recursive fault but reboot is needed!
>
> the kernel is based off of kvmarm/fixes, applied your series and
> Hyunwoo's patch as well. Could you take a look at this?
Thanks once more!
This is caused by kvm_destroy_vm_debugfs() being called before
mmu_notifier_unregister() in kvm_destroy_vm(). In mmu notifier release I
remove each nested mmu's debugfs file, but all is removed priorly, so of
course UAF and bad dereferences happen.
I didn't catch this because mmu notifier release can also be called
independently before kvm_destroy_vm(). It looks like in my case kvmtool
doesn't close the VM fd on normal exit, so at process exit mm_struct
goes away before kvm, triggering mmu notifier release to free the nested
mmus and the shadow ptdump files before VM destruction. Hence when
kvm_destroy_vm(), the bug is avoided.
I don't see a way out with this per-mmu file scheme. The core issue is
mmus have a different lifetime than the VM's debugfs directory, and
both's removal can happen in parallel, i.e. the VM debugfs directory
can be removed anytime we are in mmu notifier release freeing the mmus
and their shadow ptdump files.
The original idea of just having one "nested_mmus" file could be sound,
we'll just have to take the mmu_lock to check if mmu->pgt is still alive
when getting information.
Thanks,
Wei-Lin Chang
>
> Thanks,
> Itaru.
>
> >
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Krzysztof Kozlowski @ 2026-06-25 7:46 UTC (permalink / raw)
To: Jonas Karlman
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Diederik de Haas, devicetree, linux-rockchip,
linux-usb, linux-arm-kernel, linux-kernel
In-Reply-To: <20260624192726.781864-2-jonas@kwiboo.se>
On Wed, Jun 24, 2026 at 07:27:24PM +0000, Jonas Karlman wrote:
> The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
> being enabled, or the system may freeze when registers are accessed.
>
> Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
> constraint as RK3588, also extend the EHCI constraint to include RK3588
> to match similar requirements of RK3588.
>
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> ---
> Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
> next patch make use of these new compatibles and adds the missing
> clk_usbphy1_480m clock references.
>
> Existing DTs for RK3588 have contained the required four clocks since
> the initial addition of the EHCI/OHCI nodes.
>
> Changes in v2:
> - Include rockchip,rk3588-ehci in the EHCI constraint
> - Make clocks prop required for EHCI and OHCI
> ---
> .../devicetree/bindings/usb/generic-ehci.yaml | 14 ++++++++++++++
> .../devicetree/bindings/usb/generic-ohci.yaml | 7 ++++++-
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> index 55a5aa7d7a54..a39f01e740b1 100644
> --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> @@ -52,6 +52,7 @@ properties:
> - ibm,476gtr-ehci
> - nxp,lpc1850-ehci
> - qca,ar7100-ehci
> + - rockchip,rk3568-ehci
> - rockchip,rk3588-ehci
> - snps,hsdk-v1.0-ehci
> - socionext,uniphier-ehci
> @@ -186,6 +187,19 @@ allOf:
> required:
> - clocks
> - clock-names
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3568-ehci
> + - rockchip,rk3588-ehci
> + then:
> + properties:
> + clocks:
> + minItems: 4
> + required:
> + - clocks
This is ABI break for RK3588, so your commit msg should also mention
that RK3588 is not working for example. Otherwise you provided rationale
only for breaking RK3568 ABI.
Same for OHCI part.
Best regards,
Krzysztof
^ 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